Structuring project contracts with PRINCE2 Agile

While typical contracts specify a solution or output, plus a deadline and price, agile methods work on the premise that change is inevitable and shouldn’t be considered negative, as the result could benefit the customer even more.

So, structuring a contract for an agile project needs to support collaboration while recognizing the level of risk each party is prepared to accept. Why does this matter? When using agile methods in projects, the scope changes and if there is an issue – such as a delay or going over-budget – it needs to be detailed.

For this reason, PRINCE2 Agile^® includes a series of guidelines for constructing a contract governing for an agile project:

1. Focus on outcomes vs outputs
   A contract focused on outcomes relates more to value and connects directly with the product adopted by the users; i.e. supplier and customer work together on changes to a product during a project, the product is delivered, the customer uses it, change happens and this generates value in the organization. Therefore, the contract reinforces customer-supplier interactions.
2. Defining the level of customer involvement
   This formalizes the degree of commitment required from the customer. It outlines their responsibilities and becomes a legal framework for the level of collaboration between customer and supplier. It also helps with the speed of decision-making, accuracy of deliverables and product ownership. Naturally, this contractual arrangement relies on both sides having familiarity of agile working methods.
3. Create time-based delivery
   Having high-level agreement for time periods based on project requirements, a breakdown of deadlines and budget provides milestones for delivering products and, in turn, a timescale for delivering value. This allows the customer to see how a project is progressing and is measured according to velocity, value or story points – an agile measure of delivery.
4. Involvement of the project board
   Having the project board involved means that a project can be stopped at any point. This can happen if the business requirement or market has changed which makes the project no longer viable. For the supplier, this is not breaking an agreement as termination is always included in any form of contract.
5. Incentives
   If a supplier delivers everything intended, they can receive 100% (or more) remuneration. A sliding scale would reward a delivery of less than the required amount.
6. Customer requirements
   These are defined at a high level in the contract but not in detail as requirements can change. However, they should be prioritized to ensure the most important parts of the product are delivered first: mandatory requirements ensure the minimum viable product is delivered along with the associated value to the organization. If requirements change, especially if it’s a new mandatory requirement, this is articulated and therefore is reflected in the contract.
7. Trust between customer and supplier
   Having a “minimum viable contract” concept allows for a skeleton agreement to which it’s possible to add items and provide complete transparency, which supports trust building between the parties. The important thing is having clauses that are meaningful, e.g. specifying ownership of the intellectual property created.

Agile projects should create freedom and collaboration for project management and product delivery. However, there still needs to be an agreement in place and the principles outlined in PRINCE2 Agile ensure the contract works for the agile project environment.