Agile - Not just a line in a Statement of Work
Last month my colleague Andrew Matangi and I spoke at the ITx conference on contracting for agile projects. It was a great opportunity to meet a number of people who are involved in projects undertaken using an agile methodology. The conversations we had reinforced some of our concerns about how agile projects tend to be contracted for in New Zealand.
What we're finding in practice is that:
- "agile" means very different things to different people. It is a bit of a buzz word at the moment which means it is applied to very different projects - from iterative roll-outs of COTS products to development of innovative new software. Often before we can work out best how to contract for an agile project, the first question we have to ask is "what do you mean by agile?"
- agile methodologies remain really popular and anecdotally seem to work well for many projects. Many people we've met have used agile for a number of years and swear it leads to better outcomes. However, it's not uncommon to find that key people involved in ICT projects, including project managers, procurement specialists, and lawyers, don't really understand the methodologies and so the contracts used aren't always fit for purpose.
- "agile contracts" in New Zealand still tend to take two forms:
- use of a standard "waterfall" master agreement with a statement of work or service schedule attached that says "this implementation will be conducted using agile". In some cases this can be a recipe for disaster because the "front end" of the agreement simply won't reflect how the parties will work in practice. If this happens, the contract tends to be discarded pretty early on in the project (with the customer and supplier both acting as if it doesn't really exist) and, if the parties later end up in dispute, resolution can be very tricky.
- use of a supplier-friendly basic consultancy agreement where work is undertaken on a time and materials basis and there are few, if any, binding commitments to milestones and/or meeting specific requirements. This type of contract isn't always inappropriate but it is a difficult sell if the project is a high risk or costly with significant time or budget constraints.
In our view, just because a project is going to use an agile methodology, doesn't mean the parties need to abandon all standard contractual protections. We'd like to see more use of contracting models that are more sophisticated - contracts that reflect agile processes (e.g. sprints, early deployment of working software, product backlogs) and encourage innovation and learning as the project progresses but which also identify and fairly allocate project risks (e.g. inclusion of termination rights, pain/gain share fee models).
However, creating a contract that is appropriately tailored to the way in which a project will run and the parties' respective appetites for risk can take some time and unfortunately (depending on your perspective) requires the early engagement of your lawyers to ensure they are on board and don't just trot out a standard precedent.
Amy Ryburn is a partner in Buddle Findlay's ICT practice. She really loves her job. When Amy's not at work, she can generally be found hanging out with her husband and trying to keep up with her three small children.
Comments
You must be logged in in order to post comments. Log In
Thanks for sharing - this is a very good assessment. Your point re "agile" waterfall contracts is so true.
The issue is that customers want surety of cost. They all know and fear the issues of IT project overrun. The fundamental issue of "overrun" though is in having unrealistic expectations on what the cost should be. That cost is often not based on any decent scoping and designing practices. Design serves to save cost, but we make that activity part of the fixed price contract, i.e. the refinement of the scope is in the fixed price cost, but as you refine it may stretch the cost by -25% to +100%. This approach that is so typical of most government contracts can never work. We all know it.
The line of defence then is not in contracts, but in contracting for the right thing. Contract for the design only to determine a refined cost. That design phase can be done using a host of agile techniques, all involving elicitation and feedback with the client (that is what design is). Once you have a good enough design that you can more accurately cost, only then tender for the bulk (90%) of the work and commit. You could design using two agile teams, or you could be really smart and do process modelling etc. to figure out if you need all those screens in the first place.
If design was such a flawed model why do all other engineering disciplines use it?
If one starts an Agile project at the typical point in time that people have finished their inaccurate business case, then any project will fail. The issue with starting with Agile development too early is that once you work out that the beast is much bigger than thought, one is typically 1/3 rd into the project, and you have to write off 1/3 rd of the cost as Capex (oops). In contrast if you use design first, then you'll spend no more than 10% of project costs to figure out that it will or won't stack up.
Think then do, and using a three stage rocket (business case, design, build) is cheaper / less risky than persisting with the two stage model. That affects what & how you contract :)
