I recently was chatting with a PM about scheduling based on work vs. scheduling based on hours.
I never work in hours. Work hours serve a real purpose, but when I have to develop a project schedule, it’s always duration based, and I always round up.
I know my process isn’t the common one these days, so I decided to work through the math of converting hours to duration to determine if I was just old school or if there’s something to my core assumption that knowing duration helps me manage on a day-to-day basis.
The following is a journey of discovery, with more numbers than most of us like. My hope is when you reach the end, you will have developed the following mental model that lets you understand that 1,000 hours at .80% utilization roughly corresponds to 7.4 months on a duration basis. For a back-of-the-envelope calculation, use 135 hours to the month to get the duration of any given work estimate number.
Using estimated hours to deliver projects on time
One of the reasons why this is so critical is that not all developers are created equal. You will need to adjust your duration around the speed at which your developer codes, especially if you have more than one resource assigned to the same task. Two or more developers always end up with a productivity number that will match the slowest developer. There is also a shared work penalty – but I’m skipping that because that is one estimate too many.
Why do you care? After all, aren’t most schedules always overly optimistic anyway? And how many organizations expect on-time delivery?
While organizations may have let their standards slip, as a project manager, you can make your career by being the one in a 100 that does deliver on time. To do that, you need to know how many resources you need for the “estimated hours,” and odds are it’s more than your organization was planning to give you.
Approximating the duration
Let’s dive into the numbers so you can sanity-check your schedules for yourself
Let’s use the example of a project that needs a python developer for an estimated 1,000 hours. The first thing we do is multiply the 1,000 hours by the agreed-upon utilization rate and see how many days duration we need. For the sake of this first example, we’ll assume this project is important enough to justify full-time staffing.
If you have a resource management system in place, the system will do the calculation to get to a simple approximation of durations. But for this thought experiment, I’m going to assume we are doing the math in Excel.
Trust me when I say, for most of us (mathematical geniuses excluded), there is a neurocognitive reason for this recommendation. By the time we reach the end and have worked through the number, you will be confident that the “magic number” will work for you.
Based on 1,000 hours at 80% utilization, you come up with 1,250 hours or 156 days. For 2021, there are, on average, 245 working days (this includes the standard holiday schedule and the average 3-week vacation for the US.) With a little more math, we come up with about eight months duration for what we have defined as one of our critical path work efforts.
The trap of overly-optimistic assumptions
In a perfect world, the resource manager for python developers would assign Carl full time for eight months.
Why Carl? Carl is a B proficiency developer. This means he’s better than average. We need to understand Carl’s skill level because in this case, it can potentially provide the project with enough slack to compensate for the things that will go wrong and result in unforeseen delays.
Now, we need to stop at this point and reflect that when we first heard a 1,000 hours, odds are good that we mentally said, “half a year.” If we don’t have a resource management system that will do some of the number-crunching for us, we might trust our first instinct and assume we can get the work done in six months.
The motivation to do this is enormous. 1) people are always optimistic, 2) everyone wants the project done sooner rather than later, 3) we might get a better person assigned if we need him or her for a shorter time, and the list goes on.
Our final reason for our over-optimism is that we assume if Carl comes to us saying he can’t make a deadline, we’ll have a better chance of getting an extra resource than if we’d requested one in advance.
Factoring in developer efficiency
Additionally, as I mentioned earlier in this blog, adding another developer slows down the efficiency coefficient of the work. Why? Because two developers are only as efficient as the least efficient developer.
If you knew at the beginning of your project you needed two developers, you could have arranged for two equivalent developers. Suppose you wait and only acknowledge that you have an additional two months of work that you hadn’t accounted for on the original project plan. In that case, the odds are good your second developer will be at the lower end of the efficiency curve.
It isn’t that Joe is a bad developer; it’s just that he isn’t fast.
Years ago, some research showed that coding talent came in two flavors. Fast and average. The research also showed that the speed at which a developer coded was innate (i.e., brain wiring) and that an average developer could never develop faster coding skills. For the sake of illustration, let’s assume that Joe is 20% or 30% slower than Carl, depending on the complexity of the work. If we pair Joe with Carl, we increase Carl’s estimate of eight months to nine months, or 4.5 months for the pair of them.
Now, let’s return to reality. If we say that the coding needs to be done at the end of month 5 to finish the project in six months, then you have two weeks slack before you need to declare that the Python work will take two developers, not one, and get Joe assigned.
The key to planning for accurate months durations
If your head hurts from even thinking about trying to work at this level of precision, here are some averages to help you run your own back-of-the-envelope estimate.
The magic number is 168
Take any hour estimate divided by your internal utilization rate (time spent on project work as a percentage of 40 hours a week), divide it by 168, and you’ll know how many months duration you need to plan for.
Once you have the duration, you can make sure your schedule reflects that number. You can also make doubly sure that the resource forecast shows your critical resources are assigned for the appropriate duration.
You should also meet with the resource manager and explain that your resources cannot be borrowed for any purpose without your project slipping on a day-to-day basis.
Obviously, this is a little dramatic, and if you are a multi-project manager, you are probably stretched too thin to give all of your projects this level of oversight. Still, you can do it for the critical path resources on your highest priority projects.
This one little bit of extra effort can pay off across your entire organization. Consider giving it a try on your next project, and then let me know how it works!
