Business-focused custom software

Go Back

How to protect yourself from the creeps (part 2)

In part 1, I described some of the causes of software development scope creep.

So now the $64,000 question is: what can we do to prevent scope creep?

Unfortunately, there is no bulletproof, 100% guaranteed method of eliminating scope creep for your software project. That doesn’t mean that the requirements will definitely change, but it does mean that no one can promise you it won’t happen. (If they are promising that, they are selling you a bill of goods.) However, there are some things you can do to decrease the likelihood that creep will derail your project.

Document requirements (and periodically review them.)
There are few people who enjoy documenting system requirements, and even fewer who enjoy looking at them once they are done. But in my experience, the more things are written down, the more likely it is that everyone can agree on what the scope is.

Verify requirements by discussing them fully.
Often times a quick discussion about a features will lead to questions and additional understanding. For example, what if a requirement is “allow users to upload images to the website”. A good discussion about this requirement will lead to answers to the following questions:

  1. What kind of files? Any kind or can/should we restrict the uploads to just pictures or PDFs.
  2. How large can the files be? Large file uploads can affect bandwidth and server resources.
  3. Where should the files be stored? In the file system or the database?
  4. Should there be a way to delete the files too? What about replacing them?

As you can see, a simple requirement involves a lot of details. A programmer will usually (although not always) assume the easiest solution, but that may not be what you want. Fully discussing the requirement will help the programmer to better understand your needs and not go with their first assumption.

Encourage frequent builds/iterations.
The more frequently you can see progress, the more likely it is that you can steer the project in the right direction. If you wait to review the application at the end, if there is something wrong with what has been accomplished it will be much harder and more expensive to change it. For larger projects, periodic reviews of the software will help you to know if the project is going down the wrong path before all the project budget is spent.

Even if you use all of the above suggestions, you will still occasionally see some scope creep. So, what can you do to handle it?

Set aside a change order budget.
I recommend that this budget should be approximately 10%-20% of the project size. That way if we discover features that were not initially included, we already have a budget for them.

Make it a partnership.
You need to trust the people you are working with. (If not, you shouldn’t be working with them.) So, don’t assume that the programmer is trying to rip you off.  That isn’t a partnership – that’s a bad relationship. A good programmer will provide some free changes if they are minor or if they believe they are responsible for the mistake. But that doesn’t mean they should eat the cost for all changes. Be fair.

What tips do you have to decrease scope creep?

  • Facebook
  • Twitter
  • Digg It!
  • StumbleUpon
  • Technorati
  • Del.icio.us
  • Reddit

Post a comment!

Formatting options
   
 
 
 
 
   

Wanna Subscribe?
Here's the RSS Feed

What the critics are saying...

Avonelle has been a pleasure to work with.  Working with someone that you know will always deliver is tremendous.

Mark McNamee @ Renewal by Andersen