Adding More People Makes Your Project Late
From the pmStudent Blog
by Josh Nankivel
Ranting and raving about project management and systems engineering.
Recent Posts
The Problem with Project Management
The Problem with Project Management
The Problem with Project Management
LinkedIn Recommendations Are Easy
The Catch-22 of Project Management Certification and Experience
Categories
Agile,
Career Development,
Certification,
Change Management,
Communications Management,
Cost Management,
Documentation,
Earned Value Management,
Education,
Integration and Test,
Kanban,
Leadership,
Lean,
Lessons Learned,
Methodology,
Misc,
Multitasking,
New Project,
Operations,
Planning,
PMP,
Productivity,
Professional Development,
Project Estimation,
Project Leadership,
Quality,
Requirements Management,
Risk Management,
Schedule Management,
Scope Management,
Software,
Systems Thinking,
Tools,
Video,
Work Breakdown Structures (WBS)
Date
One of the things I'm constantly surprised by are project managers and writers who seem to ignore The Mythical Man-Month and Brooks' Law.
"adding manpower to a late software project makes it later" -Fred Brooks
Don't Call People "Resources"
They are people. They make up teams.
I've been guilty of this, but maybe calling people "resources" in your schedules and plans has a negative impact.
People aren't widgits, and teams aren't perfect systems where you can add another widget and get everything done that much more quickly.
I think using the term "resources" instead of "people" may allow tool-savvy project managers to get more and more detached from the reality of their project team and the work to be done.
You Can't Add People Like Widgets
I hear it more often than I would like.
Project managers see a shortfall in the amount of staffing available on a particular part of a project, which is going to cause missing a milestone date.
Then the exclamation "I can just take .2 of an FTE from John Doe down the hall and it all works out on paper!" (FTE = Full Time Equivalent)
Brilliant.
You know, there are some cases where you can do that. Perhaps the person has previous experience with the product your team is developing, or the type of work is generic enough that someone from outside the team can come in and pick it up without training.
But more often this is a big mistake. You are going to leach out .2 FTE from your current team (maybe more with multiple people helping the new guy) in order to get him up to speed.
So unless you are going to have a long-term commitment from a new team member and have considered the time and effort involved with bringing someone up to speed, their lowered productivity level until they are fully immersed, etc. don't even think about adding new staff.
Especially not temporary staff.
Posted on: October 21, 2011 05:19 PM |
Permalink
Comments (4)
Please login or join to subscribe to this item
Wai Mun Koo
PMO Director| Intergraph PP&M
Singapore, Singapore
Josh, I guess you have pointed it out well that this depends much on the nature of the job if it requires more brains or muscles; or in other words, how much time and effort are needed to get the extra helpers up to speed on what they need to do. Obviously this may work out well for simple tasks like data checking (which just needs eye-balling and coordinating with people) but for some more complex tasks like data analyzing it just won't work.
Josh Nankivel
Engineering Project Manager| Apple
Sioux Falls, Sd, United States
Thanks Wai. In my project environment, it really doesn't work to try to move people around for short-term attempts at managing schedule. The business rules and the code to implement the business rules are just too complex and take too much time to get someone new up to speed. So unless it's a long-term commitment where we can really bring someone into the fold of the team, I tend to resist having additional staff.
Long term, dumb down task or specialized (but generic) task. That's where it mostly pays off. That being said, when a project is late, you often do have some of those 'lying' around. My experience is that it (can) pay off for mid to large size project but small project are usually too specialized. YMMV
Josh Nankivel
Engineering Project Manager| Apple
Sioux Falls, Sd, United States
Thank you for the comment and your insight Yvon!
Please Login/Register to leave a comment.
|
"The most incomprehensible thing about the universe is that it is comprehensible."
- Albert Einstein
|