Insights and EventsQuantifying Uncertainty
"The effective communication and shared understanding of stakeholder expectations is a critical factor in the success of any project. The risk associated with a poor understanding of needs is well known; late delivery of projects at higher than estimated cost, providing a fraction of the intended benefit.
A 2012 McKinsey & Co. survey of over 5400 large IT projects found that, on average, projects deliver 56% less value than predicted while running significantly over budget and over time. In fact, 17% of IT projects so exceed budget that the very existence of the companies involved are threatened. The most significant contributing factor was found to be the lack of early stakeholder involvement, resulting in poorly defined objectives and shifting requirements.
The IT industry attempts to communicate and validate its understanding of required business outcomes by producing and circulating requirements documents. These comprise hundreds, sometimes thousands of fragmented statements, written in set phrases like, "The system shall..." or, "Given... when... then..." In many cases this is the only vehicle that is used to communicate understanding of intent with stakeholders outside of the project, but the limitations of human short-term memory makes this method unworkable.
At AccessHQ, in our experience, around half of all requirements base-lined for development or tender contain omissions, conflicts, ambiguities or are just plain wrong.
"The single biggest problem in communication is the illusion that it has taken place."
- George Bernard Shaw
To put this into perspective, about half of all requirements contain “unknown unknowns” with respect to what the IT project understands of its stakeholders’ expected outcomes. It is little wonder that IT and the business stakeholders may be misaligned and that stakeholder expectations are not met.
Fixing this situation requires the ability to resolve conflicts with a diverse set of stakeholders within the context of established political, contractual, business and change management frameworks. This often leads to a large rework effort – an effort for which there is often limited or no budget. It is common for projects with such problems to stall or fail in their delivery. There is also a school of thought that believes making certain decisions too early in a project actually increases project risk, rather than reduce it. A key risk mitigation strategy of Lean manufacturing and Lean software processes is that of delaying commitment until the “last responsible moment”, that is, the moment at which failing to make a decision eliminates an important alternative. Agile refers to a similar “just-in-time” principle.
Knowing what needs to be asked enables effective communication resulting in all parties to a project obtaining a deep, accurate and shared understanding of needs. Quantifying uncertainty is not about guaranteeing perfect requirements documents and reducing risk to zero, it is about aligning IT understanding with stakeholder expectations and with project budgets and schedules to give a project the best chance of achieving valued outcomes, on time and on budget."
- Dr Dan Powell, Practice Manager AccessHQ
For requirements uncertainty that could significantly impact scope, conversations should be held earlier. For other requirements uncertainties, often those relating to the human aspects of the system (such as the human interface, training, etc.), open questions may only be effectively answered through iterative design with real people – e.g. through iteratively prototyping and evaluating usability and customer experience.
At AccessHQ, we believe that finding requirements deficiencies early provides the benefit of allowing uncertainty to be quantified; articulated in such a way that it can be addressed by the appropriate people at the appropriate time during the design and development/integration process.
Our proprietary Requirements Quality Assurance (RQA) technique helps projects to “know what they don’t know”. This goes well beyond mere acknowledgement that there are unknowns (and that the requirements are imperfect); it allows us to plan, schedule, budget and architect for the conversations that are required to align the understanding of IT with business stakeholders’ needs. Quantifying uncertainty focuses stakeholder conversations, workshops and interviews making them more effective.
Ⓒ AccessHQ | All Rights Reserved