There are obvious difficulties with the project scope. Defining 100% of required work is problematic. It is a problem to control the changes consistently. It is easy to miscommunicate what should be done to stakeholders.
No matter what kind of project you manage. A methodology does not really matter as well. 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 like a pro.
Here is the deal:
Before you start defining the scope of the project you need to think through all the way until 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 will say that it is not what he expected…at all.
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, behaviour, performance, etc. While project scope describes what work should be performed to meet those requirements.
There is 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 will significantly impact the scope.
You see, zero defects approach is too costly. It requires a lot of efforts. Therefore, in most cases, 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.
Do it the Right way with Scope Management Plan
Scope is the King. Remember that. You have to treat it kindly.
Your ultimate goal is to deliver what your customers perceive that they asked. Read it again. Customers think that they clearly explained what you need to do. You think that you understood them correctly. That is almost never true.
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 lease the following aspects.
How to Collect Requirements
What is the real story here?
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 is a guide on how to collect requirements from 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.
How to Crackdown Requirements and Define Scope
Here is a requirement: “The pmbasics101.com website should have a capability to collect emails and send out a PDF document in return.”
What does it take to meet this requirement?
- Select a mailing service provider.
- Create an account.
- Design the form to collect emails.
- Implement the designed form.
- Install plugin from the mailing service provider.
- Upload the PDF document.
- Activate the form.
- Test the form.
It is just a list of required actions. If I were to put it correctly as a Deliverable and Work Packages, it would end up into:
- Email Optin Form
1.1 Report on Mailing Service Providers
1.2 Approved form design
1.3 Optin form on Testing environment
1.4 Test Report
So, how do you get from that one-sentence-requirement to actual scope of work?
- You can find someone who has relevant experience or knowledge. It can be stakeholders, customers, or external consultants, subject matter experts or other parties. 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 a direction or advice. It is a basic technique that you will apply widely.
- Product Analysis. It is applicable when you need to produce a product rather than service or result. This technique focuses on decomposing product value. Just like WBS does with the scope.
Further, you need to analyse the product from ergonomic and functional viewpoints, then make decisions on materials or processes that will comply with performance requirements. All in all, your goal is to define tangible deliverables.
- Alternatives Generation. This technique works well when you have expertise in the nature of the project. Now you need to find the best solution to meet requirements. In most cases, you will use brainstorming to get the alternatives.
What is the goal?
You need to clearly define what is and what is not part of the project scope.
How to Manage Project Scope
It is not enough to define 100% of the project scope in the beginning. That 100 % WILL change during project lifetime
So, you need a way to monitor, control, and make changes to the scope.
The cure is well known. It is 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 is 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 project scope. Therefore, you also need a Project Scope Statement. We will 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 need to be done from User Story description.”
How to Validate Scope
Once in a while, you need to get a formal sign-off that a deliverable meets stakeholders expectations.
It is 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 do not want to get all the change requests, all the defects, and “minor changes to the project” in the end. You will deprive yourself of 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. Stakeholders will be less prone to negotiating changes to the scope, timeline or budget. They will 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 here. 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 current project status and progress. Point out known defects and work-in-progress parts. Collect feedback from the customer. You can also 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
What’s the real story?
Usually, a project starts, and we receive requirements in different forms. Emails, PDFs, meetings, mockups, bug reports, whatever. And of course, we do not prepare a Project Charter or anything similar. In most cases, we do not even discuss the business case for the project.
We usually create a Work Breakdown Structure. However, it is only used internally and never goes to the customer. Then we decompose the work to the activities and estimate the project. We use bottom-up estimation technique.
Now comes the first expectations check. We present estimates for the project. You see, there is apparently a lack of transparency here. The customer does not know what work we actually estimated.
If the estimate is close to customer’s expectations, he will not dig into the details. He is ready to spend that amount of money and time already. They do not want to waste their precious time.
A lot of organisations and project managers hide inefficiencies behind such silent agreements. It is a topic for a separate post, but it is a root cause for many of your problems.
What happens next? We start project execution. Sooner or later customer will ask to add another piece of work. Then we will find a part of unidentified work. Then quality problems will appear. They will eat up a lot of time.
Then we hand-off a delivery to find out we did something wrong. And then customer informs us that he forgot something and it should be added asap.
Does it sound familiar?
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 Scope Baseline Example here. It is intended for a small software development project.
Project Scope Statement
Work Breakdown Structure
WBS Dictionary
As you can see, this one required little efforts. Scope Statement was created together with WBS and WBS dictionary in one application. Also please note that you don’t have to put “everything” the textbook prescribes. Just ensure that Scope Baseline serves its purpose.
Describe Any Scope to Stakeholders with 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 is 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.
What should be included?
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
Product Scope. A description of characteristics, traits and functionality of a product or a service that you will produce. Keep in mind that you collected requirements from different stakeholders. Do not assume that all of them keep track of each requirement. Also, it is not always clear how much work is required to deliver a requirement.
It is the primary place to align expectations of key stakeholders. You need to show the amount and complexity of work required to meet different requirements. Put the most efforts to this section.
Acceptance criteria. The conditions that must be met before project deliverables are accepted. You can include acceptable level and a number of defects here as well.
Deliverables. A description of all deliverables your project will produce. It may include the product or service, project documentations, product manuals, educational materials for your product, etc.
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. It is 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 future.
Firstly, you will not 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 is clearly stated someone may still expect you will deliver it. Do not feed false expectations. It will be easier to hand off the project at the end.
Constraints. Anything that limits you to deliver the product efficiently should be stated here.
Assumptions. 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 project scope statement. In fact, it is a formal and mutual agreement. 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.
Organise the Project Scope with WBS
WBS is a mandatory part of scope baseline on all projects. Large or small. Agile or Plan-driven.
There is a complete guide to a Work Breakdown Structure on PM Basics already. I will not repeat it here.
There is 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.
I would not suggest you create a separate document. Maintaining 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, WBS Dictionary may include:
- Description of the work
- Assumptions and constraints
- Responsible people or organisations
- Milestones
- Related activities
- Required resources
- Cost estimates or budget
- Acceptance criteria
- References other documentation
So, whatever suits you needs and helps you to integrate WBS into other processes.
Conclusion
“There is no wind that blows right for the sailor who doesn’t know where the harbour is.”
You can not lead the project to the 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.
Recommended Further Reading:
- Truth About Benefits of the PMI PMP Certification
- How to Create a Realistic Project Schedule
- How to Grow When Project Management is not Appreciated
The post How to Manage Project Scope In a Structured Way appeared first on PM Basics.