In March 2001, the General Accounting Office (GAO) issued a report that discussed the importance of matching needs, that is, requirements, to resources, that is, supplier capability to perform. The report specifically looks at the Department of Defense and its general practice of contracting for large weapon systems, but the results of the GAO study are applicable to any project, public or private sector, large or small, complex or simple. The findings, when viewed practically or logically, probably are not surprising. Yet, the very problem that the findings focus on is the problem that invariably dooms many IT, and other, projects. Namely, the customer's requirements are not matched to the existing resources before starting the product development cycle.
In the rush to start coding, euphemistically speaking, the project is started without giving proper consideration to the available resources—human, capital, or technical. In short, planning is rushed, incomplete, or not done at all. Consequently, the project is not successful in the sense of performing as one would hope or expect.
The GAO found that a match between a developer's resources and a customer's expectations is eventually met on just about every project's product. But the key distinction between successful products—those that perform as expected and are developed within estimated resources—and problematic products are when this match is achieved. When a customer's needs and a developer's resources were matched before a product development started, the more likely the development was to meet cost and schedule objectives. When this match took place later, after the product development was under way, problems occurred that took significantly higher investments—sometimes double—of time and money.
The study found three factors that were key to matching needs and resources before product development began. First, developers employed the technique of systems engineering to identify gaps between resources and customer needs before committing to a new product development. Second, customers and developers were flexible. Leeway existed to reduce or defer customer needs to future programs or to allow the developer to make an investment to increase knowledge about a technology or design feature before beginning product development. Third, the roles and responsibilities of the customer and the product developer were matched, with the product developer being able to determine or significantly influence product requirements. In cases where these factors were not present at program launch, product development began without a match between requirements and resources. Invariably, this imbalance favored meeting customer needs by adding resources, which resulted in increased costs and later deliverables.
Matching the customer's needs to the provider's resources would seem a logical thing to do. The fact is, though, many projects are begun with little thought and less planning. The only basis for the commitment in these cases is that the project seems doable and perhaps is similar to one that the organization has already done. Unfortunately for both the organization and the customer, even if the product is finally delivered with the functionality desired by the customer, it usually costs more and takes longer if the needs were not matched with the available resources before the product development began.
"Best Practices: Better Matching of Needs and Resources Will Lead to Better Weapon System Outcomes," General Accounting Office Report GAO-01-288 (March 2001).