A human non-solution to scope creep

We’ve all experienced it: a project is halfway through, if not almost completed. Somebody (generally a wealthy client) wakes up in the morning and announces that it’d be great to add that “very simple” feature to the page, which of course means it has to be done no matter what, possibly by yesterday.

Somebody else says ‘Yes, no problem’, maybe out of true conviction that the request is actually simple (99% of the time it’s not) or just out of sheer fear of contradicting the boss/client/project manager.

That’s a scope creep, when something gets added at the very last minute and strong-arms its way in an otherwise well planned work schedule.

It’s also known in plain English as ‘disaster’, ‘finger-pointing’, ‘people quitting’ and so on, until the parties involved call their respective lawyers.

Of all the magnificent theories about how to avoid all this, I haven’t found one that actually works. And not because the theories are flawed, but because we are human and therefore flawed.

Here my solution, which is in fact a non-solution because it doesn’t involve any specific techniques or process (there’s plenty of it out there, from Agile on) but it just relies on my own experience and observation of human beings fretting around a project.

The idea to this post came on the train to London, on my way to an agency we’re working with. I was reading a blog about User Experience and Product Design. It’s an excellent blog written by a very good consultant and writer, Joe Natoli.

I got to know him through his blog and his video course and I have always thought that what he writes makes a lot of sense, especially when he talks about scope creep.

I couldn’t recommend it enough, it’s written in an entertaining, accessible English and it’s full of real life examples of Joe’s extensive experience, on top of his extremely good practical suggestions.
He’s so authoritative because of his experience in the field. He’s seen it all, and he shares it with us, for everyone to learn, change and benefit from someone else’s mistakes. O, if only everyone would follow such a wise advice…

And this is my point: how many people do you know that changed thanks to new theories?
Well, I myself did, and I’m sure a lot of UX designers out there got caught by an epiphany while reading UX books and blogs that changed their own mind set and workflow.

But let’s be honest, a lot of people don’t listen to somebody else’s advice, don’t want to change because they think they’re infused with wisdom and truth (it gets worse with age) and learn only the hard way, when forced to after a disaster.

They’re not all monsters, of course, maybe some are simply human beings used to do things the way they’re used to. Or maybe during their daily job they experience a lot of limitations we might not be aware of (everyone is fighting their own battle, let’s not forget that).

Whatever the case, only when it’s too late – and legal documents are piling up on the desk – these people start reconsidering the whole process in retrospective, looking for what went wrong.

That’s when they are at their most vulnerable and ironically open to suggestions, finally humbled or simply aware that they are not as perfect as they thought.

If you want to help your team, this is the moment to intervene and point out that you’ve been saying that all along, when you kept pestering people with catastrophic emails that nobody bothered reading. Yes, everyone will think you’re a ‘told-you-so’ kind of a person, but who really cares if you manage to make a difference in the long run?

This is the time for you as a UX designer to provide some data, prepare a quick presentation, a case study, a video, whatever you feel comfortable with, so to show how changing process – and specifically avoid scope creep like the plague -can help everybody next time around.

The downside of my non-solution is that it requires time. You need to allow time for people to digest your contribution, they need to see real value to it when they most need it and are receptive to consider changes (you also need to allow some disasters to happen, I can’t see any other way around it). This non-solution also requires that people don’t leave but stay in the team long enough to improve all together, and I can see how that might be a problem.

But if all goes well, and people are still there after the mayhem, you will see that, little by little, everyone will become a User Centric Design process advocate, and if not perfect (we’re human, after all), your team work will become much more effective, and possibly even enjoyable.

You just need to keep sticking: to your guns, and to your own ever improving team.