Commercial Contracts: Guarantees, commitments and risks
“When you buy something, you want to know exactly what you’ll get and how much it will cost. It makes sense.”
Our very own Simon Baker wrote this back in 2007. This is the prevailing mindset when anyone buys something, whether it is a personal purchase or multi-billion pound government contract. When we “buy” something we automatically want a guarantee that we will get something for our money.
But Simon immediately goes on to say…
“But this doesn’t work when you’re buying software development.”
Old habits die hard
As many have done before and since Simon describes the various follies that arise from trying to “buy software” where the contract specifies exactly what you want (fixed scope), exactly how much you will pay (fixed cost) and when you will get it (fixed time). But if this doesn’t work what’s the alternative?
The extreme opposite is to abandon any notion of guarantees around scope, cost and time. A client can hire a supplier to deliver software and pay for their time until the client has what they want. However, in this arrangement all the risk is plainly and openly carried by the client. The client either places a great amount of trust in the supplier that they will act in the client’s best interests or the client must tightly manage their supplier. For many people and organisations this kind of arrangement isn’t palatable, especially for any work of significant size, or where they haven’t worked with the supplier before.
Even if the client is happy to carry the risk they will often face internal obstacles that will make it difficult to get sign-off. Procurement and legal department policies may mandate how contracts must minimise exposure and risk in the event that trust breaks down in the client/supplier relationship. Unfortunately these policies are often based on the incorrect assumption that “building” software is relatively predictable and comparable to other “building” activities like construction. It’s not surprising then that fixed price, fixed cost contracts continue to dominate our industry despite their flaws.
An agile approach to contracts
The agile community have championed the risk-reducing effect of delivering early and often within iterative and incremental cycles. When they looked at traditional commercial contracts it was obvious that they clashed with the values and principles of the agile manifesto. However most, if not all, have focused on better aligning contracts with agile process and management methods such as Scrum and Extreme Programming. This was a step forward, allowing clients to limit their risk with smaller statements of work, permitting changes in scope without expensive penalties, and even the option of cutting an engagement short if they thought no more significant value could be delivered.
However, as people like Susan Atkinson and Gabrielle Benefield have pointed out the traditional contract model for software and their agile derivatives still fail to make any guarantees to the client that what a supplier delivers will actually be of value. Even with a more progressive agile contract, where a supplier is more incentivised to do a good job and deliver features early and often, they are still not contractually obligated to ensure what is delivered satisfies the clients needs. This means that whilst the contract reduces exposure to risks, in terms of cost and time, it doesn’t reduce risk around value which ultimately remains the responsibility of the client. Contractual incentivising this kind of value/cost asymmetry can have serious consequences.
So is it possible to have a contract that aligns the client and supplier so they may equitably share the responsibility for delivering value? And if so, how? What would it look like? What would we need?
From day one at Energized Work we lived by the agile manifesto principle that “our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. However, as our approach has matured and evolved we realised that it is a somewhat simplistic statement and being able to objectively evaluate what is of value in a way that is testable and measurable is essential to success.
It is simplistic because there are, invariably, multiple stakeholders who need to be satisfied or are impacted in some way by any software delivery. We must therefore have the means to make effective prioritisation and design trade-off decisions to meet our stakeholder needs so they get the biggest “bang for buck” from our time and efforts.
Objectivity is required because balancing the needs of all our stakeholders is extremely difficult unless we can have rational, constructive, conversations to agree on how valuable a particular need is in comparison to another. Defining value requires us to be able to agree on the facts, explain our reasoning and capture our critical assumptions.
Our definitions of value must be testable and measurable to make our prioritisation method meaningful and effective. As decision theory expert Douglas Hubbard points out at the start of this talk, decisions made on the basis of expert intuition, consensus voting or arbitrary scoring methods might make you feel more confident about your decisions but it probably won’t make them more effective. A more scientific, data-driven method is therefore required.
With these key realisations and having been inspired by Tom Gilb’s Competitive Engineering we have adopted an outcome-based and data-driven approach where we define the underlying needs of our client’s (and their stakeholders) in clear and unambiguous terms, but most importantly in a way that can be tested and measured. I will talk more about how we do this in future posts.
Committing in the contract
As we started to run more and more engagements toward measurable stakeholder outcomes we came to the conclusion that we could go a step further and make this a part of the commercial agreements with our clients. This has in fact been a strategic decision for Energized Work. We believe, like Tom Gilb does, that there are many benefits for our clients and ourselves. But primarily, our view is that outcomes-based contracts, where a significant part of our fee is tied to meeting those outcomes, ensures that the responsibility and risk of delivering value in a project is shared fairly between client and supplier.
To close, I invite you to try a small thought experiment based on the opening quote of this post. What if you changed the word “buy” to “invest”? How would that change your perspective and how might it make you think differently software contracts?
Here’s my attempt: “When you invest in something, you ….”
… you want a good return on your investment
… and you understand that nothing is absolutely certain and there are no guarantees
… and that the potential return on your investment should be high enough to outweigh the risks
… and that anyone you are investing with or in should have their interests aligned with your own and share the risks (and rewards)
Does this make sense? If so, how would you manage an investment in software to deliver a return on your investment?