Most fixed-price contracts are inherently anti-Agile.  It is not because they set a budget ceiling for a project.  I and many others argue that budget and schedule constraints actually enable Agile project planning.  The issues associated with fixed-price Agile software development contracts lie in how project management determines and enforces scope, budget, and schedule constraints.

Predictive vs. Adaptive Planning

Most fixed-price contracts ignore a fundamental disconnect between traditional project management and Agile practice.  Traditional project management planning is predictive while Agile planning is adaptive.  Fixed-price contracts require planners to define the three constraints of the Iron Triangle – scope, cost/budget, and schedule – upfront.

In traditional software projects, project management closely tracks task progress towards scheduled milestones and the associated budget burn rate.  There is little room to change project plans when things go awry.  Also, projects lose the flexibility to change plans based on lessons learned and discovery of new requirements during development.

In contrast, Agile planning “breaks” the Iron Triangle by allowing scope to “float” within budget and schedule constraints.  This means that given a fixed budget and timeframe, project sponsors, stakeholders, and software development teams collaborate to determine what to build during development.  We control Agile software development projects primarily by managing scope. 

We determine what viable and valuable capabilities to develop, deploy, and release within budget and time constraints.  As long as project sponsors and stakeholders work with development teams to continually refine and prioritize requirements, teams will deliver the most important product / system / solution features at appropriate levels of quality and complexity.  In Agile projects, sponsors have the flexibility to:

• Continue developing the current implementation as planned
• Pivot to a different implementation approach
• Stop when enough useful functionality is developed and fielded
• Cancel development altogether if necessary

Control vs. Flexibility

Fixed-price contracts are one way traditional project managers attempt to mitigate project risk.  Government agencies prefer fixed-priced contracts because they shift project risk onto vendors.  Vendors bid based on solution requirements stated in requests for proposals (RFPs).  It is up to the vendors to ensure their proposals accurately reflect the cost of satisfying requirements, within the specified timeframe, and at a competitive price that allows them to make money.

Since no one can predict the future, vendors often do the following:

1. Pad their proposals and project estimates
2. Underbid with the expectation of submitting change requests or Engineering Change Proposals (ECPs) later
3. Challenge any interpretation of requirements that may increase project scope (scope creep)

Vendors are disincentivized to accept changes in requirements that may perturb the plan and cost them margin.

Meanwhile, project sponsors worry they will not get what they paid for in terms of functionality and quality.  Those worries often translate into burdensome tracking and reporting requirements.

Agile provides opportunities to inspect and adapt solutions and their development.  This transparency is Agile’s safeguard against scope creep and project and solution underperformance. 

Unfortunately, traditional project managers often forgo opportunities to define and validate solutions during development. Instead, they favor traditional project management tracking and reporting.  They focus on tracking tasks completed rather than validating value delivered.  Even the misnamed concept of “Earned Value Management” (EVM) assumes a deliverable’s value during development equals the budgeted cost of the effort expended on it, regardless of its ability to provide business or mission value.

The Agile Alternative

Instead of attempting to manage all three Iron Triangle constraints as variables, keep cost and timeframes fixed while managing scope.  Rather than tracking task completion, deliver working functionality early and often to validate that development teams built the right things in the right way.  This places responsibility for defining the solution or “product’ squarely on project sponsors, with help from stakeholders and development teams.  Traditional project managers often struggle with this approach because it is a product management approach rather than a project management approach.

Conclusion

Fixed-price contracts do not have to run counter to Agile practices.  They can be written to allow project sponsors and stakeholders to define what business or mission capabilities they need, within fixed cost and schedule constraints. 

Doing so encourages developing solutions by starting small and building on successes.  After all, it is much easier to cancel a $10 million project after six months than a $100 million dollar project after two years.  This Agile approach to fixed-price contracts ensures that something of value comes from the investment while opening the door to future investments based on business or mission success.

Last Updated on March 19, 2023