« Cost Reimbursable Contracts - A PMP Definition
Introduction to Project Management Processes - Risk Management »

Low-Hanging Fruit To Avoid Scope Creep

May 13, 2009 | Author: PM Hut | Filed under: Project Scope Management, Scope Management

Low-Hanging Fruit To Avoid Scope Creep
By Bruce Beer, Global Knowledge Instructor

What issue consistently appears in the top ten causes of project failure, and what is the easiest and arguably most effective measure a Project Manager can take to virtually eliminate that issue?

The answers are “Scope Creep,” and “Change Management,” respectively.

Without a solid definition of scope, scope creep is almost inevitable, and implementing change management is like trying to swim up the Colorado River in full flood!! However, if the PM and their team do a good job of identifying and documenting scope requirements, then scope creep can be virtually eliminated by a good change management plan and unyielding execution.

So - assuming the Project Manager and team have started scope definition with a deliverables-based Work Breakdown Structure (WBS) and have then broken these deliverables down into activity definition, they will end up with a list of activities required to complete those deliverables. Great start! However, we all know that before the ink is dry on the scope definition, some kind soul will usually want to change it. Does this cause disruption to the Project Manager’s karma? Not if there is a good change management plan in place that has been communicated to all stakeholders and is being enthusiastically followed. Change is good and healthy for a project provided -

  1. The entry point for change is the PM (without exception)
  2. The change required has been well defined
  3. All ripple or knock-on effects within and outside the project have been evaluated
  4. All impacts on time, cost, functionality, risk, and quality have been assessed and documented on the change impact analysis
  5. The customer (or entity paying for the project) approves and authorizes the change

If any one of the above does not happen, your project is in serious jeopardy. Let us look at each element in turn.

1. The change request is given to the PM

Without exception, the change request’s path to glorious implementation starts with the PM who first receives it, logs it, then allocates it to a team member best suited to assess and evaluate that request.

2. It is well defined

A change is like any element of scope definition - if it is not well defined, neither the PM, the team, nor the customer can be clear or unified on what needs to be delivered - a grand opportunity for different interpretations by all concerned.

3. All ripple or knock-on effects have been evaluated

Once the change is received, the position of the affected deliverable on the WBS can be determined, and potential impacts on other areas can be assessed. Following this first assessment, a qualified team member can evaluate what other areas of the project may be affected. For example, lengthening an address line field from 25 to 35 characters on an input screen and database record may have impacts on many other areas such as invoice printing, search engines, etc.

4. All effects on time, cost, functionality, risk, and quality have been assessed and documented on the change impact analysis

This is the crux of the impact analysis and is what the customer needs to understand before they authorize or reject the change. This may not only affect the baselines for scope, time, and/or cost, but other areas such as risk. The customer should also be able to assess the business case for potential effects of implementing the change before authorizing.

5. The customer (or entity paying for the project) approves and authorizes the change

If the customer does not approve the change, the decision is logged and the change request filed with no further action by the PM or team. If the customer does approve the request, this formally recognizes that they accept all the implications and impacts of that change, particularly to the triple constraint baselines. This will be logged by the PM, who will provide authorization to the team to implement the change.

Summary

Once a change management process is defined and communicated, the next task is for the PM to review it thoroughly at the Kick-off meeting so that the team is in no doubt of the process to follow if anyone asks them to implement a change, or if they want to propose a change themselves. It should be heavily stressed that no change at all will be implemented without approval by the PM. It is also advisable, for the PM’s longevity in the job, to emphasize that not adhering to this process would be a career limiting event!!

Why is this easy to implement? Because it just needs one standard process, communication of that process to all stakeholders, and strict adherence to the process during execution.

What if there is no impact to time or cost baselines - do we still need to go through the process? Absolutely yes! Supposing a minor screen change is requested that will re-arrange the appearance of fields on the screen and maybe add a new easily accessible field - none of which will take additional time or money to implement because it was requested before there has been any work done on that deliverable. When it comes to acceptance, the acceptor will look at the specification, then look at what is delivered, and say, “Lo! Verily this is not good!!,” and will fail acceptance because the specified deliverable and the actual deliverable are not identical. However, if there is a formally authorized change request to explain the difference, the acceptor will say, “Lo! Verily this is good,” and will place a tick in the right box.

One common issue with this process is that the optimum resource to assess a change request is often working on a critical path activity, and time taken for evaluation may affect the timeline of the project. This has many project dependent solutions which could be the source of a further paper!

The moral is to identify, communicate, emphasize, and strictly adhere to a change management process - it could save the project, and with it, the PM’s career aspirations (but only where there has been a good initial scope definition).

Bruce Beer has been a Project Manager for 25 years following experience as programmer, systems analyst, system designer and general management.

This article was originally published in Global Knowledge’s Business Brief e-newsletter. Global Knowledge delivers comprehensive hands-on project management, business process, and professional skills training. Visit our online Knowledge Center at www.globalknowledge.com/business for free white papers, webinars, and more.

© Copyright 2009, Global Knowledge. All rights reserved.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Wednesday, May 13th, 2009 and is filed under Project Scope Management, Scope Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories