Getting to the Scope Baseline

We are concerned about two major things in defining the scope ofthe project, the project scope and the product scope. The product scope is all of the features and functions that the completion of the project will provide to the stakeholders, whereas the project scope is the work that must be done to deliver the product scope to the stakeholders.

The first thing that happens in a project is usually characterized by the feeling of wild and unbridled enthusiasm. This results in a great many things being included as the needs of the project. In many respects this is a good thing. If the project has many good things that can result, it is probably a good project to do. The problem is that many of these things are not necessary or may be impractical. Many of the items may just not be the things that the stakeholder needs or really wants.

The solution is to have the project team and the stakeholders come together one or more times and separate out the needs that everyone agrees are not going to be practical or necessary for the project to be useful. When we reduce the needs of the project by deleting the ones that everyone agrees are not part of the project, the result is a list of the ''requirements.''

We are not nearly finished at this point. We have only reduced the project by the items that everyone agrees to eliminate. We will need to further reduce these items by the items that may not be good for the project. These items are not so obvious and will not have the agreement of all the stakeholders. There will have to be some investigation and some justification applied to make these items acceptable or not acceptable to the project. When this analysis is completed the result is the project's scope baseline. This is the first baseline that we will develop. We need to have the scope baseline before the remaining two baselines, cost and schedule, can be completed.

When moving from requirements to scope baseline, the items that are eliminated from the project must be documented as exclusions to the project. It is important to do this since, at one time, these items were thought to be good for the project by at least some of the stakeholders. If their exclusion is not properly documented, they will return again and again as new requirements to be considered.

In all of these items that will or will not be included in the project there are a number of factors that must be considered, such as cost, expense, time to develop, service, and maintenance. These items are called the deliverables of the project or the product scope definition.

It is critically important that all of the stakeholders be involved with the parts of the project in which they have a stake. To accomplish this there must be a good cooperative relationship between the stakeholders and the project team. Detailed descriptions of the intentions of the project must be obtained.

All items making it to the scope baseline must be fully documented and clearly defined. There must be measurable tangible results that will be achieved. These should be documented along with the acceptance criteria as part of the scope definition. When this is not done, scope cannot be controlled, and project scope tends to creep ever upward with requests from the stakeholders that start out by saying, ''There is one little change that we need to make to the project'' or ''This item should have been included in the original scope of the project.''

When all of this is completed, we will have developed a set of deliverables that the stakeholders and the project team can agree upon. These deliverables must be formally agreed to by all stakeholders, and there should be a formal sign-off. Everything should be done to impress all of the participants in the project that the deliverables list is a conclusive, exhaustive list of the things that the project is going to produce. There should be no doubt in anyone's mind that the deliverables list that has been agreed to is final unless a formal change is approved and paid for by someone. They must also know that approved changes to the project after this point are going to result in increases in cost. Oftentimes these changes are paid for by the customer or sponsor, but frequently the changes will be absorbed by the company organization doing the project. In any case, if the scope changes the project budget should be adjusted as well.

To make all this possible, each of the project deliverables must be clear and concise. Each deliverable must have tangible, measurable criteria that determine that the deliverable has been completed and accepted by the stakeholder. Every effort must be made to avoid describing deliverables in a way that can be misunderstood. The situation where the project team thinks they have completed a deliverable and the customer disagrees must be avoided. It is also important when defining the scope that the acceptance criteria for each of the deliverables be defined as well. The stakeholders are likely to accept the acceptance criteria early in the project but will be more reluctant to accept the test criteria later in the project. This is because as the project progresses and the stakeholders find additional requirements they will attempt to include them in the test criteria for acceptance.

For example, a project team determines that a user manual for the system they are proposing will be required. The deliverable that they put into the scope of the project is entered as ''User Manual,'' with no additional description. The customer sees this and agrees to the item.

When the user manual is delivered to the customer, it is a five-page document that basically says to hit the green button to start and hit the red button to stop. The project team does not want to give too much information to the customer, because they want their own maintenance and support people to take care of problems that might arise in the life of the product they are delivering.

On the other hand, the customer's expectations were for a fully detailed user manual that would allow them to understand the inner workings of the product delivered—200 or 300 pages of detailed information about the product and its use. Stakeholders want this information because they do not want to be committed to the supplying company forever. They are concerned that they may have to maintain the product after they have terminated their relationship with the supplying company. They are also concerned that the supplying company may go out of business.

When this dilemma becomes known, usually late in the project when there are many things to be done, the project team says that they have met the agreed-upon requirement with their five-page user manual, and the stakeholders disagree. Generally, at this point, the stakeholders appeal to higher levels of management in the project team's company, and eventually the project team will write that 300-page manual.

At this point in the development of the project scope we have determined what all of the project deliverables are, and we have gotten full agreement from all of the stakeholders. All of the deliverables are tangible and measurable items that cannot be easily misunderstood. There has been a formal sign-off on the deliverables that are due to each stakeholder. In addition to the deliverables being developed from a preliminary definition to a detailed baseline for scope, there should be a development of risk in parallel to the scope development. An order of magnitude estimate should be done to determine if the project is feasible.

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment