“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions” – Albert Einstein
Introduction
One of the central activities and a major cost driver of business analysis revolves around the elicitation of business requirements since requirements reflect the needs of the users.
Requirements should be treated as an intangible asset which has a value depending on its quality and its overall business impact. It has to be safeguarded, documented, maintained and like any other intangible asset be subject to amortization during its lifecycle.
This article will delve into quantifying the hidden cost of requirements as well as propose certain measures so organizations can get maximum return on investment on their requirements.
Quantifying hidden cost
Cost of reworking requirements
Studies done by the University of Massachusetts showed that the initial estimated project cost will ultimately only account for approximately 50% of total project cost. The remainder of the costs will be spent on rework (any additional effort spent redoing a process or activity that was incorrectly implemented the first time or, due to changes in requirements from the client), with the costs increasing exponentially the later the problem is identified in the development life cycle.
This has a direct impact on the performance, productivity and ultimately the profit margins of a company.
Common reasons that necessitate rework include ambiguous requirements, a lack of essential documentation, inadequate testing and poor communication, especially during requirement elicitation and analysis.
Codeclimate.com, a company focused continuous improvement of software engineering, stated that a standard software development team reworks an average of 26% of its code prior to release - costing a medium-sized US business upwards of $4.7m a year. Further studies done by the Donald Firesmith from the Software Engineering Institute estimated that cost could total up to more than $30 billion per year in the US alone. Time and resources that could have been allocated to innovation and other more value generating endeavors.
Cost of undocumented requirements
The Agile Manifesto states ‘working software over comprehensive documentation’ as one of its four core values, yet many organizations interpret this statement as simply no need for any project documentation resulting in all info on a project being dispersedly committed to the memory of those who had the privilege of being part of the project discussions.
This could roughly be compared to paying for the recipe for a mouthwatering cake that you have had your eye on but then only receiving the final product. Although the cake is great, you cannot reproduce it when the cravings hit without having to spend more money on another cake that might not even be as good as the first one, since you don’t know what ingredients were used nor do you have the instructions on how to make it.
At an average salary of $78 000 per annum for an intermediate business analyst, this cost can quickly add up, with no recipe, or requirements, to show for it.
Returning to the matter at hand, the requirements are in essence the same as the cake recipe, both are intangible assets with details that should be documented and preserved, during and post conception.
The need for documentation exists independent of the adopted project methodology; with waterfall we would want the recipe upfront. Whereas with agile, the chef would be encouraged to provide just enough information at the right time, ensuring focus remains on the cake.
Cost of not exposing and managing requirements
Similarly, to undocumented requirements, inaccessible and unmanaged requirements result in the same outcome with business analysts having to reinvent the wheel when a similar problem presents itself instead of maximizing the return on existing requirements by re-using or improving on them.
Strategies to minimize wasted costs
As the costs for the above-mentioned aspects are difficult to quantify it is often overlooked when companies look at cost cutting or value adding initiatives, opting to rather scrutinize easily quantifiable costs like licensing fees or salaries.
Listed below are but a few strategies that a business analyst can implement to contribute to the reduction of the cost of requirements:
Solve the right problem
Invest time to do research and analysis to ensure that you understand and define the real problem. Most of the time the stated problem is the problem as it addresses the symptoms and rarely ever the source.
There is a variety of problem-solving tools and techniques available to assist in recognizing the root cause of a problem including the more well-known Ishikawa diagram or fishbone diagram and the 5 Why’s, where it generally takes five iterations of the questioning process to arrive at the root cause of the problem.
Lesser known but highly effective techniques include the Pareto Chart, Fault Tree analysis and the Failure Mode and Effect Analysis (FMEA analysis) which is a technique used to pro-actively identify problems before they occur.
Stating the correct requirements clearly and accurately
Any number of project documents produced will be of little value if the requirements stated are poorly defined, incomplete, or conflicting in nature leaving it up to the implementation team to interpret that which was not explicitly stated.
Ensure that your requirements are realistic and accurately reflects the needs and expectations of your stakeholders by verifying your requirements against a quality checklist and making use of techniques like process modelling, prototyping and reviews.
Performing frequent reviews
Although some part of rework will always be inevitable, studies have shown that performing design, requirements, and code reviews earlier and more frequently in the project life cycle significantly reduces the amount of rework, in some cases to less than 10% of the total project costs.
A study done in 2008 by Mark W Huston at the University of Montana concluded that the optimum time spent on a review is between 16 and 24 hours to allow for the most efficient error detection rate. Any lesser time spent will result in an unacceptable number of defects in the product while a longer period will see the return on investment diminishing as it become increasingly difficult to identify defects and the downstream impacts on the system.
Although it might still be worthwhile when working on a mission critical project, it can become fiscally wasteful especially when looking at COTS, fixed budget, or time-boxed projects.
Follow a requirements management plan
Proper management of requirements yields value beyond the project lifecycle by enabling the business analyst to define, trace, analyze and track changes to requirements in a secure, central and accessible location.
Sorting requirements by category, priority and risk creates consistency that increases the reusability and traceability of requirements by having the relevant information organized in a logical manner that is easy to understand. In its entirety requirements management allows for improved collaboration between stakeholders subsequently leading to minimized rework required and an extended lifespan of existing requirements.
Conclusion
While not being exhaustive, the above list will address a substantial portion of the additional, usually unbudgeted cost of rework on requirements whilst ensuring that the company’s assets will continue to provide value in the present and in the future.
*This article was originally published in the BA Digest Q2 edition of 2023
Commentaires