Managing Project Scope

Managing Project Scope (#30 in the Hut Introduction to Project Management)
By JISC infoNet

In any project there are likely to be changes to the original plan during the course of the project. The changes may arise due to:

  • The business case altering
  • The need to find a way round a problem
  • Identifying a better way to meet your objectives
  • The scope of the project altering
  • Somebody thinking the change is a good idea

A Change Control mechanism is necessary to ensure that such changes are handled in a managed and controlled way in order to keep the project on track. Without formal procedures in place the project runs the risk of ‘Scope Creep’.

Scope creep is an ever present risk in most projects. It is a particular issue in software development projects where it is always tempting to add a few extra changes as benefits become clear during the progress of the project. It can often prove quite difficult to keep within scope given that additional suggestions can be closely linked to the original initiative. Changing the scope of the project frequently poses risks in terms of keeping to budget and deadlines but it is important to realise that scope change may also offer opportunities to derive previously unforeseen benefits. Conversely you may also need to ‘de-scope’ items from time to time in order to keep within project tolerance limits.

Any proposed change to the agreed deliverables of your project should be subject to an impact analysis. Key to any approach is to consider the impact in terms of:

  • Time
  • Cost
  • Quality

By this stage in the project you already have an agreed plan and deliverables and an agreed budget. By considering the proposed change under the above headings you should be able to establish whether the change is within acceptable ‘tolerance limits’ or whether it has a significant impact on any of these areas.

If you are not using the concept of tolerances as previously described, then the definition of ‘within tolerance limits’ is usually that the change can be implemented:

  • without affecting achievement of major milestones in the plan and
  • within the overall existing budget

Generally a Project Manager may approve changes that are within tolerance but will refer to a higher authority such as a Project Board where the proposal amounts to a significant scope change. To help the Project Board make a decision the Project Manager may prioritise the issue using ratings such as:

  • must do – the project cannot complete successfully without this change
  • important – functionality would be impacted without the change, although it is not vital to the success of the project
  • nice to have – an enhancement to agreed scope and quality
  • cosmetic – no functional improvement

Change controls are particularly important where a contractual relationship exists. Where you are working with a third party supplier or consultants you need to be particularly careful about correctly defining your original scope and managing changes or you could suddenly find costs spiralling out of control.

Good project management is a careful balancing act and handling change is a key element of that act. It is not good management to ‘freeze’ a specification and plan on day one of the project and stick rigidly to it, nor is it good practice to change so often that the project never comes to an end.

Change control mechanisms usually involve some form of Change Request form that records:

  • Details of the proposed change
  • Analysis of the likely impact and
  • Agreed actions

JISC infoNet aims to be the UK’s leading advisory service for managers in the post-compulsory education sector promoting the effective strategic planning, implementation and management of information and learning technology.

PMHut Team

PMHut Team

PMHut.com is a website dedicated to providing PM articles, detailed project management software reviews, and the latest news for the most popular web-based collaboration tools.

1 Response

  1. Avatar Steven Levy says:

    It’s great to see recognition that — especially in s/w projects — scope changes are both a matter of course and not always anathema. It’s not uncommon that as you learn more in an area where you cannot know it all at the start, scope will need to change. Bad PMs resist without investigating the ROI or cost/benefit analysis of change; it’s a sign they’re more concerned with personal project stats than delivering value. (Other bad PMs, of course, never learn to say No.) Good PMs — perhaps it comes with maturity — understand that scope changes are themselves part of the flow and build a plan to deal with them in a way that most benefits the customers, whether that means deferring a change, adding it, or trading something else out for it.
    — Steven B. Levy
    Author, Legal Project Management: Control Costs, Meet Schedules, Manage Risks, and Maintain Sanity

Leave a Reply