REQUIREMENTS MANAGEMENT: HOW IT BENEFITS YOUR BUSINESS

Transcription

1 REQUIREMENTS MANAGEMENT: HOW IT BENEFITS YOUR BUSINESS TERRA FIRMA JULY 2013 In 2001, a group of researchers set out to develop a definitive list of risk factors as a reference tool for project managers i. They had a significant incentive their preliminary research indicated that: 25% of projects were cancelled outright without delivering anything of value 80% of projects overran their budgets, with an average budget overrun of 50% 75% of large system projects delivered operational failures, with the final product either not ii iii iv functioning as specified or not being used. The researchers recruited three expert panels of project managers with extensive experience working on major projects; one group in Hong Kong, one in Finland and one in the United States. Each group collaborated to produce a ranked list of project risk factors, which was combined into a single ranked list. Poor requirements management made it into the Risk Top Ten twice: at number two (requirements not thoroughly defined) and number six (constant changes to requirements). More recently, CIO magazine estimated that up to 71% of projects which failed did so because of poor requirements management. v THE HIGH COST OF PROJECT FAILURE The cost of project failure is high: the Standish Group has estimated that total waste on project overruns in the United States alone was $US55 billion per annum and a more recent McKinsey Report identified total cost overruns of $US66 billion across 5,400 projects studied. vi To put this in perspective, there are 182 countries in the International Monetary Fund: the GDP for 106 of those countries was less than $US66 billion. When you think that a relatively small group of people (5,400 project teams) can lose more money on a single project than an entire country can generate in a 12 month period, the scope of the problem becomes evident. How does that apply to your organisation? Let s assume that the average budget overrun of 50% has remained constant. That means that for every $100 your organisation spends on projects, you are Terra Firma Pty Ltd Page 1

2 getting approximately $66 of value and losing roughly $33 in cost blowouts. Consider your current year budget for IT upgrades, change initiatives and other projects. Can you really afford to waste 33% of that money? MANAGING REQUIREMENTS TO ENSURE SUCCESS The concepts of requirements and requirements management have been around since the early days of software engineering over this period, a number of methodologies have been developed to improve the requirements management process. Essentially, each methodology describes a four step process: 1. Requirements elicitation, when requirements are gathered from stakeholders and documented. 2. Requirements analysis, when the requirements are checked for clarity, completeness and consistency. At this point, the business analyst begins to engage with stakeholders to prioritise and validate the requirements. 3. Requirements documentation and validation, when requirements are logged or documented and the stakeholder input is finalised and agreed. 4. Requirements traceability, where the outputs of the project are monitored and measured to confirm that they meet the requirements. ELICITATION A well-run elicitation phase helps to ensure that all requirements are identified. This allows the requirements to be defined appropriately and reduces the risk of constant or ongoing changes to the requirements. During the elicitation phase, the business analyst works with the project stakeholders to develop a list of requirements that the project must deliver. There are different schools of thought on the amount of detail required to complete this stage: some projects have thousands of documented requirements, whereas an Agile project might only have half a dozen, documented as user stories. During the elicitation phase, keep an eye on the level of detail in the requirements. In some cases, a project is derailed by too much detail. This often happens when the stakeholders have had bad experiences with projects which have under-delivered in the past: they decide that the best way to avoid this happening again is to provide minutely detailed functional requirements covering every possible feature of the project and to insist that every requirement is absolutely essential to success. The end Terra Firma Pty Ltd Page 2

3 result is usually an unwieldy mess of confused and sometimes contradictory requirements that cannot possibly be met by any deliverable. Other common pitfalls during the elicitation phase are gathering too little information or not ensuring that requirements meet the key characteristics of a requirement (as sent out in the Business Analyst Body of Knowledge (BABOK)) vii. In this case, the project will either spin its wheels while the developers try to clarify vague requirements or deliver something which is the development team s approximation of what they thought the user wanted. These issues can be corrected relatively easily by meetings with stakeholders. Use a root cause analysis or similar technique to find out what is driving the over or under performance, and work with all parties to bring the process back on track. This problem can also be identified and corrected during the analysis phase. ANALYSIS Analysis ensures that the requirements are thoroughly defined before being signed off. This also reduces the risk of constant, ongoing changes to the requirements. Analysis may occur concurrently with or following the elicitation phase. During this phase, the requirements are checked for clarity, consistency and completeness. The business analyst may also begin to engage with the stakeholders to validate and rank the relative importance of the identified requirements. Projects may run into difficulty here if stakeholders insist that every requirement is equally important, or if there are significant differences in the importance that different stakeholder groups place on requirements. The first issue is likely to lead to time and budget overruns, as the development team attempts to build the perfect product. The second is likely to lead to conflict (and time and cost overruns!) as the project team try to work out whose high priority requirements get built and whose are shelved for later releases. The good news is that these issues can be resolved quickly and cheaply by negotiation. If necessary, the project sponsor or another senior person should be asked to mediate until a satisfactory prioritisation has been agreed on. DOCUMENTATION AND VALIDATION This is the final opportunity for the business analyst to ensure that the requirements have been thoroughly defined. Once requirements have been documented, signed off and passed to a development team, the cost of changes escalates (as does the risk to the project from each change). Terra Firma Pty Ltd Page 3

4 During this phase, the business analyst documents the requirements and obtains stakeholder agreement that the requirements accurately reflect their needs. A well-defined requirement has the following characteristics: viii Unitary (only addresses one thing) Complete (fully stated, no missing information) Consistent (does not contradict any other requirement or other authoritative document) Atomic (no ands or buts remember, it must be unitary) Traceable (meets a business need identified by stakeholders) Current (has not been made obsolete by time or project progress) Unambiguous (can only mean one thing) Verifiable (possible to demonstrate that the requirement has been met by the deliverable). During the analysis phase, any requirements that do not meet the characteristics of a good requirement can be taken back to stakeholders and refined with relatively little cost to the project. Perform a careful review before signing off and releasing requirements to the development team for action! TRACING Throughout the development phase, the business analyst confirms that the deliverables meet the documented requirements. This is usually done through the various testing processes, which involve a tester completing a series of steps to demonstrate that a deliverable meets one or more requirements. As development proceeds, the cost of remedying defects or shortfalls against requirements becomes higher. Ideally, the project should control against this risk by implementing stringent quality control procedures to ensure that each deliverable is measured against the requirements during development and prior to release. A sound requirements change process also reduces risk, by eliminating unnecessary changes to requirements and ensuring that the impact and risks of any required changes is fully understood. Terra Firma Pty Ltd Page 4

5 CONCLUSION Bad requirements management is a common cause of project failure, leading to significant financial losses. Careful requirements management and a swift response to any issues will mitigate this risk. AUTHOR CONTRIBUTIONS: Andrea Tappe i Schmidt, R., Lyytinen, K., Keil, M. And Cule, P., Identifying Software Project Risks: An International Delphi Study, Journal of Management Information Systems, 17, 4, pp 5 36 ii Gibbs, W.W., Software s chronic crisis, Scientific American, 271, 3 (September 1994), iii Johnson, J., Chaos: the dollar drain of IT project failures, Application Development Trends, 2, 1 (January 1995), iv Walkerden, F. And Jeffery, R. Software cost estimation: a review of models, processes, and practice, Advances in Computers, Vol 44, San Diego; Academic Press, 1997, pp v Lindquist, C., Fixing the Software Requirements Mess, CIO, 15/11/2005, accessed 11 March 2013 vi Standish Group (2004). CHAOS Report. West Yarmouth, Massachusetts: Standish Group vii Business Analyst Body of Knowledge (BABOK) viii Business Analyst Body of Knowledge (BABOK) CONTACT US If you require assistance with Requirements Management, Terra Firma can help. Our experienced consultants can guide you through elicitation, analysis, documentation and traceability. Contact us today at info@terrafirma.com.au. Terra Firma Pty Ltd Page 5