When businesses take on big IT projects (or any kind of big projects, I suppose), they puff their cheeks out and say, metaphorical hands on not-at-all-literal hips:
Gonna cost you guv.
They’re thinking: we’re going to have to plan this. We’ll need a risk register. We’ll have to fix the scope, gather all the deliverables, consult all the stakeholders.
Then we’ll create a PID, and a project plan. And if we get approval, and funding, we’ll start on an 18 month delivery plan that we’ve already been talking about for 6 months.
Then they’ll spend 2 months going round everyone who may have even the smallest stake in the project. They’ll seek their opinions, solicit their preferences.
Everything will be documented, in documents that will never be read by anyone.
Once all the stakeholders have been consulted, they’ll start planning. The risk register will be completed. A project plan will be drawn up. It is submitted for approval, and approval is granted.
Hey, we’ve been working on this thing for 6 months already and have delivered nothing but documentation. But we’ve already spent so much money on it that we can’t stop.
Sound familiar?
So, how do we get off this not-so merry-go-roundabout?
Step off, take a step back, and have a close look is the answer.
In my previous post, I explored why trying to treat complex environments as if they’re merely complicated could lead us into trouble.
And here’s why.
We think we can predict the future. We think that we know everything that could go wrong. We try to pin the future down, because we’ve thought about that. We’ve mitigated this.
When we create a risk register, it’s like we think: Nothing that’s not in this document can happen.
But, of course, they will. Terrible things happen all the time. Usually, they happen to other people. Just once in a while, randomly, they happen to us.
When we produce a project plan, it’s like we’re saying: The future will look exactly like this.
Except, of course, that’s precisely the opposite of what will happen. The late Douglas Adam expressed it brilliantly in his theory of Bistromathics.
The first nonabsolute number is the number of people for whom the table is reserved. This will vary during the course of the first three telephone calls to the restaurant, and then bear no apparent relation to the number of people who actually turn up, or the number of people who subsequently join them after the show/match/party/gig, or to the number of people who leave when they see who else has shown up.
The second nonabsolute number is the given time of arrival, which is now known to be one of those most bizarre mathematical concepts, a recipriversexcluson, a number whose existence can only be defined as being anything other than itself. In other words, the given time of arrival is the one moment of time at which it is impossible that any member of the party will arrive. Recipriversexclusons now play a vital part in many branches of mathematics, including statistics and accountancy, and also form the basic equations used to engineer the Somebody Else’s Problem field.
The third and most mysterious piece of nonabsoluteness of all lies in the relationship between the number of items on the bill, the cost of each item, the number of people at the table and what they are each prepared to pay for. (The number of people who have actually brought any money is only a sub-phenomenon in this field.)
So, how do we deal with this?
Well, that’s what comes next …
You can predict the future or you can innovate. Not both.
— Alan Cooper (@MrAlanCooper) November 29, 2014
I'm a service designer in Scottish Enterprise's unsurprisingly-named service design team. I've been a content designer, editor, UX designer and giant haystacks developer on the web for (gulp) over 25 years.