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 […]