Some time ago, I came across a cartoon that sums up the current state of affairs on most projects. Here’s how it goes.
A programmer is asked for his work estimate on a task.
-
He thinks: “Two hours.”
-
He says: “Two days.”
-
The project manager tells his boss: “It’ll take him two weeks.”
-
The boss tells her boss: “Two months.”
-
The CEO is told: “Two years.”
We tend to chuckle at this because it’s funny … and sadly true. In this case, everyone’s safe. It’s hard to envision a situation in which, no matter what goes wrong, the task doesn’t get completed on time. Even if the programmer is off in his estimate by 100 percent, he’ll still beat his two day delivery promise. In fact, everyone in this story is safe because they’ve all padded their estimate of the project by a gigantic margin.
The trouble in this case is that no one (except the programmer) is working with real information anymore. And it’s just as likely that the project will get cancelled because it’s going to take too long.
Humans are often motivated by fear and usually this is a good thing. After all, fearing stampeding elephants kept our ancestors alive. Sometimes the fear makes us act too cautiously though. Most of us want to be perceived as efficient, helpful contributors to the team. We fear disapproval from colleagues and our leaders, so we make time estimates that show us in the most favorable light.
This fear-based mode of operating is all too common in project-based work, and its roots are understandable (and lamentable). We account for the unknown by padding our estimates. Everyone does it. It’s based in fear of the consequences when we fail to meet our commitments.
One of the key shifts that a team adopting agile project management will need to make is to shed this fear-based mode of estimating the work at hand. It requires both a behavioral and a cultural shift among team members, by the team leader (or Scrum Master) and by the stakeholders and project sponsor. For, after all, an estimate is merely an estimate.
The first day of a project is the worst day on which to give an estimate
In fact, every single day that we work on a project, we learn more about it and are better able to make an estimate of when it will be done, what it will cost, and what it will look like. Of course, we rarely have the luxury of not giving a project estimate until the very end. But I always tell this to the project sponsor. In fact, the first step in shedding the fear is to confront its source at the very start of the project. You’re going to tell me about the project, and I’m going to give you a very wide range of possible outcomes. As we kick off the project, we’ll narrow that range. After we release a first iteration, we’ll narrow that range some more. (Or maybe not, depending on what we learn.)
Marry the top-down and the bottom-up estimates
For sure, it’s helpful for the project sponsor to let the team know what’s desirable and what’s possible in terms of budget, timeline, and outcomes. There’s no sense in scoping out a grandiose $250,000 project when the budget will bear only $25,000.
Once you’ve gotten a few projects under your belt, you’ll have a sense for about how long the next one will take. You’ll use this experience to make a quick high-level estimate of each new project you encounter, adjusting for familiarity with the topic, the audience, the project sponsor, the technology, and the like. This experience-based estimate, along with the project sponsor’s budget in mind, gives you the top-down estimate.
You’ll then break down the bigger project into smaller pieces, even down to the task level. As you build up this project plan from the bottom-up, you check it against the top-down estimate. When the two don’t meet, you’ll have to have a conversation with the project sponsor about scope, budget, time, and expectations.
Estimate in small increments
The more you can break a project down into small increments, the more accurate your estimate will be. When I teach agile project management to instructional designers and developers, I like to use the jelly bean exercise I learned from Rich Sheridan at Menlo Innovations in Michigan.
I fill a two-ounce shot glass with jelly beans and ask the group to estimate how many jelly beans are in the glass. I’ll ask for about 10 responses, then calculate the mean (average) and the range between the highest and lowest responses. When I reveal how many jelly beans are actually in the glass, we find that the average is usually off by quite a bit, and the range of answers is pretty wide.
I then bring out a tall glass tumbler and we do the same exercise. Then I bring out a big glass water pitcher filled with jelly beans. As you can imagine, the average is farther off and the range is wider as the container gets larger.
What does this have to do with project management? It’s easier to estimate in smaller batches. You’re more likely to know if your estimate is way off if you’re counting a small glass full of candies as opposed to the gigantic pitcher. You get more practice and more feedback when you’re estimating smaller pieces. That’s why agile projects and agile tasks are broken down into the smallest increment possible.
Use an estimating scheme that accounts for the uncertainty inherent in large estimates
Some project estimating approaches force a false sense of precision. If my Gantt chart calculates a project at 27.83 days, what does that really mean? It’s calculating a false sense of precision, as though I could actually calibrate my work to the hundredth of an hour, over a month out from today.
Agile teams use one of several estimating schemes that helps us deal with uncertainty: powers of 2 (2, 4, 8, 16, 32...), the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34...) or even a simple small/medium/large approach. It doesn’t matter which one you pick. The point is simply that the distance between each increment increases as you go up.
When estimating specific tasks, we work in hours: two hours, four hours, eight hours, and so on. When we’re estimating larger components of work, we’ll work in units of days or weeks. The scheme allows us to very quickly make an estimate that both accounts for uncertainty and avoids a false sense of precision.
Prepare for the unexpected
This will sound a little counterintuitive after all the preceding: make an estimate for the unexpected.
Your computer crashes and takes days of work along with it. The project scope changes. The underlying business need changes. The software you’re using upgrades. The subject matter expert leaves the organization. It takes seven attempts to get the graphics just the way the project sponsor wants them. A key team member gets pulled to another project.
Something will happen. You just don’t know what it is. But you can plan for it.
In old fashioned project planning, this is called your contingency factor. It’s a block of time (and/or money) that you set aside for the unexpected. Low risk projects have smaller contingencies than higher risk projects.
The point here is that the contingency factor isn’t baked into every task, but rather held out on its own. That way, if you find that you’ve used up all your contingency time and you’re only a few weeks into the project then you’ll know you need to adjust.
Keep your finger on the pulse
An estimate is neither a bid nor a promise. Estimates are just that: estimates. And that’s precisely why close tracking and good communication are essential.
Agile can handle inaccurate estimates much more readily than it can handle poor communication. As soon as someone realizes something is awry with the task or the estimate, he or she must speak up. You can make alternate plans and the project will continue. However, when a team member doesn’t alert others to a potential problem, all the other tasks are put in jeopardy and the project can grind to a halt. If an employee needs to fear anything, it’s the consequences of not reporting a problem.
At the project level, agile teams report status to project sponsors every week or every sprint (usually two-to-several weeks). If your time reporting system or agile software allows for it, you can easily track estimated hours vs. actual hours. This lets you head off problems before they grow too large.
Whether you’re using agile methods or a more traditional project management approach, you’ll need to estimate your work. Before you add in that extra measure “just for safety’s sake,” remember: never fear! Estimate small, adjust frequently, and keep your finger on the pulse of the project.
Editor’s Note: Hear Megan speak on agile project management at Learning Solutions in March!
Megan Torrance, the author of this article, is leading a pre-conference workshop and a concurrent session at the Learning Solutions Conference & Expo 2015, March 25 – 27 in Orlando.
- Pre-conference Certificate Program: Using Agile Project Management for eLearning
- Concurrent session: Adopting Agile Requires a Culture Change—Are You Ready?
Register by December 19, 2014 for a $200 discount on the conference fee!