The software project landscape is littered with failures. A recent example in the UK is the failure of the NHS National Programme for IT. At the point the plug was pulled, £6.4bn had been spent with the final bill expected to be £11.4bn. The post mortems are already under way and what they’re finding is not surprising. Large IT contracts continue to make the same mistakes. It’s time for a change.
Software contracts and the initial budget
As an IT leader, I’ve worked on software projects of all sizes for many years. Over those years, I’ve been asked many times “How much will it cost”? I used to try and answer that question but, I don’t any more. Because it’s impossible.
Just for fun, imagine that you’re Leonardo Da Vinci. Francesco del Giocondo comes to you and says “I want you to paint my wife, Lisa”. You nod. He continues “The painting has to capture her beauty, show her enigmatic smile and be a focus of desire for generations”. You remove your cap, scratch your head, and wonder how you’re going to do that. Then Francesco asks “How much will it cost”?
It’s been said that producing a software application is an unholy alliance between engineering and art. You can predict the engineering but, the art? It cannot be done.
Software contracts and the delivery date
Right up there with “How much will it cost?” is that other well-worn favourite “When will it be ready?” Back to our analogy.
Having agreed to accept the commission, you tell Francesco that his painting will cost 4,000 écus. Francesco accepts and then says. “We’re celebrating the birth of my second son and moving in to a new home. I’d like to have it on the wall. When will it be ready?” You’re back to scratching your head again and you’re sure there’s a bald patch starting to form.
You consider the work involved. The paints you’ll have to source and buy. The poplar wood you’ll need to paint it on and whether Salai will be able to find the right quality this time. Then there’s that helicopter design you’re working on. Not to mention the submarine. You’ll need Lisa to sit for the painting too – when will she be available. And what the heck is an ‘enigmatic smile’ when it’s at home?
You suck your teeth and, for some unknown reason the phrase “Tricky, Guv!” enters your mind. You ignore it and say “Three months”. You’re not sure why you said it but, Francesco has a glint in his eye and the answer seems to have made him smile. Result!
Software contracts and changing requirements
Two months later and you’re working on the painting when Francesco drops by to take a look. He stands back, his right hand thoughtfully cupping his chin. “Too many teeth” he says. You turn to him with an enquiring look. “There are too many teeth” says Francesco. Look at her. She looks more like a grinning shark than a beautiful woman!” You look at the painting. Anatomically, she has precisely the right amount of teeth. You know it for a fact. You’ve carved up enough bodies to know. Probably best not to mention it though.
“Anyway”, says Francesco, “I wanted an enigmatic smile. Not a smile that’s missing a ‘Kiss-me-quick’ hat” thus proving that it wasn’t only Leonardo who was prescient. Inwardly, you sigh quietly. Externally, you ask how the smile should be made to look. “Well, you know, like an enigmatic smile. It’s obvious.” Francesco then takes his leave. Just as he’s leaving the room. he calls over his shoulder “Oh – don’t forget that I need it for a week next Friday. Did I mention that we’re moving in early?”
Software contracts and budget over-runs
You grind your teeth. You’ve ended up with an impossible commission. You’ve got a customer who doesn’t know what he wants but knows when he wants it. Worst of all, Francesco has already paid and you’ve promised to start work on a new, paying, commission in a months time. You decide you’ve just got to talk about it with Francesco.
A few days later, you find Francesco and tell him your tale of woe. “You told me you’d be ready in three months!” he exclaims. You explain your problem and how you hadn’t planned for the numerically challenged teeth or the ‘wrong sort of smile’. “Well”, says Francesco, “I suppose I can give you another two weeks. But that’s it. It must be ready by then!”
By this stage, you’re wringing your hat in nervous anticipation, wondering how to propose the question of remuneration. You decide not to mention your new, impending contract as you imagine Francesco would be unsympathetic. Instead, you say that the extra work will cost more. “What!” exclaims Francesco. “You’re late and you want me to pay you more? The cheek of it.” But you know the best is yet to come. Because now you have to ask Francesco to explain exactly what an enigmatic smile is as well.
Better software contracts
Leonardo was the victim of a ‘fixed-price, fixed-scope’ contract. An unwitting participant in a drama that unfolds regularly in software projects today.
Businesses place software contracts with the best of intentions. Over the decades, they’ve been conditioned to state precisely what they want, up-front. In return, they demand a cost and delivery date. What we’ve found, time after time, is that this model of software contract rarely works for either party. The main problem is this: The customer does not know what they want up-front and they are unaware that they don’t know it.
Ask the central team that designed the NHS National Programme for IT. They’ll tell you that they knew exactly what they wanted up-front. But I guarantee that they didn’t. The requirements changed regularly over the course of the project. Part of those changes were by customer request.
What software contracts need, are agile customers. Customers who accept that they won’t be able to think of everything up-front. Customers willing to commit a budget, state a delivery date and work with their software provider to produce the best software possible in that time. In Agile / Scrum terms we call that ‘fixed-price, variable scope’. It works. Try it!