How to Avoid the Double-Edged Sword of Scope Creep

How to Avoid the Double-Edged Sword of Scope Creep
By Jennifer Brogee

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.

Jennifer Brogee is the Chief Information Officer for HR Tech company, myStaffingPro. She has been in the technology sector since the early 90s. You can read more from Jennifer on her blog.