Monthly Archives: January 2012

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

10 Technology Commandments for HR When Hiring In 2012

1.  HR shall not be intimidated by IT folk who talk in big, scary words.

2.  HR shall not let their software lead them, but shall lead the software to help meet their goals.

3.  HR shall not collect a bunch of superflous information from applicants via an online application, just because they can.

4.  HR shall not allow their marketing department to place the link to the career section anywhere but on the home page of the brand web site.

5.  HR shall not let resumes slip into the infamous black hole, but rather should get to know their ATS and use it.

6.  HR shall not buy any software without first understanding why they need it.

7.  HR shall not assume that the software companies with the biggest marketing budgets have the best software for their needs.

8.  HR shall understand and walk through their hiring process as an applicant from beginning to end at least once a year.

9.  HR shall not waste their applicants’ nor their recruiters’ time with extraneous information gathering and unncessary form validation.

10.  HR should keep asking questions of technology experts until they gain the understanding they want and need.