1. Project Management Chris Imondi Ejvin Berry FIRSTFare – October 15th, 2011
2. What is a Project? One goal + some parameters: Scope Time Cost Quality Risk
3. Project SuccessRequirements to survive the process: Happy customers On time deliverables On budget Optimistic investors Team cohesionCongratulations… but if you have problems “surviving”, you’ll have problems “thriving” as an engineering organization…
4. Project Successes Customers who generate new requirements Under budget Innovation Investors are paid Team talent pool intensifies Leftover energy? Diversify: Create community infrastructure like FLL teams, or academic mentorship
5. Project Manager Primary Roles: Build a team (organize existing resources) Maintain/Analyze data and schedule Schedule resources Organize capital (money + manpower) Manage conflict (interference) Review work – Initiate Design Reviews
6. What is Project Management? Novations Group, Inc., "Tools and Techniques of Project Management, v6.1"
7. Initiation Occurs at the start of the project Contains clear project goals and parameters Often involves the customer Your big chance to control scopeInitiation will take place between 5am and midnight on Kickoff Day.
8. Planning This is the opportunity to modify: Team structure Tactics – Define “envelopes” Schedule: Chronological schedules Cost schedules – when to buy? Acceptable risks – Weigh your skills and your needs with your “wants”
9. Early vs. Late Project Planning Unexpected problems late in development kill projects Time spent up front to understand the requirements, anal yze, and correctly design a solution saves big in the end
10. Executing Do what you planned. Do only what you planned. Feedback and repeat.Note: It is important to document activities during the execution phase.
11. Monitoring and Controlling Gather feedback via Design Review Sort feedback Make decisions regarding remaining resources Manage schedule changes
12. Closing A project is closed when a successful Final Design Review is held between design, management and the customer. This is a formal process in which you sell your product to the customer. Which projects need to close? Minor components vs. Entire robots Who is your customer?
13. Now it’s time to manage… If you were looking for someone to spell it out for you; here’s your chance…
14. First: Team Structure Match people with their strengths It may be helpful, particularly for rookie teams, to develop a skills matrix. This will help identify training needs, or where you need to get more outside help (a trainer, or a hired gun?) Develop an organization chart, matching team members to their responsibilities.
15. Second: Plan the work… Work Breakdown Structure (or WBS) = Everything you want to do on the project Determine the form and function of every part, and what they all do for you (Functional Efficiency Technique) Also any related work – fundraising, major events, support equipment This ultimately becomes your project plan, as detailed as you choose to plan and schedule it. Match with your team structure.
16. Plan the work (cont.). . . Estimate each item or system using a Resource Loading Diagram along with a Network Diagram: How much time (work hours) do you think it will take? How many people do you have? How much time do they have? How many days/ hours will each item take? Where are you short handed? Make sure you aren’t double booking people.
17. Develop a Project Schedule Make a simple project schedule, easy to read and status. Stick to your plan Monitor progress – fill in the bars, but not if they are not done. Adjust on the fly – you may have to give up some goals, or shift more people to key tasks that are falling behind. Enlist more experts? Keep everyone productive, but don’t forget this is all fun! Communicate!
18. Third: Execute - do some work
19. Fourth: Design Reviews Plan and schedule design reviews Every day, if required, until design completion Document (as specifically as possible) how subsystems will work together and connect as they are designed, built and integrated Check your interfaces in the reviews – if there is change, it must be fully investigated, understood and agreed to
20. Fifth: Risk Management Also known as “what-ifs” Leave a little time for disasters and unforeseen details Testing is essential to reduce risk Set goals for features or functions that would be “nice to have” If there is insufficient time, the project will still be successful without them
21. Risk Management (cont.) FMEA (Failure Modes and Effects Analysis) Consider system components Identify symptoms of failure Identify root cause Predict consequences to other sub- systems Rank failure modes by severity (1,2,3) Rank failure modes by probability (1,2,3) Example FMEA.