Chapter 2: Learning Requirements is Our First Priority

---

The two things that should drive your project are requirements and deadlines. The calendar tends to take care of itself, although there will be those white-knuckle moments every now and then. As for requirements, with the possible exception of hosting productive meetings, the single most difficult challenge facing the project manager is ensuring that the right requirements are derived from scope.

2.1 The Trouble with Requirements

People generally take one long look at scope, jump to conclusions regarding "the solution," then rush off to build it without adequate analysis and planning. We can illustrate this natural tendency by reflecting on the Integrated Services Digital Network (ISDN) project presented in the first chapter. The scope was the creation of an automated process for selling and installing circuits on the public telephone network. The assumption was that this new system could be constructed with a few menus linking the user to legacy information technology (IT) infrastructure, thereby drawing on the existing processing power and knowledge base to streamline the ISDN provisioning process.

In essence, what happened was that the requirements, if you will, were never fully examined. We were well into the coding process and holding meetings with many of the targeted beneficiaries long before the feasibility of our basic assumptions had been properly vetted. Theologians call this a "leap of faith." Good project managers call this "dumb."

Another common defect in technical projects is the comfort zone issue, wherein designers specify products with which they are most comfortable, and hope or assume that the selected product will satisfy requirements and be readily assimilated into the legacy-operating environment. This is understandable and hardly a capital offense, but it is putting the cart before the horse. Requirements should drive specifications, not the other way around. Remember that requirements describe what the project will accomplish, and that specifications state how those requirements will be implemented.

Finally, we must acknowledge that gathering requirements is a daunting task to the degree that multiple parties must be consulted, conflicts resolved, and compromises made. There is an old engineering joke about a camel being a horse designed by committee. I suspect that too many project managers shy away from a rigorous requirements process for fear of creating a beast that has no resemblance to the original assumptions made about scope. In truth, creating an honorable consensus on requirements can be as rough as getting legislation through Congress without painful bickering, Frankenstinian mutation of design elements, or the forced inclusion of deliverables supporting extraneous agendas. As our ISDN example suggests, however, if you do not follow the requirements process faithfully, the results may be far more disastrous than the confusion inherent in the democratic process of building consensus.

---