Scope is defined at a high level by describing the
boundaries and deliverables of your project. You add more detail to that
definition through the gathering of your business requirements. Once these
items are agreed to by your sponsor, you can manage overall scope change
through a simple scope change process. Remember that having your scope and business
requirements approved doesn’t mean nothing can change from that point on. It
means instead that you will manage the overall change process from that point
forward using a good scope change management process.

Here’s a simple scope change process that you can use on
your project.

  1. Solicit
    potential scope change requests from any project stakeholder, including the
    project team, clients, sponsors, etc.
  2. Smaller
    projects can document the scope change in a short form or an e-mail. For
    larger projects, the scope change request should be formally documented
    using a Scope Change Request Form. The important thing is that you need to
    document the scope change in writing. Don’t act on scope change requests
    you receive verbally.
  3. Enter
    the request into the Scope Change Log for tracking purposes.
  4. The
    person making the scope change request should define the business value to
    the project. The sponsor will need this information to make a final
    decision.
  5. The
    project manager will assign the scope change request to a team member for
    further investigation. (The project manager could assign it to himself.) The
    team member will first determine how much time it will take to investigate
    the scope change request. If the time required to perform the analysis
    will cause deliverable dates to slip, the request must first be taken to
    the sponsor to determine whether the request should be investigated or
    not. If the sponsor gives the initial approval to proceed, the workplan and budget may need to be updated to reflect
    this new work. If the sponsor does not agree to investigate the change
    request, then the request should be placed closed as “not approved”
    on the Scope Change Log.
  6. Take
    the scope change request, alternatives, business value and project impact
    to the sponsor for a resolution (yes we do it or no, we don’t do it).
  7. Document
    the resolution or course of action.
  8. Document
    the resolution briefly on the Scope Change Log. If the Sponsor does not
    agree to the change request, then the request should be closed as ‘not
    approved’ on the Scope Change Log.
  9. If the
    scope change request is approved, the appropriate activities are added to
    the workplan to ensure the change is
    implemented. The project budget should also be updated, if necessary.
  10. The
    current Project Definition (Charter) should be updated if an approved scope
    change results in a substantial change to the project.

Throughout the process, make sure that you communicate all scope
change status and resolution to project team members and other appropriate
stakeholders. This is usually done by attaching your current Scope Change Log to
your Status Report. This helps manage expectations and shows how approved scope
change requests are impacting the project end date and budget.

Subscribe to the Developer Insider Newsletter

From the hottest programming languages to commentary on the Linux OS, get the developer and open source news and tips you need to know. Delivered Tuesdays and Thursdays

Subscribe to the Developer Insider Newsletter

From the hottest programming languages to commentary on the Linux OS, get the developer and open source news and tips you need to know. Delivered Tuesdays and Thursdays