Is your scope definition gathering dust? You have just been selected to manage that big, important corporate project. Now that you’ve defined your project’s scope, what do you do with it, and how do you deal with scope change?
Changes are a normal part of a project’s life — Don’t your scope definition gather dust.
Have you ever managed a project that produced a result that matched exactly what was defined in the project’s scope? It’s a myth that a project is in control when the project manager is assigned; it takes a lot of skill, talent, and hard work to make a project appear to run smoothly.
Managing change is critical to a project’s ultimate success. Changes can be initiated by an external party (a supplier or regulator, for example) or by someone inside your organization. Project change management is the process by which you manage and control your project’s scope and should not be confused with organizational change management or software change management. Nor should project change management be confused with variance analysis, which is another important activity performed when managing and controlling your project.
Changes to a project are considered an indicator of a project’s stability and ability to meet budget, cost, and quality targets. Now that your project’s scope is defined, keep listening. Did the requirements definition require any revisions to your project’s scope? Has any stakeholder requested changes that affect the scope?
Determining the impact of a change consumes time and money.
When requirements change so should your scope definition. The change request must include the time required to investigate, analyze, and develop an estimate of the impact of the change request. Sometimes the mere reminder that the project team’s progress will be interrupted to assess and respond to a requested change is enough to weed out requests for ‘nice-to-have’ or lower-priority items.
There are five general steps to project scope change management:
- Initiate. The person requesting the change documents the change request by completing a form. This form is usually online and in a central, easily accessible, and visible location listing all requested changes.
- Analyze. Plan to interrupt your team for up to five days to perform and document the change impact analysis. The response to the change request should detail impacts on product functionality, schedule, cost, quality, and/or resources.
- Approve (or deny). Identify the person(s) that must review and approve the requested change and related impacts. For expediency, consider specifying a deadline for the approval response (three days is usually adequate) and developing thresholds that align approvals with the size and complexity of the requested change.
- Prioritize. If the requested change is approved, understand its priority relative to the most recent scope definition.
- Implement. Align your work plan, scope definition, and solution delivery work products based on the impact analysis results. Consider establishing a change budget equal to 15% – 20% of the total project cost, where the change budget is exclusively controlled by the person(s) reviewing and approving the requested change.
Some changes are not changes to project scope.
Scope changes occur when business requirements change, which materially changes the project’s scope definition. Examples of items that may result in project variances but are not changes to project scope include:
- Informational changes used to communicate expectations.
- Staffing changes due to project team member departures.
- Failure to perform any aspect of a contract.
- Changes to an accepted project deliverable (for example, testing revealed inadequacies in design or a missed requirement).
- Inaccurate estimates (examples include time lost due to unavailability of required nonhuman or human resources, delays in approvals, project elements revealed during design, and assumptions proving to be false)
The useful life of your project’s scope definition lasts through project closure. Your project’s scope defines the project’s outcome; don’t forget to summarize the delivered business value by comparing the project’s result to the original project scope definition. Did your stakeholders focus more on the project budget and/or schedule instead of scope? If so, it will become apparent during this exercise where the project’s scope was likely to be cut in order to meet cost and time objectives.
Similar Content:
-
The implications of skipping scope definition
-
How to best define your project’s footprint
-
Project plans: More than just a task list
