How to Avoid the Double-Edged Sword of Scope Creep

I love the term scope creep because it so adequately describes what can be the downfall of any IT project – the never ending changing of specifications during the building process.

In the early days of working with clients, almost every project I worked on fell victim to scope creep.  It’s so easy to do because IT folks and account managers want to please their clients, but scope creep is a double-edged sword – not only does it add non-billable hours of programming to an IT project, it also creates discontent on the client’s side.  Ironically, clients are happier when specs are followed religiously and the end product is what was agreed upon at the earliest phase.  Based on 12 years of experience, I can say that even though clients may ask to change specs in the middle of the project, they are more satisfied overall when you say, “sure, but that will cost you x.”  Knowledge of the effort and costs required to make functionality or design happen results in happier programmers and customers.

How to prevent scope creep?  It’s actually not that difficult once you practice it a bit.  Here is how we do it:

Ask the client to identify the end goals of IT project

This seems obvious, but can often be missed when the client already has an idea of what the application should look like.  Even if the client provides detailed specs, step back and ask what the business goal of the project is.  A better understanding results in a better software product.

Provide a detailed scope of work document

Include in the scope of work the goal of the project, a detailed functionality list, an estimate of the design, mockup, programming and testing hours needed, and an estimated timeline for completion.  If user interface changes are to be made, build into the scope of work a time frame and hours to build mockups.  Base timelines on receiving required sign-offs from client, for example: “6 weeks from receipt of signed mockups.”

Walk through the scope of work document with the client

With the client’s account manager, plan a call or face to face meeting to walk through the scope of work document and make sure the client understands what they are getting before signing the document.

Require sign-off on the Scope of Work before work is begun

This is very easy to do when using electronic signature online software such as Echosign.

Require sign-off on mockups before programming is begun

Put the screen shots into a document and ask the client to sign it to verify everyone is on the same page.

Re-quote scope changes

You may be tempted to allow some minor scope changes along the way without going through the hassle of re-writing the scope document.  Don’t do it.  Those minor changes can easily turn into major changes.  If you want to comp the changes, fine, but still write them into the scope document, indicate the number of hours, and then put a zero price next to them.  The client then understands that work is being done, but you’ve given them some hours out of the kindness of your heart.  Ideally, you would charge for any scope changes.  Most often the client decides that “x, y, z feature isn’t that important.”  As they say, “A pretty good test of a man’s religion [or software requirements] is how it affects his pocketbook.” – Francis J. Grimke.

Create beta testing guide for the client and ask for sign-off

This doesn’t have to be a formal sign-off (although you might want to make it one in some cases), but at least ask for an email from the client indicating they’ve beta tested the product and it is ready for release.

Advertisements

3 responses to “How to Avoid the Double-Edged Sword of Scope Creep

  1. The funny thing about scope creep, is that in the end, when the project is late, over budget, and full of bugs; everybody gets Amnesia about how creep got in there. In my experience, I’ve put “Freeze Points” into project plans, so everyone knows that when that date hits all development/enhancements are frozen in place and nothing new can happen. And usually on “Freeze Day” I make sure I’m not in the office for last minute walk ups to my desk!

  2. Jennifer Brogee

    Great idea!

  3. Hi Jennifer,

    This is an excellent post on avoiding scope creep altogether, I’m sure many project managers will benefit from it. That’s why I would like to republish this post on PM Hut ( http://www.pmhut.com ), please either email me or contact me through the “contact us” form on the PM Hut website in case you’re OK with this.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s