Course Transcript

You've been invited to a state dinner. It's a black-tie event and you want to look your best. You decide to phone a tailor and ask for a custom-made outfit. You explain the outfit is for a very important dinner party and give your measurements. The tailor says "No problem, I'll have it ready for you by 3:00 PM the day before the event." The tailor didn't even ask what type of dinner it was or ask what color the outfit should be! How confident would you feel you will have a finished product that matches your expectations?

Now consider a similar example in a project. You've successfully guided a team through all the activities to create a technically advanced car model that uses an extremely efficient hydrogen-based fuel system. You and the team overcame challenges to do this in a short space of time, and within the project's budget.

That is impressive. But what if the company you built the car for was looking to fill a new niche in supplying affordable, fuel-efficient cars to middle-income earners?

The car you've designed will cost a fortune to manufacture on a large scale. At least for the coming years, it will appeal to a small set of high-income earners at best.

To put it in obvious terms, you might pull off a project to build a space shuttle. But if the customer was expecting a small corporate jet instead, it doesn't really matter how much you achieved – the project will have failed.

In this course, you'll learn about Project Scope Management – why it's important, what it involves, and how it relates to processes for managing a project. You'll also learn the importance of planning scope management activities so everything stays on track.

This course covers three important processes for managing scope: Plan Scope Management, Collect Requirements, and Define Scope.

Throughout this course, you'll learn about the activities you perform to plan overall scope management for a project. You'll also learn about ways to stimulate collaboration between stakeholders. For example, you'll learn how to use the Collect Requirements process to gather and refine stakeholders' requirements for a project. This isn't as simple as asking stakeholders what they want. Instead you'll learn how to use creative techniques to unearth and refine their requirements. You'll also learn how to lead stakeholders with different interests towards reaching consensus.

You'll also learn what goes into the Define Scope process and what its purpose is. This process is critical because it makes it clear exactly what stakeholders and the team agree a project must deliver.

As a result, it also feeds into other activities throughout a project's life cycle.

Back to top

1. What is project scope?

Imagine you map out a road trip. You include the route you'll travel, the guest houses you'll stay in along the way, and the money you'll need. You've defined the scope of your trip. If you add side trips to your route or choose to stay at four star hotels while you're traveling, it will exceed the scope of your plan thereby increasing the time and money spent.

Like a road trip, a project has a scope. This defines everything you need to do to get from objectives to the results. If you change the project's scope, it's likely to have implications for the project's cost, time, and quality.

Project scope is all the work required to complete a project's deliverables.

By making it clear exactly what is required, you also make it clear what's not required.

So project scope is like a boundary around a project, with everything required to complete it on the inside, and everything else outside.

If you don't draw a boundary clearly, too little may be put into a project and it will fail to meet requirements. Putting in too much could lead to schedules not being met and costs getting too high.

Consider the following project. The planned scope for this project is to construct a computer assembly factory using one major vendor to avoid quality issues.

Everything's running smoothly, but then one of the construction supervisors suggests using a subcontractor to help out with some electrical work. This suggestion diverges from the original project plan, and will create a ripple effect of changes and updates in several other areas, including the budget and stakeholders.

So the project manager explains the budget and stakeholder constraints of the project. To keep project scope in control, he rejects the idea.

Like a project that is undertaken to build a product, the product itself has a scope.

It's defined by all of the components, functions, and features the product must have to meet requirements, but not to exceed these.

Project scope is the work required to deliver the product, so project scope is based on product scope.

Say a project must create a handheld electronic device. The device should include wireless Internet connectivity and features like e-mail, high definition audio and video, and GPS.

If a stakeholder puts in a request to add voice control features to the device, the product will exceed its original scope.

Scope changes always have cost, time, and quality implications.

2. The causes of scope creep

Scope creep is what happens when the scope of a project changes, without the change being managed. Often these changes can seem minor. Over time, unmanaged changes add up and can have a major impact on project costs, schedules, and quality.

The main causes of scope creep are unexpected scope-related issues, perfectionism, placating stakeholders, and misunderstandings. By learning to recognize these causes, you can mitigate the risks they pose to a project.

Select each cause to learn more about it.

Unexpected scope-related issues

Unexpected scope-related issues often arise during a project and these can change the project's requirements, or raise its complexity. For example, a recent change in a safety regulation causes the project manager of a construction project to also consider additional training. This will push the project's scope beyond what was planned and may impact the schedule and budget.

Perfectionism

Usually, everyone with an interest in a project wants it to produce the best possible result. So it's natural to want to go beyond what's required – for example, by adding extra features to a product. But this kind of perfectionism can change the scope of a project, and end up costing too much time and money.

Placating stakeholders

Stakeholders may make requests that are beyond the original scope of a project. If you just try to avoid conflict by doing what they ask, it can change a project's scope. This may lead to delays and over-spending. Instead, you should discuss each request and consider how it will impact scope before going ahead.

Misunderstandings

Misunderstandings can change a project's scope if they affect what work is done, how long this takes, or how people on the project team understand requirements. So when you define scope, you need to be especially careful to avoid ambiguity or unclear statements. These can lead to conflict and costly delays or changes later.

A project manager of a large software integration project lacks experience with complex projects. Before long, the project starts to run into trouble.

The developers find that the integration is far more complex than was planned for. More functionality needs to be developed in order to have a seamless integration.

The project manager becomes aware that the project's gone out of scope only after the developers have already fallen behind. Expert judgment prior to integration could have prevented this.

One of the developers feels that the software should contain several features if it is to be really good. She adds extra features beyond what the client required. But because it's still early in the project, the manager encourages this innovation.

The problem is, he hasn't watched the schedule closely enough. The developer puts too much into the early stages of the project and starts to run out of time. Some of her work needs to be reassigned to other developers, causing them to rush their own work.

Towards the end of the project, the client asks the project manager to add a small, apparently simple feature. They both assume it'll be easy to add so the project manager agrees to do it.

The request creates technical problems for the developers, and the project runs over schedule. The project manager is blamed for granting the request without thinking of the implications.

At the handover of the finished product, the client learns that although the new software complies with local industry standards, it doesn't comply with the international standards he expected it would. The scope statement identified standards, but not which ones.

Because of this avoidable misunderstanding, the project manager now has to send the entire project back to design, at his company's expense.

The project manager's experience with the software integration project has taught him how essential it is to consider scope creep. He's learned to recognize the main causes of it – unexpected scope-related issues, perfectionism, placating stakeholders, and misunderstandings – and takes them into account when planning for his next project so that he avoids scope creep.

3. Summary

Project scope is all the work required to complete the deliverables a project is intended to produce. If either more or less work is put in, it's likely a project will suffer. Product scope identifies the required features and function of a product, and may be one aspect of project scope.

Scope creep occurs when changes to scope aren't detected early enough or managed. Causes of scope creep in a project include unexpected scope-related issues, perfectionism, placating stakeholders, and misunderstandings.

Back to top

1. Scope management processes

Scope creep happens easily, without anyone realizing it. The unmanaged, unnoticed changes it causes can disrupt a project terribly. So how can you make sure a project includes only what it's supposed to, from start to finish?

The Project Scope Management Knowledge Area includes all the processes, that define and control what is and isn't involved in a project, throughout its life cycle.

The methods that will be used in controlling scope throughout the project are described in the scope management plan. This plan is developed during the Plan Scope Management process and provides guidance on how project scope will be defined, documented, validated, and controlled.

Project Scope Management consists of six processes. The ones used early on in a project are Plan Scope Management, Collect Requirements, Define Scope, and Create WBS. Processes used later in a project are Validate Scope and Control Scope.

Select each scope management process to learn more about it.

Plan Scope Management

Plan Scope Management is the first process you perform in Project Scope Management. This process includes documenting the plan for how project scope should be defined, validated, and controlled during the project.

Collect Requirements

Collect Requirements is the second Project Scope Management process. This entails investigating, defining, and documenting stakeholders' needs and expectations about the project, and about a product's features and functions.

Define Scope

Define Scope involves creating the project scope statement, which is a detailed description of the project work required and the product or service it must deliver. This document is used throughout the remainder of the project. It elaborates on the deliverables, assumptions, and constraints for a project.

Create WBS

The fourth Project Scope Management process is Create WBS. This document subdivides each step into smaller, manageable work packages. The execution stage of the project relies heavily on this document.

Validate Scope

Validate Scope is the final Project Scope Management process. It's the process of formally accepting the completed deliverables and confirming that the project has met its objectives, as defined in the scope statement.

Control Scope

The Control Scope process involves monitoring the status of the project and product scope, and managing scope changes. It is integral to controlling change in all parts of the project, including the other Knowledge Areas.

Scope management processes fall into two of the project management Process Groups – Planning, and Monitoring and Controlling. Plan Scope Management, Collect Requirements, Define Scope, and Create WBS take place in the Planning Process Group. The Validate Scope and Control Scope processes interact with the Monitoring and Controlling Process Group.

Each Scope Management process that falls in the Planning Process Group has an output that guides project activities.

Select each process to find out about its outputs and why these are important.

Plan Scope Management

The Plan Scope Management process produces the scope management plan and the requirements management plan. These two plans detail how to carry out all the other activities when managing project scope.

Collect Requirements

The Collect Requirements process results in requirements documentation and the requirements traceability matrix. You use requirements documentation in the Define Scope process to produce the project scope statement, as well as during the Create WBS, Validate Scope, and Control Scope processes. The requirements traceability matrix is used to validate and control scope.

Define Scope

The Define Scope process produces the project scope statement, which details the work required to complete the project. This provides the starting point for the work breakdown structure. It also forms part of the scope baseline, which is used in the Validate Scope process. The Define Scope process also results in project documents updates, such as updates to the requirements documentation and the requirements traceability matrix.

Create WBS

The Create WBS process results in the scope baseline. The scope baseline encompasses the project scope statement, the work breakdown structure (WBS), and the WBS dictionary. The scope baseline and its components provide the benchmark information that all work is measured against during the Validate and Control Scope processes. The Create WBS process also results in updates to requirements documentation.

As part of the Monitoring and Controlling Process Group, the Validate Scope and Control Scope processes have implications throughout the project. In particular they impact the Knowledge Areas dealing with time, cost, and quality. By validating and managing scope, you ensure that the project's requirements are met, on time and within budget.

A residential construction project has just come to an end. It was a success but it didn't all go smoothly.

Early in the planning phase, the architect selected the luxury finishes, even down to the light fixtures for the bathroom vanity unit and ceiling. This was all noted in the requirements documents and project scope statement.

During a walkthrough, the project manager noticed that while the ceiling lights were installed, the vanity lights had been left out entirely. She needed to find a solution right away.

The project manager called in the builder, and he agreed his team would work after hours to install the vanity lights, to avoid making the project run over schedule.

The Validate Scope process enabled the project manager to detect a serious scope error and correct it in time. She succeeded in realigning project performance with scope requirements.

2. Summary

The Project Scope Management Knowledge Area includes all the processes for defining and controlling the scope of a project. The Planning Process Group contains Plan Scope Management, Collect Requirements, Define Scope, and Create WBS. The Monitoring and Controlling Process Group contains the processes required later in a project, namely Validate Scope and Control Scope.

Back to top

1. Gathering the inputs

You are ready to start planning a new project. Where do you begin? With the schedule? The budget? No, the first step is to establish the scope of your project – what features the product or service will have, and exactly how you will meet the customer's expectations.

The Plan Scope Management process will guide you in establishing exactly what work your team needs to carry out in order for the project to be successful.

The purpose of this process is to create a scope management plan that documents how the project scope will be defined, validated, and controlled.

The scope management plan is a component of the overall project management plan, and provides guidance and direction on how scope will be managed throughout the project.

In order to begin planning the scope of your project, you must gather the information you will require. The inputs to the Plan Scope Management process are the project management plan, the project charter, enterprise environmental factors, and organizational process assets.

Select each input for more information.

Project management plan

The project management plan is a critical input to any of the planning processes. Early in the planning phase it contains a rough estimate of the budget allocated for the project and a general timeframe. These parameters contribute to determining the scope of the project. It also contains a description of the processes that will be used to create the product.

Project charter

Planning scope management begins with an analysis of the information found in the project charter. It provides the rationale for the project and how it will meet the customer's business need. It also contains the project's objectives, and a general description of the anticipated product and its features. Considering business need and desired features are the first step in determining what the product will look like and plotting the scope of the project.

Enterprise environmental factors

The enterprise environmental factors that influence scope management planning include infrastructure that may impact how the work is carried out or what work can be carried out, as well as marketplace conditions. For example, the availability of raw materials could determine whether certain product features are included in the scope.

Organizational process assets

In planning scope management, the project manager will need to comply with the organization's policies and procedures, which will always influence how work is planned and carried out. Any historical information and lessons learned from previous similar projects will also be useful in determining scope.

2. Creating the outputs

Once you have gathered the inputs, it is time to prepare the planning documents. The tools and techniques for the Plan Scope Management process are expert judgment and meetings.

Use expert judgment to determine how scope was managed on similar projects and to capitalize on the expertise of others.

Based on the information about your current project found in the project charter and project management plan, you'll examine records from similar past projects.

You may also want to hold planning meetings to draw on the expert judgment of others. Meeting attendees may include the project sponsor and other stakeholders who have insight into what the project's scope will be and how best to manage it.

The goal of the Plan Scope Management process is to produce two key documents: the scope management plan and the requirements management plan.

The scope management plan may be broadly based or detailed, depending on the needs of the project. At the very least it should describe

• how the scope statement will be prepared
• the process for creating, approving, and maintaining the WBS
• how the acceptance of deliverables will be obtained, and
• how scope change requests will be handled

The second key output is the requirements management plan, a component of the project management plan. It describes how the project requirements will be analyzed, documented, and managed.

Project requirements are the specifications the product or service must meet in order to satisfy stakeholders' needs and expectations.

How requirements are managed depends largely on the phase-to-phase relationship chosen for the project.

For example, in a sequential phase relationship, the plan may indicate that all requirements will be completed within their associated phases.

In a project where phases overlap, requirements may be carried over from phase to phase and managed throughout the life cycle of the entire project. Some projects may be a combination of both situations.

Consider this example that illustrates how a project can have a structure that is a combination of the two types of phase-to-phase relationships.

Rita is managing a project to create a new employee orientation program. Most phases in the project are sequential, and most of the requirements will be completed in their respective phases.

For example, the training plan will be completed in Phase 1, and the presentations and student guides will be completed in Phase 2. There is one requirement that will span the duration of two phases: a report containing trainee feedback and program evaluation. Feedback for this report will be gathered from trainees during Phases 2 and 3.

In addition to describing how requirements will be managed across project phases, the requirements management plan includes

• activities related to creation of the requirements and how they will be planned and tracked
• the configuration management process that will control and report changes to the product
• the process for prioritizing requirements, and
• metrics for evaluating requirements

Select the components of scope management and requirements management plans for examples of each.

Scope statement

The scope statement may be written by one person, then submitted to a group for approval, or it may be written collaboratively during the first team planning meeting. The customer may or may not be involved in its creation, but will typically be the one to give final approval.

WBS

A WBS is usually created and maintained by the project manager using project management software. In some cases this task may be delegated to a team member. The WBS is typically approved by the project sponsor, and sometimes the customer.

Acceptance of deliverables

Deliverables and requirements are typically reviewed by the customer or project sponsor who then either requests changes, or approves the deliverable. Approval may be formal in nature – for example via signoff form – or it maybe given informally, such as by e-mail or phone call.

Change requests

Requests to change the project's scope will most typically be managed using the company's change control process. This may involve the project manager completing a change request form, and then submitting it to a change control board for review and approval.

Requirements activities

Requirements activities could be planned using team meetings or by the project manager alone. Activities may be tracked and reported using project management software, or other types of spreadsheets and reporting tools, such as charts distributed by e-mail to stakeholders.

Configuration management

Methods for managing configurations of electronic products and requirements include using storage software that automates version control, using filenaming conventions to maintain version control, and online collaboration sites that force users to check out versions of files that they are making changes to. Versions of physical components can be maintained using physical tools, such as log books.

Prioritizing requirements

There are a few standard techniques for prioritizing requirements. The most common method is to have stakeholders and team members vote on requirements and defend their rationale in a group discussion. The final prioritized list is developed after the group reaches consensus.

Metrics

Examples of product metrics would be any type of measurements, such as size, caliber, strength, capacity, duration, survey results, and error rates.

3. Summary

Plan Scope Management is the first process in the Project Scope Management Knowledge Area. The inputs to this process include the project management plan, the project charter, and various enterprise environmental factors and organizational process assets.

The tools and techniques used for the Plan Scope Management process are expert judgment and meetings. Both are used to create the outputs: the scope management plan and the requirements management plan.

Back to top

1. Collecting project requirements

Proper planning is essential for the success of any project. Before you can plan everything involved in building a house, you need to know exactly what the house must be like. For example, should it have more than one floor? What rooms are needed and how big should they be? How should the house look, and what features must it have? In the same way, you can't plan the work needed for any project until you know exactly what it must deliver.

The Collect Requirements process is what you use to gather the requirements a project must meet. The PMBOK® Guide, describes it as determining, documenting, and managing stakeholder needs and requirements to meet project objectives. The key benefit of this process is that it provides the basis for defining and managing the project scope – including product scope.

Requirements are functions or features a product must have, as well as needs that stakeholders want to have met in a project's final result.

So requirements depend on the attributes of a product and on the client's needs.

For example, a requirement for building a new house may be that windows must be double-glazed to meet local building regulations. Another requirement may be that the house include an open-plan living area, because this is what the client has requested.

Getting to a final set of project requirements isn't as simple as just asking stakeholders what they need. Often stakeholders start with very general ideas of what they want.

You have to narrow these ideas down into specifics to make sure you understand what's really required.

This is also important so you don't end up with a long list of requirements that aren't really essential or product specifications that are too detailed. If this happens, a project's scope is likely to get ahead of what stakeholders have in mind.

Think about the example of building a house for a young couple. If you don't know exactly what the house must have, you can't break down the work needed, plan what this will cost, or plan how long the work will take. You also won't have a control for measuring the progress of the work. Ultimately, you can't hope to satisfy the couple's expectations.

It's vital to define and document requirements in as much detail as possible for the following reasons:

• they represent the customer's and other stakeholders' expectations
• they form the basis for a project's work breakdown structure – otherwise known as the WBS – and for all cost, time, and quality planning, and finally
• they are needed for control purposes, so you can make decisions for a project quickly and efficiently

It can be a lengthy process to get to a final set of project requirements. By the time you start work on this, however, other processes have already created some starting points you can use as inputs.

The inputs for the Collect Requirements process are the project charter, the stakeholder register, the scope management plan, the requirements management plan, and the stakeholder management plan.

Select each document to find out why it's an important starting point for collecting requirements.

Project charter

The project charter identifies high-level requirements. It also provides a high-level description of the product or service a project must deliver.

As an example, a project charter might state that a project must deliver the design for a small, affordable, and fuel-efficient family car. It might specify how this fits in with the company's aim of expanding into new markets. But it won't tell you the exact design that will best meet the needs of the company or its customers.

Stakeholder register

The stakeholder register lists stakeholders for the project. The project's results must meet their needs. So you need to consult stakeholders for detailed information about a project's requirements.

Scope management plan

The scope management plan provides direction on how project teams should determine which types of requirements need to be collected.

Requirements management plan

The requirements management plan outlines processes that will be used to define and document stakeholder needs.

Stakeholder management plan

The stakeholder management plan details stakeholder communications requirements and the level of stakeholder engagement necessary. Information in the plan is used in the Collect Requirements process as a guide to determine which stakeholders to involve in requirements activities and how best to do so.

2. Tools and techniques

Once you've analyzed information in the project charter and stakeholder register, and reviewed the plans outlined for scope, requirements, and stakeholder management, you need to collect detailed project requirements from stakeholders. You can use several tools and techniques to do this.

One technique you can use to collect project requirements is to conduct interviews with stakeholders, subject matter experts, and people who've worked on related projects.

These people can help you identify what features and functions a product or service should have.

Most often, you hold one-on-one interviews. You ask the person you interview a set of questions you've prepared and any other questions that come up. And you record the person's responses.

Focus groups are a less formal way of collecting project requirements.

In a group of stakeholders and subject matter experts, you guide an interactive discussion about what a proposed product or service must deliver. This can help you find out what expectations the stakeholders have.

Usually, a focus group includes stakeholders with a similar role or perspective. You use the group to collect requirements focused on a specific aspect of a project, like the design of a product or the technical requirements it must meet.

In a facilitated workshop, you bring together cross-functional stakeholders. These are stakeholders who have different perspectives on what a project should deliver. For example, managers are likely to have different needs than the people who'll use an end product, or who'll manufacture it. The job of the person who leads the workshop is to help the group identify requirements and reach consensus.

Questionnaires and surveys let you gather responses to a set of written questions. Using these tools, you can get information from a large number of people quickly. And information gathered in this way can usually be evaluated using statistical analysis.

You could use an online questionnaire, for instance, to find out which features customers across the country value most in a new car. But it probably wouldn't be a good idea to use a questionnaire to find out what requirements executive managers in your company have for a new car model.

Melanie is managing a project to create a new model of dishwasher. The project charter specifies that the dishwasher must use significantly less energy and water than the company's existing models.

This fits in with the company's aim of positioning its products as environmentally friendly.

At the moment, the project team is working on identifying detailed requirements for the project.

Select each tool or technique for an example of how Melanie's team uses it.

Interviews

The project manager holds one-on-one interviews with several stakeholders in the company. For example, she interviews an engineer and the managers in charge of design and manufacturing. The questions she prepares are specific to the interviews. The responses give a lot of information about features the dishwasher must have in order to meet efficiency expectations.

Focus group

The project team uses a focus group to collect requirements from a group of sales and marketing staff. These people know some of the features a dishwasher must have for it to be marketed successfully.

Facilitated workshop

A facilitator holds a workshop with staff from the separate departments that will be involved in designing, manufacturing, marketing, and selling the dishwasher. The workshop helps identify several new requirements. For example, marketing staff have research showing high demand for a very compact dishwasher with a streamlined design.

The workshop also helps stakeholders with different points of view reach consensus. Stakeholders focused on the look and size of the dishwasher learn where their needs must give way to technological requirements.

Questionnaire

For this project, customers who eventually buy and use the new dishwasher are stakeholders. The project team decides to send a questionnaire to all customers on the company's mailing list. The team can then apply statistics to the responses it gets to identify the features customers rank as most important.

Group creativity techniques are activities you use to help create a list of potential requirements for a project. They're a useful way to get groups of stakeholders with different perspectives to come up with and share ideas. Here are some examples of these techniques:

• mind mapping, where different stakeholders' ideas are mapped to show their similarities and differences, and to inspire new ideas
  Description of structure of a basic mind map:
  
  A basic mind map includes the problem to solve – or the question to answer – in the center. From there, branches lead out to group general types of ideas. Sub-branches lead to one or more points refined from more general ones.
  
  Description ends.
• brainstorming, where a group generates an unstructured list of possible requirements for a project or product
• the nominal group technique, where the group ranks possible requirements in terms of their importance
• multicriteria decision analysis, which uses a decision matrix to evaluate ideas based on certain criteria, such as risk levels and uncertainty
• affinity diagrams, where ideas are sorted into groups for review and analysis

Once groups of stakeholders have generated possible requirements, final decisions have to be made about which ones are in scope. This involves classifying and prioritizing necessary requirements, and rejecting ones that are determined to be out of scope. To do this, you can use group decision-making techniques.

Observation is a unique way of identifying requirements. Watching how a task or process is performed can make you aware of requirements you wouldn't have thought of otherwise. Examples of observation techniques are job shadowing and participant observation.

Select each observation technique for details of what it involves.

Job shadowing

Job shadowing is watching a person or group of people as they perform their job. This is especially useful for complicated processes or when the people who'll use a product or service find it difficult to clearly express their requirements.

For example, you might watch an accounting clerk process accounts. This could help you collect requirements for a new accounting system. You'd be able to record the exact steps required, and might see how the job of the clerk could be made easier.

Participant observation

Being a participant observer means trying out a task or process yourself. For instance, you might go through all the steps needed to process an account. After each step, you'd record the actions you took. This could help make requirements for a new accounting system clear.

A prototype is a working model of a product. You can create a prototype early in a project and let stakeholders use it to see how well it meets their needs.

This is a much more concrete way to collect requirements than simply asking stakeholders what they need.

Prototypes are the most useful if a project must deliver something people will use to complete tasks.

To help collect project requirements for a new accounting system, a project team builds a prototype of the system.

The project manager asks a focus group of accounting managers and end users to try using the prototype to perform accounting tasks.

Using an online spreadsheet, all group members give immediate feedback about the system as they use it. The manager then meets with the group to get more general feedback.

Based on what he learns, the team refines the prototype and lets the focus group test it again.

Once it's clear the prototype meets all requirements, work on building the final accounting system can start.

There are other techniques that do not require contact with users or decisions to be made in a group setting.

• Benchmarking – involves studying how other organizations create similar products and identifying best practices and new innovations
• Creating a context diagram – a model that shows the inputs and outputs of a system and all the people surrounding its use
• Document analysis – studying documents such as business plans, marketing material, and issue logs to identify requirements

3. Summary

Project requirements are the basis for defining a project's scope and for planning and controlling project work, costs, time, and quality. They will depend on the required attributes of a product and the needs of the client. High-level project requirements are outlined in the project charter. Using the stakeholder register, you need to consult stakeholders to collect more detailed requirements. This is the purpose of the Collect Requirements process.

Tools and techniques you can use to collect project requirements include interviews, focus groups, facilitated workshops, and questionnaires and surveys. They also include group creativity techniques, group decision-making techniques, observation, prototypes, benchmarking, context diagrams, and document analysis.

Back to top

1. Using group creativity techniques

Say you're leading a project to build a new recreation center. You organize a meeting of diverse stakeholders. You stand in front of a whiteboard, holding a pen. And you ask the people in the meeting what their requirements are for the new center. This can backfire on you in two ways. Imagine you're met with dead silence. Or imagine everyone starts arguing at once and all the meeting does is generate conflict.

You can use mind mapping, brainstorming, or the nominal group technique on its own. Or you can combine two or more techniques. But using each technique in sequence is a good way to get as much feedback from stakeholders as possible about their requirements. Ultimately, this can go a long way to ensuring a project succeeds.

2. Mind mapping

A mind map is useful because it brings together a lot of ideas. It groups these ideas visually to make it clear how they relate or differ. At the center of the map is the problem to be solved. As you think of ideas, you build branches out from the center. Each branch groups related ideas. At the end of each branch, you get to specific ideas that develop from more general ones.

When you're collecting project requirements from a group of stakeholders, the specific ideas you want to get to at the end of each branch are project requirements.

Take a project like recruiting qualified candidates for new job positions. In a mind map, you might move from a general idea – marketing your company to candidates – to more specific ideas about what kind of marketing is needed.

You could have a group of stakeholders create a mind map together, or work in smaller teams to create a few mind maps. The best method, though, is to have each person in the group create their own map. As a facilitator, you then combine the ideas in the separate maps into a single map. This makes sure everyone has a say, and shows how everyone's ideas fit together.

Rita is an HR specialist in a pharmaceutical company. She's been asked to manage a project to create an orientation and training program for new employees.

For the program to be a success, it will have to satisfy the needs of different groups.

Rita asks the production team manager, the IT manager, a training specialist from the company's product training team, an employee who joined the company eight weeks ago, and an HR coordinator to meet to discuss their requirements.

To get everyone relaxed and thinking creatively, Rita asks each person to create a mind map answering the question "What should the new employee program include?"

Select a map from the training specialist, the IT manager, and the HR coordinator for more details.

Training specialist's map

The training specialist's map has three main branches. One groups ideas for general training about the company and its policies. Another relates to an e-learning training product. A third branch groups ideas for giving new sales employees hands-on training in dealing with issues they're likely to face.

IT manager's map

The IT manager's map has one main branch. It groups ideas related to getting new employees set up with the needed equipment, e-mail, and security badges.

HR coordinator's map

The HR coordinator's map has one main branch that groups ideas for welcoming new employees, introducing them to the company, and equipping them with needed documents.

The next day, Rita calls a second meeting. She shows everyone the mind map she created, based on their maps and one she drew. Rita's map brings everyone's ideas together and makes it more clear what must go into the project.

3. Brainstorming

Brainstorming is a great way to generate an unstructured list of possible project requirements. This is because it encourages everyone in a group to have their say. And what one person says often inspires someone else with a new idea.

For a brainstorming session to work, it's important to follow four rules:

• identify the objective or problem – although brainstorming isn't very structured, its focus must be clear
  For example, an objective might be to develop requirements for a new product.
• record all the ideas stakeholders come up with so no good ideas are lost
  For example, their ideas for the new product may include very high availability, 10,000 transactions a day, and high security.
• make sure nobody criticizes other people's ideas – this can cause conflict and keep people from having their say openly
• encourage everyone to build on other people's ideas

One especially effective strategy is to use brainstorming after you've already created a mind map. This way, everyone can focus on clarifying the early set of requirements. The purpose of the session will be clear, so it's more likely everyone will have productive ideas.

In the project to create a new employee orientation program, Rita finishes the mind mapping process and then invites the managers, training specialist, HR coordinator, and new employee to a brainstorming session.

She starts by putting the requirements they've mapped out so far at the front of the room. She explains the purpose of the session as refining and adding to the list of requirements.

As the brainstorming session proceeds, Rita writes down everyone's ideas. Follow along as the new employee Candy, the training specialist Debora, and the production team manager Alex try to refine some of the requirements the group outlined earlier.

Candy: As someone on the sales side myself, I have to answer a lot of questions about how the company's products work. How about some training on this Debora?

Debora: I agree. I think the e-learning product we come up with has to cover the basic pharmacology of the company's drugs. This should be simple enough even for people who don't have a lot of pharmaceutical knowledge to follow, so maybe some good animations? We'll need help from research and development.

Alex: I think worrying about graphics at this stage is a bit of a waste of time.

Candy: Oh, OK. Well, I've got a background in pharmaceuticals, but that doesn't mean I could explain how this company's products work when I first got here. But let's leave that for now.

Alex: Why don't we focus on what is really important for new people to learn about company protocols? Everyone here should know the validation protocols we use and the Federal Drug Administration requirements we have to meet.

Rita: That's a good idea. Let's do that. But let's also think some more about how to fit some effective explanation of the company's products into the program. Do you have any ideas, Alex?

The brainstorming session Rita led helped everyone refine their ideas about what the program should be like.

It didn't follow all the rules for a good session though. Alex's criticisms about what others said caused them to give up on trying to reach a solution that everyone could agree on.

Rita was right, though, to make it clear what the objective of the session was, to record all the ideas, and to try to steer the group back toward building on each others' ideas, after the session derailed a bit.

4. The nominal group technique

The nominal group technique is a way you can help a group of stakeholders identify which requirements are the most important for a project. The technique can include brainstorming ideas and then ranking them. Or, if you've already used techniques like brainstorming, it can involve ranking a list of possible project requirements that you've already put together.

An advantage of the nominal group technique is that it lets each stakeholder in a group have a say about what's most important to them.

Another advantage is that this can happen without leading to conflict. The way people rank their requirements can even stay secret.

The way you use the nominal group technique will vary depending on what information you're trying to gather. If you're trying to refine a list of possible requirements you've already collected from stakeholders, the best way to use the technique is to follow these steps:

1. have the full list of possible requirements you've already gathered in front of the group of stakeholders
2. ask each person to rank their top five or so requirements
3. have group members call out the requirements and their rankings, and write down these rankings – optionally, have members exchange cards before doing this so their choices stay anonymous
4. tally the results for each requirement on the starting list, and identify the requirements with the highest scores

It's important that if you use a scoring system, you have each person assign the highest score to the most important requirement.

If group members rank their top requirement as 1 and their least important requirement as 5, the scoring wouldn't work.

This is because the most important requirements would have low scores – but so would requirements nobody voted for at all.

Remember Rita and the group of stakeholders who are working on requirements for a new employee training program? Follow along as she leads stakeholders in using the nominal group technique.

Once Rita has a list of possible requirements from the brainstorming session, she puts a chart that lists all these requirements at the front of the room. Then she gives each person in the group a set of five cue cards.

Rita asks each person to look at the chart and write down their top five requirements, one on each card. She also asks that everyone put a number from 1 to 5 next to each requirement. She explains that 5 indicates the most important requirement, and 1 the least. This will ensure the most important requirements come out with the highest scores.

Once everyone has finished, Rita asks each person to trade cards with another person in the group. This means nobody will know who has made particular choices, so it avoids arguments.

Each person then reads out what's written on the card, and Rita writes the results on a whiteboard.

Finally, Rita adds up the total score for each requirement. This makes it clear exactly which requirements the group feels are the most important.
The final tally shows that requirement B has a score of four, which is the highest. In second place is D with a score of three.

Using the nominal group technique, Rita helped stakeholders narrow down their requirements and determine the most important ones. This happened quickly and efficiently, without the need for lengthy discussions or arguments.

5. Summary

Group creativity techniques help you guide stakeholders in generating, refining, ranking, and approving the requirements for a project. These techniques include mind mapping, brainstorming, and nominal group technique.

Using each technique in sequence can ensure you obtain as much information from stakeholders as possible during the Collect Requirements process.

Back to top

1. Characteristics of good requirements

Imagine a situation where one part of the team working on a project is using inches as a unit of measurement and the rest of the team is using centimeters. Hard to believe that could happen? Unfortunately, that's exactly how NASA lost a $125 million orbiter in 1999. Because of a misunderstanding, the team made a calculation error and the spacecraft missed its entry into the orbit of Mars.

In projects, misunderstandings like the one that resulted in the loss of a spacecraft are more common than you might think. Often this happens because requirements aren't clear.

It's easy to misinterpret exactly what an important client wants. And it's common for different people on a project team to understand specifications a little differently.

This is what makes how you manage collecting project requirements so important. Stakeholders and all the people working on a project need to have the same understanding of what's required. If they don't, it can spell disaster.

For a project to meet agreed requirements, there must be a way to assess whether the requirements are being met. So each requirement has to be measurable. It must answer questions like "how much," "how many," and "how well." It must also be testable so there's an objective way to verify it.

If a requirement is testable, you can verify whether it has been met. These are examples of some of the techniques you could use to verify requirements:

• demonstrate how a product works, to verify it is functioning as required
  Description of graphic:
  
  A car crash test is shown as an example of a demonstration that an airbag works as required.
  
  Description ends.
• observe a product or service being used, to verify that it performs as required in practice, or
  Description of graphic:
  
  Using a software system to check it performs as required in practice is shown as an example of observation.
  
  Description ends.
• examine a product, to verify it has the agreed features
  Description of graphic:
  
  Checking the visual layout of a graphic design is shown as an example of examining a product to verify it has agreed features.
  
  Description ends.

A pharmaceutical company is developing a training program for new employees. An early requirement for the project was "must teach the pharmacology of the company's products." But how can you be sure everyone will agree the training does an adequate job of teaching how a drug works? This isn't easy to measure or test.

The requirement was changed to "must use three-dimensional animations to explain the clinical pharmacology of the company's products, and include narration for visually-impaired employees."

This requirement is measurable and testable. Any stakeholder or project team member can examine the training product to check if the requirement has been met.

Now say you're collecting requirements for the rear bumper on a new model of SUV. Examples of requirements you can't measure or test are "License plate holder looks right," "Is strong enough to resist denting," "Is rustproof," and "Is lightweight." For example, almost nothing is dent-proof if enough force is applied. And how light is lightweight?

An example of a requirement you can measure and test is whether the license plate holder on a rear bumper follows a set of specifications you define. You can also measure and test whether the body work has a minimum dent resistance and stiffness you specify exactly, passes standard durability tests in terms of rust-proofing, and has a weight of 110 pounds or less.

As well as being measurable and testable, a requirement must be traceable – forward and back. You must be able to track it as work proceeds so you know when it has been met.

And at the end of a project, you must also be able to look back and identify exactly how a requirement was met, or why it wasn't.

The two items that make a requirement traceable are a unique identifier and a tracking system for monitoring it through the project life cycle.

Select each item for more details.

Unique identifier

Giving each requirement a unique identifier that won't change throughout a project ensures you can track it, even if circumstances change and it's canceled.

Tracking system

You use a tracking system to document and monitor progress and any changes affecting requirements. The system identifies each requirement, its source, priority, and version, and its current status – such as active, canceled, deferred, or approved. It might also record attributes like the stability of a requirement, details of its complexity, and the criteria that will be used to accept it has been met.

Rita is managing the project to create a training program for new employees at the pharmaceutical company. Find out how she traced a requirement throughout the project.

One of the requirements listed for an e-learning training product was "must include pie charts showing the breakdown of the target markets for each of the company's pharmaceutical products."

Rita assigns this requirement the unique identifier e-004 and enters information about it in a tracking system.

Once the content has been developed, passes initial quality reviews, and is approved for use, Rita updates the system to show the requirement has been met.

Well into the project, Rita's team finds the training is running well over the required maximum length of 20 minutes. As a result, a change request to increase the duration of the training is approved.

Rita updates the tracking system to show the requirement has been changed to 30 minutes, the date, and the reasons for the decision.

Because Rita traced the requirement, she was able to verify when it had been met.

When the team is ready to close the phase for creating the training product, she'll also be able to explain to stakeholders exactly when and why a decision to change the requirement was approved.

2. Collect Requirements outputs

The Collect Requirements process has two main outputs. These are the requirements documentation, and a requirements traceability matrix.

The requirements documentation is a direct result of the group creativity techniques you used to collect and prioritize project requirements from stakeholders. It lists each agreed requirement and its attributes. This gives a baseline you can use to monitor and control a project throughout its life cycle.

The level of detail in the requirements documentation will differ for different projects. But the documentation should do four things.

Select each attribute to find out more about it.

Organize requirements by stakeholder and priority

Requirements should be grouped by the stakeholders or stakeholder categories they come from, and based on their priority. This helps ensure you can trace requirements easily and guide project work based on which ones are the most important.

Describe what objectives requirements meet

It's a good idea to document the business need or broad project objective that a requirement satisfies. This ensures that stakeholders and the project team know what overriding objective a requirement is there to meet.

Classify requirements by type

A requirement or its components can be functional, nonfunctional, or quality-related. In other words, it relates to how a product or service must function, to features that don't affect its underlying operation, or to performance standards it must satisfy. Identifying the broad type of each requirement helps you determine the aspects of project work that is needed to meet it.

Identify assumptions and constraints

It's important to document any assumptions and constraints on which a requirement is based. For instance, a requirement to assemble a product by a specified date might depend on a customer supplying the product components on time.

It's important that all requirements in the requirements documentation are consistent. This means that meeting one requirement can't rule out meeting another. For example, it might be impossible to create a camera that's small enough but also has all the required features. This is something you'd have to iron out in the Collect Requirements process, before going ahead with project work.

Consider some of the requirements training stakeholders came up with for a pharmaceutical company's training product.

Each requirement is measurable, testable, and traceable. In practice though, the content development team won't be able to keep the training duration to 20 minutes and still cover the required content. So the requirements aren't consistent.

Once the time requirement is changed, the requirements work together and can all be met.

The other output of the Collect Requirements process is a requirements traceability matrix. This is a table that assigns each requirement a unique identifier, and lists its status. It also lets you relate each requirement back to broader objectives and forward to the more detailed requirements phases must meet.

The requirements traceability matrix has three main purposes:

• it ensures each requirement adds value to the project by linking it back to the business need or objective it helps satisfy
• it tracks requirements, including their status, throughout the project, and
• it provides a structure for managing changes to the scope of a project so these changes don't result in requirements not being met

So the requirements traceability matrix lets you check how far a product or service has come in meeting each requirement, at any point in a project.

It's also what you use to map user requirements to project scope and to product design, development, and testing. For example, it may map a user requirement like "system must remain operational in the case of power cuts" to a functional requirement like "secondary power supply must kick in within 0.1 seconds."

The matrix may also include a summary of the details of each requirement from the requirements documentation, so these can be easily referenced.

3. Summary

The outputs of the Collect Requirements process are the requirements documentation and requirements traceability matrix.

The requirements documentation identifies each requirement and its attributes. The requirements traceability matrix is a tool you use to track requirements throughout a project.

Back to top

1. The Define Scope process

A good truism to remember is that projects fail in the beginning, not at the end. If it's not clear exactly where you're headed, no amount of work and effort is going to take you to the right place.

The Define Scope process is what you use to arrive at a documented agreement about exactly what a project will include.

It involves documenting objectives, deliverables, and requirements in enough detail to guide the rest of the project.

The Define Scope process occurs early in the planning stages – after you've developed the project charter and collected requirements, but before you create the WBS and perform processes related to planning the schedule. It involves progressive elaboration. This means refining and expanding on what you know so far, from the information you've gathered and the work you've done on the project.

You can think of the project charter and requirements as road signs pointing in the direction you need to head. Defining scope is more like a detailed map that includes what you'll see and do, what you'll leave out, and the precise coordinates a project must reach. It helps ensure stakeholders and the project team agree on exactly what product, service, or result the project will deliver, and becomes a basis for future decision-making.

The Define Scope process involves defining two types of scope.

Select each type for more information.

Product scope

Product scope refers to all the required characteristics of the product, service, or result that a project must deliver. It's measured against the requirements stakeholders set out for a product.

Project scope

Project scope refers to all the work required to meet the project deliverables. It's measured against the project management plan. You can define project scope only once the project deliverables and the product scope are defined.

Product and project scope support each other.

Throughout a project, you monitor the work done against the project management plan.

This is how you ensure all the work done – the project's scope – stays on track to meet the requirements set out in the product scope.

Defining product scope means moving from requirements to detailed descriptions of a project's deliverables.

Project scope is based on product scope. But it also involves examining and recording the assumptions, constraints, and risks that could affect the required work.

A fully defined project scope elaborates on conditions for a project's success.

Select each of the factors that relate to these conditions for more information.

Assumptions

An assumption is any idea held but not proven to be true. Defining scope involves identifying all assumptions and how they could affect a project. For example, you might assume that a client will provide artwork before the layout work for a magazine starts.

Constraints

A constraint is anything that puts a limit on what can be achieved – like a limited budget, resources, or time. An example of a constraint might be a contractual agreement that layout work for a magazine will be completed within a week.

Risks

A risk is any potential circumstance that could affect the success of a project. This ties in with assumptions and constraints. For instance, there might be a risk that artwork required for a layout project won't arrive on time. Or perhaps receiving it in an incompatible format will prevent the work from being done on time.

Rita is managing a project to develop a new employee orientation program for a pharmaceutical company. One assumption she elaborates on when defining the scope is that accurate information about the clinical pharmacology of the company's drugs will be supplied to the project team.

A constraint is that the project must meet requirements without exceeding its budget of $22,000.

A risk is that research and development might yield new information about the company's drug products before training material on these is completed.

Through the Define Scope process, Rita makes it clear exactly what the deliverables are for the project and what work will be required to complete them. She also identifies conditions under which the project can be expected to succeed.

2. Inputs for defining scope

Before you can define scope, you need the scope management plan, the project charter, and requirements documentation. You also need any organizational process assets that can guide the process.

The Define Scope process has four inputs.

Select each input for more information.

Project charter

The project charter provides a high-level description of a project and of the product, service, or result it must deliver. It outlines basic requirements and expectations, assumptions, constraints, and risks. Defining scope involves elaborating on what's in the project charter.

Requirements documentation

Requirements documentation identifies requirements the project must meet to satisfy expectations, and their relative importance. Defining scope involves moving from these requirements to more detailed ones that can guide all steps of a project.

Organizational process assets

Organizational process assets can make the process of defining scope easier and more accurate. For example, project files and lessons learned from previous projects may help you identify important information about deliverables, risks, assumptions, and constraints that apply to your current project. Policies, procedures, and templates for a scope statement can also influence the define scope process.

Scope management plan

The scope management plan provides guidance on which processes should be used to define the detailed product and project scope.

In the project to develop a new employee orientation program, the project manager Rita knows that the charter calls for new employees to be productive in their jobs after a one-week training period. This helps her determine what is required during training – and also what should be left out – when she's defining scope.

Rita also follows the processes laid out in the scope management plan. For example, she make sure that the formal acceptance of the training materials will be signed off by both the HR and compliance managers as the plan outlines.

The requirements documentation specifies that the training must cover updated Food and Drug Administration regulations for information in the company's packaging inserts. So Rita knows the project will have to include sourcing the current regulations and incorporating them in the training products.

Rita also looks at documents from a project the pharmaceutical company used to train a group of new sales representatives last year.

Using these organizational process assets, she sees where the project scope of the earlier project missed elements that resulted in scope-related changes later on.

This helps Rita avoid making similar errors in the current project.

3. Tools and techniques for defining scope

Defining scope involves elaborating on what you know so far, to come up with a detailed description of what work a project will include and exactly what product, service, or result it must deliver. But how do you move from what's in the scope management plan, project charter, and requirements documentation to this description?

There are four main tools and techniques you use to do this:

• expert judgment
• product analysis
• alternatives generation, and
• facilitated workshops

Defining product and project scope requires expert judgment, or judgment based on specialized knowledge.

This is because it involves determining the implications of what's in the project charter and requirements documentation for the rest of a project.

Defining scope involves answering two main questions. What must a product or service's exact specifications be to meet all requirements, given constraints and assumptions? And what precisely must be done to deliver this product or service? It takes specialized knowledge to answer these questions. This knowledge can come from a variety of sources.

The next important tool in defining scope is product analysis. It's by analyzing a project's deliverables that you determine exactly what attributes and features they must have – in other words, the required product scope.

Many different techniques can be used to analyze a product. Here are some examples:

• product breakdown
• systems analysis
• systems engineering
• value engineering
• value analysis, and
• requirements analysis

In the new employee orientation project, analysis identifies several features that must be included in the proposed training software.

For example, Rita works with other experts to identify the operating systems it must run on and the duration of each type of content it must cover.

She and a team also decide on the level of interactivity the software must include to teach concepts clearly, without this making the training too slow for new employees to download and play if they access it from the company intranet.

Two remaining tools and techniques for defining scope are alternatives generation and facilitated workshops.

These are related because they both involve encouraging creative thinking about the best ways to meet the requirements for a project and its deliverables.

Select each technique for more information about how you can use it to help define scope.

Alternatives generation

Alternatives generation focuses on coming up with alternative ways that work can be done to meet requirements. It involves thinking creatively about different ways to meet the project deliverables. For instance, a group of experts might evaluate alternative technologies or designs. They might also debate choices like whether to make or buy particular components. Through investigation, the best alternatives are identified.

Facilitated workshops

An important purpose of the Define Scope process is to make sure all key stakeholders agree on project and product scope. In a facilitated workshop, you bring together cross-functional stakeholders – people whose interests in a project differ. You guide the group to think creatively to come up with solutions and then to reach consensus. You could use this technique to elaborate on what a product must be like or what work a project must include to meet requirements.

The project manager for the employee orientation project, along with a group of experts, generate alternative ways of doing the work to develop an e-learning product. For instance, they weigh the pros and cons of developing the software in-house or outsourcing the work. Ultimately, the group decides it will be best to contract a specialist company to create the product, which is just one of the project's deliverables.

The manager then brings together a group consisting of IT managers, executive managers, employees who joined the company recently, and a training specialist.

In a facilitated workshop, she guides the group through a brainstorming session where ideas generated so far about project scope are refined. She then uses the nominal group technique to have the group rank the ideas they've generated.

By the end of the facilitated workshop, the group has identified and agreed to all important details about how the work will be done.

4. Summary

The Define Scope process involves defining what specifications a product, service, or result must have and what work must be performed to deliver it. This should be defined in enough detail to guide the rest of the project.

Inputs for this process are the scope management plan, project charter, requirements documentation, and organizational process assets.

Tools and techniques you use to define scope include expert judgment, product analysis, alternatives generation, and facilitated workshops.

Back to top

1. The purpose of the scope statement

Imagine a project is drawing to a close. The team has designed a technically advanced tracking system. There's just one problem. The customer says the system was meant to integrate with the company's existing tracking software. This is news to the project team. Now the customer won't sign off on the project, and the deadline is already at hand.

The main output of the Define Scope process is the project scope statement. This is like an official agreement among all of the project stakeholders. It explicitly identifies what will and what won't be included in a project's deliverables.

The project scope statement has four main purposes:

• it defines and progressively elaborates on the work of a project
• it guides the work of the project team
• it sets a baseline for evaluating whether requested changes or additional work are within or outside the project's boundaries, and
• it sets stakeholder expectations

Select each purpose the scope statement serves for more information.

Defines the work

The project scope statement defines the work that will go into a project through progressive elaboration. This means it refines and expands on what the team already knows from the project charter and requirements documentation. It's also what feeds into the process of creating a detailed work breakdown structure, where further progressive elaboration occurs.

Guides the project team

The scope statement makes it clear to the project team what will and won't go into a project. It describes the deliverables that must be created and the work effort and methods required to do this.

Sets a baseline

The scope statement is one of the documents against which progress and change requests will be evaluated. It forms part of the scope baseline for a project.

Sets stakeholder expectations

The project scope statement makes it clear to stakeholders what they can expect to receive, and what they can't, from a project. It's against these expectations that success will be measured.

Rita, a project manager, is working on a project to create a new employee orientation program for a pharmaceutical company. As per the project plan, she delivers the first draft of a chapter for the HR coordinator guidebook to internal stakeholders for review. One stakeholder advises that it hasn't covered the use of company property or security policies for laptops that are removed from the premises.

Rita checks if the missing topics were included in the scope statement. They weren't. But Rita remembers that when she and the team were collecting requirements, an agreement was reached to cover these topics in a separate training project.

Rita calls the stakeholder on the phone to discuss the issue and work out the misunderstanding.

But how do you get to a list of scope exclusions? For example, suppose you are creating a workplace health and safety manual. It's obvious the scope statement can't possibly itemize all the content the manual won't contain.

But it should address the most important exclusions that could affect a stakeholders expectations.

Identifying important exclusions to include in the scope statement involves expert judgment. You should probe stakeholders and draw on the specialized knowledge of experts. The goal is to identify things that might reasonably be expected of deliverables but that don't actually fall within a project's scope.

Consider an IT company's software development project. The company has been contracted to develop all the artwork, programming, and video components for a new video game.

An example of an exclusion the project manager outlines in the scope statement is that the company won't be handling audio production for the game. This is a good example of a relevant exclusion because audio features are a typical element of a video game.

All key stakeholders understand the rationale for the exclusion and sign off on the scope statement. So now when the deliverables are handed over, no stakeholders will be concerned that audio production wasn't included in the contracted work.

2. Components of the scope statement

A project scope statement should have six main components. Together, these ensure everyone involved knows what falls within the project's scope. They also form a basis for determining how to manage all remaining activities in the project's life cycle.

The product scope description identifies all the attributes a deliverable must have to meet requirements. For example, one of the attributes might be that a database management system must be available 99.8% of the time.

The product scope description is an important input for later processes. You use it to guide the development of a detailed work breakdown structure.

You also use it as a baseline for later quality assurance activities, like quality testing and scope verification.

A description of project deliverables is another important component. This makes it clear what stakeholders should expect to receive, throughout a project and when the project closes. For example, deliverables might include documents for review at specified stages, completed components, and an end product or service.

Consider Rita's project to create a new employee orientation program. One of the project's deliverables is a self-paced training product that employees will be able to work through in their own time.

In a scope statement, Rita includes details about the training software in the sections on the product scope description, project deliverables, and project exclusions.

Select each section of the scope statement that Rita has drafted for examples of what it includes.

Product scope description

In the product scope description section, Rita notes that the training product must provide 10 minutes of training on the pharmaceutical company's history and market position, and 20 minutes on the clinical pharmacology of its main drug products. The training must include 3-D animations demonstrating how the drugs work, and a minimum of 10 test questions.

Project deliverables

In the project deliverables section, Rita specifies that draft versions of the training content will be submitted for approval no later than May 10. A version of the developed training product will be ready for review by June 15. And a fully developed and approved e-learning training product will be delivered by June 30.

Project exclusions

In the project exclusions section, Rita notes that the e-learning product won't cover company policies and guidelines, which will be adequately covered in the New Employee Kit. It also won't include audio content, as per agreement, due to resource and time constraints.

A project scope statement should include product acceptance criteria.

These are the standards stakeholders and the project team agree to use to judge whether the project's deliverables have met requirements. The criteria play an important role at the close of a project or any of its phases.

They're used to verify scope and to confirm completion and acceptance of deliverables.

It's important to detail product acceptance criteria. Otherwise, it's possible that not everyone will agree that a requirement has been met, or even that a project is successfully completed.

For example, a product may meet one set of standards for durability but not another. If it isn't clear which standards must be used, the product could fail to satisfy some stakeholders.

As well as defining product acceptance criteria, the scope statement should identify project constraints. These include any factors that could limit the success of the project or pose possible risks.

Describing constraints often helps make it clear why certain scope exclusions were made. This makes it more likely that stakeholders will understand and agree to the scope statement.

In Rita's project to develop an employee orientation program, for example, an important constraint is a total budget limited to $22,000. This helps make it clear why documents for new employees won't be printed in color. It also helps explain why the self-paced training deliverable won't include audio content.

A final component that's important to define in the scope statement is project assumptions.

These help identify possible risks. For example, Rita outlines the assumption that the Research and Development Department will supply documents detailing the pharmacology of the company's drug products by no later than April 30.

This serves as a reminder to stakeholders and the project team. It's a risk that the documents won't arrive on time, in which case the project could run late.

As well as the project scope statement, the Define Scope process results in updates to project documents. Documents you may update are the stakeholder register, requirements documentation, and the requirements traceability matrix.

The process of analyzing all the components that go into the scope statement can make it clear where new requirements – or changes to existing ones – are necessary. So the two outputs of Define Scope are the project scope statement and updates to project documents.

3. Summary

The main output of the Define Scope process is the project scope statement. This statement progressively elaborates on the work of a project. It guides the work of the project team, sets the expectations of stakeholders, and provides a baseline for evaluating whether requested changes or additional work are within or outside the project's boundaries.

The project scope statement should include a product scope description, product acceptance criteria, and details of a project's deliverables, exclusions, constraints, and assumptions.

Another output from the Define Scope process is project documents updates.

Back to top