Many project managers must deal with project stakeholders who request, and often demand, a change to the project after the original requirements have been defined.

Webinar: 3 Simple Steps for Managing Project Risks in SharePoint

It is all too easy for a project manager to allow a small change to the project and before they know it, the scope of the project has changed considerably compared to the originally defined requirements.

This is referred to as Project Scope Creep.

Project scope management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully.

There is another term called “gold plating,” which involves adding features and requirements in the project that were not originally planned in order to improve customer satisfaction. This is also not a recommended practice as it too contributes to scope creep.

Triple Constraint

In order to help understand the effects of change to the scope of a project, we need to take a look at the project management triple constraint.

Below is a  graphic to illustrate the three forces  – Time, Cost, and Scope – that control the overall performance of a project and clarify how a change in one of these forces can affect the other two.

Immediately you can see if there is a change to the scope of a project and you want to maintain the same overall performance of the project, you will need to either increase the cost (or project budget) and/or increase the Time (or Project Schedule). Therefore it’s imperative that the relevant stakeholders fully understand the consequence of the change to the overall Project.

Change Management

One of the main processes used to control the scope of a project is change requests. Deploying a structured process to log and track change requests is one key way to prevent Project Scope Creep. A Change Request form details the modifications to an agreed upon project scope as defined in the Work Breakdown Structure (WBS). Other information required will include:

• How will require adjustments affect:
  • Cost
  • Time
  • Quality
  • Other project objectives
• What happens if scope changes?
• How is the Scope change fed back through the planning process?
• What are the technical and planning documents that need updating?
• How are other Stakeholders are notified of the change?
• Who is responsible for tracking the Change?
• What are the Deadlines?

Manage Project Scope in SharePoint

SharePoint provides the ideal platform for defining both Forms and Views to manage Project Changes, to report on Changes,  and to measure Project Scope as a Key Performance Indicator (KPI) of the overall Project. Below is a very standard Project Change form with the most common metadata captured. Using  SharePoint Views, you can then easily transform this from Project Data into Project Information that provides Project Managers the visibility to better manage the changes and thereby keep the project in scope. Typical views would include:

• Open Requests
• Approved Requests
• Overdue Requests  (based on deadlines)
• Rejected Requests.

Measuring Scope Creep

Your Project Management Governance will then dictate when a Project starts to slip regarding its scope, and using a KPI, give immediate visibility in your project dashboard.

A typical measurement of Project Scope could be based on the total number of Open Requests per Project. If Project Requests are approved after being logged, reviewed and actioned upon as per your Project Management Governance, then the Project Scope is in good shape. What you would need to be mindful of is the volume of Changes per Project as this could lead to them slipping in without fully acknowledging the implications.

Image credit