Sometimes, no matter how exceptionally you do, a development project fails. And even if you apply the best practices in this area. Whether you are customer or supplier, a fixed-price contract most likely sends you on the highway to failure.
Tension source
Customers need effective and user-friendly product or servie. Suppliers want to build it. But in most cases they both fail. And it does not matter what domain we are talking about.
Do you create marketing strategy for your client? Do you develop new weather sensors? Or do you build software? Watch out – your project will most likely fail – at least statistically.
There are many factors causing this failure, but one of the main root causes is the contract – an interface between the customer and the supplier. Everything starts there, and at the end of the day it is the contract that is evaluated. Let’s take a closer look at what is the evil of fixed-all contracts that we sign nowadays and what is the way out.
Most development projects fail
Let’s take look at software development area since all the risks and problems are visible here. The alarming fact is that the success-probability of Software Development (SWD) projects is pretty lousy. It is about 37% according to the Standish Group [Chaos report 2010, 2012, 2014, 2017]. Does it mean that IT guys are silly or not competent? No, the problem is that we use inappropriate tools and methods for such a task. Most customers and suppliers approach software development the same way as making products (houses, cars, phones). But the fact of the matter is that it is not the same. Let’s take a look why.
As you can see in the picture above, chances of repeatability and reuse of knowledge while designing custom software is much lower as compared to building a car.
Approaching them similarly would be like making the Apollo program (man on the Moon), comprising of research and brand new technologies, in the Waterfall way – describe, design, build just one rocket for the first time and on the release date launch its crew to the Moon. I am convinced this has all possibilities of being a disaster. It was the 11th Apollo mission which finally landed on the Moon with the people onboard. Imagine how many millions try-fail-learn loops needed to be done with the module prototypes and subsystems before they eventually succeeded.
Success in these creative/innovative industries, where SWD belongs, requires quick learn-adapt loops in order to build something as complex as a software based on customer needs. The problem is that we approach it like it was predictable. We try to fix everything inside the contract in the moment when we actually miss critical knowledge.
House of your dreams
Needless to say, it is very difficult to define these customer requirements. And often these really critical requirements are even missing.
If we ask people “Imagine your dream house… everything is possible… what would you like to have in it?” We usually get answers like a swimming pool, a big television, self-cleaning, big living room, etc. But no one says roof, walls or windows! Have you ever wondered why? Because it is obvious that every house has those. Each architect should know it right? And now imagine a customer refusing to accept software because it is obvious that each banking system must also take care of invoicing which was not mentioned in the requirements. Business analyst should have known that…
Mary had a little lamb
And that is not all. Let’s pretend for a while that we are able to define all the requirements for the product/service. Next obstacle is we simply cannot understand them without ambiguities. Do you know the “Mary had a little lamb” rhyme? If we take it out of context – which requirements usually are – what does this sentence actually mean?
- Did Mary take care of her pet lamb?
- Did she eat a whole little lamb?
- Did she eat a small portion of lamb?
- Did she give birth to a lamb?
- Did she have a sex with a lamb?
- Did she trick a naive individual of no consequence? (stock broker’s slang)
- …
As you can see, the requirement sentence can be interpreted in many different ways. Even the ones you would never believe. Imagine thousands of sentences written inside a requirement specification document. Does a reader see the same resulting product/service as the requirements writer?
Why fixed-all contracts then?
So if we…
- need to apply learn/adapt loops that change functionality during product creation
- cannot define clear requirements upfront
- cannot understand them properly
- and thus cannot estimate them
…why do we still use contracts that are trying to estimate and fix everything upfront? Scope, time and price at the same time? I suppose that’s because people who make these contracts do not realize these specifics of R&D projects, or simply they do not know any better alternative. But this restrictive contract has very negative consequences.
Imagine yourself as a supplier who is bound with a restrictive contract that penalizes deviations from delivery. Imagine things getting more complicated (and they usually do). What will you choose – deliver what is needed and risk penalization or deliver what is exactly prescribed? Most people choose the second option, and there we go – lose-lose situation. The customer does not get what he needs and the supplier is blamed for not delivering it. Rework and error corrections can actually multiply the price of the final solution.
It is no surprise that we cannot predict the future and there are always nasty surprises waiting on the way – such as changing needs, technical difficulties and wrong assumptions. This happens especially when contract and estimates are forced very early, in project phase where we do not have much information. Also this restrictiveness introduces barriers into the customer-supplier relationship which precludes them from applying the most important universal practice – continuous improvement. Barriers make learning loops longer and inefficient.
Agile/Lean contract
So what shall we do? Simply put, do not contract detailed result requirements. Rather, focus on how both parties, customer and supplier, shall cooperate in order to achieve the best possible result together. This might be a heretical idea to some of the people living in these stories, since common sense says: “If it does not work, we must be even more strict and restrictive”. But being stricter of course does not solve the root cause and just makes the problem worse.
What should be written in the contract then? Definitely a description of the process, how supplier with customer’s support is going to produce best possible result. We put there all the patterns we know that empirically work. What does it mean in practice? Long story short it should contain the following parts:
Process of production based on learn-adapt loops (iterations) including all project phases
- Release preparation (vision, business objectives, major acceptance criteria, high level tests)
- Release execution (iterations and partial acceptance)
- Release delivery (deadlines, acceptance)
Supplier responsibilities
- Cooperate to formulate requirements from user perspective
- Commit to iteration input and have it ready for Demo
Customer responsibilities, where customer has to be present and for how long
- Help to prepare iteration input
- Support development within iteration
- Attend Demo and accept/refuse produced solution increment
Learn adapt parts
- Have common regular retrospectives to prevent issues
- In case iteration fails, or there is significant negative feedback from customer – trigger special retrospective with customer
Consequences of not following the agreed process
- Customer does not attend the demo? All demo functionality is accepted by default.
- Any errors discovered? They have to be fixed in very next iteration by supplier.
Business model
- What to pay for (capacity, per iterations, per requirement, per StoryPoint, …)
- Bonuses and penalties
As you can see this kind of contract is then always unique since it reflects concrete capabilities and constraints of concrete partners, so it does not fit all. But the parts and ideas there can be easily reused.
We managed to develop and sign a couple of these contracts with different customers of our clients. And according to the results and feedback it really works! One of the examples was presented on couple of conferences already (e.g. Leanest 2012, 2013 conferences in Stockholm and Prague).
Let us know if you are interested in hearing more, we will gladly share what we have learnt.
