Navigate IT Contracts with Vendors to Meet Mutual Goals
Navigate IT Contracts with Vendors to Meet Mutual Goals
Editor’s Note: Lou Ray is President and CEO of Alexandria, VA-based MATCOM, a company that provides information technology, engineering, and technical services to government. He may be reached at email@example.com
In today’s government contracting market, there is simply not enough money to modernize all of the government systems that need updating. Exacerbating this reality is the fact that system development failures waste what few resources do exist. Why is that? Truthfully, major system development efforts rarely fail because of technology. More often, the root cause of failure is a lack of integrity in the development process.
Integrity, in this context, is the establishment of a common goal and the elimination of private agendas. Such integrity can be achieved in a govern-ment-contractor relationship, but not without substantial attention and effort from both sides.
In the last 35 years as a government contractor, I’ve seen technology progress from simple vacuum tubes to today’s network-enabled desktop machines, which wield more computational power than the largest mainframes of the mid-1960s. Over this same period, the technical tools and processes for systems development have also made substantial advances. Management of the systems development process, however, has not advanced so dramatically.
Agencies and Contractors: Speaking a Common Language
Playwright George Bernard Shaw once observed that “England and America are two countries separated by a common language.” Along those lines, when a government organization engages a contractor for systems development, the two entities are often “separated” by a common contract.
Consider an early example from the mid-1960s. A program to develop a fire control system for the U.S. Army included a two-year development cycle for system specifications and the Request for Proposal (RFP) process and a one-year procurement cycle. This resulted in a total package procurement award for hardware and software to be delivered in 30 months for a firm-fixed price—clearly a formidable task.
While inconceivable today, the software development for this program began with an empty computer: there was no operating system, no assembler, and no compilers. The system as initially fielded was many generations behind then-current technology, and the total cost was many times that of the original contract value—by any measure a massive failure.
Total package procurement was based on the belief that it is possible to do research and development for a fixed price. Ten-foot-long lists of system specifications created the illusion that the solution sought by the government agency was completely defined. Likewise, the contractor’s proposal created the illusion that there was nothing left to do but implement the solution. As a result, the government tried to force the contractor to deliver everything at a fixed price, while the contractor tried to force the government to make expensive changes in specifications, increasing the contract value and extending the time needed for completion.
In the end, external events broke the impasse. Total package procurement failed, emerging technologies resolved key technical issues, and a new generation of managers over-came the mutual distrust and suspicion that had once precluded progress. The system was finally delivered, but with a clear caveat: If the customer and the supplier do not trust one another, progress—if there is any—will be slow and expensive. Without integrity at every level from contract initiation through development, this could still happen today.
Balancing Time, Money, and Quality Concerns
Three key variables in systems development are cost, schedule, and quality. Integrity means mutual agreement on the correct balance of these three, as well as a shared commitment to evaluating every obstacle, requirement, and milestone within the context of the agreed-upon framework.
If the goal is to minimize cost, then development strategy must be very conservative. Known technologies and products would be the backbone, in this case. Careful analysis must take place before committing development resources.
If time is the most critical factor, parallel development is essential. Be aware, though, that exploring multiple approaches to solving problems concurrently and picking the best solution from these parallel efforts will increase costs.
If the end product is mission-critical, as in the case of control software for aeronautical applications, then quality is paramount. Again, detailed documentation, logical rigor in proving algorithms, and extensive testing will be both time-consuming and expensive.
In the mid-1980s, as a program manager, I was charged with the task of developing a logistics management information system (MIS) for a major new aircraft. The project had already been two years behind schedule when the customer decided to outsource it to us. We took it on, believing we could complete the project in six months.
Early on, schedule control personnel demanded a work breakdown structure for project tasks at the 200-to 300-man-hour level. When we detailed the impact this requirement would ultimately have on the schedule, the issue evaporated. In the end, we succeeded because everyone agreed that the schedule was top priority and that cost was not a factor. Under those terms, we hired consultants and subcontractors for parallel development and provided extensive training for every employee.
Today’s Rules of Engagement
There’s nothing like having the opportunity to test one’s own theories in the real world. Today, my company is closing a major systems integration effort for a government financial system. Taking an innovative approach, we entered into a contract that included a not-to-exceed ceiling, full-cost disclosure, and profit sharing on the difference between final cost and the not-to-exceed price. This contract gave the customer total visibility into project costs, including the maximum price. It gave us, as contractors, an incentive to help control costs. Despite numerous technical difficulties and unexpected events, the program has been successful, thanks to both parties agreeing on these ground rules:
- Specification changes would only be allowed if the system would not work as originally planned.
- All enhancements were to be documented for future reference.
- All changes required the approval of the government agency, as well as contractor program managers.
Total financial and technical transparencies were established through weekly program reviews, which brought together customers and program managers. Questions that came up along the way revealed potential challenges, allowing both parties to open a dialogue that moved from fixing blame to finding solutions to keep things moving forward.
Mutual Understanding Promotes Success for All
Establishing a mutual understanding of each party’s agenda is the only way to break the cycle of failure. There are signs of promise. With greater frequency, government has begun to take contractors’ past performance as seriously as their proposal promises. Likewise, contractors are beginning to open themselves up to create a truly transparent financial and technical environment. There’s a long road ahead, but as an optimist, I know that integrity can be achieved. We already do today with ease what I could only have dreamed of when I started.
MATCOM, a government IT solutions, provider, Visit: www. matcomcorp.com