Having spent 33+ years in Federal Government service in both Contracting and Information Technology and now as an IT contractor, I’ve been pondering the current situation in contracting for IT services, especially software development. I’ve come to the conclusion that we’re in a real pickle!

Rule #1 of contract type selection is to place as much risk on the contractor as is practicable. We’ve been at the task of software development in Government-Contractor relationships for a few decades now (the Government used to use its own programmers, but that’s another blog post).

Conventional contracting wisdom is that if a process is well known and practitioners of the process are abundant then the amount of risk to either party is low and therefore firm, fixed price is the appropriate contract type. As a COTR and SOO/SOW writer I engaged more than one contracting officer in a discussion of the difficulties associated with this approach. Either the Government defaults to the straight-line method (“just bill the same amount every month”) or each system change is treated as a task order with its own price. The latter is much more in line with what FAR and DFARS envisions but it is also fraught with difficulty.

The other principle for when FFP is the appropriate contract type is that the requirements are well known. Requirements definition for software, when done correctly, is exacting. Ensuring that the software users’ needs are met requires details about data, processes, inputs, outputs, roles, permissions, formats, communications protocols and reporting. Even the best requirements writers inadvertently leave gaps in requirements. Once the requirements get to the developers there is often more than one way to produce the same outcome, each with a different cost. Most of the time, the developer estimate is based on a preliminary description of the software change, not a detailed analysis of the full requirement (because this is what the Government gives the contractor to base it upon). And lastly, the Government’s priorities have a way of shifting in ways that impact schedules and that always impacts cost.

So how do we get out of this predicament? We need to move away from FFP contracts for software development. Time & Materials contracts, the standard approach for the 1990s and early 21st century, have their challenges, too, but if managed correctly by an active, fully engaged COTR, can produce the desired results. T&M allows flexibility to get the software done right. Contracting with CMMI certified contractors helps to ensure quality code so that the only adjustments are to the requirements as opposed to eliminating defects. Cost Plus Incentive Fee is another approach that takes more contract management effort on the Government’s part, but isn’t that extra effort worth it if the final delivered product meets or exceeds expectations so that there is actually a return on investment? The essential element for success here is the COTR who must be trained and not overburdened with other work so that contractor performance can be monitored and properly compensated.

What are your thoughts? Please join the discussion by leaving a comment below.