How many times have you heard this old story?

Our agency was going to save tens of millions of dollars by implementing a new system. We did everything right in our procurement, chose what looked like a great vendor, and got to work. Everything went well at first, but soon we were getting demands for more money and more time to meet milestones. As the expenses ballooned, we became frustrated, and so did our vendor. Eventually we shut the whole mess down. By the end, the only people talking to the vendor were from the General Counsel’s office. We spent millions of dollars and have nothing to show for it.

In the space between a burning need or great idea and successfully implemented, there are plenty of pitfalls that can derail a project. However, experience shows that we can point to one area that, time after time, causes projects to bog down and ultimately fail. This ominous swamp is the requirements morass—a part of the landscape in almost every project and one that must be traversed with care. Dr. Terry Raney, a former Air Force contracting official and currently a Senior VP at CACI says, “Clearly, the requirements generation and definition process is often the weak link in the acquisition process. A lack of well defined requirements will almost assuredly lead to problems and expensive contract changes as programs move forward.”

Why is requirements definition and management such a challenge? If you ask any system customer a simple question—“what are the requirements that you want the system to meet?”—you will usually receive a clear-cut and unequivocal answer. However, the first difficulty in requirements management is that there is rarely just one customer. The larger and more complex the system, the greater the number of customers, and each has his own opinion about what the requirements should be.

It is easier for the customer and the vendor to reach agreement on requirements if they work collaboratively to plan the requirements phase and to establish the requirements process. Once they agree on a set of requirements at a level of detail that does not allow for ambiguity, the next steps in requirements management are:

• controlling requirements changes,
• minimizing the addition of new requirements to avoid scope creep,
• tracking progress relative to a firm task plan,
• resolving issues with individual customers and vendor staff, and
• holding requirements reviews.

That’s simple. A requirement is something wanted or needed. However, complications arise when requirements are considered in a real-world context. In other words, think about a requirement in the same terms that a reporter uses to tease out a story: who, what, when, where, why, and how. Suddenly, a nice simple requirement is infinitely more complex.

The specificity of a requirement is extremely important, and there is no one size fits all rule to get this right. Three keys to laying out requirements are:

• Because of internal political reasons and the practical workings of vendor management, it is extremely important to be clear about what is a requirement. Don’t be misled by pseudo-requirements that don’t actually need to be implemented.
• Communication is what drives specificity. Talk to the stakeholders frequently.
• Change is a part of life in requirements management. It’s a rare project that has all of its requirements completely and accurately defined when the project starts. Assume changes.

Good requirements should result in something that is tangible. Creating a requirement whose goal is truth, justice, and the American way is nonsensical. How, exactly, is the vendor going to meet that requirement? Rather, requirements should lead to tangible systems or subsystems, processes, reports, or activities.

Customers define requirements, making this one of the most treacherous areas in the requirements morass. Good requirements managers understand who the customer is and the importance of supporting those customers.

Good requirements management begins with a clear agreement on who the customers are and their rights to define requirements. On a small project, there may only be a single customer. The larger and more complex the project, the more customers there will be. Dangerously, very large projects also generate what we call pseudo-customers: people who believe they are empowered to define requirements even though they don't have formal rights or permission to do so. The first task of a project manager is to begin to understand who the customers are and the definitional rights they possess. We recommend a formal process that unsparingly assesses the political and technical clout of each customer, and organizes the project to respond to the customers' varying abilities to add or change requirements.

Dealing with personalities and mixed agendas is always a daunting task, but not impossible. There are tools that help. Requirements usually are defined through a negotiations process which begins as part of a discussion within an agency and grows to encompass the vendor during the procurement process. We strongly recommend that everyone involved in requirements definition and management obtain, read, and commit to memory Getting To Yes, Fisher & Ury's classic book from the Harvard Negotiation Project.

In spite of the requirement manager's best efforts, customers with no official rights to define requirements will not only do so but will also demonstrate that they have the power to make those requirements stick. Requirements management is not just a technical job; it is also political. A great requirements manager has the brain of Albert Einstein, the organizational ability of Frederick Taylor, the spine of George Patton, and the tact of Miss Manners.

The best requirements come out of a structured interviewing process that asks the right people the right questions, and then rigorously documents the answers. The first step is to identify the interviewees—often one of the most difficult tasks since you can’t interview everyone and the selection of one group implies the non-selection of everyone else.

Prepare a list of questions before the interview and allow the interviewees to see them before you meet. If possible, try to observe the workers performing their job using the existing system, and talk to them while they are working. Gather up any artifacts that are available that will have an impact on requirements—this can be almost anything: reports, logs, memos, diagrams, flow charts, documentation, signs, and more. Meet with the interviewees again to make sure that you captured their information accurately. Keep detailed records.

Flux Stresses Everything…

The first important step in conforming to the business case is to know what the business case is. Most agencies will conduct a feasibility study to determine what needs to be done, its value, the business goals being supported, how it can be done, alternatives, and risks. Collectively, these become the business case, but are not the requirements.

Keep the requirements and the business case straight. Requirements talk about the way a system will work and what it is supposed to do. The business case says how the system will save agency money, do a better job, or eliminate waste.

Most if not all development efforts begin with a misalignment of the perceptions of the government and the vendor. One problem is that it is impossible to list all of the details of a system, regardless of size and scope but particularly for large systems, in the acquisition documents. No matter how good a job the government or the vendor does, their understanding of each other will be incomplete.

Early in the requirements process, it is critical to conduct an Initial Baseline Review. The purpose of this exercise is to guarantee that the requirements stated in the RFP and the solution proposed by the vendor actually conform with each other, and that everyone in the agency’s and the vendor’s teams understands exactly what was meant by the language that was used throughout the procurement process.

Traceability is the process of tying requirements together with the products that come out of development. By creating a traceability matrix, the manager ties requirements together with the tangible artifacts or products that meet them. Every artifact produced should be traceable back to a requirement. Traceability does not solve all requirements problems. Bad requirements with perfect traceability are still bad requirements. As the product is created, ongoing tests should refer back to the traceability matrix. The goal is to make sure that in each developmental step the requirements and the product are staying synchronized. The most effective practitioners of traceability don’t wait until the end of a project to test conformance to requirements.

Here’s a simple rule to live by. If you allow your requirements to change on the fly, your system will fail. Most organizations take a casual approach to requirements management, and pay the penalty in the long run. While flexibility is a positive trait and requirements managers may have to dance to the prevailing political tune, it is important to weigh the value of unrestrained flexibility against the risk of complete failure. To gain control of the requirements process, create a requirements management plan that is a living document.

The level of detail in the requirements management plan (RMP) is critical. Metrics are a key part of the RMP. At every level of the organization, it is useful to be able to quickly put your finger on the status of each requirement and the level of volatility of the requirements baseline (i.e., how many changes are being made to the requirements, and which groups of requirements are changing most frequently). By connecting the requirements metrics to the project plan, a picture of the relationship among requirements, volatility, work effort, and cost can emerge.

There are many more projects where requirements "go wrong" than projects where they "go right." Recognizing that there are going to be problems with your requirements and understanding the impact of poor requirements is a first step to getting or keeping them on track.

The first indicator of poor requirements happens as they are being created. If the negotiation process that defines the requirement results in a compromise that is so meaningless that the requirement doesn't actually require anything or cannot be understood, it is headed for trouble.

Even the best requirements can be turned to the dark side. Perfectly defined requirements can be ruined by poor management processes that don't maintain traceability. A perfect requirement executed foolishly is still going to look like a bad requirement.

There are a few very specific indicators that you are on track with your requirements and their management. Ask these questions to assess whether or not you're on the right track.

• Do all key stakeholders agree on exactly what the requirements are?
• Does everyone agree that the requirements constitute a baseline for the work effort? Has the baseline been "locked down" in a meaningful way? Do the customers accept that a baseline has been established?
• Is a requirements management process in place, and is it being followed?
• Is there a low level of volatility among the requirements?
• When a requirement is added, changed, or deleted is it a pro forma task or a cause for panic? If it is not a big deal, you're on track.
• Can the vendor answer customers' questions about potential changes including the implications for the business case?
• When the budget needs to increase or the schedule shift, can both the customer and the vendor justify these changes with facts, not guesses?

The approach described above is not the only way to generate good requirements. Many organizations have adopted iterative requirements definition in which requirements and the product are developed simultaneously. In other words, a few requirements are defined and a small prototype product is created. The stakeholders look at the product, suggest changes and new requirements, and another product results. The process continues iteratively until the business case is met.

There are pluses and minuses to this approach. While it speeds up development and reduces the often-heard "but that's not what I mean," it has greater risk and demands more up-front knowledge and flexibility from the customer. Iterative requirements definition also demands strong trust between the customer and the vendor since they are operating in a completely transparent environment.

All projects are not doomed to sink into the requirements morass if the process is managed from the start and the stakeholders are serious about enforcing discipline. Business process reengineering, establishing and maintaining traceability, conducting an initial baseline review, and using automated tools are not rocket science-but will usually result in a successful project.