Estimating time for tasks and generating an overall project schedule can be painful. I always feel like there are too many educated guesses that go into schedules and estimating time. Estimates range from very educated, to almost complete guesses. Sometimes the estimates are dead on, most of the time they are pretty close. However, there always seems to be a handful in every project that are really off. These bad estimates are what cause people to work 80 hour weeks. Below are some strategies that may make the process of estimating and scheduling more accurate and less painful.
Estimation/Scheduling
If you write software for someone else, chances are very good that you’ve had to guess how long a given activity will take. The only real advice I’ve ever received on the topic is probably similar to advice you’ve heard. “Take a guess, multiply by x, and that’s your estimate”. This is a really crappy way of generating estimates. The problem is mitigated a bit because most of the time estimation of a large project is made up of a ton of small pieces that are estimated separately. Hopefully under-estimation in some areas will be countered by over-estimation in others. However, this is still just wishful thinking. Sometimes it works, sometimes it does not. When it does not, the result can be painful.
Perhaps a place to start looking at the problem is looking at what purpose an estimate serves in the first place. In my mind an estimate serves two major purposes. First, it gives your manager/customer some way to plan around your deliverable. If you’re developing a new website your estimate lets the your customer know when to start their marketing campaign. If you’re writing software at a company your estimate is used to help determine a potential release date for software. The second, and possibly less obvious, reason for estimates is for you. By taking a hard look at the work you have, and attaching an estimate to it, you’re giving yourself a road map. When you have a timeline, you have goals. Having some goals helps keep you motivated to make forward progress on a project. For this blog, I know I want to have at least two posts a week (which I’ve been behind on), this is a timeline. Knowing this timeline helps keep me motivated to make progress.
Estimation can get tricky when there are multiple dependencies, large sets of tasks, and multiple teams of people working towards a single goal. Enter project management software. I use project management software (OmniPlan to be exact) to help manage these dependencies. Does it help? A little. It’s easy to get some idea of the impact that major changes will have. It forces me to identify dependencies between people on the team and gives me a somewhat sane way of tracking them. However, at the end of the day, my project files are made up of guesses. Each task represents a guess as to how long something will take. If these guesses are pretty close, my plan will show me when a project will be done. If the guesses are very wrong, the plan will be misleading at best.
Ultimately estimates are used to develop a schedule. Trying to get the schedule as accurate as possible is probably more important than ensuring that any one estimate is accurate. However, you need to have good estimates to have a good schedule, or at least a way to mitigate/recognize potentially bad estimates.
Risk Based Scheduling
Some of what I’ve read seem to focus on assigning some notion of risk to each estimate. As you work on the wbs for a project, list risks/unknowns for each task. Based on what the identified risks are, assign an overall risk to the task’s estimate. For example: if I’m asked to estimate how long it will take me to drive to work tomorrow there are few unknows and risks. The overall risk for the estimate on how long it will take me to drive to work is low. Yes, something could happen, but I am pretty sure it will take me about 45 minutes to get to work, assuming there isn’t an accident or traffic. Compare this with: How long will it take to sell your car, buy a green 1985 ford Tempo, then drive it from New York to California. This one is alot harder to estimate. Finding a running 1985 green Ford Tempo is going to be a challenge. Finding one that will make it from NY to California is even more of a challenge. What if it breaks down on the way? These things are all unknowns and unknowns are risks. You can give a decent estimate for this, but the risk level for the accuracy of the estimate is fairly high. This is just giving us a systemic way to qualify our estimates.
Once there is a risk level assigned to the tasks, and their estimates proceed with your normal project scheduling. Put your tasks in your charts with their base estimates. Then, find out how many of your high risk tasks/estimates are on your CP. If a large portion of the items on your CP are high risk, it may be worth spending a bit more time clarifying/eliminating some of the unknowns. It may be worth adding some time to those estimates, to account for some of the risk.
This technique seems to focus on identifying the highest risk estimates that can impact your project. High risk estimates that are not on, or close to your CP are still of concern, but errors in the estimation can be covered by project slack time.
Evidence Based Scheduling
While doing research for this post I ran into some talk about evidence based scheduling. The basic idea behind this, read the linked article to get the details, is that you collect information about your estimates. You track which estimates are good, which estimates are bad, who’s making the good estimates and who’s making the bad estimates. How close are the good estimates? How off are the bad estimates? All of this information gets tracked. The information is tracked to help adjust the final schedule, not to beat up the people who are bad at estimating. You use the over/under estimations to generate an overall velocity for each developer. These velocites then allow you to start predicting the likely finish date for a set of estimated tasks by a given developer. Seems like a really interesting idea. Collecting the data seems to be the most problematic part, unless you want to use FogBugz. It may be possible to concoct similar data by using baselines and end variance within your project planning software. It won’t be as granular as a completely integrated system, but it may be possible to use some of that data in a similar way.
Planning Poker
This is a “game” that helps a team arrive at more accurate estimates of individual tasks. The risk based and evidence based systems above focus on how to compensate for inaccurate estimates in an overall project schedule. Planning poker focues on getting better estimates. Again, I’m not going to go into detail on the process, as you can read that for yourself. However, a brief overview is that each member of a team is given a set of numbered cards. A moderator (someone who knows about the task/feature) describes the task. The team asks questions of the moderator, and discuss everything but estimates/level of effort for the task. Once questions have been answered, each participant turns over one of the numbered cards. This card is their estimate. The high and low outliers are asked to discuss why they reached their conclusion. The process continues until there is some reasonable consensus on the estimate.
I think there are a few things that this process accomplishes. First, it allows people who seem a potential time savings, or people who for-see possible pitfalls to be heard. The people in the middle are then forced to adjust their estimates based on the information provided by the outliers. Second, it forces discussion about the task, not about how to estimate the task. One point the link above makes, is that you can’t talk about the estimate in the discussion. You run the risk of tainting the discussion. Lastly, it brings more people than the one or two developers who will be working on the task into the estimation process.
Problem solved?
I spent a good deal of time searching and reading about how people deal with estimating and scheduling. I do want to read Software Estimation: Demystifying the Black Art by Steve McConnell
I think all these methodologies work best only when there are right people making decision. Only if progress is tracked, analyzed, and corrective action taken, estimation/execution can be improved. Two biggest factors causing delays may be:
- Too many bugs caught late in the life cycle. Developers hitting the milestones with only base cases working.
- “Customer Driven” companies let customer/sales drive deliveries, and let engg/QA retrofit project plan.
To me as long as, each project is broken down to 2 week or less level with trackable milestones, milestones are well understood, and a tracking is provided, any tool will suffice. What I would like to see in a tool is some kind of post-analysis and recommendation. Every time there is a slippage, tool should allow one to put in reason of slippage and corrective action, generate a report in the end. If corrective action was not taken then suggest adding x factor based on past experience.
Part of the goal with accurate estimating and scheduling is to avoid limping over the end of a milestone. When your estimate is too short you end up taking shortcuts to hit the date. This is when these late cycle bugs creep up (imo).
You have to be customer driven to some extent. Especially when you’re small and competing against companies that can out spend you. The key, in my mind, is balancing goals. There are times when infrastructure improvements, while not customer facing, must be given time. There are other times when customer needs must take precedence over internal work. Again, accurate estimates aid in scheduling these internal projects. If you have a track record of completing your work on/under estimate, then you’re more likely to be given time to revamp something.