Project Scope Example: Scope Baseline, Project Scope Statement

There are obvious difficulties with the project scope. For example, defining 100% of the required work is problematic. Also, it’s a problem to control the changes consistently. It’s easy to miscommunicate what should be done to stakeholders.

Project Scope is the description of all the work that needs to be done to create deliverables and achieve the project objective. The best tools to describe project scope are Project Scope Statement, Work Breakdown Structure, and WBS Dictionary.

The truth is that you need to dedicate a lot of efforts to control the project scope.

Today, I want to explain how to do it faster and in a more reliable way AND with a real-life example.

Real-Life Project Scope Example

Below is the project scope example for a small real project.

(I removed the names of products and clients)

A bigger project will have all the same components.

It’ll have more text in the Project Scope Statement. However, I still recommend keeping it short.

Work Breakdown Structure will be bigger.

But the concepts of project scope will be the same for a large project. So, don’t overcomplicate scope management.

Example of Project Scope Statement

Notice that it’s a simple description of the project scope tailored to customer’s understanding.

Example of the Work Breakdown Structure

I have an in-depth guide on Work Breakdown Structure alone. If you want to dive really deep read it after this article:

Ultimate Guide on How to Create a Robust Work Breakdown Structure

Example of the WBS Dictionary

As you can see, this Project Scope Example required little effort.

Project Scope Statement was created together with WBS and WBS dictionary in one application.

Also, please note that you don’t have to put “everything” a textbook prescribes. Just ensure that the Scope Baseline serves its purpose.

In-Depth Guide on Project Scope Management

Here’s the deal:

Before you start defining the scope of the project you need to imagine the project END.

Ask yourself how I will hand-off the final delivery to the customer?

Looks easy, isn’t it?

No! What if the customer says that it is not what he expected…at all.

So, how to finish a project successfully and make clients happy?

Below is the step-by-step guide on Project Scope Management.

Requirements vs. Project Scope

Just to be sure we are on the same side, let’s clarify the difference:

“Requirement is a condition or capability that is required to be present in a product, service or result to satisfy a contract or other formally imposed specification.” – PMBOK® Guide

And

“Project Scope is the work performed to deliver a product, service, or result with the specified features and functions.” – PMBOK® Guide

What does that mean?

A requirement is what a product should look like, what should it be capable of, what are the characteristics, behavior, performance, etc.

While the project scope describes what work should be performed to meet those requirements.

There’s one more important definition:

”Quality is the degree to which a product complies with the requirements.”

You need to clarify the quality level for your project . It’ll significantly impact the scope.

You see, the zero-defects approach is too costly. It requires a lot of effort.

Therefore, you need to ensure only the acceptable level of quality. And you must include the efforts to achieve that quality level into your project scope.

How to Create a Scope Management Plan That Works

Scope is the King.

Estimates of durations, costs, risk analysis, procurement – everything starts with Project Scope.

Your ultimate goal is to deliver what your customers perceive that they asked.

Read it again!

Customers think that they had clearly explained what you need to do . You think that you understood them correctly. That’s almost never the truth.

“The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw

To ensure that you are in line with what was asked to do, you need a Scope Management Plan.

It should cover, at the very least, the following aspects:

1. How to Collect Project Requirements

By this time you already need to have a Project Charter . It should state requirements on a high level.

Also, you need to identify relevant stakeholders who can dwell on the high-level requirements. They may also have some additional ideas or related experience.

So what does it take?

In short, you need to communicate with all of them to collect requirements. There’s a guide on how to collect requirements from the project manager’s perspective.

Keep in mind that by this moment you may already need a separate specialist who is trained to collect and describe business requirements. It’s the role of a Business Analyst.

2. How to Crackdown Requirements and Define Scope

Here’s a requirement:

“The pmbasics101.com website should have the capability to collect emails and send out a PDF document in return.”

What does it take to meet this requirement?

1. Select a mailing service provider.
2. Create an account.
3. Design the form to collect emails.
4. Implement the designed form.
5. Install plugin from the mailing service provider.
6. Upload the PDF document.
7. Activate the form.
8. Test the form.

It’s just a list of required actions. If I were to put it correctly as a Deliverable and Work Packages , it would end up into:

1. Email Optin Form
   1.1 Report on Mailing Service Providers
   1.2 Approved form design
   1.3 Optin form on the Testing environment
   1.4 Test Report

So, how do you get from that one-sentence requirement to the actual scope of work?

A) You can find someone who has relevant experience or knowledge

It can be stakeholders, customers, or external consultants, subject matter experts or other parties.

So, Your goal is to acquire them from the project team or just get in touch to communicate. They may have a solution already.

Otherwise, you may get direction or advice. It is a basic technique that you will apply widely.

B) Perform the Product Analysis

It is applicable when you need to produce a product rather than a service or result.

This technique focuses on decomposing product value. Just like WBS does with the scope.

Further, you need to analyze the product from ergonomic and functional viewpoints, then make decisions on materials or processes that will comply with performance requirements.

25 Examples of the Product Analysis

All in all, your goal is to define tangible deliverables.

C) Use the Alternatives Generation Technique

This technique works well when you have expertise in the nature of the project.

So, you need to find the best solution to meet the requirements. In most cases, you’ll use brainstorming to get the alternatives.

What’s the goal?

You need to clearly define what is and what is not part of the project scope.

3. Software Applications to help with Project Scope Management

For sure, you can track the project scope in any available app. For example, Google Drive, Evernote, or MS Word will do.

However, there are serious benefits in using integrated project management software to keep everything in one place.

Ideally, you need to be able to link requirements to the project deliverables.

Then, from deliverable to specific tasks with estimates, related risks, and defects.

If you are in the position to choose a project management software for your project – use the form below to find the most suitable solution.

4. How to Control Project Scope

It is not enough to define 100% of the project scope in the beginning. That 100 % WILL change during the project lifetime

So, you need a way to monitor, control, and make changes to the scope.

The cure’s well known. It’s a Work Breakdown Structure .

Well, also you do need a clear workflow to introduce changes to all areas of the project whenever the amount of work changes.

However, it’s a matter of integrated change management process .

So, what’s the catch?

You need a high-quality WBS. Moreover, you need a non-nerdy way to describe the project scope. Therefore, you also need a Project Scope Statement. We’ll discuss it below.

If you are on an agile project , the clearly defined scope of increment or iteration is even more vital. Do not think that agile saves you from thorough documenting of the work to be done. Keep your Sprint Backlog and User Stories neat. Apply a simple rule: “A newcomer should understand what needs to be done from User Story description.”

5. How to Validate Scope

Once in a while, you need to get a formal sign-off that a deliverable meets stakeholders’ expectations.

It’s crucial to do that continuously throughout the project. Even if you are leading a plan-driven project, nothing should stop you from providing product increments for review.

Why do you need this?

You don’t want to get all the change requests, all the defects, and “minor changes to the project” in the end.

You’ll deprive yourself of the opportunity to actually integrate a change into the project.

The closer you are to the project closure, the less time and resources will be left. Moreover, stakeholders will be less prone to negotiating changes to the scope, timeline or budget. Also, they’ll put more pressure on the team to get what they need.

Just stating the obvious:

It is highly important to have a clearly described and approved project scope from the start.

When a deliverable does not meet expectations, there will be corrections.

It is your responsibility to prove whether a correction is a change request and, therefore, it should be integrated properly. Otherwise, it is a defect, and you must make amends. Sometimes at your own expense.

How do you actually validate scope with customers?

On any project, you can use Scrum-like Demo Meeting .

Just prepare a short demonstration of the deliverable. Explain the current project status and progress . After that, point out known defects and work-in-progress parts.

Also, do collect feedback from the customer. Later, you can provide any supporting documentation and reports required by your policies.

Bottomline:

Collect feedback from stakeholders continuously. Negotiate terms of introduction of new change requests. Keep the project Scope Baseline up to date.

How Scope Baseline Will Save Your Efforts

Usually, a project starts, and we receive requirements in different forms.

For instance, emails, PDFs, meetings, mockups, bug reports, whatever.

And of course, we do not prepare a Project Charter or anything similar. Bad practice!

In most cases, we don’t even discuss the business case for the project.

We do usually create a Work Breakdown Structure.

However, it’s only used internally and never goes to the customer. Then, we decompose the work to the activities and estimate the project. We use a bottom-up estimation technique.

Now comes the first expectations check:

We present estimates for the project.

You see, there’s apparently a lack of transparency here. The customer doesn’t know what work we actually estimated .

If the estimate is close to the customer’s expectations, he’ll not dig into the details. Because he’s ready to spend that amount of money and time already. He doesn’t want to waste their precious time.

Here’s the truth:

A lot of organizations and project managers hide inefficiencies behind such silent agreements.

It is a topic for a separate post, but it is a root cause of many of your problems.

What happens next?

We start project execution! Sooner or later customer will ask to add another piece of work.

After that, we’ll find a part of unidentified work. Later, quality problems will appear. They will eat up a lot of time.

All in all, we hand-off a delivery to find out we did something wrong.

And that’s when the customer informs us that he forgot something and it should be added asap.

Believe me, you experience it more than once.

Scope Baseline Definition

”Scope baseline is the approved version of a scope statement, work breakdown structure (WBS), and its associated WBS dictionary, that can be changed only through formal change control procedure and is used as a basis for comparison.” -PMBOK® Guide

Scope Baseline Example

You can download a PDF version of the Scope Baseline Example here. It is intended for a small software development project.

What is a Project Scope Statement?

Definition of the Project Scope Statement

Project Scope Statement is a narrative description of a product and project scope.

It is used as a written confirmation of what your project is going to produce and how.

What’s the key to a valuable project scope statement?

I believe you need to use terms and language that any stakeholder understands. This piece of project scope baseline is mainly for the customer.

OK, what should be included?

1. Justification of a project

It is a short description of business need. Sometimes one sentence is enough. The rest should stay in a Project Charter

2. Product Scope

It’s a description of the characteristics, traits, and functionality of a product or a service that you will produce.

Keep in mind that you collected requirements from different stakeholders. So, do not assume that all of them keep track of each requirement. Also, it’s not always clear how much work is required to deliver a requirement.

It’s the primary place to align the expectations of key stakeholders.

You need to show the amount and complexity of work required to meet different requirements. Therefore, put the most efforts into this section.

3. Acceptance criteria

It’s the conditions that must be met before project deliverables are accepted.

You can include an acceptable level and a number of defects here as well.

4. Deliverables

It’s a description of all deliverables your project will produce.

It may include the product or service, project documentation, product manuals, educational materials for your product, etc.

5. Project Exclusions

Here you need to specify what is out of the project scope.

Quite often a part of stakeholders wants something specific. The other part of stakeholders or a customer does not support it.

Therefore, it’s a conflict situation. Once the conflict is resolved, and it was decided to remove something from the project scope, put it here.

Be specific and very clear about it. It saves time in the future.

Firstly, you won’t have to revisit these project exclusions again. Stakeholders may try to include them later during project execution.

However, unless something dramatically changes, you should not waste time on reviewing exclusions.

Secondly, unless it’s clearly stated someone may still expect you will deliver it. Don’t feed false expectations. It’ll be easier to hand off the project at the end.

6. Constraints

Anything that limits you to deliver the product efficiently should be stated here.

7. Assumptions

It’s the uncertainties that could not be clarified at this moment.

You need to accept some of them during planning. In case an assumption proves to be invalid, you will have a right to modify the project plan.

A customer should approve the project scope statement. In fact, it is a formal and mutual agreement.

Also, it states that you are committed to delivering described results under the definite assumption and with clear constraints. On the other hand, the customer agrees to accept the specified result.

It does not mean that we cannot change the project scope. No. It means that to make a change – we need to amend the agreement.

Organize the Project Scope with WBS

WBS is a mandatory part of the scope baseline on all projects. Large or small. Agile or Plan-driven.

There’s a complete guide to a Work Breakdown Structure on PM Basics already. I will not repeat it here.

There’s only one crucial point I want to stress:

Deliverables described in the Project Scope Statement should get into WBS as is. Keep deliverables consistent throughout the project.

Put Everything You Know into WBS Dictionary

WBS Dictionary is a document that describes the work that should be done for each work package.

As a modern PM, I would say that it should be a part of a task tracking system . Most of the project management software gives you the ability to keep this information in one place.

Therefore, I would not suggest you create a separate document. Maintaining the WBS Dictionary is a lot of work. Look for integrated solutions.

You can include any information that specifies a component in the WBS. For example, the WBS Dictionary may include:

• Description of the work
• Assumptions and constraints
• Responsible people or organizations
• Milestones
• Related activities
• Required resources
• Cost estimates or budget
• Acceptance criteria
• References other documentation

So, whatever suits your needs and helps you to integrate WBS into other processes.

Conclusion

“There’s no wind that blows right for the sailor who doesn’t know where the harbor is.”

You can not lead the project to a successful outcome without knowing what needs to be done.

Once again I want to stress out.

Even if you are in the Agile environment and the scope is not clearly defined for the whole project, you still need to plan a way to define, manage, track, and change the project scope.

Both for an iteration level and the final project result.

I also recommend reading:

• Next in the series: Ultimate Guide on How to Create a Robust Work Breakdown Structure
• Previous in the series: How to Collect Stakeholder Requirements (Real-life Example)
• PDF: How to Manage Project Scope In a Structured Way