The Challenge of Enterprise Requirements Management

of the Agile Manifesto , by valuing "process" over "individuals and interactions," "comprehensive documentation" over "working software," and "contract negotiations" over "customer collaboration."

Waste(ful) Management

Early specification of detailed requirements forces an organization to manage costly artifacts using equally detailed project plans. These detailed plans serve to create the illusion of control, but really track the transformation of requirements documents into different phases of models and code through analysis, design, and coding phases. These transformations add little value to aligning the project team with the overall goals of the project, and should be viewed as waste.

In fact, organizations that focus on processes to manage and transform documents and models lose line-of-sight with the end result. An unintended consequence of these distractions is that teams lose their identity, since their whole worth is now tracked against how effective each individual is in completing his/her assigned task from the organization's process map. Add to this the need for detailed project plan tracking, and the end result can be a highly dysfunctional organization that is poorly aligned with creating the highest value business products. This should come as no surprise, since this violates the Agile Manifesto by valuing "following a plan" over "responding to change."

In large enterprises, early specification is not only wasteful, but becomes redundant when compared with acceptance test cases. These same organizations require enterprise system tests that must be painfully created to validate the enterprise requirements. The system tests on their own represent the clients' desired view of the system, and can stand alone as enterprise documentation of the system. Lean and Agile practitioners often suggest that the most efficient approach is to let the acceptance tests themselves represent the legacy documentation of the enterprise.

"But That's Not What the Requirements Said..."
Perhaps the most obvious (but most ignored) sign of a dysfunctional IT organization is when a well-meaning project manager rationalizes bad execution by claiming "...we implemented according to the requirements." When this excuse is heard, it is time to stop the assembly line and tear down silos. Unfortunately, the typical organizational approach is to bring in "process experts," thus kicking off the painful search for the "root cause" of requirement gathering issues.

Requirements gathering is seen as a process that can only be undertaken by specialists, and so the Business Systems Analyst organization appears. This group of specialists means well, but its activities can end up creating an inefficient buffer between business and IT. This is analogous to commissioning a portrait, but having to communicate with the artist through a third party--through detailed documentation created by a well-meaning art specification specialist. Imagine an artist, painting your portrait according to a written description, with a third-party "expert" providing feedback and clarity to the artist throughout the creation of the portrait. This is a scary analogy, particularly since software development is often referred to as "art."

There is no doubt that some requirement specifications are better than others. There are clear and vague ways to state the same thing. But there will always be opportunities to misinterpret words based on varied backgrounds and experiences of the reader (especially if the reader is isolated from the writer and can only request clarity by capturing a list of issues and emailing them to the author).

Most organizations realize this and require rigorous inspections, complete with formal sign-off in an attempt to create quality by inspection. Unfortunately, these inspections are not held often enough, and inspectors are expected to review hundreds (or worse, thousands) of pages of documents in a short amount of time. A clear sign of dysfunction is when