|
|
|
|
Each month, Tom Mochal presents a set of project management tips and techniques for handling various aspects of planning and managing a project. Tom has over 23 years of IT experience. He has developed a comprehensive, scalable project management process called TenStep, which can be viewed at www.TenStep.com.
Scope refers to the way that we describe the boundaries of a project. In general, it defines what the project will deliver and what it will not deliver. For larger projects, it can also include the organizations affected (and not affected), the transactions included (and not included), the data types included (and not included), the business processes impacted (and not impacted), etc.
When the project was defined, certain expectations were set as to what the project was going to produce for an agreed upon cost and within an agreed upon timeframe. If the deliverables change during the project (and usually this means that the customer wants additional items), then the estimates for cost, effort and duration may no longer be valid. If the sponsor agrees to include the new work into the project scope, the project manager has the right to expect that the project cost, effort and duration may be modified (usually increased) to reflect this additional work.
Here are some tips and techniques to keep in mind when managing scope on your projects.
It is not always practical to get the sponsor to approve all small scope change requests. It is a better use of time to batch the small changes up into a bundle. Then discuss them as a group with the sponsor. It might also make sense for the project manager to be given discretion to approve small scope change requests, under some threshold of effort hours. However, this assumes that the project is on or ahead of schedule, and that the changes do not make the project exceed the agreed upon cost, effort or duration.
One of the steps in the estimating process is to add contingency hours to reflect the level of uncertainty associated with the estimate. Once the contingency is approved, there will be pressure on the project manager to use the contingency to absorb additional requirements. Resist the temptation and the pressure! The purpose of the estimating contingency is to reflect uncertainty in the estimates. Do not use the estimating contingency to absorb extra work
A typical problem on a project is that the team does not understand who the customer is and who the end users are. In general, the project sponsor is the person who is funding the project. End users are the people who use the solution that the project is building. It doesn't matter how important a change is to an end user - the end users cannot make scope change decisions and they cannot give your team the approval to make a scope change. In proper scope change management, the sponsor (or their designate) must give the approval.
The project manager and project team sometimes think that they are being customer focused by accepting scope change while still trying to deliver the project within the original commitments. However, if the project is delivered late or over budget, it is usually not good enough to point out all the additional work that was included because of this 'customer focus'.
One of the neat things about enforcing the discipline of having the sponsor approve scope change requests is that, unless the change is very important, the sponsor will usually say 'no'. The Sponsor wants the original project fulfilled within the original commitments for cost, effort and duration. Even though it may be hard for the project manager to say 'no', the project sponsor usually doesn't have any problem saying it.
Scope creep is a term used to define a series of small changes that are made to the project without scope change management procedures used. One change seems small, with little project impact. Two changes seem small, with little project impact. Three changes seem small, etc. However, a series of small changes, none of which appear to have much project impact on their own, can accumulate to have a significant impact on the project. Many projects fail because of scope creep, and the project manager needs to be diligent in guarding against it.
Many scope management processes work well at the project manager level, but get compromised by team members. If the project manager is diligent in enforcing the scope change rules, the customer may try to go directly to team members for changes. The bottom line is that everyone needs to be held accountable for the scope management process.
It is possible that scope change requests may be approved by the sponsor, but deferred until a later time. These types of change requests should be captured on a backlog list, or evolution plan. After the project is completed and the solution is moved to production, there may be opportunities for enhancements, or a Phase II project. Again, these changes will be made if they are approved and if funding is made available.
These techniques point out some of the problems associated with scope change management and how to respond. It is critical to enforce scope change management, or your project is likely to have difficulties meeting its original commitments.
