Man-hour isn't a fixed size entity

by Rasmus Hvidberg Josiassen 7. January 2012 15:54

When a project-manager (and managers at large) takes a look at his project plan and realizes that deadlines are looming and the graphs on the burn-down aren’t burning at the right pace, he has three handles to pull. He can move the deadlines, he can lower the scope of the project or he can add more resources.

In most project-manager’s minds the implementation of a requirement equals a certain amount of developer-time. Thus the easy solution is to add more developer-time, and the requirements will be implemented equally faster. It’s quite simple, right? 20% more developer-hours shave off 20% of the calendar-time to implement the solution. Sorry, but unfortunately it’s not that simple.

There are three factors, which must be taken into account.

First: You can’t produce a child in just one month by adding eight extra women to the task. Some development tasks have the same type of constraint and require specialized knowledge and skills. Sharing that knowledge and skills can be difficult and expensive.

Second: When adding extra developers the need for coordination, processes, attention to quality standards and understanding of the requirements grows. And the people, who are most competent on training the new developers and reviewing their code, are often the developers who used to be the most productive ones. Hence adding new developers to the team comes at a greater price than just the hours it takes to train them and review their code, since the hours you spend on those tasks where the most productive hours you had.

I would suggest that when the project’s deadlines come under pressure, you should avoid the reflex action of adding extra man-hours to the project and instead be looking at how you can increase the productivity of the developers you already have. And if you decide to add more resources anyway (‘cause of course this in many cases is the right decision) then remember that a “man-hour” is indeed an entity that neither has a fixed size or a fixed price.

Tags: ,

Developer performance

About the author

I'm a software craftsman who ended up as manager and now is trying to get a grip on what makes good developers and how to establish a high performing developer environment in regards to people, processes and tools.

LinkedIn Profile

RecentPosts

Month List