A recently married young lady asked her parents for money to build a new, single-family home. The parents asked some reasonable questions to determine if they could help and whether the daughter fully understood what she was getting into. In response to her parents' questions, it was revealed that the daughter did not know how much the house would cost, how big the house would be, how many bedrooms or bathrooms it would have or any other specifications. She only knew she needed a house and a lot of money to build one.
Since her parents did not have an unlimited amount of money, they told their daughter to hire an architect, figure out all the details involved and then report back to them with a competitive, fixed-price to build the house.
Unfortunately, this house-building example resembles a common scenario in the Defense Department when program leaders seek funding for information technology projects. In the DoD the services of an IT architect are not always sought at the beginning of a technology project, and the processes of designing and building are too often conducted in parallel. Inadequate planning can result in overspending, increased business and technical risk and hasty decisions made under less than ideal conditions.
Programs leaders need the solutions that the most current commercial technology provides, but some fail to develop firm requirements or a clear definition of the end results to obtain a fixed-price bid from a vendor.
These types of program leaders are often rushed, and they may move forward without obtaining a clearly defined blueprint. Then they may compensate by using time-and-materials or cost-plus pricing mechanisms to allow the greatest flexibility in the scope of the program. In doing this, the government assumes all risk of cost increases, even when it is reasonable to pass some or all risk to the contractor. This would be the equivalent of deciding the type of house to build as you are pouring the foundation and putting up the walls.
The government has a history of failing to successfully complete IT projects on time and within budget, which equates to inadequate controls on spending in many cases. Some vendors have become comfortable in assuming that the government will change its course and incur the additional costs associated with many change requests during the life cycle of the project. But establishing a solid relationship between government and vendor program leaders will go a long way to improve results. Setting clear expectations up-front for each party will pave a smoother path for the project teams on both sides.
There must be disciplined contracting and program management practices. Well-defined requirements must be included in a performance-based Statement of Work (SOW) or Statement of Objectives (SOO) to allow a vendor to propose a fixed-price bid for commercial IT services and solutions. If information is not sufficient for vendors to submit a fixed-price offer for the project, then the process should be halted and more detailed requirements documentation should be developed to include in a revised Request for Proposal (RFP).
If this cannot be done, time-and-materials or cost-plus pricing should only be used for the portions of the work that cannot be defined adequately, and options should be established to obtain competitive pricing for additional work that will likely be required.
Alternatively, the work should be separated into acquisition increments that will be satisfied by individual contract actions for which requirements or objectives can be adequately defined. The increments should be sequenced and designed in such a way that required capability is not dependent upon subsequent increments. The IT architect should specify the minimum, appropriate standards that will assure compatibility among capability modules acquired in separate increments.
The requirements document or SOO should be a formal, binding document. The vendor's proposal response to the requirements document or SOO should become the basis for the contractual documentation that will bind the vendor to deliver a solution that meets the requirements or satisfies the objectives.
If a performance-based SOO is used by the government in lieu of a requirements document, the proposal must represent a detailed SOW for the contract. The government SOO is not made part of the contract per the Federal Acquisition Regulation, so it is essential that each contractor's proposal SOW adequately describes the solution and/or all of the work to be performed.
The competitive solicitation process to implement commercial software should include an explanation of how the contractor will demonstrate that the government objectives will be met; either through the core software, an enhancement to the core software, a custom report, an interface to a system that will continue to operate with the new software, or by requiring a conversion of data from an existing software system that will be retired.
During the technical evaluation of each proposal, the burden is on the government to determine that the proposed solution and performance measures are adequate to assure that the government's objectives will be satisfied.
In a fixed-price contract both parties must know what their roles and responsibilities will be for the duration of the project. The proposal should impose specific duties and any essential time constraints on the government.
If the government does not perform these duties, the price will be adjusted to reflect this unmet condition. To prevent this from happening, these responsibilities must be endorsed by leadership on both sides with a commitment to work together. If the government cannot accept these responsibilities and time constraints, they must be negotiated and modified before contract award. Once the winning proposal is selected, the government must plan and organize to carry out its duties.
Ambiguity can create profit opportunities for vendors and heartache for inexperienced government program personnel. To curtail unnecessary spending due to poor planning, the government must establish firm requirements or objectives that the vendor clearly understands — and then stick to them.
Only requirements changes that are essential to comply with emerging law and regulations and satisfy urgent, mission-essential needs should be made during contract performance. This reduces business, technical and price risks. Other necessary changes should be made after the solution is successfully delivered for the agreed fixed-price.
Some vendors have been able to take advantage of poorly managed contracts in the past, but in going forward, it is important to change this mindset and accept that the initial contract is the binding contract for the scope defined. The government must also stop the expectation that prices are fluid even in a fixed-price environment.
During a time when the Defense Department must support our troops in ongoing missions in Iraq and Afghanistan and fulfill international commitments, a concerted effort must be made by the DoD to administer IT contracts with strict discipline, careful planning and best commericial practices.
The next time your kids want money to build a house, make sure there are firm requirements and a solid blueprint before the construction starts. If you're implementing commercial IT or IT services in the government, the same practices hold true.
Many of the tools and best practices mentioned in this article are available through the DoD Enterprise Software Initiative (ESI) Web site at http://www.esi.mil.
Mr. Chris Panaro, of Panaro Dynamics LLC, provides contract support to the DoD Enterprise Software Initiative.