I spent my early career bidding (and sometimes even winning!) contracts with the federal government for developing IT systems. Currently, as an academic, I have researched numerous case studies about IT projects that have experienced major challenges. Many of these systems never even made it to production.
There has been a common denominator in most of these contracts that needs to be addressed if we are going to fix the federal government’s IT acquisition challenges.
In most IT contracts, the first major phase is requirements definition. This allows the government and the contractor to flesh out the requirements and come to a common understanding.
The issue here is that these requirements are defined after the budget and schedule are locked in by the contractor’s proposal. If the requirements were not known before the start of the contract, what were the contractors bidding on?
House Building Analogy
Let’s look at a simple analogy to see what’s happening here.
You develop a Request For Proposal (RFP) for a contractor to build a new house for your family of four. The contract is going to go to the “lowest cost, technically acceptable” bidder. When the bids are received, your Source Evaluation Board (SEB) reviews them and determines that several of the proposals meet the requirements for your new house. The SEB then selects the lowest priced bidder from the acceptable contractors and the contract is awarded.
Rather than start the house immediately, the first phase of the contract requires the builder to generate a requirements document. This document will detail what the house is actually going to look like. Upon reviewing this requirements document, you notice there is only one bathroom. You think that two bathrooms is the minimum number acceptable for this project. You admit that the RFP didn’t go into this level of detail, but the contractor should have known it was necessary. With all their home building experience, don’t they know a family of four would require two bathrooms?
The contractor explains that having a single bathroom saves on construction costs, reduces utilities, and is an “industry best practice.” When you explain the need for an extra bathroom, the contractor explains that you must complete a contract modification. This change will add three weeks to the schedule and cost additional money. Now the house will not be completed on-time and on-budget unless you are willing to settle for a house that doesn’t meet your needs.
Know Your Requirements Before Putting out the RFP
IT development is far harder to estimate, schedule, and scope than this simplified house example. The analogy shows what happens over and over again in every IT requirements phase. If you lock in your schedule and budget, before you have agreed on the requirements, you are setting yourself up for some serious problems.
One thing that will help tremendously with our IT acquisition issues is providing detailed requirements in our RFPs. This isn’t an easy thing to do, but understanding what is going to be built, before the schedule and costs are estimated, will improve our chances of a successful project.