Person-hour (PH) and its variations (month/day/minutes) are the favorite metrics of those who deploy rather traditional project models.
The estimate person-hour was used for the first time in 1912, and, as a metric, it describes a 1-hour unit of a person’s work. It was conceived to allow project managers to create estimates for projects, manage costs, issue price quotes, etc.
On many occasions, we see people trying to hammer such metrics into Agile. They create dazzling formulas to convert points for histories, cycle time, and lead time into person-hour. As it turns out, it never works since those metrics were created for different paradigms.
10 reasons to stop using “Person-Hour”
Do you still catch yourself leaning towards thinking through a “Person-Hour” mindset? Check out why we think you should drop it for good.
- Knowledge work is unknown until it is fully carried out
Imagine the following situation: you are a project manager and ask a software developer how long this person will need to create a specific feature.
After some thought, the answer is, “about two days.” But, in the end, it takes almost five days, as some aspects of the tasks deemed necessary to create that feature were overlooked.
Such aspects may be, for instance, too much manual labor, complex algorithms that had to be created or unforeseen, and unknown bits of coding that had not been predicted. All that (and much more!) may affect the estimate of completion.
But you are a good project manager. You take into account that, for similar tasks, similar deadlines will apply. So, for the app’s next feature, you plan 5 days for the software developer to create it.
During the execution period, however, the developer ends up taking 8 days. This feature was more complex, and there was much more manual work to be done. But how could you know that?
The thing is, those who work with knowledge assets are aware that a task is not fully known until its total completion.
Trying to estimate how long a creative activity will last is like rolling a bunch of dice and expecting to get a 6 with all of them. You may even get a few estimates right, but rest assured that you will also get them wrong.
- Absolute time X Relative time
Absolute time is, for instance, the number of hours in a day. As stated by Henrik Kniberg, it is the most standardized, abundant, and cheap resource on the planet.
A working day usually comprises 8 working hours. If we take out breaks and interruptions, it is reasonable to assume that a regular employee works 5-6 hours per day.
This way of estimating works with absolute time. It thinks of people working exactly 5-6 hours per day.
But, in reality, there are oscillations. On some days, a person may work for 10 hours, while, on other days, this same person may work for just 1 hour, or even not work at all.
Who plans based on person-hour is continuously trying to make one fit into the other. How often do we find ourselves redoing the planning just because a task took longer than expected?
- Perfect days
As human beings, we are fully aware that not all days are perfect. Not even by far.
A child falls ill, an argument with a spouse, family disputes, internet connection issues, personal matters to address… the list of events that may jeopardize a “perfect” day is simply never-ending.
And all those events have a significant impact on the Person-Hour estimate.
- Perfect individuals
The Person-Hour metric considers perfect, standardized individuals. For example, senior software developers always have a productivity rate corresponding to “X”.
Well, what happens when you confront this person with a problem that was never faced before? Or when one must use a new programming language? Do all software developers respond to a challenge in the same way?
People are not perfect. Everyone has weaknesses, fears, yearnings, challenges that stop them from having a constant performance.
- The false notion that a person equals a resource
I remember once being in a conversation and hearing, “No one is irreplaceable. If the process is really good, go ahead and replace anyone. Productivity will not drop.”
I asked if this statement was also valid for complex environments, and the person said, “Sure!”
A light bulb went on in my head. I thought of Barcelona — not the city, the soccer team, which was then the best in the world. I asked, “So, can we replace Neymar with John-Scissor-Feet (fictitious player), and Barcelona will still be the best soccer team in the world?”
His eyes popped up in surprise, and he rushed into explaining how that situation was totally different, yadda yadda.
If you ever were in charge of a team, you’d know for sure how unique people are. If a good professional leaves the team, the impact on performance is huge, since PEOPLE ARE NOT RESOURCES!
Resources are goods that can be accumulated, thus either yielding a linear performance gain or covering losses.
For example, if my problem is printing documents and I must work with a printer that prints 30 pages per minute, if I buy a second printer just like that one, my printing capacity will be 60 sheets per minute.
But this doesn’t apply to people! Human beings have different skills, capacities, attitudes, and personal histories.
- Adding more people to a process with a tight deadline
Oh, how many times have I seen this happen! The scope has been defined, the final deadline is coming, and the team has been working like crazy.
Overtime hours are skyrocketing, and then someone asks the 1-million-dollar question, “What can we do to increase productivity?” “Let’s hire more people!”
Pitfall alert: when someone joins a project, familiarity with the tools, context, and the team is never a given. At least one team member will have to provide some initial support, which causes loss of productivity in the short term.
A second pitfall was highlighted by Frederick Brooks in this book “The Mythical Man-Month” (1995). His point is that adding people to increase team productivity has side effects.
Coordination costs, communication, and complexity are exponentially increased (Brooks’s Law). Over time, such effects become so bloated that, instead of gaining performance, losses occur.
- “They say” is often a great liar
Have you asked a project’s member how long it took to complete a task and heard an answer in the line of “8 days, 6 hours, and 20 minutes”?
This is probably an attempt to adjust execution to the time estimate. Very few people can be that accurate when it comes to time.
Do not take my word for it. Try it yourself: For how long have you been reading this article?
- Fosters individual comparison
In our blog post on toxic metrics, we discuss how harmful it is to measure individual work instead of teamwork. In that post, I explain how this metric undermines information sharing and mutual help.
As a consequence, work becomes more competitive instead of collaborative.
- Parkinson’s law
If you like to use a metric such as Person-Day and, because you are not naive, add some extra slack to your planning, beware of something that is known as Parkinson’s law, which states that “work expands to fill the time available for its completion.”
Here’s how it works: you take up a task imagining that it will take you 5 days to complete it. However, you allow another 2 days for it in your planning, just in case something goes wrong. So, now, in your planning, you are forecasting 7 days for a person to complete this task.
Two things may happen there. One is known as the “Student’s Syndrome,” meaning that the assignee will start the task on day 6. After all, the team had been busy with something else, and there was a bit of extra time.
The second is being overzealous, meaning that the assignee actually gets started with the task on day 1, but since there are another 6 days, a lot of extra functionalities end up being added to the initial scope. It might sound good, but there was never a request for such “gold plating,” nor does the client want it.
The final result will be a delay both in the task and the whole project.
- Tough arithmetic
Before a project starts, it’s all cool. Task A = 10 days, Task B = 5 days, Task C = 1 month, and so on.
The project finally starts, and then the adjustments start: 10 days + 1.5 days + 2 hours + 1.3 months… = ???
When will the project be ready?
This is NOT the most important question!
Read about it in the article “When will this be ready?” — This is not the most important question“, where Rodrigo Toledo explains why this question does not take too much place under the business spotlight in Agile environments.
Takeaway
Person-Day is a metric that is normally used in Plan-Driven Development modeling. Often overlooking execution efforts, this strategy prioritizes creating the project plan with as little risk and as perfectly as possible.
The quest for rendering processes predictable is so strong that adaptation to change happens slowly and is often dragged by red tape, so much so that, sometimes, changing is just impossible.
When it comes to Agile methods, though, we understand that it is impossible to have a perfect, fail-proof plan from the get-go. The best way of mitigating risks is delivering the important items first and keep in mind that changes are part of the process and are bound to happen. All Agile metrics should fit this context.
