Your project is almost finished. Last week, it was almost finished. And you suspect that next week, it will still be almost finished. Why does this happen, and what can you do about it? In some ways, we’ve known about this problem for almost 2500 years But the solutions are still far from widespread.
Zeno’s Paradox
The Greek philosopher, Zeno of Alea, posed a paradox, in the form of a race between Achilles and a tortoise. The tortoise won. And not like the tortoise and the hare – the lesson here is mathematical, not one of having good work ethics. The solution to Zeno’s paradox is found in infinite series mathematics. Here’s an easy to understand version of the paradox:
Zeno’s Paradox may be rephrased as follows. Suppose I wish to cross the room. First, of course, I must cover half the distance. Then, I must cover half the remaining distance. Then, I must cover half the remaining distance. Then I must cover half the remaining distance . . . and so on forever. The consequence is that I can never get to the other side of the room.
As an engineer, frankly, I struggled with infinite series in college. Differential equations? Cake. Infinite Series? “Let them eat cake.” I struggled to overcome the notion that once you get close enough, you just take a step that is larger than the remaining fraction of the distance, and you’re done. There is an interesting parallel in project estimates, and therefore a point to this story.
Almost Completed Tasks
If you’ve ever been working on a deliverable, and thought to yourself, “I’m almost done,” then you’re halfway there. A day later, you find that you’re still “almost done.” And after that – still almost done. Have you ever depended upon someone to deliver something for you, to have them perpetually almost done? Like Achilles, some people simply lose out to the tortoise. But it isn’t a problem with the people, it’s a problem with how they are keeping track of their work. Or with how you’re asking them to keep track of their work.
Johanna Rothman writes about this exact issue.
Imagine you’re a project manager. You talk to your technical lead and ask how far along the team is. “Oh, we’re about 90 percent done,” he says. If you’re like most project managers, your heart sinks. You’ve been here before. Ninety percent done means the other 90 percent is left to do.
We’ll look at one of the techniques Johanna identifies in her article – and as we talk about it, we’ll overlap several of her other suggestions.
Discrete Deliverables
Johanna offers several tips to address this issue – and one of them reminds me of my engineer’s solution – just take a step, and to heck with the halfway stuff. We sidestep the percent complete problem, by having people report a discrete status on a smaller amount of work. Then we roll those estimates up and describe “percent of the small tasks that are completed” instead of “percent of the nebulous task that has been completed.”
If people estimate tasks in large chunks (like weeks or months), then when you ask for updates, they can give you an arbitrary percentage complete. Johanna suggests having developers break up their larger tasks into daily tasks. In our experience, when building a detailed estimate from the bottom up, all of your tasks should be between 2 and 8 hours. If a task is shorter than 2 hours, you’re becoming inefficient – the time spent tracking the deliverable becomes too burdensome. And if the task is longer than 8 hours, then you really aren’t getting a way from the percent complete idea. This has been very effective for us in projects with both junior and senior people, and in projects with all sorts of deliverables.
Here’s the interesting part. Every contributor, working against a set of these 2 to 8 hour deliverables reports them as complete or incomplete – not with a percentage. Anything less than completely done is simply tracked as “not done.” Think of it as moving from an analog to a digital world. Instead of a week-long task like “Secure the website from hackers” you would create multiple tasks like “Whitelist all displays of user generated content” and “Implement SQL-Injection protection.” For a large site, you might have to break this down further, perhaps by areas of the site, etc.
Rolling these discrete estimates up gives you a top-level percentage complete. But by breaking it up into discrete deliverables that are independently complete or incomplete, you prevent the “almost there” problem. Eventually, there is only one step left – and you just take it.
Armed with this approach for task-tracking, you can become even more effective by using the burndown technique popularized in the scrum world for tracking projects. We’ve used this very effectively as a means to help new business analysts manage some large requirements deliverables on a high-profile project. The new analysts did not have experience in estimation of their tasks, and the project manager did not have confidence in, or visibility of their progress. By introducing burndown for managing requirements deliverables (use case and activity diagram development and validation), we simultaneously improved the ability of the team to communicate and estimate status.
Johanna also suggests using rolling wave planning to track these detailed level tasks. And this is important – the further you look into the future, the more changes there will be to the plan before you get to the future. And therefore the more likely that your planning work will be discarded, as you are asked to do something different. So only do the detailed planning one release out. Do higher level planning across all the releases. And then establish a process and expectations for how changes to the plan will be managed.
Summary
When people report the percentage complete of a single task, that estimate is suspect because of the hard-to-nail-down definition of almost done. When people report the completion of multiple tasks, we can then quantitatively add those up to provide a reliable percentage complete estimate of a set of tasks.
This approach provides for more reliable reporting, and a better feedback loop (helping the estimators get better at estimating). A side benefit is that the decomposition of large tasks forces or reinforces (depending on how you think about it) the act of decomposing larger tasks into smaller, actionable activities.
The tortoise story remembers me of some math courses ;o)
In reality there are people that can decide that something is “good enough” and then you stop. You should ask the question if it is “finished”, because usually you could always perform additional work.
Excellent post. I’ve used the technique(s) you mention some, but I need to use it rigorously.
This is something I deal with in music in the way that Franck mentioned – a piece of music is never finished. I can always improve an aspect of my singing or playing. But it reaches a point where you have to say that it is good enough.
Thanks guys for reading and commenting! There are definitely benefits (at least in software) to defining what it means to be done. Test driven development (and behavior driven development) are two approaches to this. Define the criteria for “done” – and when you meet those criteria, you are done.
When thinking about music, I guess that’s the value of having a good producer. Someone who can make a subjective call of “good enough” (and more importantly – not good enough). It also re-emphasizes the challenges of determining the ROI of design that we wrote about last week. How do you quantify “better”? We talked about that some. But how do you justify, in advance, making it better?
Great software development is still both an art and a science.