A consulting colleague recently asked me what topics organizations are most interested in learning more about and getting help with. I said requirements and return on investment (ROI) are major concerns I hear expressed. In discussing further, it became evident to me, though, that many organizations seem aware of only the tip of the iceberg about these two business-critical subjects, especially the ways and extent that requirements and ROI are inextricably linked.
In all industries, but especially in IT, the rule rather than the exception seems to be that projects fail to deliver adequately what is needed despite severely overrunning budgets and schedules. Some skeptics and cynics even suggest that actual project ROI so seldom is calculated, let alone compared to the estimated ROI that was the basis for doing the project, because those charged with projects know implicitly they're not producing a reasonable return on the organization's investment. Using ROI effectively is a key to project success, and ROI difficulties lead to projects failing to deliver expected value.
While practically everyone acknowledges that requirements are an issue, the full extent of poor requirements' impact is far greater than generally recognized. Inadequate requirements overwhelmingly cause most project difficulties, including ineffective ROI and many of the other factors commonly blamed for project problems. For instance, many senior managers blame the project manager/team for overrunning estimates, but some insightful experts cite poor estimates (typically by those same blaming senior managers) as the main reason projects overrun their estimates. Though often not recognized, poor estimates usually are due mainly to inadequately defined requirements.
No estimating technique, project management tool, or whatever other magic bullet one espouses can overcome the fundamental failure to adequately understand the REAL requirements the project must satisfy. Garba
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
ge in, garbage out.
REAL requirements
I put the word "REAL" in all capital letters to differentiate it in three ways from other uses of the word "real." First is simply mechanical because all capital letters tend to hold up in many formatting situations which may remove other emphasis techniques such as italics, underlining, and color.
Second, the requirements must be real and right. But this is not meant to imply Sarah Palin-like value judgments, such as needs vs. wants. Such distinctions often are wrong, especially when it's the wrong people (too often us) with wrong understandings wrongly declaring what's a need and what's a want. In the name of efficiency and controlling scope, many people reduce the number of requirements by excluding the wants, but that often turns around to bite them in the form of scope creep as they quickly learn that the excluded wants indeed are needs and must be reinstated — at higher cost.
Rather, I use REAL to mean the requirements we end up with. That is, most software projects go through a costly and time-consuming series of iterations building the product/system we think we should, finding out it's not right, and then modifying what's built over and over until we've finally backed into the right, REAL requirements. Only these requirements are a suitable basis for creating and determining the ROI of solutions.
Third, REAL requirements are business requirements, where the term is used correctly as explained below. Most people misunderstand and misuse the term, and what they commonly call "requirements" actually is high-level design.
REAL business requirements
There are two importantly different types of requirements. Both types need to be defined adequately and in the appropriate sequence.
Business requirements are what must be delivered to provide value. Three of the words in that brief definition are more important than the others. First is value. Something is not a requirement if it doesn't provide value. Ultimately value is measured in financial ROI terms, so accurately identifying the business requirements is essential to determining ROI. Value is provided only when the requirements are delivered (met, satisfied, or accomplished). What is the third important word in the definition of requirements. No, that's not a question. Requirements are whats, as opposed to the hows that deliver them.
Business requirements are from the perspective of and in the language of the business, user, customer, or stakeholder. The term "business" is used broadly and includes at work and personal, for profit and not for profit. Business requirements are conceptual and exist within the business environment, which means they must be discovered. There usually are many possible ways to accomplish the business requirements.
However, most requirements authors and conventional common usage tend to think the requirements are the product/system/software requirements of a human-defined product or system that presumably is one of the possible ways how to accomplish the presumed business requirements. Calling them requirements, or even business requirements, doesn't change the fact that they are product requirements, which actually are high-level design. Designs don't have to be technical or engineering detail. The product or system is a presumed solution that will provide value if and only if it satisfies the REAL business requirements.
Because product requirements generally are based upon so many presumptions, and each presumption increases the chances of error, the conventional almost total emphasis on product requirements is unlikely to satisfy the REAL business requirements. Contrary to conventional wisdom, most creep (changes to requirements after they supposedly have been established) is not due to unclear/untestable product requirements. Instead, much of creep occurs because the product requirements, regardless of how clear and testable they are, fail to satisfy the REAL business requirements. Such failure is largely due to inadequately defining the business requirements, which in turn is due to flawed conventional wisdom that product requirements are the requirements.
A second flaw in the conventional view of requirements further leads inevitably to inadequately defining REAL business requirements and thus causing creep. This widely accepted view says that business requirements are high-level, vague, mainly objectives that decompose into detailed product requirements. According to this view, the difference between business and product requirements is simply a level of detail or abstraction: If a requirement is detailed, it's a product requirement, and if the requirement is high-level and vague, it's a business requirement.
This levels-of-detail model is 100% wrong because business requirements are whats and product requirements are hows. Whats do not decompose into hows. Hows are responses to the whats, and if the whats are not known in detail, trying to detail the hows can only result in presumptions that turn out to be wrong.
Business requirements are not just high-level but also need to be driven down to detail. No matter how far down in detail they go, business requirements are always business deliverable whats that when delivered contribute to providing value.
REAL business requirements do change, but not nearly so much as people think. What mainly changes is the awareness of the REAL business requirements. Building, checking, and revising a presumed product is an egregiously inefficient way to arrive at the REAL requirements that the product must satisfy to provide value. As people become more aware of the REAL requirements, they usually don't realize that the REAL business requirements have been there all along and that they just didn't know how to identify them.
The key to defining a product/system whose requirements don't creep so much is to first discover the detailed business requirements and then map them to a product/system that will satisfy them and thereby provide REAL value. This not only takes more effort than often is allocated in projects, but it also requires skillfully applying mindsets, approaches, and techniques that even many experienced business analysts are not familiar with.
REAL ROI
I use "REAL" in much the same way to highlight and differentiate REAL ROI. It is determined using a specific methodology that overcomes 10 common shortcomings that otherwise render many, if not most, ROI uses ineffective. (Additional information and a white paper on ROI pitfalls are available on my ROI consulting partner ProveIT's website.
The first and most important thing about right, reliable, and responsible REAL ROI is to start with the REAL business requirements deliverable whats that provide value when satisfied. The "Return" in return on investment comes from that value, whereas the investment/cost comes from implementing the product/system presumed solution how.
ROI typically is calculated to support decisions regarding some proposed purchase or course of action that the proponent wants. Too often, ROI is driven from the perspective of the presumed solution, which does not itself provide value. Proponents tend not to realize it because they are so intent on advocating their proposed solution. Not surprisingly, presumed benefits driven by a proposed solution often are not very convincing. The claimed benefits may not be believed or they may be believable but not something the decision makers truly value.
REAL ROI believably and convincingly quantifies both tangible and intangible return benefits that the decision makers truly value because the value comes from meeting their REAL business requirements.
The other half of ROI involves identifying the investment costs of achieving the benefits with the proposed solution. REAL ROI explicitly links the proposed solution's differentiating features to the REAL business requirements they will satisfy, which is key to making the solution and its costs believable.
-------------------------------
About the author: Robin F. Goldsmith has been president of Go Pro Management Inc. consultancy since 1982. He works directly with and trains business and systems professionals in requirements analysis, quality and testing, software acquisition, project management and leadership, metrics, process improvement, and ROI. Robin is also the author of Discovering REAL Business Requirements for Software Project Success.
