Project Problem : Poor Scope Management*

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 are delivering and what the boundaries of the project are, you have no chance of 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 is a good thing. First, the client 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 his/her evaluation. The sponsor can determine if 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 with scope change management.

· Scope creep. Many project managers recognize large scope changes, but are not as diligent about 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 they have taken on too much extra work and can no longer meet their budget and deadline 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 they should be accepted. Again, this is a mistake. The end users usually surface scope change requests, but they cannot approve them. Even a client manager cannot approve scope change requests. The only person that can is the sponsor (unless the sponsor has delegated this authority to others). Many projects get in trouble because the team thinks 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 that 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 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 trend over its budget and schedule, try to find the cause. In many cases, you will find that you are 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 manager 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 first hand the impact of not controlling scope because the project is already in trouble. They should be better able to understand the purpose of scope change management and be more willing to follow the more rigorous process in the future.
* TenStep Project Management

Project Problem : Inadequate Project Definition and Planning *

Have you ever attended an end-of-project meeting on a project that had major problems? If you have, chances are that one of the major themes you will hear is that “we should have spent more time planning.” Many project managers think that they need to jump right into the project by gathering business requirements. They think that if they do a good job gathering the business requirements, they are ready to run on the project. That is not true. In fact there is a definition and planning process that needs to happen before you ever start gathering the business requirements.

Before the project work begins, the project manager must make sure that the work is properly understood and agreed to by the project sponsor and key stakeholders. The project manager works with the sponsor and stakeholders to ensure that there is a common perception of what the project will deliver, when it will be completed, what it will cost, who will do the work, how the work will be done, and what the benefits will be. The larger the project, the more important it is that this information be mapped out formally and explicitly. All projects should start with this type of upfront planning to prevent future problems caused by differing viewpoints on the basic terms of the project.

Common Planning Problems

Poor up-front definition and planning cause problems in many areas later in the project. These problems include:

· Lack of business support. If you do not define the major characteristics of a project up-front, it is very common to have differences in expectations among the major stakeholders. This is true even if you take all of your initial direction from the sponsor. As a project gets larger, even the sponsor may not have a totally complete picture of what needs to happen for the project to be successful. Other times, the sponsor has a vision, but there are other visions that may be better or more viable. These competing ideas end up surfacing later in the project and causing confusion and rework.

· Poor estimates. Usually a project needs to have a budget and deadline before the business requirements are completed. In many cases, if the definition and planning is not done ahead of time, the project team starts off with inadequate resources and time, and you don’t realize it until the project is already in progress. Many projects that could be successful are viewed as failures because they overshot their budget and deadline. This situation is often caused by the project manager committing to numbers that are too low, the result of a lack of up-front planning.

· Poor scope control. One of the major aspects of defining a project is defining the high-level scope. If you do not define and gain agreement on scope, you will find it very difficult to manage scope effectively throughout the project.

How to Avoid the Mistake

Spending time on a good definition and planning ends up taking much less time and effort than having to correct problems while the project is underway. It should not be surprising, then, that the best way to avoid this problem is to do a good job of defining and planning the project up-front. This includes:

· Defining. Before the actual work of the project begins, make sure you have spent the time to define the project objectives, scope, assumptions, risks, budget, timeline, organization and overall approach. The project manager may think that they know all of this already. However, the purpose of this work is to ensure that there is a consensus between the project manager, project sponsor and all other stakeholders. Even if the project manager and the sponsor are in agreement, there may be other major stakeholders that have other ideas. Differences of opinion need between the major stakeholders needs to be resolved before the project starts – not while you are in the middle.

· Planning. The project manager should create an overall project workplan before the project starts. This will help you estimate the total project effort and duration. The project manager also needs to ensure that he or she has the detailed work mapped out over the next few months to ensure that the project resources are assigned the right work once the project actually begins.

In addition, it is very helpful to have an agreed upon set of project management procedures that are used to manage the project. These will include how the project manager will manage scope, issues, risks, communication, the workplan, etc. Again, the key is to define these all up-front to better manage expectations. For instance, if you define and get agreement on the procedure for approving scope change requests, you should have a much easier time managing change once the project begins.

What if You Are Already Into the Project?

Of course, the best way to solve a problem is to prevent it to begin with. However, what if you do not have that option? Let’s say you are into a project, and you start to see some of the problem areas described above. For instance, you start to see stakeholders coming forward with different ideas for what the project should accomplish, but you are already well down the path to the prior vision.

If you are having trouble with one or two aspects of the definition process, you may be able to resolve it with a mini-definition process. For instance, if you find that you cannot control scope because you did not define it to begin with, you can take the time to formally define and gain agreement on the scope. This involves going back to the sponsor and major stakeholders to gain the consensus and approval that you did not get earlier.

If you start to see differing visions as to what the project should achieve, you may need to actually complete the entire definition process while the project is in progress. This is very difficult and painful, but it can be done. You need to take a step back and define objectives, scope, roles, risks, etc. You might need to actually stop work on the project until this definition process is completed, although in many cases this is not practical.

As painful as it is to define the project while it is in progress, it is still preferable to ignoring the problem. The first option may end up causing rework, resulting in additional cost and a later delivery date. However, ignoring the problem may end up making the entire solution irrelevant or obsolete as soon as it is delivered.

* From TenStep Project Management