Forget Everything You've Learnt About Project Delivery, Part 1: Scope Management

Many articles and media reports talk of the danger of 'scope creep' in terms of the project's size and scale increasing, blowing out the timescales, budget and, often blowing up the project itself.

This focus on scope creep has disguised the more common problem of 'de-scoping', where what gets delivered is a subset of what was intended to be delivered. Here, the project is sometimes delivered on time and budget (success!?) but the promised business results are not realized in full if at all.

Every manager coming onto a project knows they need to 'control scope'. As a result, they can inadvertently destroy the project from the outset.

There are two types of scope on a project, and failure to distinguish between them causes many of the scope-related problems. There is a 'problem' scope - the extent of the problem/business area that is to be considered. This scope should be as wide as possible, so that all of the performance improvement opportunities are identified.

Then there is the 'solution' scope. Just because you've defined a broad number of opportunities doesn't mean that they all have to be delivered. The solution scope selects the areas/solutions to be focused on and delivered. Tight scope control becomes appropriate with solution scope to ensure the value associated with the agreed solution scope is delivered in full.

Acknowledgement of these two types of scope causes some of the problems with scope management to disappear.

When the opportunity area has been broadly reviewed, the incidence of later finding aspects to be added to the scope, because they were missed in the first stage, disappears.

Good bright ideas that will extend the scope of the project are precluded by the initial broad analysis. Having selected your solution scope, bright ideas can be parked for a later day.

When the scope is defined too narrowly at the outset, there is always the danger that something critical has been missed; but when the initial 'problem' scope is defined broadly, this danger is avoided.

Conversely, with the solution scope, it can be defined in the full knowledge of the value of each inclusion and exclusion. 'Adding' to this scope is precluded. Similarly, any de-scoping can now be seen to directly impact the project's business value and, therefore, require rigorous scrutiny and evaluation.

(NB: The determination of the solution scope requires its own business case to be approved - this is not a decision made by the Project Steering Committee as a de-scoping exercise, but a redefinition of the project to be implemented after the broad analysis work has been done.)

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email CIO
• Follow CIO on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark