5.2.02TS Scope Definition - Techniques

The following overview further describes how projects are approved, and what things need to be in place before a project begins. 

This supplemental content comes from the TenStep Project Management Process.

Overview (5.0.P2)

Scope is the term used to describe the boundaries of the project. Scope is used to define what the project will deliver and what it will not deliver. For larger projects, it can include the affected organizations, the transactions impacted, the data types included, etc.

If you look at the reasons that projects fail, it is usually the result of two problems. Either the team did not spend enough time defining the work and / or there was a lack of scope management. Even if the project manager did a good job of defining scope, the hard part comes in having to manage the project within that agreed-upon scope.

The purpose of scope change management is to protect the viability of the approved Project Charter and the approved business requirements. In other words, the Project Charter defines the overall scope of the project, and the business requirements define the deliverables in detail. The project team committed to a deadline and budget based on this high-level and detailed scope definition. If the deliverables change during the project (and usually this means that the client wants additional items), 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 current budget and deadline will be modified (usually increased) to reflect this additional work. This new estimated cost, effort and duration now become the approved target.

Sometimes the project manager thinks that scope management means having to tell the client ‘no’. That makes the project manager nervous and uncomfortable.

However, the good news is that managing scope is all about getting the sponsor to make the decisions that will result in changes to project scope.

This is very important. Few clients can see and express every requirement up-front. Therefore, there are usually changes that need to be introduced during the project. These changes may be very necessary for the solution and there may be valid business reasons why they should be included. The project manager and project team must recognize when these changes are requested. Then they must follow a predefined scope change process. This process ultimately brings the appropriate information to the project sponsor and allows the sponsor to decide if the modification should be approved based on the business value and the impact to the project in terms of cost and schedule.

Overview (1.0 P1)

How many times have you heard about or been involved in a project that failed miserably? Or perhaps it just was not as successful as it needed to be. Did you ever spend time looking back to see what caused the project to go wrong? If you did, chances are that you will have said, "You know, we should have spent more time planning."

Most projects have deadlines, and it seems they are getting shorter and shorter. Hitting aggressive deadlines puts pressure on the project manager to start the project as soon as possible. However, before the project work begins, you need to spend time in up-front planning to make sure that the work is properly understood and agreed to. This is not wasted time or 'overhead' time. This is the time the project manager spends ensuring that the project team and the client have common perceptions of what the project is going to deliver, when it will be complete, what it will cost, who will do the work and how the work will be done.

At the end of a difficult project, the benefits of planning might be obvious. But the benefits are known ahead of time as well. At a high-level, these benefits include:

It should make sense that small projects need a shorter planning cycle and larger projects need a longer planning cycle. The effort required to plan the project depends on the amount of information and the level of detail that need to be understood and documented. The duration required to define the work depends on the length of time necessary to discover and document the information, as well as the time required to gain agreement and approval from the client. At times, the project manager can get frustrated because of the difficulty in gaining agreement with the client on scope, schedule and cost. But that is exactly the reason this work is done ahead of time. Think of the problems you will encounter trying to gain agreement with the client on scope, schedule or cost when the work has started and the deliverables are actually being produced.

Project Organization - Roles and Responsibilities (1.2 P5)

For small projects, the organization is pretty simple - maybe just the project manager and the client / sponsor. The person who is managing the project may be the only person actually working on the project as well.

However, for large projects, there may end up being an elaborate and formal organizational structure. You may have team members, an executive sponsor, a project sponsor, a client manager, a project director, a steering committee, vendors, customers, and others involved. You do not want to get overly complex, but the more people that are involved in the project, the more important it is that everyone be clear on what his roles and responsibilities are. For example, the last thing you want is to have someone give you direction as if he were the sponsor when really he may just be a management stakeholder.

One aspect of defining the project is to define the organization structure and the roles and responsibilities of all the major participants. Usually the typical roles and responsibilities can be defined ahead of time for your organization and then reused as appropriate from project to project. Many of the common project roles and responsibilities are outlined in 1.2.2 Roles and Responsibilities.

Establishing the Triple Constraint (1.2 P7)

At the end of the Definition and Planning process (Steps 1 and 2) you should have an agreement with your sponsor on the work that will be completed and the cost (time) and duration that are needed to complete the work. These three items then form a concept called the “triple constraint”. The key aspect of the triple constraint is that if one of the three items change, at least one, if not both, of the other items need to change as well. (The triple constraint is actually written a couple similar ways. The cost item can also be referred to as effort, which makes more sense if the labor costs are all internal and if there are no non-labor costs. Sometimes, the scope item is referred to as quality, which then focuses on delivering a certain quality level for a certain cost and duration. This is a more narrow aspect of the triple constraint, but the general concepts still hold true.)

This concept is easy to visualize if you think of the triple constraint as a triangle, with the sides representing cost, duration and scope of work.

If the scope of work increases, the cost and / or deadline must increase as well. This makes sense. If you have more work to do, it will take more cost (effort) and perhaps a longer duration. (Likewise if you reduce the scope of work, the cost (effort) and / or the duration should decrease as well.)

If you are asked to accelerate the project and complete it earlier than scheduled, it would also be logical to ask for less work. However, if you are asked to deliver the same work with less duration, the third leg of the triple constraint must increase to maintain the balance. This should also make sense. You will need to increase costs (effort), perhaps by working overtime hours or perhaps by bringing in more resources to complete the same amount of work earlier.

Try to Understand your Client's Expressed Needs and their Real Needs (1.2 P9)

The Project Charter describes the project at a high level. The Project Charter specifically describes the needs of the client, as well as the project team’s estimate of the effort, duration and cost to fulfill those needs. The details of the client’s need are then defined in more detail through the gathering of business requirements.

It is important for the project manager and project team to understand that the true needs of the client may or may not be the same as the needs that are expressed to you and that are the foundation of the Project Charter and the business requirements. In many cases, the client does not understand their true needs when the project starts. The true needs can sometimes evolve over the course of the project. Likewise, the client may have a clear vision of their needs, but they may have a hard time expressing the needs to the project team. To a certain extent, this is the purpose of scope change management – to allow the client to change the requirements of the project while it is in-progress.

The project team can do nothing better than to document the expressed needs of the client and use the expressed needs as the basis for the approval of the Project Charter and the Business Requirements. However, it is also true that the project team should do as good a job as possible uncovering the true needs of the client. This involves techniques such as asking good questions, asking targeted follow-up questions, gathering input from all key stakeholders, asking more questions when requirements don’t seem to make sense, etc. Obviously, the project team should do whatever it can to try to uncover the true needs of the client. The closer the true needs of the client are to their expressed needs, the closer you will be to getting the project right the first time. 

Spend More Time Up-Front to Save Time Later (2.2 P8)

Doesn’t it seem that most problems that are encountered on a project tend to surface toward the end in the construction and testing process? In fact, some project managers purposely hurry through planning, analysis and design because they think they will catch any mistakes in the testing process.

Unfortunately, the longer it takes for errors to be caught, the more time-consuming and expensive it is to fix them. When you are building your schedule, try to spend more time preparing and planning work up-front. This should end up saving time and cost in the overall project. For instance, spending more time in early planning will save time in analysis. Spending more time in analysis makes the design work go more smoothly. Spending more time on deliverable reviews will catch errors earlier and save time in testing. Testing thoroughly will save time in implementation and support. Of course, you don't want to over-plan or overanalyze; that doesn't buy you anything. But be diligent in this up-front work. Don't rush through it. Time invested up-front will more than make up for itself over the life of the project.

Create a Short-Term Schedule to Guide the Definition and Planning Processes (2.2.P9)

The process of creating the Project Charter, schedule and budget may take a long time and may be very complicated. Therefore, the work should not be left unorganized, for the same reasons that you are building the schedule for the project to begin with. Immediately after being assigned, the project manager should create a short-term schedule to plan and guide the initial activities. This initial schedule should cover the length of time needed to create the Project Charter and schedule. If this is a two-week process, the project manager should create an interim schedule of at least two weeks - probably three. If the time to create the final Project Charter and schedule is four weeks, this initial schedule should cover at least four, if not five or six weeks. This preliminary schedule covers all of the organizing and up-front planning activities until the formal project schedule is completed to guide the remainder of the project.

This up-front schedule should be defined at an organizational level so that all projects use the same process to define and plan the work.

Overview (5.0.1.P1)

Defining scope is perhaps the most important part of the initial definition and planning process. If you don’t know what you are delivering and what the boundaries of the project are, you have no chance for success. 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 in defining scope:

Overview (1.2.1.P1)

Business goals are high-level statements that provide overall context for what the project is trying to achieve. Objectives are lower-level statements that describe the specific, tangible products and deliverables that the project will deliver. The definition of goals and objectives is more of an art than a science and it can be difficult to define them and align them correctly. However, through practice and the use of some common definitions, you can start to identify and tell the difference between goals and objectives. 

Business Goals (1.2.1.P2)

TenStep does not use the term “project goals”. Goals are at the organization level. Objectives are at the project level.

Goals are high-level statements that provide the overall context for what the project is trying to accomplish. For example an organization goal might be to "increase the overall satisfaction levels for clients calling to the company helpdesk with support needs".

Because the goal is at a high-level, it may take more than one project to achieve. In the above example, for instance, there may be a technology component to increasing client satisfaction. There may also be new procedures, new training classes, reorganization of the helpdesk department and modification of the company rewards system. It may take many projects over a long period of time to achieve the goal.

The goal should reference the business benefit in terms of cost, speed and / or quality. In the prior example, the focus is on quality of service. Even if the project is not directly in support of the business, there should be an indirect tie. For instance, an IT infrastructure project to install new web servers may ultimately allow faster client response, better performance or some other business benefit. If there is no business value to the project, the project should not be started.

If you can measure the achievement of your goal, it is probably written at too low a level and is more of an objective.

If your goal is not achievable through any combination of projects, it is probably written at too high a level. In the above example, you could envision one or more projects that could end up achieving a higher level of client satisfaction. A goal statement that says you are trying to achieve a perfect client experience is not possible with any combination of projects. It may instead be a vision statement, which is a higher-level statement showing direction and aspiration, but which may never actually be achieved.

It is important to understand business goal statements, even though goals are not a part of the Project Charter. Goals are most important from a business perspective. The project manager needs to understand the business goals that the project is trying to contribute to. There are not project goals – only project objectives.

Project Objectives (1.2.1.P3)

Objectives are concrete statements that describe the things the project is trying to achieve. An objective should be written at a lower level, so that it can be evaluated at the conclusion of a project to see whether it was achieved. Goal statements are designed to be vague. A well-worded objective will be Specific, Measurable, Attainable / Achievable, Realistic and Time-bound (SMART). (SMART is a technique for wording the objective. An objective does not absolutely have to be SMART to be valid.)

An example of an objective statement might be to "upgrade the helpdesk telephone system by December 31 to achieve average client wait times of no more than two minutes".

Objectives should refer to the deliverables of the project. In the prior example, the objective refers to the upgrade of the telephone system. If you cannot determine the deliverables that are created to achieve the objective, the objective may be written at too high a level. On the other hand, if an objective describes the characteristics of the deliverables, it is written at too low a level. If the statements describe the features and functions, they are requirements, not objectives.

If the project is a part of a larger program, the objectives of all the underlying projects should be in alignment with the program objectives.

 Importance of Objectives (1.2.1.P4)

Objectives are important because they show a consensus of agreement between the project manager and the project sponsor on the main purpose of the project. The specific deliverables of an IT project, for instance, may or may not make sense to the project sponsor. However, the objectives should be written in a way that they are understandable by all of the project stakeholders.

Define Objectives Before the Project Starts (1.2.1.P5)

The project objectives and the business goals they support should be defined and agreed upon before the project starts. The deliverables of the project are created based on the objectives.

On many projects, however, it is easier to see the deliverable that need to be built rather than the project objectives that are driving the deliverables. It is important to have both objectives and deliverables. If you think you know that deliverables that need to be built, work with your sponsor on why they need to be built. The answers to this question should help you uncover the project objectives. You can then make sure that the objectives all align to business goals. If you think you have to build certain deliverables, but you are not able to tie them to project objectives and business goals, you should seriously question why you are building them.

A facilitated meeting between all major stakeholders is a good way to create the objectives and gain a consensus on them at the same time.

Use High-Level Objectives as Your Starting Point (5.0.1 P2)

When the project was proposed for funding, there should have been an initial set of high-level objectives and deliverables defined. There may even be some type of high-level scope statement. Any information that was created earlier should be used as the starting point for defining the more detailed scope statements for the Project Charter. If you find that you do not have enough information to create a clear and comprehensive scope statement, you must work with the sponsor to gather additional information. That is one of the main purposes of the definition and planning process.

If you have project objectives, look at them to help shape the scope statements. By definition, there needs to be one or more deliverables created to fulfill each objective, and defining the project deliverables is one of the primary aspects of project scope. After you determine the major deliverables the project will produce, start asking other questions to determine other aspects of scope. The deliverables describe ‘what’ the project will deliver. You can also identify ‘what’ organizations are impacted, ‘what’ types of data are needed, ‘what’ major features and functions are needed, etc.

As a point of clarity and contrast, you can also identify out-of-scope conditions by describing what deliverables will not be created, what organizations will not be impacted, what features and functions are not included, etc. Of course, there are an infinite number of out-of-scope statements. For the purposes of scope definition, you want to include only those statements that help define the project boundary and touch upon related areas that the reader may have questions about. For instance, if you were installing financial software, you might state that a new Accounts Payable package is in scope, but the related Purchasing System is out of scope. This would make sense because the Purchasing and Accounts Payable processes are related and there may be questions as to whether the Purchasing System was in scope. However, you would not have to list every other system as out of scope – just the ones that the reader might have questions about.

It is a good practice to document those organizations that are in scope and those related organizations that are out of scope. The readers can then determine more easily if they are impacted or expected to assist in the project. Also, it may make sense to identify the organizations that are in scope so that you can have people from those organizations represented on the project team – perhaps on a steering committee.

Aligning Objectives and Scope (5.0.1 P3)

When you have completed creating your objectives and scope statements, go back and make sure that they are all in alignment. You should not have any objectives that make references to deliverables that are not defined in your scope statements. If you are not building something to satisfy an objective, you will not be able successfully complete the objective.

Likewise, you don’t want to include deliverables in your project scope that do not help to achieve the project objectives. If you are proposing to build deliverables that do not help you achieve your project objectives, you would need to ask yourself why. Since the objectives describe the purpose of the project, why would you want to build deliverables that do not help you achieve your objectives?

If the objectives and the deliverables in your scope section are not aligned, you need to determine how to bring them into alignment.

Overview (2.1.3 P1)

The project approach is a section in the Project Definition that describes in words the thinking that goes into the creation of the project workplan. There are two benefits to creating an approach section. First, this information will help the client and stakeholders understand how the project will progress without having to interpret the actual workplan.

The other benefit of the project approach is that it allows the project manager and project team to lay out a high-level vision for project execution and use this vision to help create the lower-level workplan. Sometimes if the project team finds it hard to build a workplan, creating a high-level approach first can make it easier to create the lower-level workplan second. 

There are a number of ways the section can be prepared. Usually, you start off with general content about how the organization and environment will impact the project. Then you walk chronologically through the project, starting at the beginning and going to the end. Of course, you don't describe the detail at an activity level. You want to stay at the milestone, stage or phase level.

The following information gives you more detail and examples of the areas that can be described. You will notice that much of this information may be available elsewhere, but it is in the approach section that you tie everything together in context for the benefit of the reader.

Stakeholder Analysis - Overview (1.2.5.P1)

Stakeholders are specific people or groups who have a stake or an interest in the outcome of the project. Normally stakeholders are from within the company and could include internal clients, management, employees, administrators, etc. A project may also have external stakeholders, including suppliers, investors, community groups and government organizations.

Other then managing the expectations of the sponsor of the project, the manager of the project manager, the project team and the client, small projects typically do not have to worry too much about understanding and managing the stakeholder community in its entirety.

As your project gets larger and larger however, you generally have more and more stakeholders to worry about. If you have a large and diverse stakeholder community it makes sense to perform a stakeholder analysis. In some cases you might want their help, in some cases you need their buy-in, and in some cases you need to make them aware of accomplishments of your project. This stakeholder analysis will help you determine the various stakeholder groups and what their role is on your project.

Use the following process for stakeholder analysis.

 

Role

Stakeholder Analysis Process

1

Project Manager, Project Team

Identify Stakeholders

You can’t do the stakeholder analysis without first knowing who your stakeholders are. Organize a brainstorming session with your team to identifying all possible stakeholders. These could be individual persons or stakeholder groups. The list below provides an example list of potential stakeholders.

  • Sponsor

  • Client

  • Project Director

  • Executive Management Team

  • Project team

  • End users

  • Suppliers

  • Other internal departments / projects

  • Partner companies

  • Third parties (Suppliers, investors, unions, government organizations)

It is important to recognize the project team as a specific stakeholder group. This will allow the project manager to focus on their needs as well and make sure that their needs are taken into account on an ongoing basis throughout the project.

2

Project Manager, Project Team

Determine the importance of each stakeholder

Look at each stakeholder and determine how important he or she is to the success of your project or what the impact would be on your project if the stakeholder had no connection at all. Categorize each stakeholder in terms of high/medium/low importance.  For example, if your project would proceed fine, then the stakeholder probably has a low importance. If your project cannot be successful without him or her, he or she probably has high importance. This evaluation is important because sometimes you spend too much time and effort working with stakeholders that are of low importance to your project, while short-changing the time you spend on stakeholders that are very important.

Another area you need look at when determining the importance of a stakeholder is that of power. Does the stakeholder have the power to block or hinder the progress of the project? Does the stakeholder have the power or influence to help make the progress of the project run smoother? This information is important to know. For example, you may categorize a stakeholder as low if the project would not be effected if they where not actively engage in the project, but you may want to categorize them as high if they would have a great impact (negative or positive) if they were to get engage in the project.

3

Project Manager, Project Team

Identify the interest level of each stakeholder

To varying degrees each stakeholders has a stake or interest in your project. You now need to identify what these stakes or interests are. In some cases a stakeholder might be expecting to get something specific from the project and will want to be kept informed of its progress and involved wherever possible. In other cases, the stakeholder may have very little interest in the project, other then to be kept informed. Again you can categorize each stakeholder in terms of high/medium/low interest.

4

Project Manager, Project Team

Identify the impact each stakeholder can have on the project

You may now have a long list of people and organizations that will be affected to varying levels by your project. Now determine what their impact and influence are. Some stakeholders can block your project. Others have no formal power but are influencers. This information will help you determine how to communicate Some may be interested in what you are doing and others may not care. You need to categorize each stakeholder into common groups to determine how best to manage each stakeholder.

5

Project Manager, Project Team

1.   Understand the emotional standpoint of each stakeholder

2.   Understanding the emotional standpoint of each stakeholder is very important to your project. You need to understand their current opinion about the project and how they might react to it. Will they be a supporter or non-supporter of the project? You need to find out what or who influences their opinions and utilize this information to formulate your engagement plan.

In most cases you and your team should be able to determine the emotional standpoint of each stakeholder. But for those cases where you cannot, you should arrange a meeting with the specific stakeholder and ask them directly.

6

Project Manager, Project Team

1.   Determine how you will engage each stakeholder

2.   For each stakeholder, you should identify a set of activities or even an overall approach to satisfy their needs. You should identify activities that help you to achieve your interest while also recognizing the relative importance of each stakeholder group. Obviously you will spend more time working with stakeholder groups that are important to your project and less time on groups that are of low priority. The purpose of this step is to define the activities that your project team needs to do to make sure that you address the interest of each stakeholder. You will definitely be communicating with many of these stakeholders, so some of these activities may overlap with your Communication Management Plan. It is okay to mention these in both places. You are still only going to execute each activity one time. You can use the following table to help guide your discussions.

Importance / Interest

Management Style

High Importance and High Interested

These are the most important stakeholders. These individuals and groups must be managed closely and kept fully engaged in the project. You must make the greatest efforts to satisfy their needs.

High Importance but Low Interest

These individuals and groups need to be managed closely to ensure you satisfy their needs, but you will not want to over manage or over communicate.

Low Importance but High Interest

These individuals and groups need to be kept adequately informed. Communicate with them regularly to ensure that no major issues are arising. (Note: Normally, these individuals and groups can be very helpful when you are defining and planning your project)

Low Importance and Low Interest

Monitor these individuals and groups to ensure their status does not change through the life of the project, if it does, you will need to need to reassess the way they are being managed.

7

Project Manager

4.   Gain agreement with the stakeholders when necessary

5.   In some cases, stakeholders want things from your project. However, in other instances you need something from them. If you need something from the stakeholder or stakeholder group, make sure that they understand what your expectations are and make sure that they agree to provide it. For instance, the stakeholder group may need to provide resources, time, money, attention, feedback, etc.

8

Project Manager

6.   Move the activities to the schedule

7.   You don’t want to keep a separate stakeholder activity spreadsheet. After you identify the activities to engage the stakeholder groups, place all of the activities in the project schedule, along with who is responsible, the timeframe, estimated effort, etc.

[ Previous Page - 5.2.01.3TS Scope Definition - Process (Large Projects)]  [ Next Page - 5.3 Create WBS]