Structuring agile contracts in Agile Project Management. What is an agile contract? Do we use agile contracts in Agile projects management?
IN our talk this week, we focus our discussion on agile contracts. Agile project management is trending and there is increasing appetite from industry to adopt and embed agile as a new way of working and delivering much needed products and services to customers.
The reasons for this shift of corporate mind-set are obvious in forward looking organisations and companies.
Agile delivers immediate value to the customer, and that’s correct if you use agile correctly. Who doesn’t need value anyway? Value is often defined as the delivered net positive benefits.
Most work which is undertaken in the government and private sector is normally contracted work and if there is need to deliver immediate value then definitely agile delivery is the solution as an approach.
This means that we need to design contracts for such work which are agile friendly. I think understanding whether project deliverables should be classified as outputs, outcomes, benefits or value is very key to embracing the philosophy of embedding agile ways and methods of delivering products and services
Contracts must be aligned and responsive to the way projects will deliver the much needed products and services by customers. Often than not, we find most contracts are rigid and cast in stone and thereby limiting the ability of the project team to deliver products and services which closely match customer preferences.
The reason being that some customer requirements and needs change rapidly from the time the so-called traditional contract is drafted to the time the products and services are delivered by the project team. The end result is that the customer is not happy with the delivered end product.
Ultimately, this can result in project failure. Project managers may argue that we did everything to the book and according to project management best practices but the customer did not like the end product or deliverables.
Ironic example in the medical cycles is when the medical surgery team confirms and validates that the operation on a patient and standard operating procedures was followed but unfortunately the patient died, can this be deemed a successful operation or not?
Well different stakeholders may view this differently but basing the opinion on agile approach the operation in question was definitely a failure because expected value was not achieved.
Value in this case was going to be defined as positive outcome and in the example given the patient died so Project failed.
Now let’s delve a little bit deep into specifics of agile contracts and before we elaborate more on what an agile contract is let us first understand what an agile contract is.
Many of the project contracts would involve the customer engaging the supplier to deliver a specific solution in a number of ways and may be quite elaborate.
Accompanied with this, there may be several drop dead deadlines and associated price or penalties to it. When looking to structure a contract in a way that is more conducive to working with agile, it is most important to understand the level of trust and cooperation between the customer and the supplier.
Trust is a difficult area to cover in a contract, as many elements of a contract concern the problems that may occur. Therefore a contract needs to support collaborative ways of working (e.g. by containing incentives and levels of commitment).
A customer and supplier may have worked together for several years and the trust and cooperation between them may be very high. Alternatively, if a supplier is new to a customer, levels of trust and cooperation might be unknown and difficult to assess.
The reason this is so important is because it will determine the amount of risk that is shared between the customer and the supplier. The risk relates to the uncertainties of the project.
A popular phrase used extensively in project management is a reference to “known unknowns” and “unknown unknowns” and these exist on any project.
When these unknowns appear during a project, who “pays for the change: the supplier because they should have anticipated it, or the customer because they should have specified it?
Alternatively, should the ‘cost’ of the change be shared because both parties know that there is uncertainty and ‘unknowns’? The more trust and collaboration that exist between a customer and supplier, the less likely it will happen that:
- The supplier will add a contingency amounts to the price of the contract in relation to the amount of risk involved
- The customer will go into too much detail when initiating a project in the understanding that they are removing uncertainties from the project.
Structuring a contract that is suitable when working with agile does not necessarily involve creating a completely new type of contract. Existing contract frameworks currently being used by organisations may still be suitable to a large extent (e.g. as a master agreement).
However, change will be needed at the lower levels in order to work in a more agile way (e.g. in a statement of work (or SOW), which may apply to a period of time, such as a sprint or a release).
When using agile, structuring a contract according to the following guidelines is likely to be more beneficial to both customer and supplier than using a traditional style of contract:
- If possible, make the focus of what is being delivered “outcome-based” in preference to “output-base, ‘ ‘. An output focus is basically about a product or solution that either is, or is not, as specified. An outcome focus relates to the benefits and value that a project enables or delivers.
This allows the customer and supplier to work together to create an output (or product) that can be changed and adjusted throughout the course of the project, in order to deliver something more valuable and if the opportunity arises.
- Define the level of customer involvement needed during the project.
- Create several time-based deliveries as part of the main agreement.
- Allow for the project to be stopped at any time by the project board. This allows the customer to stop a project if feedback from early deliveries indicates that the project as a whole is no longer viable.
- Supplier incentives can be linked to the amount delivered. If the supplier delivers everything that was intended during a particular time-frame, then they receive 100 per cent (or even 100 per cent) of the payment agreed.
In conclusion, the guidelines for structuring an agile contract for use in an agile project are as follows: Focus on project outcomes or throughput in preference to project outputs; Define the amount of customer involvement required in order to collaborate with the supplier in the best way; Buy amounts of time relating to time boxes with deliverables; Allow for a premature end to the project should the project all of sudden become unviable; Relate supplier incentives to the amount of values delivered.
This article was written by Dr Laban Mwansa, MSP®, PMP®, PRINCE2® Practitioner, Agile®, Laban is a consultant and trainer in project management and specifically trainer/coach in PMP®, PRINCE2® Practitioner, and PRINCE2 Agile® in Zambia, South Africa and Europe for many years. He was in the executive committee of ICTAZ as technical chair. He is also the managing partner of Betaways Innovation Systems and can be reached at: Laban.Mwansa@betaways-innovations.com, +260975280392 or WhatsApp +27817029669. He is also a professional project management member of PMSA and PMI-USA.