We just got carried away!

The Truth About Scope Creep--And How To Avoid It.

  "How much longer 'til we get there?" isn't just a question our kids ask after we've crossed the river on our way to grandma's house.  It's one we might also ask when our hopes for quick deployment of a web site or desktop application fail to materialize as rapidly as we'd expected.

 Sometimes there's no excuse for project delays--we've heard of cases where developers (working for our competitors, of course!) failed to even get started on a major project until the deadline had come and gone.  But more often, there's another culprit lurking in the shadows.  It's called scope creep. 

What is Scope Creep?

Also affectionately known as "kitchen sink syndrome", scope creep refers to uncontrolled changes in a project's scope.  The project appears to start growing all by itself, expanding like a fast-moving cancer. You'll know you're looking at scope creep when the work escalates beyond the time or money budgeted for its completion.

 "How did we get here?" a frustrated client might ask after the fact.  "After all, we're intelligent professionals who know exactly what we wanted and exactly where we wanted to go--right?"  Probably so.  But there's a reason for the word creep in scope creep.  More often than not, the cause for delays stems from not one, but a multitude of incremental little tweaks and improvements that, when combined together, can put the delivery date for a large project in serious jeopardy.

 When the scope of a project "creeps" beyond its initial boundaries, it can be due to a number of reasons: 

·        Poor Project Definition:  No one took the time up front to adequately define the project, or document what the finished result should look like.  Sometimes there are genuine misunderstandings about what a client wants, and what the developer thinks the client wants.  Whenever requirements aren't spelled out in black and white, the potential for scope creep to sneak in is very high.  Here are a few examples of how poor project definition can manifest itself: 

1.      Vague statements in the description of work to be done.  Here's one  example,

"a screen will be developed to track all vendor communication..."

What's wrong with such a statement?  Nothing, if it's the beginning of a lengthy paragraph which describes exactly how the screen should look, and exactly what how it should function.  But if this is the entire extent of the screen definition, do you see how much room for confusion and misunderstanding it introduces? 

A good statement of work will go much farther, describing the fields to be included, how users can access the screen, and how each of the various controls on the screen should work.  Vague statements in the project definition often result in disappointment when the project is delivered.

2.      Failure to document the criteria for completion.  While it's important for everyone to agree on what the completion criteria for the project will be,  "We'll know we're done when everybody's happy" just won't cut it.  Without a well-defined set of completion guidelines, folks will be caught in an endless cycle of having to add "just one more feature" or make "just one more change".

3.      Forgotten project components.  This is also known as the "Where's the feature we never told you about?" conundrum.  A good systems analyst should be able to help ferret out the scope of an application up front.  But sometimes clients fail to mention that they want to incorporate the functionality of an entirely separate application into a new project.   Only after the new project has been delivered do folks on the client end realize that something's missing. 

·        Changing requirements mid-stream, with no adjustments in the project documentation.  For example, "What we said we wanted six months ago no longer applies, because we've introduced a new product line.  And we no longer need the widget feature because we stopped manufacturing widgets."  Changing requirements can have a significant impact on the project scope. 

Additions, changes, overlooked features and enhancements can add substantial cost to any project.  As the size of a project grows, managers on both sides may expect more tasks to be completed at the same cost and in the same time frame as the original series of project tasks.  This can lead to increased stress on both sides.  Thus it becomes increasingly difficult, if not impossible to deliver a finished product on time and within budget. 

What can we do to prevent scope creep?

Scope creep can be controlled, or at least managed, with proven project management disciplines and techniques.  Whole books have been written on how to manage software development.  To distill their collective wisdom in a nutshell:  When it comes to software development--the best medicine is prevention.    

Here are three of the most salient methods to prevent scope creep from ruining everyone's day: 

a.       Start small--especially when you're working with a new software developer for the first time.  This will protect your investment of time and money most effectively.  If the first project goes well, then subsequent enhancements will cause less anxiety.

b.      Document expectations thoroughly.  What exactly should the finished product look like?  What functionality should it include?  The more documentation that has been established in the initial stages, the less likelihood of surprises and unmet expectations.  Some folks think they're too busy to take the time to do this.  If that's your situation, consider hiring a systems analyst to do the documentation for you  Failure to document will likely result in undocumented failure.

c.       Expect change orders.  Even the most detailed statement of work can't incorporate changes in a company's environment, such as a new service offering, merger and acquisition of another company, or change in management. 

And it's not unusual, once a customer gets the chance to actually work with what previously had been someone's idea, for the light bulb phenomenon to kick in.  For example, a sales manager takes one look at the new software and cries out, "Hey!  If the software can automate invoicing, why can't it help us automate proposal writing too!"  As long as both customer and developer agree that the desired enhancement is just that--an enhancement--change orders can help facilitate the development process.

Furthermore, change orders can help identify the priority of the additional functionality.  Should a new feature be incorporated into the main project before the final deployment, or should it be included in a future release?   

Scope creep is nobody's friend--not the clients, and not the developer.  The client will likely become frustrated by delivery delays and cost overruns.  The developer will be disappointed when his or her creation doesn't fully meet the client's expectations.  Before you embark on your next project, consider taking the time to document your needs.  Talk with your software developer about how best to document your expectations and requirements.  Agree on detailed software development plan before a single line of code is written.  You'll be pleasantly surprised with the results. 

About I/O Technologies, Inc.
Founded in 1994, I/O Technologies Inc. is a woman-owned company that writes software applications for business computing. The company offers a wide range of products and services designed to empower people through great software - any time, any place.

Dave Martin
dmartin@iotechno.com
262-437-3239