Overruns in custom software development are common. In an Oxford study on megaprojects (valued at over $1billion), nine out of ten projects had cost overruns. For Information and Communications Technology (ICT) projects overruns are large, with one in six projects reporting overruns averaging at 200%.
The cost of overruns is not just in their financial and resource costs. It also impacts the image of companies, their marketability and client satisfaction (source). This then threatens client loyalty and the potential for new clients.
With overruns running rampant, it’s important that project managers work to decrease the risk of overruns. To achieve this, the first step is identifying the reasons for overruns.
1 Incomplete Requirements
Arguably the main cause for overruns is incomplete requirements. When requirements aren’t fully explored, the project will not be understood by all parties involved. Assumptions are made that have a knock-on effect. For example, a client may assume that a search function on a list page is an obvious inclusion, but this is not included in the requirements. This may be seen as a fairly minor misunderstanding, but if it is not in the requirements then it will not be included in estimates and therefore will result in an overrun.
Incomplete requirements are not limited to small misunderstandings. Without thorough clarification, the goal of a project and how it is to be achieved can be understood very differently by various stakeholders. Without exploration of how the project is to be developed, there can be risks that are not identified which later become issues. The feasibility, usability and functionality of the project will not be considered to a meaningful extent, meaning the project may not achieve what it has set out to.
With incomplete requirements comes underestimation. Estimates cannot be accurate without a full understanding of requirements. After all, estimates are based on the scope of the project. Estimation also relies on your understanding of your team, their skills and the time it takes to complete tasks. Task estimates will vary based on the individual and their experience. As such, knowing your team and understanding the work are what makes estimates as accurate as possible.
Inaccuracy will lead to underestimation (overestimation is also a risk, though generally less of an issue unless it causes work to be overcharged or you lose out on work due to higher proposed costs). Once a client is given a number, then that is often the maximum budget they have available for the project. If overruns then do occur and the project is fixed price, then it is likely the provider that will have to eat this cost. If the project is time & materials, then the client will be left with the rising costs which may lead to the client changing software development provider or abandoning the project altogether.
3 Scope Creep
Another risk related to project requirements is scope creep. Rather than a misunderstanding or oversight in requirements, scope creep is when the project changes after it has been started. This can be at any point after the project begins and can cause serious issues. Scope creep can be new additions to the project or changes to the existing project plan. It could involve reworking components that have been completed or could be additional work on top of the already planned and scheduled work. On top of changes extending the work of a project, changes made after project initiation could have damaging knock-on effects if how the change fits and interacts with the other components of the system is not effectively explored.
4 The Unexpected
How to expect the unexpected? By its very nature you can’t, but you won’t expect what you don’t consider. Before the project begins, it is important to consider all the risks to the project. What assumptions have been made, what are the unknowns, what internal and external factors could have an impact, what areas are new. Consider the project from start to finish, all the components and actors and make a risk log. The risk log should be a living document, added to whenever new risks are identified. Time should be built into the project plan for overruns, estimates based on the likely time it will take as well as the worst case.
So, while there still may be some issues that you don’t anticipate, completing a thorough risk assessment means that you can identify risks before and during the project, therefore limiting the unknown.
5 Poor Planning
Planning is the frontline of defence against project overruns. Requirements gathering forms part of the planning process. From this, schedules and estimates are made. Planning should involve identifying and incorporating time for project risks. It is also the project manager’s role to identify and counteract scope creep. It is planning and project management that works to identify and counteract the reasons for overruns we have listed. So, poor planning is a major cause of project overruns.
Sometimes projects won’t run smoothly. There will be issues that weren’t expected or tasks that take longer than estimated. To counteract project overruns in custom software development projects, it is important to plan projects thoroughly. Spend time exploring and fully understanding the project requirements before jumping into development. It will save both time and money in the long run.
Have a custom software development project in mind? We can help!