Software projects, while not inherently unknowable, are notoriously difficult to estimate. In fact, a study by PWC found that the largest contributor to IT project failures, at 32%, was poor estimation at the project planning phase. But why do software projects take so long (i.e. longer than you think)?
Well, there are a number of reasons why software project management performs so poorly when it comes to delivering projects on time. These include:
- Unclear objectives: One of the biggest issues that developers face is clients who don’t actually know what they want. An initial estimate can be pushed back weeks from even starting as the exploration phase drags on and the project is clearly defined.
- Not all developers can work at the same speed: There are varying estimates as to the difference between the capabilities of good developers and average developers, ranging from 5:1 to 300:1 (from a Google Vice-President). Just because one developer managed a certain task in two weeks doesn’t mean another will be able to complete it in the same time.
- Desire to push timing: For various reasons, such as trying to get a business case pushed through or to impress senior executives, management or project sponsors might be purposefully over-optimistic with their software project estimation techniques. Pushing deadlines forward instead of back rarely results in on-time delivery.
- Late-in-game changes: It happens with nearly every development project – the team is five months in, and two weeks off delivery, the client gets a look at an evaluation prototype and suddenly they actually want something completely different. The result is a big firestorm as they try to push for out-of-scope changes, while the team tries to explain why that can’t happen, usually resulting in a compromise that brings the project way over time and budget, which then has to be further explained at the executive level.
- Not factoring in all processes: Too often the software project estimation techniques used don’t factor in what it actually takes to make software “client ready.” Alpha testing, beta testing and final bug fixes all take time and can’t be rushed through, no matter when the deadline was.
There is a multitude of reasons why software project estimation techniques fail to adequately predict a project’s timeline. So, what can be done to make those estimations better? Here are some tips:
Determine your critical path: An effective critical path approach will set out the minimum possible length the project can take. This is at least a good place to begin from and gives everyone a basic idea of where they stand.
Choose an estimation strategy that suits the project: There are a number of software project estimation techniques that are commonly used. Choosing which one is right for you depends on the team’s situation at the time:
- Expert-driven estimation: The lead expert on a given point is asked to give their estimation and all of these are gathered together.
- Analogy-based estimation: Using the experience of similar projects and tasks to make predictions.
- Estimation by complexity: For larger projects with lots to estimate, tasks are assigned a complexity value, then times are worked out based on complexity.
- Negotiated estimation: Team leads and subject matter experts give their estimates and negotiate through differences if there are any.
Run estimations by external sources: If the project has a project sponsor or a person who can be relied upon to check over the estimates you are making, then utilize them and ask for their assistance.
Use a 20% range: Rather than insisting on a precise estimate, give a range, to account for the likely unknowables in the project. A standard range to go by is whatever your final estimation would be + 20%.
For software project management – and indeed all project management – the greater the visibility, the more accurate the estimates. When it comes to identifying how long certain things are taking and project length, Planview AdaptiveWork’s project management software is a world leader. Talk to us to organize a free demo.
