To be agile is to move quickly and easily. As a project management method, it is characterized by the division of tasks into short phases of work and frequent adjustments of plans. As a contract management method, it is characterized by collaborative relationships with outcome and performance-based contracts, designed to deal with high levels of uncertainty. The fundamental premise is that you can’t plan or contract for what is unknown, so decisions are made along the way as better information becomes available through experimentation and client feedback. This allows you to adapt as circumstances change and to counter predictive risk.
The challenge comes when we want the freedom of being agile, but want to counter contract risk by fixing responsibilities, price, and service levels as well as imposing a higher level of governance. We do have budgets, timetables, probity and stakeholders which act as constraints to unfettered freedom so, as good contract and commercial citizens, we seek to provide as much certainty as possible. However, agile contracting cannot be ‘set and forget’ because the requirements or product/service features change through the development and testing lifecycle as we learn more. The Principles behind the Agile Manifesto even encourage such changes, with Principle 2 saying: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
As a consequence, if scope changes, then the other ‘iron triangle’ components of time and cost have to vary. In a fixed contract, this can lead to time and cost overruns, delivery risks and strained relationships as the costs exceed the ability of the contractor to absorb them or pass them on (as opposed to new scope via change control and often to the contractor’s commercial advantage).
Conventional wisdom, well Wikipedia, will tell you that fixed price contracts don’t suit innovative new projects with untested or underdeveloped technologies. Yet I’ve worked recently on so-called ‘hybrid agile’ projects in the government military sectors and in the commercial financial services sector where fixed price contracts are used. Indeed, sometimes because of an extended governance process and a management culture that demands order, the costs are fixed before the scope is even agreed. According to the results from the IACCM Most Negotiated Terms Survey 2018, the ‘Scope and Goals/ Specifications’ was the #1 Most Important Term in the contract. But in agile projects still we try to fix price for a moving scope and specifications.
Why do we do that? Yes, for change control reasons (but aren’t we trying to encourage change not limit it?). Yes, for risk and governance reasons (but isn’t a governor used to limit the top speed of a vehicle and aren’t we seeking speed through an agile approach?). Yes, to provide certainty (but don’t we know that we can’t predict the future only adapt to it?). Yes, because as good contract and commercial practitioners we seek to avoid time and cost overruns (but the body of evidence is showing that fixing the contract is actually contributing to these negative consequences). I am saying Yes because we do need to consider these reasons as we establish and manage contracts. However, I propose the other reason is that we don’t trust the contractor not to exploit either the lack of firm specifications or the ready access to the end-customer to up-sell scope and increase their revenue. Frankly, I also propose that we don’t trust the project team or end-customers to manage scope creep. Therefore, we seek to limit their freedom through the contract and seek to fix as much as we can negotiate with the customer and the contractor.
Rather than fix price for the whole contract or even various releases of features, contemporary project and contract thinking recommends the use of cost-plus time and materials contracts; or incremental delivery and checkpoints (e.g. after the initial test phase) where scope, budget and due-dates are agreed; or target cost contracts with gain/pain share. Each of these approaches balance freedom and control, so start to suggest that the term ‘Agile Fixed Contracts’ does not need to be an oxymoron. Each of these approaches also presents an opportunity for collaboration. For example, if a root cause of the desire for greater control is lack of trust, then a cost-plus T&M contract will require a substantial level of trust. The #2 Most Negotiated Term for 2018 of ‘Responsibilities of the Parties’ will need to be clear, but moreover, the relationship will need to be strong and open to share cost and profit data to support a “trust but verify” contract management approach. Similarly, for a gain/pain share target cost contract, trust will be important to encourage open dialogue around scope, perhaps using the agile MoSCoW prioritisation rules (i.e. there are Must haves, Should haves, Could haves and Won’t have this time).
We often focus on the type of contract that is best-fit for agile projects and my encouragement is to focus equally on the best-fit relationship. A key first step in the IACCM Relational Contract process is “To build the trust necessary to focus on the relationship, ensure alignment within your own organization and thereafter use a process for choosing a partner that considers relational competencies in addition to service offerings, quality levels, etc.”  Trust but verify sure but, if we want to be truly agile in our projects and our contracts, collaborate for trust first.