When Requirements Failures Become Epic Fails
By now, the arguments for improving product requirements are very familiar – all too familiar. Bad requirements lead to misconceived projects, many of which fail outright. The survivors can waste frightening quantities of time, effort, and money. (And if you've been unlucky enough to be part of one, you don't want to repeat the experience.) In technology companies, even the best requirements are no barrier against failure: insights into what kinds of problems customers face, how the company's products and services can help address them, and why they'd consider getting the vendor's help remained siloed in the requirements, never reaching other people in the company – sales, marketing, support, etc. – who deal directly with customers and partners.
Nonetheless, it wasn't until relatively recently that the market for requirements tools expanded and diversified, as described in my previous post. Many organizations had the same attitude toward requirements that most of us share about regular visits to the dentist: We understand the clear, direct benefits of changing our behavior, but we'd rather not make the effort. Clearly, something changed in the last few years to increase the general interest in adopting better requirements hygiene.
In fact, many things changed, all pointing in the same general direction. Not every potential requirements tool adopter experienced the same new pressures, so you won't be able to identify a single, iconic tale. Instead, the history of the requirements tool market is more of an anthology of stories that have the same moral: the business consequences of bad requirements are no longer tolerable.
Increasing The Speed Of Rejection
In the technology industry, SaaS was one of these developments. Realizing that SaaS was a different business model, not just a novel delivery mechanism, tech vendors venturing into SaaS realized the immediate impacts of bad requirements. The axiom Build it, and they will come had a corollary: Build it badly, and they will leave.
Agile, too, contributed to this new concern over requirements, among both IT departments and technology vendors. If you shorten development cycles, you increase the need for an economy of effort in each iteration. It's no accident that user stories are part of Agile, since they move quickly to the punch line for development teams: Who is going to use this technology, how are they going to use it, and why? That question is just a rephrased version of, What projects should we undertake, how should we prioritize them, and how should we design them?
Increasing The Costs Of Waste
In this fashion, the medium of requirements in many teams adopting Agile changed. So, too, did the requirements process. Teams could not have shorter iterations unless the content improved, creating a new social contract between the authors and consumers of requirements. Business analysts and product managers have to master the difficult art of delivering "just enough" requirements, at a challenging level of coherence and reliability, given the short time frames. Development teams have to be clear about the type of content they need and when they need it. Trust between these two groups is critical, since protracted arguments ("You didn't give us useful information!" "You never told us what you needed!") destroy any chance of building working technology in short iterations.
SaaS and Agile are only a small part of the explanation for the requirements tool market's evolution. The recession contributed, as did other changes that we discuss in both my report and Mary Gerush's just-released, complementary analysis of this market. In many cases, these same forces are changing the role of product managers and product marketers, as producers, reviewers, and purveyors of requirements. Go through the report and replace the phrase requirements tool with PM, and a lot of the analysis will probably still make sense.