Home Planning Scope Writing a Scope Statement - Page 2
Custom Search
US FTC Compliance
Yes, all these ads are some kind of affiliate link and I get paid a commission if you click or buy.
Not enough to quit my day job, but it keeps the site alive.
- Jeb Riordan, Editor, PROJECTmagazine
Writing a Scope Statement - Page 2 Print

 

Scope Verification

In previous articles we discussed writing a scope statement and developing a Work Breakdown Structure in scope definition.
This month we make a bief mention of scope verification, because without completing this step in the process in a controlled way how do you and your client know if the job is complete?

Scope verification includes activities such as measuring, examining and testing the project deliverables to make sure they conform to the requirements in terms of specifications and quantities.

Formal acceptance of the deliverable by the buyer is the objective.

Scope verification is time consuming and expensive. So it is preferable to do it only the one time for each project deliverable.
This is achieved by making sure the whole project team understands and complies with the agreed acceptance procedure and that all acceptance documentation is signed by the designated person in the buyer's organisation.
The acceptance process is usually included in the contract document and is always included as an agenda item in the project kick off meeting.

It is not necessary to wait until the end of the project before scope verification activities begin. Scope verification can proceed as soon as a deliverable is complete and can be measured, examined and tested.

Scope verification also takes place if a contract is terminated before completion. In this case the extent of the completed works must be agreed, documented and signed off. This is particularly important if there is possibility of dispute.

Scope Verification: Inputs and Outputs

Inputs

  • Completed Work
  • Product specifications

Tools and techniques

  • Measuring
  • Inspection
  • Testing

Outputs

  • Agreed records of work completed
  • Formal acceptance

Scope Change Control

We now focus on managing and controlling the inevitable changes in project scope.

The need for scope change can come from

  • Customer
  • Project Team Members
  • The environment
  • Product obsolescence
  • Technological advances
  • Funding changes

Small changes can be approved by the Customers representative. However big changes must be approved by a "Change Control Board" comprising members from all interested parties.

Big or small, the management of scope change is best accomplished with a formal documented change control system.

A change control system will include the following:

  • Recognising that a change is needed
  • Reviewing all requested changes
  • Ensuring that any change is beneficial
  • Evaluating the benefits of the requested change
  • Identifying alternatives that would achieve the same result
  • Identifying all impacted tasks
  • Analysing these impacts and how they affect project performance in terms of time, money and scope
  • Approving or rejecting the request
  • Communicating the approved changes to all stakeholders
  • Changing the baselines for performance monitoring
  • Updating the project scope definition
  • Implementing the change
  • Documenting the change

The Scope Management Plan, usually a section within the Project Plan, describes how scope changes are evaluated, processed and integrated into the project.

A change control procedure will be successful if the following steps are taken.

  • The contract or agreement must include a description of how changes to the agreed scope will be processed.
  • Any change in the scope must be recorded in the form of a "Change Order" which describes the change and how it impacts budget, schedule and project deliverables.
  • Change Orders must be approved by the Customer
  • The project master plan must be amended to reflect the change

The following flow chart describes a typical change control process.

change management

 

A potential change in the project scope is identified. This potential change is reviewed. If it is not considered beneficial to the success of the project but will impact the project result if left unattended, an issue is recorded in the Issues Register.

The change is then evaluated. If there is no impact on the project deliverables, budget or the schedule, the change is made and documented.
Otherwise the calculations are made and the Change order Form is completed.

The Change Order Form is reviewed by the customer and / or the Change Control Board. If the change is approved it is implemented and then documented.

If the change is not approved, there must be something that needs to be resolved, so an Issue is raised and resolved through that process.

A sample of a Change Order Register and Change Order form can be downloaded from the templates area. They may need to be adapted to suit individual requirements.

Many project managers adopt an informal approach to handling requests for changes. Unfortunately, misunderstandings often arise, things are forgotten and the project manager is forced to deliver the changed scope without any change to budget or schedule.

Don't let that happen to you!

 

2001 © Jeb Riordan

About the Author

Jeb Riordan PMP, is a working project manager, currently on assignment in Thailand and enjoying every minute...

Share/Save/Bookmark
Comments (0)Add Comment

Write comment

busy

 
Credit Counseling - Credit Card Consolidation - Nevis Hotel - United Specialties
PROJECTmagazine (c) 1998 - 2010 for practical project management information. All rights reserved.