We are now seeing projects outside of the IT space shift their delivery mindset from the traditional approach to an Agile one where all stages are carried out within shorter iterations. If the project environment suits Agile – the concept is that value is delivered earlier in the project lifecycle, gathering feedback at each iteration.
Because the end solution is something which has been iterated on and gradually improved throughout, it increases its likelihood of delighting the customer. Agile is good at responding to change and provides a high level of visibility of project progress. Progress which is reflected in more than just project reporting, it’s seen through tangible iterations of the solution.
However, be aware that not every project and programme will lend itself to Agile or agile ways of working, and one must know when and when not to apply them. In addition to Agile ways of working within the team, one needs to consider the impact on contract and procurement routes when operating in an Agile environment.
Reflect on your project conditions
You need to first understand the environment you are operating in and assess how that will play on choosing which contracts to operate in an Agile fashion, whether you phase in contracts, or whether the organisation’s procurement routes will even allow for agility enablement. Conducting an Agile Alignment Diagnostic will help you identify the right fit based on your project’s conditions.
Some basic elements to reflect on are:
- Will your project last years, months or weeks?
- What level of commitment is there to meet key milestone dates?
- How much change are you expecting over the project’s duration and how much of that is outside of your control?
- Do you have a strong working relationship with your considered supplier(s) and do you have confidence in their ability to work flexibly with you in light of emerging requirements?
- Is there a driver for predictable project costs, and if so where is it coming from and how strong is it?
Choosing the right type of contract
Contracts can be confusing – there are many different types, supporting different project environments and project approaches. Even when delivering Agile, it is common for organisations to default to traditional contract methods which are just that – better suited to traditional linear (waterfall) delivery methods.
At one end of the spectrum, there is an uncapped Time and Materials (T&M) contract where the buying organisation has no option but to continue paying in the event of project overrun.1 At the other end is a contract with a fixed price, based on a specified set of requirements (or features) early on in the lifecycle.
i Traditional vs. MoSCoW Approach
Estimating the cost and time against a fixed set of features inherently ‘fixes’ the iron triangle of project management. This is a difficult contract to navigate as the only variable is quality, yet fixing all constraints of the triangle in an Agile project can compromise success.
Taking a MoSCoW prioritisation approach within a fixed price contract where time, cost and quality are fixed – but features are tradeable, can provide the degree of certainty needed for the buying organisation’s governance, while yielding the project results and the right mindset needed.2
Prioritisation is categorised as: Must (without these, the solution will not work); Should (important but not critical, though still painful to take out – future work around may be required); Could (nice to have, but if removed will do less damage than if a ‘Should’ is omitted); Won’t (project has agreed that it will not deliver and will help manage expectations).
One contract may not be the answer
A phased approach to contracts can help balance the risk between buyer and supplier throughout the project’s life.
The degree of uncertainty is inherently much higher at the start of your project and it is possible that the team will want to hit the ground running, rather than spend time specifying requirements at the beginning.
A strong relationship with a supplier may give you enough confidence to not need to spend time specifying requirements upfront as they can ‘discover’ during this phase with you. If the solution is novel, then prototyping may be required in early cycles to improve solution confidence.
Why not use a T&M contract to start with? Focusing on de-risking the must have features will also help set a benchmark for future iteration size and speed, including helping to validate the choice of supplier(s) before a longer-term commitment is made.
As the project progresses and more information becomes available, a fixed price contract could be drawn up based on the size of future iterations anticipated – this will help provide clarity upstream in the organisation to satisfy organisational governance and support the business case process.
Consider the procurement function’s perspective
On larger, more complex projects, the procurement team can consist of sub-teams within the procurement function, with special expertise in contracts.
Central procurement functions who are used to specifying traditional fixed price contracts may need a shift in mindset. From suppliers estimating cost and time against a defined set of requirements, to adopting Agile contract considerations.
Some organisations will have a standardised suite of contract templates that local project teams are mandated to follow and these may or may not lend themselves to Agile delivery.
It is important that the right contract type is chosen for the right project environment.
The contract plan will define the relationship between the project and the suppliers (this can be a supplier, vendor, or partner). This will also set out processes to manage the contract once in place – for example in dealing with any changes that occur.
Depending on the organisation’s ‘way of doing it’ there will be a different appetite to risk. Some organisations may want to veer towards fixed price (lump sum) contracts because anything else is perceived as unacceptable in cost risk by central governance. If that is the case you may still be able to satisfy their requirements considering the above points to shift the mindset from ‘cost’ to ‘value’ driven.
There are many factors to consider when procuring in an Agile environment and there isn’t a one-size-fits-all solution, but your project conditions, your organisation’s appetite for risk and phasing of contracts are key factors to consider. But one thing is certain, the mindset at the heart of your project should be around customer collaboration over contract negotiation.
1 Eckfeldt, B., Madden, R., Horowitz, J. and Esq. Grotta, 2005, July. Selling Agile: Target-Cost Contract. In AGILE (pp. 160-166).
2 Case study by General Dynamics UK where Agile was adopted to deliver a combat technology project on behalf of the MoD: In the DSDM model, trading out requirements provides the flexibility to ensure on-time and on-cost delivery of an acceptable and fit-for-purpose solution. Cobb, C., 2015. The Project Manager's Guide to Mastering Agile: Principles and Practices for an Adaptive Approach (pp.355-367)
Osian Evans is a Principal Consultant for Pcubed based out of the London office with 10 years’ experience of delivering major projects, programmes and change initiatives across a diverse range of clients.