Defining and planning a project is only the first step in successfully managing a project. After you plan the work, you have to work the plan. You must make sure that the work you agreed to deliver is completed within the timeframe and budget allocated. Part of the work-the-plan process is preparing for the inevitable fact that, once the project starts, the client will probably end up asking for more (or different) work than what was originally agreed to. This is when you must use scope-change management. If you don’t, you will end up trying to complete more work than what was originally agreed to and budgeted for. In other words, you will be heading down the road to trouble.
What are the leading reasons why projects fail?
All of us have been on projects that were less than successful. I discuss the five most common project management mistakes in this series. Read part one, “Poor planning is project management mistake number one” here.
Scope management starts with scope definition
Defining scope is perhaps the most important part of the upfront process of defining a project. In fact, if you don’t know for sure what you’re delivering and what the boundaries of the project are, you have no chance for success. Managing scope is one of the most critical aspects of managing a project. However, if you have not done a good job of defining scope, managing scope will be almost impossible.
The purpose of defining scope is to clearly describe and gain agreement on the logical boundaries of your project. Scope statements are used to define what is within the boundaries of the project and what is outside those boundaries. The more aspects of scope you can identify, the better off your project will be. The following types of information can be helpful.
- The types of deliverables that are in scope and out of scope (business requirements, current state assessment)
- The major life-cycle processes that are in scope and out of scope (analysis, design, testing)
- The types of data that are in scope and out of scope (financial, sales, employee)
- The data sources (or databases) that are in scope and out of scope (billing, general ledger, payroll)
- The organizations that are in scope and out of scope (human resources, manufacturing, vendors)
- The major functionality that is in scope and out of scope (decision support, data entry, management reporting)
Have a viable scope-change process in place
The project manager and project team must realize that there is nothing wrong with scope change. That is, changing scope while a project is underway is not an evil proposition. In fact, in many cases, it’s a good thing. First, clients typically cannot identify every requirement and feature that will be required for the final solution. Second, even if they did, the business changes over time, and therefore the requirements of the project may change as well.
If you cannot accommodate change, the final solution may be less valuable than it should be, or it may, in fact, be unusable. Therefore, you want the client to have the ability to make changes during the project when needed. The problem comes when the project manager does not proactively manage change on the project. Every project should have a process in place to manage change effectively. The process should include identifying the change, determining the business value of the change, determining the impact on the project, and then taking the resulting information to the project sponsor for its evaluation. The sponsor can determine whether the change should be included. If it is included, then the sponsor should also understand the impact on the project and allocate the additional budget and time needed to include the change.
Common problems with scope-change management
There are a number of common problems that project teams encounter when dealing with scope-change management.
Scope creep: Many project managers recognize large scope changes but are not as diligent on smaller changes. There is a tendency to just go ahead and add the additional work without too much thought. Scope creep refers to what happens when a project accepts a large number of small changes. When all of these small changes are combined, the team realizes that it has taken on too much extra work and can no longer make its budget and must delay commitments.
No sponsor approval: Many times, a project manager will receive requests for changes from end users, stakeholders, or client managers. Since these are all people in the client organization, there is a tendency to think that these requests should be accepted. This is a mistake. The end users usually surface scope-change requests, but they can’t approve them. Even a client manager can’t approve scope-change requests. The only person who can is the sponsor (unless the sponsor has delegated this authority to others). Many projects get in trouble because they think they are getting approval to proceed with scope changes but discover later that the person who really counts, the sponsor, has not agreed.
Project team accountability: Since the project team members can have a lot of interaction with the client, they are the ones who field scope-change requests the most often. Therefore, the entire project team must understand the importance of scope-change management. All of them must detect scope changes when they occur and funnel them back to the project manager. If they take on the extra work themselves, there is a good likelihood that their activities will be completed late and jeopardize the entire project.
It’s never too late to start
If you find that your project is starting to go over its budget and beyond its schedule, try to find the cause. In many cases, you’ll find that you’re simply taking on more work than you originally agreed to. The best time to define a scope-change management process is before the project begins (as a part of the project management procedures). However, if you do not have a good process in place, it is never too late to start. The project management must call a quick time-out and work with the client on a process for detecting and approving scope-change requests. Then everyone must be educated in the new process.
If there is a good side of this effort, it is that the team and the client can see firsthand the impact of not controlling scope, since the project is already in trouble. They should then be better able to understand the purpose of scope-change management and more willing to follow the more rigorous process in the future.