Keeping Kids Alive – Team 2

Photo TeamPhoto Project Description

Our team sought to partner with Feed My  Starving Children (FMSC), an organization  that ships packets of life-saving food to  malnourished and impoverished families and  orphans all over the world. The best way for  our team to support their cause was to  provide the three things they always need:  donations, volunteers, and awareness. To  facilitate this, we partnered with Team 3  (who was also supporting FMSC) and  planned a joint fundraising, volunteering, and social awareness campaign.

We looked to deliver on all three fronts by hosting a major multi-faceted event on August 8th, which included a red carpet event with a photographer (to use for our post-event social media push), a fundraising food basket raffle, a two-hour packing event, and a fundraising dinner immediately following (with a contribution equal to 15% of the check). We also conducted an ongoing fundraising drive online with the support of FMSC during the length of the class, and supported both the fundraising and service efforts with a comprehensive social media campaign that included Facebook, Instagram, Twitter, and email/phone calls/face-to-face interactions.

FMSC-logo 10.47.46 AM

About FMSC

Founded in 1987, FMSC is a national non-profit organization, based in Minnesota with three locations in the Chicago-land area. Their mission statement is to “Feed God’s Starving Children Hungry in Body and Spirit.” and their goal is to provide packed meals to needy children internationally. Since their founding, they have become a well-established organization. They have earned a four-star rating from Charity Navigator for the last ten years, and allocate 92% of their donations to the feeding process.

How we chose FMSC

One of our team members, Mark, works for a company that has a close partnership with FMSC. He took the lead to contact FMSC and spoke with Lisa at FMSC’s development department to begin partnership efforts. We were able to utilize some of their resources to start our social media campaign and were able to utilize a FMSC website portal for collecting donations and for educating our friends and families about FMSC.

Project Objectives

Because of our partnership with Team 3, we maintained both team and combined goals. We broke out our goals as followed:

  • Fundraising goal: $350 per team member or $2,450; collective goal of $5,000
  • Volunteer goal: 7 attendees per team member (49 volunteers), collective goal of 91
    • Stretch goal: 10 attendees per team member (70 volunteers), collective goal of 130
  • Packing (base) goal: 10,584 meals packed, collective goal of 19,656 (average 216 meals per volunteer)
  • Kids fed for one year: 29 kids, collective goal of about 54 kids
  • Awareness goal: 2 communications per team member per week, or 98 communications total; collective goal of 182
  • Survey results: Solicit feedback from at least 25% of our event attendees to determine effectiveness of our program

Screen Shot 2015-08-16 at 4.51.50 PM

Project Analysis

Several group members were able to generate volunteer interest for a day other than August 8th. Given the numbers involved and the relative ease by which volunteerism could be accommodated, three micro-events were held on July 16th, July 27th, and July 30th. These micro-events netted 33 volunteers and 7,128 meals packed. Better still, these micro-events were used to generate further interest in the August 8th event day by serving as a concrete demonstration of the good that can be done by volunteering with FMSC.

After weeks of working tirelessly to pursue our goals, the day of the event eclipsed even our wildest expectations. In addition to the micro-events leading up to the 8th, both teams together registered 157 volunteers for the service event, or an average of 12 volunteers per person. Our team specifically registered 104 people for the event, or an average of just under 15 volunteers per person. While it was impossible for us to get an exact attendance count for our group (a family not associated with our project reserved space for twenty), we had no fewer than 144 volunteers show for the service event.

Photo GiftBasketTable

 Volunteers arriving early to the service event were  treated to our red carpet photo session (courtesy of  Team 3, and full marks for a job very well done  there). They also had an opportunity to purchase  raffle tickets for our two-chance raffle, which was an  incredibly popular draw. And, of course, each of us  had the opportunity to network and verbally speak to  what we were about to accomplish.

 

Photo PackingKIDReachScoop3withKit

Two exhausting hours later, our volunteers packed an amazing 33,188 meals, which is enough to feed 90 kids for a year. We were also able to collect survey feedback from 53 people, or 37% of total attendees. Following the event, we moved over to Jimmy’s Charhouse, where we expected to have about 64 guests attend. Instead of 64, we had a whopping 94 people show. The raffle was drawn following dinner, a thank-you cake was shared with the group, and Jimmy’s Charhouse cut a check of $250 to FMSC.

Photo Dinner1

Overall, we surpassed every project objective  we set for ourselves which was a pleasant  surprise. Our group’s collaboration with Team 3  helped diversity our resources to create a better  day-of experience for all of our volunteers. We  raised $3,950 in donations and another $5,324 in volunteer time value as assessed by FMSC.

 

 

 

Lessons Learned

  1.  Scope-Creep: First and foremost, our group  learned the trial and tribulations of managing  scope-creep. From the beginning we had difficulty agreeing on the scope for the project and once it was set we had difficulties staying with the set scope. Without an official project sponsor, it can be hard to work out differences in opinions within the group about the direction of the project. Opportunities presented themselves for unique fundraising events, and the group had to workout amongst ourselves what best fit into our project’s scope.
  2. Communication: Managing communication during the project amongst our 7 member group and then with the 6 additional member of Team 3 became a challenge. We used traditional methods like email, conference calls, and text messaging to communicate, but due to the volume of communications things got lost in the mix. Other teams used communication management applications that could have benefited our group. Communication amongst 13 people is never easy, but a service like Asana could have served as a hub to organized and distribute information.
  3. Risk Management: We found that our risk register addressed risk mitigation for what to do if too few of people RSVP/attend the events, but did not well enough account for too many RSVP/attend. The number of guests who attending the fundraising dinner surprised us all and left us scrambling a bit. Thankfully our venue was very accommodating and handled the issue quickly. In retrospect, we would like to have addressed this potential risk ahead of time.

Advice

In addition to the lessons learned above we have the following advice for future project teams:

  1. Determine what your project will consist of early and stick with it. The sooner you cement your plan, the sooner you can focus on fundraising and outreach. Uncertainty leads to limited time executing then plan.
  2. Appoint a project manager. Previous students gave this advice to us during the first class and it was invaluable. With large teams that are spread out around the Chicago-land area and all have numerous other commitments, a strong project manager is crucial to keeping the momentum going. Mark was our project manager and he did a fantastic job of motivating and organizing the group and we do not feel as though we would have been as successful without his great leadership.
  3. Utilized all of our friends, family, and coworkers to the best of your ability. We were continually surprised how much our networks were willing to give (both of their time and money) if you just simply ask.

Photo RecapMarkClosingComments

Trek Bicycle: How PM software can change an entire company

Trek Bicycle Corporation is a major multinational bicycle manufacture based in Waterloo, Wisconsin. Up until recently, different divisions used varying software programs and communication styles to perform its project management. This lead to constant delays in getting new products to market as well as missed sales due to stocking out at key times. When Kris Lamp took on the newly created position of program manager, she initiated a search for a unified project management software suite. There was a clear organizational need for a product that would allow for seamless communication amongst divisions around the globe.

The company chose AtTask (which in early 2015 rebranded as Workfront) as their Enterprise PMIS solution. Under Lamp’s guidance, the implementation was kept simple. They opted for a software-as-a-service (SaaS) model, which transferred the support risks onto the vendor. Also, the company opted for minimal customization to the PMIS and chose to implement the rollout to one group at a time. This slow start allowed for the project team to work out any issues as they came up and before larger scale implementations. This mitigated the risk of project failure by starting simple and allowing time in the schedule for early rework.

Trek and the PMIS project management team heavily relied on management buy-in to help with employee adoption of the new system. Because the PMIS was eventually rolled out company-wide in many different countries, the project management team utilized local managers to encourage and/or mandate employees to adopt the new PMIS. In return, the PMIS project team kept manager notified of changes far in advance and conveyed why and how the changes would happen. The overall consensus from employees was that the PMIS not only helped with daily work, but also helped them feel more connected with the company’s work.

The PMIS implementation was almost immediately considered a success. End-user buy-in was high and due to their slow but steady implementation, they were able to begin to introduce customization. On-time delivery rates improved 20 percent, which directly benefited the bottom line.   A few years after implementation, 800 projects were being managed using the PMIS. These projects were being managed much more smoothly than far fewer projects the company had prior to the implementation.

Lamp credits the PMIS’s implementation success to decisions made early on by the project team. Choosing a vendor that had an off-the-shelf product that fit most of their needs and was able to provide support alleviated much of the early risk of failure. By using a slow and careful implementation, group by group, change requests were minimal and easy to handle. Most importantly, the team was sure to provide ample advanced communication to managers about the software. This allowed managers to educate employees on why the change was happening and why it was so important to the company. Overall, the PMIS took Trek’s project management from an ineffective and redundant process that frequently went over schedule and budget, to a transparent and seamless linking of divisions.

Does your company utilize a PM software suite?  If so, which product do they use and what is your opinion of it?

Overby, S. (2014) Trek Bicycle Rides Project Management Tool to Efficiency. CIO Magazine, retrieved 7/23/15 from http://www.cio.com/article/2377427/project-management/trek-bicycle-rides-project-management-tool-to-efficiency.html.

The Art and Science of IT Project Planning

Software projects face a unique set of challenges when it comes to scope estimating and this is especially true for new software developments. Research has found that poor cost and schedule estimates are much more detrimental to software projects than any other problem. Typically, estimates are based on historical project information and/or expert opinion, which can be more of an art than a science. The author, William Roetzheim, suggests a more systematic approach to planning estimates for new software projects using research-based techniques.

Based on his experience with software projects, Roetzheim suggests companies take an approach similar to that found in the PMBOK when it comes to life cycle cost estimating accuracies. Initial estimations should be within +/- 50% of the actual cost and the budget should continue to be refined as the project’s requirements are more fully understood.

Screen Shot 2015-08-02 at 3.47.37 PM

The first step to estimate scope is to determine metric used as a measure of scope. In software there are numerous options, but the most common is the number of source lines of code (SLOC), which is the number lines of code written by humans and is usually given as thousands of SLOC (KSLOC).

To determine the number SLOC, you can use one of two options: the direct estimating approach and the function points (FPs) with backfiring approach. Using the direct estimating approach, you break the project down into modules and use multiple expert opinions to estimate the number SLOC’s per module. This is called a Program Evaluating and Reviewing Technique (PERT) calculation and is done by obtaining optimistic, pessimistic, and most likely values. The most likely value is weighted times 4 and the mean and standard deviation are calculated and used to create an estimate with a high level of accuracy.

The FPs with backfiring approach uses the estimate of the number of logical internal tables and external inputs, outputs, interface files, and queries to estimate the number of ways the program must interact with the users. Then you multiply the raw data by its FP conversation factor to fund the number of FPs.

Screen Shot 2015-08-02 at 4.43.29 PM

Then using backfiring you convert the FPs to SLOC using the function point for the applicable language.

Screen Shot 2015-08-02 at 4.43.43 PM

Once you have estimated the number of KSLOC, you take that number and multiply it by the effort required per KSLOC to find the estimate for the project. Researchers have come up with estimates for the effort required per KSLOC based upon different project types. For smaller projects, you would multiply the number of KSLOC by the productivity factor of the applicable project time to find the number of person-months the project requires.

Screen Shot 2015-08-02 at 4.11.04 PM

Since research has found that large projects tend to be less productive due to increased time spent communicating and coordinating, you must apply a penalty factor to the above calculation for larger projects. The calculation for the larger project would then = Productivity Factor * KSLOC^Penalty Factor.

Screen Shot 2015-08-02 at 4.11.15 PM

The author argues that the calculation above will deliver a reliable person-months estimate feeds into the project’s schedule and budget and that it should continue to be managed as the project moves forward in its lifecycle.

While the author’s presents his methods for estimating scope for a software project, he does make any recommendations on how to utilize them. If your company conducts software projects, does it use SLOC when estimating? Is there a specific process used to calculate time requirements and how does it compare to the process suggested by the author?

Roetzheim, W. (2005) Estimating and Managing Project Scope for New Development. Journal of Defense Software Engineering, 4-7.

http://static1.1.sqspcdn.com/static/f/702523/9277557/1288927629910/200504-Roetzheim.pdf?token=Iy0EhkuVC%2Fp4nH9ybNkoKNjsICw%3D