Elements of a Scope Document

In a previous post entitled the Triangle of Truth; I talked about how many of the firms I coach ask me to assist with scope creep problems. In most cases it turns out not to be scope creep at all, but rather the lack of a decent scope document.I hereby submit the following as the required elements (consultants call them inclusions) of a scope document.

• Scope statement
• Objectives
• Constraints
• Project structure
• Roles definition
• Project team definition
• Assumptions
• Deliverables
• Scope details or functional requirements
• Project change control
• Future projects list
• Approval

I will now briefly examine each of these elements.Scope statement. The scope statement defines in one sentence what the project will accomplish. It should support either the mission statement of the customer or be tied to at least one strategic objective of the company. An example scope statement would read: To (infinitive) (something) on or before (date) and at a price of (dollar amount). Notice how this statement addresses each of the three angles of the Triangle of Truth. While this statement appears first in the document, it will usually be written last.Objectives. Objectives answer the specific question "What does success look like?" They are high-level statements that explain exactly what the desired results of this project are. Since they are general actions, they should begin with verbs. For example: train ... , create ... , develop ... , followed by specific, measurable, attainable, relevant, and time-sensitive (SMART) items to be accomplished. A general rule of thumb is that a project should not have more than eight objectives. If you have more than eight, you probably have more than one project.Constraints. Constraints are limitations to the successful completion of the project due to affecting the scheduling of activities. They are things that could prevent work from getting accomplished. Common constraints are found in the following areas: technical, financial, operational, geographic, time, resource, legal, political, and ethical. Note that while similar categories exist for risk, constraints are not risks. Constraints are known facts; risks are uncertain events. A constraint may evolve into or cause a risk, but at least early on in the project they are different. An example constraint might be the lack of availability of data from current systems.Project structure. Each project must have an overall organization. In short, your project structure is the organization chart for the project. Usually, this organization is in some conflict with the normal regular structure of the company and, therefore, creates a temporary matrix-type organization. While there are some advantages to matrix organizations, the main weakness is lack of authority of the project manager since the functional manager has more say in the work performed by the individual.Roles definition. Once you have outlined the project structure, it is important to define each role within the project. For each role you must define the specific responsibilities. These can and will change from project to project. Some roles requiring definition are:

• Steering committee member or executive sponsor
• Project manager
• Project owner
• Team leader
• Team member
• Project advisor

Team definition. This is simply the list of people who are functioning in what role on the project. Once you have the structure and role defined you need to assign people to the roles. In large projects this is part of resource planning.Assumptions. Assumptions are beliefs about the relationship that serve as the starting point for project definition. Be sure to evaluate each assumption in terms of it being true, real, and certain. Another way of looking at them is that they answer the question "what should we not leave unsaid?" Do not have too many assumptions. If you do you probably need to refine your scope — having more than ten assumptions looks careless. One example of an assumption relates back to the Triangle — In order for success to be attained the relationship between scope, costs and time must be maintained. A change to any one of these three interrelated variables will affect the other two. For example, adding to the scope of the project will require an adjustment to either the cost of the project or the commencement date.Deliverables. Deliverables are the tangible results — the products or services of the project. If objectives are verbs, as we stated earlier, deliverables are the nouns. They are usually things you can physically touch. There are two types of deliverables: intermediary, meaning they are to be used in subsequent tasks on the project and final deliverables, meaning they are turned over to the customer at the end of the project. Examples of deliverables include: the project plan, a training schedule, and training manuals.Scope details or functional requirements. These will change depending on the project, but this is a critical section which expounds on the scope statement's infinitive. Think of this section as the detailed definition of that infinitive.Project change control. I will consider project change requests in a future post. Suffice it to say that this section is like Article V of the United States' Constitution which describes how amendments are to be made. This section simply says that the scope document can be changed (amended) and defines the process for doing so.Future project list. In addition to the obvious of being a list of possible future projects and major tasks that will be deferred until after this one is complete, the future projects list is important in that it defines what is not included in this project. It is important to list these additional projects as they are identified during the planning process, since they are the future business of a professional knowledge firm.Approval. The scope should be signed and dated by the project manager and the project sponsor.If you do not have each of these elements, it is my belief that you do not have scope. If you do not have scope, you cannot have scope creep.