2. Project Management
Chris Imondi
Ejvin Berry
FIRSTFare – October 15th, 2011

3. What is a Project?
 One goal + some parameters:
 Scope
 Time
 Cost
 Quality
 Risk

4. Project Success
Requirements to survive the process:
 Happy customers
 On time deliverables
 On budget
 Optimistic investors
 Team cohesion
Congratulations… but if you have problems
“surviving”, you’ll have problems “thriving”
as an engineering organization…

5. 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

6. 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

7. What is Project Management?
Novations Group, Inc., "Tools and Techniques
of Project Management, v6.1"

8. Initiation
 Occurs at the start of the project
 Contains clear project goals and parameters
 Often involves the customer
 Your big chance to control scope
Initiation will take place between 5am and
midnight on Kickoff Day.

9. 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”

10. 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

11. Executing
 Do what you planned.
 Do only what you planned.
 Feedback and repeat.
Note: It is important to document activities
during the execution phase.

12. Monitoring and Controlling
 Gather feedback via Design Review
 Sort feedback
 Make decisions regarding remaining
resources
 Manage schedule changes

13. 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?

14. Now it’s time to manage…
 If you were looking for someone to
spell it out for you; here’s your
chance…

15. 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.

16. 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.

17. 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.

18. 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!

19. Third: Execute - do some work

20. 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

21. 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

22. 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.

23. References
 MBA.com
 PMI PMBOK Guide
 Contact:
 Chris Imondi, chris.m.imondi@boeing.com
 Ejvin Berry, ejvin.m.berry@boeing.com

24. Questions ????