Feature Creep and The Grinch Who Stole Christmas

There are a lot of creeps in the world, there are folk who do one thing and then say another and there are folk who act only on their own selfish ideals.

But I’m not here to talk about those kind of creeps.  I’m here to tell you about feature creep.

Feature creep is the bane of Project Managers everywhere and I myself have been confronted with it several times lately.  It can be best explained by the following:

Feature creep (sometimes known as requirements creep or scope creep) is a tendency for product or project requirements to increase during development beyond those originally foreseen, leading to features that weren’t originally planned and resulting risk to product quality or schedule. Feature creep may be driven by a client’s growing “wish list” or by developers themselves as they see opportunity for improving the product.

Or to put it in simpler terms:

Let’s say the children of the world could all document and specify their gifts to Santa when they write their letters.  Santa gathers up these letters and slots their wishes into his various elves workflows according to what each child needs.  Santa acknowledges (provided the child is not on the naughty list) that he can meet these expectations in time for presentation on Christmas Day.  Time goes by and the gifts are produced in Santas workshop.  He is about to set off around the world to deliver them on Christmas Eve when suddenly he receives a call from a child who has changed their mind and now would like their Barbie car to come in green, not pink.  Because of these last minute changes Santa is forced back into the workshop to meet these expectations and so is subsequently late on delivering not only this particular childs present, but every other childs too.

Checkpoint Reached:

Most project managers introduce “checkpoints” into their project management process to ensure this does not happen but these do not always work.  Checkpoints consist of a “sign off” so that the end user is tied into their own agreement that they requested this in their own words and cannot change their mind without adding further cost and time to the project.

I have learned of recent times that checkpoints only work if all stakeholders  are involved in the decision and sign off process.  Leaving one out can cause friction and feature creep further down the line.  This project management processes needed to be adjusted for special case scenarios where more than one stakeholder is involved.

Specify, Specify, Specify:

Stakeholders need to be made to specify all that they require, sometimes they may not always know all that they want and that is when it is up to the Project Manager to ask the right questions based on experience.  The stakeholder is then needed to sign off on all of their answers to these questions.

A good way to look at it; Is your project management process currently looking like “Nike Town”?  That is, does an end user tell you what they want and you “just do it” even though there may be questions that you need to ask in order to have all their expectations completely specified?

There are a great many logical points behind why projects are managed the way that they are and I hope this article has helped you to understand why process generally work the way that they do when it comes to a complex project.

Don’t be the Grinch who stole Christmas!