Project Management

Chris ImondiEjvin Berry

FIRSTFare – October 15th, 2011

What is a Project? One goal + some parameters:

Scope Time Cost Quality Risk

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…

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

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

Novations Group, Inc., "Tools and Techniques of Project Management, v6.1"

What is Project Management?

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.

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”

Early vs. Late Project Planning Unexpected

problems late in development kill projects

Time spent up front to understand the requirements, analyze, and correctly design a solution saves big in the end

Executing Do what you planned. Do only what you planned. Feedback and repeat.

Note: It is important to document activities during the execution phase.

Monitoring and Controlling Gather feedback via Design Review Sort feedback Make decisions regarding remaining

resources Manage schedule changes

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?

Now it’s time to manage…

If you were looking for someone to spell it out for you; here’s your chance…

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.

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.

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.

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!

Third: Execute - do some work

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

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

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.

References

MBA.com PMI PMBOK Guide

Contact: Chris Imondi, chris.m.imondi@boeing.com Ejvin Berry, ejvin.m.berry@boeing.com

Questions ????