Excessive Customization: The Fastest Way to Kill Your Project

I have run many projects to implement software over the years, and learned many lessons along the way.  One of the most common themes I hear project managers talk about is the dreaded “scope creep” – the constant moving of goal posts that often occurs.  Of course, the real difficulty is that project sponsors often don’t know what they want but, surprisingly, do know when they want it by.

Usually, problems are apparent right from the outset.  Firstly, if your project involves building a system that is available off-the-shelf then alarm bells should be going off.

Unless you are building something that provides a significant competitive advantage, then 99% of the time you are better off buying the package, and here is why:

Penny Wise & Pound Foolish
The off-the-shelf package won’t exactly match the way your company does business.  But I will bet good money that accepting that, or slightly changing your processes will cost less than building, customizing  and maintaining a bespoke system.

You’re Already Late!
The off-the-shelf software already has several years head-start on you.  By the time you build a fraction of the functionality contained in the package, they will have moved on.  After all, this is their competitive space and their existing customers will be constantly pushing them to keep improving.  Not only will you never catch up, you  won’t even get close.  Your expensive software will constantly fall behind the rest of the market and end up a competitive disadvantage.

But, let’s assume that the decision was made before you were given the project, and you don’t have the political clout to get that changed.  Your task now is to deliver, on-time and on-budget, while still keeping the sponsors happy.

Scope creep is inevitable and, I would argue, actually positive if you want to deliver something that makes sense at the end. There’s no point in delivering a feature from the original design if the market has changed and the module will never be used.  A somewhat controversial  study by the Standish Group suggested that 64% of functionality delivered is “rarely or never” used.  Some argue that Standish’s measurements are harsh.  But even if they are off by 50%, that is still a huge number.  Your job, therefore, is not to limit change, but to make sure that what you are building actually adds value.

Most project sponsors have seen the story before.  They get one chance to say what they need and this  is then split into “Phase 1” and “Phase 2“, which really translates into “Phase 1 minus the stuff we couldn’t complete on time” and “Never“.  Because of this, the sponsors have adopted a simple technique – Stuff the hat with as much functionality as possible.  If they get enough in there up front, then they might actually end up with most of the functionality they really need at the end.

This desire to keep adding functionality needs to be managed before the requirements gathering session turns into a customization binge and you find yourself waking up in a pool of customizations, unable to remember the past two weeks and with a maintenance headache like a jackhammer.

So how do you avoid this?

First off, you need to grow a pair.  Be willing to stand up to your sponsors and push them to prove the functions that they are asking for actually make sense and are worth the effort.  Putting things into dollar or time values can really help here.  e.g.  “Is that field really worth an extra $100,000 and a 3 week delay?” You will have some fights, you will lose some, and you will win some.  But ultimately, as long as the rationale is solid, people will respect you for your commitment and the project will be successful.

Know when to stop! Some people like to tweak things constantly – continually trying to make things just that bit better – but all this tweaking takes time.  Doing things right is important, but you need to recognize the cancer of perfection, if you are to avoid spinning your wheels long after an acceptable solution has been found.  Sometimes good enough is good enough.

Try mixing in Agile techniques. Like the traditional Waterfall project methods, agile software development requires a list of requirements up front (your backlog).  The big difference is that the team only agrees to deliver the items that can be completed within the next “sprint” (usually 2-4 weeks).  At the end of the sprint you deliver real, working software and then agree the next set of deliveries.  This way the business receive working software much earlier than they normally would and, over time, the items being delivered have less and less value.  Eventually the sponsor will realize that they have bigger fish to fry elsewhere and will redirect resources to those projects…but it will be their decision to do so.

Picture by Simon Clarke

Unless  you manage it vigilantly,  excessive customization will take over your project – and your life. Your projects will fail, your career will go down the tubes, and you will find yourself sitting on a park bench with a bottle-shaped paper bag, muttering phrases like “scope creep” and “waterfall” to people passing by.

So get with the program already, before the person in this picture becomes you!