First fare 2011 project-management
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


First fare 2011 project-management






Total Views
Views on SlideShare
Embed Views



2 Embeds 4 2 2


Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

First fare 2011 project-management Presentation Transcript

  • 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.
  • 22. References PMI PMBOK Guide Contact:  Chris Imondi,  Ejvin Berry,
  • 23. Questions ????