Software project estimation: handling the dreaded ‘how long will it take?’
There’s excitement in the air. It’s the start of a new software project. But that excitement is often cut down at the utterance of one little question: ‘how long will it take?’ Suddenly, you need to make a software project estimation. Sometimes, it’s even expected on the spot.
But asking how long a software project will take is like asking ‘how long is a piece of string?’ The answer is different for each project and each team, and there simply isn’t enough information to make an accurate suggestion.
So, how can you handle the dreaded ‘how long will it take’ and manage software project estimation successfully?
The problem with software project estimation
A software project estimation is the weather forecast of the development world. It’s a ‘best guess’ based on your knowledge, the team and the project requirements.
Software project estimations are useful for conveying an understanding of the size, difficulty and scope of a project. For a smaller project such as deploying new features to existing products, it can give an idea of the cost of development. But software project estimations are commonly misinterpreted or made with poor foundations.
The problem is, a software project estimation can be easily miscommunicated. Because they’re commonly requested — and even coerced — without supplying much information to work from, estimates are often rushed and inaccurate. Unfortunately, these inaccurate software project estimations are then taken to be exact and used to prescribe deadlines.
This makes for unrealistic expectations, high levels of stress, and unmet goals.
When the dreaded question is asked
Answering the ‘how long will it take’ question is about managing expectations, and effective communication is key. If you’re approached and asked for a software project estimation, but not given time or information to help you work it out, it’s both frustrating and stressful.
You might think that you need to give an exact answer right now. This is even what some people might expect. But, instead of giving a random answer straight away, ask for time to work it out, and explain why you need it. It’s no good just taking a shot in the dark, after all.
If your manager or team leader (whoever is asking the question) pushes for an answer on the spot, offer a wide range as your ‘best guess’, based on your experience. Be sure to reiterate that it’s a complete guess and that you will have a better idea once you’ve taken some time to analyse the project.
Making a detailed software project estimation
Once you have some extra time to consider your estimate, you can start to work out a slightly more accurate time frame. But this can still be a daunting task. Here are the factors you need to consider:
- The requirements of the finished piece
The bigger the project, the harder it is to estimate. So, by breaking down into the different requirements/functions that it needs to have, you can make easier estimates in smaller chunks.
- Other projects/work commitments other than this project
Often, there will be more than one project or set of work happening in the dev office. Other commitments can mean that a project will take longer to complete. A project that might be completed in three months with undivided attention might take six if half of the workday is spent on other tasks. So, the time spent on these other commitments should be included in your estimate.
- Existing code
New projects aren’t just about new code and functions but integrating with the old ones. So, consider how the code that will be written will fit with the code you already have. Remember to factor in the time you’ll need to spend on editing any existing or legacy code.
- Time for unforeseen issues
You can’t possibly know what will happen during the project; what problems will be faced, and how long they’ll take to be resolved. Something that looks easy could end up being much harder. (And vice versa.) So, be sure to give some extra breathing room for unforeseen hurdles.
Giving the estimation
When you’re giving your estimation, whether it’s on the spot or after some time spent analysing the project, make it clear that it isn’t set in stone. This means giving a range (best-case scenario to worst-case scenario) and erring on the side of caution. Remember: over-estimating is often far less detrimental to your project than underestimating.
Also, consider what time measurement you use when you deliver your estimate. Bigger time increments tend to seem less accurate than smaller ones. (3-5 months rather than 750 hours, for example.) This keeps it clear that your estimation is exactly that.
The more you work on the project, the better idea you have on the problems you’ll face. This means estimations are likely to change, and likely become slightly more accurate. So, after giving your initial software project estimation, be sure to keep updating it as necessary.
Doing so not only keeps it clear that your estimate is not a commitment, but helps management understand the state and scope of progress on the project better too. If something causes your estimate to change, tell your manager.
Software project estimation
When it comes to the ‘how long will it take’ question, communication is everything. Don’t be afraid to ask for time or request more information to provide a good answer.
And when you do give your answer, make sure that you’re effectively communicating that it still isn’t a guarantee or commitment. Remember to reinforce that the time frame could change, give a range instead of a fixed answer, and update as you go.
When you keep it clear that your software project estimation is still just an educated guess, you avoid impossible deadlines, the stress they cause, and cross-team arguments.
