According to some studies the failure rate of digital transformation projects can be as high at 70% (Sources: Boston Consulting Group and McKinsey). Separate studies also site poor requirements as the major cause of project failure in another. Requirements (or lack of) come top of many lists if you search the internet for reasons for project failure. Why is this and how can we improve our chances of project success?
When an organisation decides to undertake a digital transformation project it usually starts with an idea or a concept that is perceived to provide some sort of benefit. This might be increased sales, improved efficiency, or cost savings, amongst other reasons to undertake the project. This generally involves a business case for the spend on the digital transformation and the vast majority of business cases will consider the return on investment. For example, the project will cost $1M to implement but will return $4M in savings over the next 3 years.
Of course, developing a new digital system or indeed implementing any sort of change is inherently risky. A business case is, by necessity, built on a set of assumptions. Is the basic idea for the project sound and achievable? How much will the project cost? How much, financially, will the benefits deliver to the organisation? How capable is the organisation of successfully delivering the project? A combination of these factors represents much of the risk for a project. Decisions are made based on these factors but if one is these factors is wildly inaccurate then the business case for a project can quickly fall apart. A study by McKinsey showed the average software projects overran by an average of 66% over budget (Source: McKinsey) and some projects have run over by 200% or 400%.
Forecasting cost savings or additional income from a project generally relies on business or financial predictions and can be difficult to predict. However, as we have seen from the statistics above there is clear evidence that the costs of actually implementing a project are generally inaccurate so even before the predictions of savings/benefits are tested the business case is already stressed.
Putting together a business case for a project is an exercise which very quickly boils down to two questions; how much will it cost and how soon will we get that investment back? In a lot of cases stakeholders want to make any decisions quickly and with the minimum spend on the business case. There is a perception that a broad budget for a project can be defined with a broad set of software requirements. The idea is that stakeholders present a project brief or description to the software team to estimate how much this will cost.
Below represents a concept called the Cone of Uncertainty (Source: Construx) as defined by Barry Boehm, an eminent software engineer who researched software economics. Boehm researched project estimation and costing and found that the uncertainty of software estimates could be wrong by a factor of 4 on both the high and the low sides. So for example, a project which eventually cost $1M could have been estimated at $250k or $4M. The curve suggests that as more detailed requirements gathering and discovery is undertaken the uncertainty reduces in the estimates.
If the organisation is mature enough, then they realise that the business plan is just a door opener to undertake further requirements capture in order to refine costs and make further stop/go decisions.
Some approaches to agile methodology in software development also give the impression that high level requirements gathering, and discovery can yield project success. In this scenario the requirements are used as a trigger to start the project and requirements are honed as the project progresses. Features can perhaps be descoped to deliver the project on time and to budget if the project starts to run over budget. Indeed, some requirements gathering acknowledges this issue by categorising requirements as must have, should have, could have, won’t have (the MoSCoW method). This can be very useful but with only high-level requirements then perhaps the project will run remarkably overbudget and so much functionality is descoped that the project does not reach anywhere near it’s intended features and benefits.
The case we are making here and the various statistics on project failure bear this out, is that basing budgets on high level requirements or poorly defined requirements will likely result in an inaccurate budget. When a project fails to meet its return on investment then that project can be classed as a project failure.
Our advice and experience is that if running projects to budget is important to you then do not tie yourself to a project budget made using very broad requirements. Certainly, you can use high level requirements to check if it may be worth pursuing the project, but the next step should be to undertake a detailed requirements capture, discovery and estimation phase before defining a budget and deciding whether to undertake the project.
Software requirements gathering is an often-overlooked skill and its contribution to project success is undervalued. Project success starts with correctly understanding what the system should do in the first place so start the project as you mean to go on and undertake requirements gathering well by using Requiment.
For more read ‘Why You Need to Use Software for Requirements Gathering and Management in 2023.’