Effective Strategies for Managing Requirements

Several years ago, I called upon an old acquaintance who had recently assumed management of a troubled program. I told
him that I would like to help him manage his requirements. He told me that he did not need any help because he had asked the advice of a mutual friend and NASA manager. That advice was: “Just say ‘no’ to all proposed changes.”

The advice was not necessarily bad, it was just not appropriate to this manager’s problem. A major problem with the program was that it had very poor requirements that could not be satisfied within budget or schedule. I have no idea what the program manager actually did, he moved again fairly soon, but the program has since been canceled.

You may be surprised to learn that you are not really managing requirements. Program managers tend to focus on subjects other
than requirements. This occurs because of a bad assumption — the manager assumes that everyone knows how to write requirements, thus the requirements process will take care of itself.

Most program managers come from a technical background and will focus on the non-technical aspects of the program, since these are new and alien. The program managers know that they do not fully understand budgets, so more attention goes to budgets. Besides, the program manager’s boss will focus on budgets, and not on requirements, so the program manager places more attention on that which interests the boss.

Most people understand that bad assumptions are traps just waiting to get you, and this bad assumption — requirements will take care of themselves — is no different. This paper will look at how this bad assumption can wreak havoc with a program, the types of problems that occur because of this bad assumption, and what NASA program managers can do to improve their requirement management process.

How Failure to Manage Requirements Affects Programs

If the program requirements are not well understood, there is not much hope for estimating the cost of the program. In today’s environment — 15% overrun and your program may be canceled — it is foolish to budget incorrectly. But you cannot budget correctly without a good set of requirements.

Werner Gruhl developed a history of NASA programs versus cost overruns (Figure 1). He attributed much of the problem of cost overruns to the failure to define the program properly in Phase A and B so that good cost estimates could be made.

Even with the best cost estimate, many programs will encounter overruns because of changing requirements. This phenomenon is one of the aforementioned program manager was trying to avoid. The time to avoid this problem is not in Phase C or D but at the beginning of the program.

Therefore, I interpret the Gruhl chart differently. If you have not done a good job in Phase A and B in defining and confining your program, including documenting the requirements, you are going to encounter large numbers of changing requirements and the cost will go up accordingly.

The relationship between program cost and requirements is cyclic (Figure 2), you cannot affect one without affecting the other — but program managers try. Budgets are cut, but the program manager tries to keep the requirements intact. There are some occasions when a design change will save money and all requirements will still be met, but this is a rare occurrence.