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