Home Monitoring & Controlling Scope Self-Inflicted Scope Changes
US FTC Compliance
Yes, all these ads are some kind of affiliate link and I get paid a commission if you click or buy.
Not enough to quit my day job, but it keeps the site alive.
- Jeb Riordan, Editor, PROJECTmagazine
Self-Inflicted Scope Changes Print
How many projects have you seen where scope changes cause dramatic schedule and cost overruns?
As a project manager, you’re well aware of the importance of scope definition and management to the success of your project.
You have your scope documented, reviewed, and formally approved, so you’re in good shape, right?

Not necessarily!

Natural vs. Self-Inflicted Scope Changes.

Some amount of scope change is natural for a project.
No project exists in a vacuum; the world around it keeps changing.
It is common that shifts in the external business environment result in a valid need to change the project scope.
The longer the project, the more likely this becomes. Scope management techniques help you handle this effectively.

Many scope changes are not so natural though, and could be avoided.
This insidious variety of change is not due to the business environment, but to problems with the original scope definition.
By allowing these flaws to exist in the scope definition, you’re setting yourself up for scope changes down the road.
Keep on eye out for these problems to make your project as change-free as possible.

10 Signs You May Have Scope Problems

  1. Unclear purpose. It is impossible for the scope to be adequately defined if the purpose and raison d’etre of the project isn’t clear. Is the purpose to sell more products? Cut costs by reducing manual entry time? Keep a key customer happy by fulfilling their request? If the overall purpose isn’t clearly understood and agreed upon, there is tremendous room for future disagreement on the project scope.

     

  2. Doesn’t meet objectives. The scope as defined doesn’t adequately address the objectives of the project, or its expected benefits. If your project has an objective “cut turnaround time on customer requests by 50%”, but your project scope doesn’t include the right items to do this, then you’ ve got a problem. You will not be able to meet the project objectives with the scope you have - a recipe for failure or future scope changes.

     

  3. Gaps in definition. The scope definition doesn’t mention some things at all. If Reports aren’t mentioned in the document, does that mean they’re not needed? Or does it really mean that people haven’t thought about this yet, but will ask for it later? Try to make sure you have all areas covered in the scope document. If your project scope is not going to cover Reports, then state this explicitly under Exclusions, to make sure everyone agrees.

     

  4. Insufficient detail. Your project scope may include “Provide flexible pricing capability”. But what does that mean? This could be subject to many different interpretations, with radically different sizes. It pays to clarify this and be more specific up front. You won’t have all the details, but try to find ways to define this and fence it in as well as possible. Identifying parameters or guidelines may help, such as “provide flexible pricing based on customer type, purchase history, and credit rating”.

     

  5. Hidden assumptions. These can be deadly when they hit you later. You may hear “You’re replacing module X, so obviously you have to replace Y and Z as well”. Or “Of course we have to continue supporting customers on the old version too”. It may seem obvious to the people who assumed this, but how were you supposed to know? Uncovering the hidden assumptions can be difficult, but is possible with persistent, delving questions. Document all known assumptions clearly, including those you’re making yourself. Spelling out constraints and exclusions can help with this too.

     

  6. Undocumented interfaces. Everyone is busy thinking about the exciting new system, but overlooks the initial data conversion and the fact that you’ ll need to exchange data with the legacy mainframe system. These can represent an enormous amount of effort on a project! Make sure you have every interface defined in the project scope, and all sources required for data conversion.

     

  7. Items don’t fit. If something in the scope doesn’t make sense to you, then you should question it. If everything fits together except one module that seems unrelated to the rest of the project, does it really belong there? Sometimes people like to slide their requests into the most convenient (already approved and funded) project. But should this really be part of your project scope?

     

  8. Wrong participants/approvers. You interviewed key users in defining the scope. You had a number of experts review it, and designated executives approve it. But are they the right people? If there are other people who have a better understanding of what should be done, a more significant stake in the project, and/or more appropriate authority to make the decisions, then get them involved as soon as you can. If these people get involved a month or two later, you can bet they’ll have something different to say about your project scope.

     

  9. Silent questions. You see people, especially project sponsors, who just don’t seem convinced. They’re on the verge of saying something, but don’t come right out with it. They’ll probably bring it up later, so try to get it out on the table now. Perhaps they’re thinking “But will this resolve our issue with the Mexican market?” Or “How does this fit with the Genesis project that Cheryl’s group is doing?” It’s better for you to know about these concerns early on, before they blossom into scope changes.

     

  10. Unresolved issues. Sure, you can take some open issues and table them for later - sometimes you have to. But make sure you know which are the sharks in the bunch, the ones just waiting to bite you. Understand your issues well enough to identify those that potentially affect the scope, and then try to address each of these as early as possible. Skipping it now is just asking for a scope change later.

     

 

2002 © Deanna Keahey.

Deanna Keahey
VMG Services, Inc.
Increasing project management success
Email:
This e-mail address is being protected from spambots. You need JavaScript enabled to view it

Share/Save/Bookmark
Comments (0)Add Comment

Write comment
bold italicize underline strike url image quote Smile Wink Laugh Grin Angry Sad Shocked Cool Tongue Kiss Cry
smaller | bigger

busy
 
Copyright © PROJECTmagazine (c) 1998 - 2019 for practical project management information. All rights reserved.