“[Agile developers] [w]ith so many tasks needing attention throughout the workday, accurately tracking and recording time spent on each individual item is inherently troublesome. … But no project is ever exactly identical to those that have come before. … Even if teams can achieve high accuracy rates for actuals versus planned against tasks, there is no good way of leveraging that data to improve the estimation process. … Instead of providing an estimate, consider taking a measurement of how fast your teams can deliver ….” Escaping the time trap, Joel Semeniuk (co-CEO of Imaginet), Software Development Times, May 2011.

Joel sees recording how long tasks take as a time trap. I agree. As a project manager, I rarely worry about how long individual tasks will take. Too often, task progress and completion looks like a horse race and I can watch how one task speeds up or slows down or becomes part of the “critical path” only to jump off of it later. I might as well throw a pair of dice to decide which task will be completed by when.

I do believe that in a well managed and automated environment, we can get down to tracking and recording the time and variation for individual tasks. However, in knowledge work projects (IT, software, etc.) I don’t believe we’ll see that kind of precision in the near future, if ever. Don’t get me wrong, I do know that we can get such knowledge work projects down to a predictable drumbeat. A drumbeat where we know what we can deliver and by when, and with good quality.

I admit I had a hard time parsing some of Joel’s suggestions. The one that resonated with me first was “the measure of wall-clock time between when a task starts and when it finished.” I added this to his earlier statement of measuring how fast our teams deliver. That’s it! This is something that has worked well for me over my career.

Simply put, I care more about the end-to-end time of a project than I care about the individual tasks in the project. The wall-clock time, when we start and when we end, measures how long it took to deliver a project. If we are in a project centric organization (e.g., software development and maintenance, IT, consumer electronics, etc.) then we are doing these projects, often dozens at a time, over and over and over. This gives us lots of measurements of how fast we deliver a project. Plainly put, this overall average measurement of speed is inherently more accurate, in my experience, than trying to estimate how long a project will take by piecing together what we believe are the individual tasks and their dependencies.

But see Get The Schedule Right!

This end-to-end approach is always met with cries of heresy and the arguments of “no two projects are the same,” “different projects are different sizes,” “software is not a repeatable process,” “you are mixing apples and oranges” etc.. It just does not seem intuitively right to so many people that recording when projects start and stop and using an average to characterize how fast we deliver a project that such a number is useful in estimating the next project.

For example, see Software Is A Repeatable Process

I often like to soften the argument by agreeing that once an organization really gets their project management under control, that such a high level gross measure of speed (or velocity) will be less useful. They will be able to go back to relying upon micro details assembled bottom up to estimate a project. The only hitch is that I’ve rarely seen this happen. Often, in fact, after being successful at delivering projects on time, we would focus less on trying to speed up the overall cycle time and instead focus on getting more functionality delivered in that same period of time.

Joel asked the same question in his article that we asked all the time: “How long is it going to take?” We found that by backing up and looking at the overall process performance, rather than drilling down and looking at the details, gave us a better handle on what our true capabilities were. It also gave us the strategic ability to respond quickly to a customer and say “yes, we can give you that by the third quarter” when we didn’t even know all the details of the customer’s requirements (and yes, we delivered on time).

How we did it: How To Give Your Boss A Quick Estimate

I love data, details and software tools, but too often we quickly jump to using them when a step back, a bigger picture, and a more simple measure will give us what we need right now. Classic approaches of trying to measure how long everything takes are often nothing more than a time and activity trap without any increase in estimation accuracy. Instead, measuring our overall speed and working with that concrete reality, gives us the ability to make and meet current commitments while we look for ways to speed up that process.

Do you know how long it has been taking your teams to deliver your projects and do you use this insight to commit your future projects?