Question:
I am a team leader for a group of nine developers. In general, we do support and enhancements, but once in a while we are asked to do a large piece of work that would definitely be considered a project. Our problem is that we have a hard time estimating what the effort and duration is for these larger projects. We typically underestimate the work, and then end up trying to shove everything in over the last few weeks. I am tempted to just take the estimates we receive and double them in the future. Are there any simple answers?
ââ,¬"Kurt
Answer:
This is a good question, Kurt, and I can sympathise with your pain. I worked on application support teams for years, and the people on the team were notoriously bad estimators. I should qualify this first: They were fine estimating the time it would take to fix a problem or to research a question for the users. However, if you had a large enhancement or a significant piece of work, they did not fare too well.
You need a different mental model for estimating large projects.
It might not surprise you to learn that people who handle a high volume of short requests would not have good techniques for estimating large pieces of work. Part of the problem is that their mental model of work is typically a straight line between the start and finish. In the world of support, the work is typically all within their control and they can see the finish line from the starting point. Of course, the problem with larger efforts is that you cannot clearly see the finish line, or, if you can, it is not very clear.
Typically, when support people are asked to estimate a larger piece of work, they have the following problems.
- They don't plan the project well. If you're used to fixing a problem first and asking questions later, you might not be comfortable having to plan the work before you start. Therefore, support people tend to make many assumptions in terms of how the project will lay out and what the finished deliverables will look like. Then they find out later that their assumptions were not all correct and that the client has a different notion of what the end state should look like. If you don't spend the time to define scope and deliverables, it's hard to know what you're committing to.
- They don't build in project management time. Many studies have shown that project management will typically take 15 to 18 percent of a project effort. Support people aren't used to managing projects, and don't always build in the time required to update a work plan, resolve issues, deal with risks, and communicate effectively.
- They don't follow good project management procedures.To follow up on the last point, support people typically do not include project management time in their estimates, and in fact, they don't typically manage larger projects very well. They don't update their work plans. They don't manage scope well and end up doing more work than they thought. They don't plan for risks and end up having problems they could have foreseen. All of this makes the project go longer than they estimated. This characteristic is typically the result of not having any formal training or coaching around good project management concepts.
- They have to work on support as well as the project. The support people can't win when they work on projects. They fight to complete the project on time, while at the same time they get interrupted with support issues that must be resolved as the first priority. This results in thrashing, and makes it hard to complete project work on time. There is always some unproductive time as you put down one piece of work to focus on something else.
- They estimate for best case and do not build in a contingency for estimating errors. For each activity, it's possible to estimate the work in terms of best case, most likely case, and worst case. If you're only going to pick one value, it is best to go with the most likely case estimate. However, a lack of experience results in people estimating in terms of the best case. This is always wishful thinking and normally won't come true for all the activities. The result is underestimating the work at hand.
- They are not used to the relying on other people to do the work. This is a problem similar to the previous one. When all the work is within your control, you have a very good idea of how long certain activities will take to complete. However, on a larger project, you typically need to work with other people as well. Many times, the estimator estimates the work based on how much effort it would take him or her to do the work. When the work is assigned to someone else, it can take longer. Again, this is an example of estimating based on the best case, not the most likely case.
Kurt, the purpose of looking at the prior six points was to allow you to review your team's ability to accurately estimate larger work efforts. In many cases, developers vastly underestimate a work effort, but, as they look back, they aren't sure why. Sometimes you don't realise where the time is going, and so it's hard to make improvements to your techniques in the future. The good news is that you can avoid the traps above, while also using some sound estimating techniques to do a much better job estimating work in the future. The next column in this series will show you some of those techniques.
Linkedin 
RSS Feeds 
Newsletters 
Alerts
