People like to use jargon in order to feel smart. The same is true in project management, where the word scope is one of the most frequently used terms.
Because I don’t want to let you standing in the rain, I’ll give you my explanation of what scope is.
What is meant by project scope
In a nutshell, project scope is the sum of things that a project has to take care of. It’s an abstract concept and it’s not something you can put in a case and ship off. Rather, think of it as a list of responsibilities, tasks and tangible items or deliverables a project must take over, conduct or create so that the project goal is achieved.
You define the scope while planning your project, so both planning and scope definition go hand in hand and are carried out by the project manager.
Having a clear picture of the scope is critical for your project’ success. Scope determines all important parameters of the project, including the timeline, cost and risks. In other words: If you aren’t sure about your project’s exact scope, you cannot predict its duration, timeline and risks properly — and you will ultimately fail.
That was a lot of theory, right?
An analogy from everyday life:
You’re looking to get a new kitchen. So you talk to several furniture stores who offer custom made kitchens. In the end they’ll hand you an offer consisting of several pages, describing what they will do for you such as designing the kitchen, choosing surface materials, suggesting suitable appliances etc. Maybe you want them to get the old kitchen stuff removed and of course to have the new one installed by a handyman. So all the work and all the items are part of your kitchen project scope 🙂
In scope or out of scope? That’s the question!
In project management, you often hear people talking about something being ‘in scope’ or ‘not in scope’. If an activity is in scope, this means a project will take care of it. Not in scope means the project is not responsible for it.
How to define the scope of a project
How do you typically define the scope in a project? It all starts with a conversation between the customer and the contractor (the party running the project and doing the work). Customer side management will describe to the contractor their issue and what kind of solution they are looking for. They might say something like:
Customer: We have a lot of issues with managing our inventory. It takes our workers so much time to find the right item on the shelves, and very often goods get lost because we don’t properly track physical movements … we just use Excel.
and the contractor will say:
Contractor/vendor: Ok, what you need is an IT based inventory management system. This is exactly what we are offering. We can roll out that system for you in 4 months only.
These kind of talks occur long in advance before an actual project is started, maybe even years in advance!
Then, over the following months client and vendor will have further meetings. The content of their discussions will change from high-level topics to very specific questions:
Sample Questions to clarify scope:
- Do you want a cloud-based inventory management system? Or do you prefer an installation on your own servers?
- Do you need hardware? like barcode scanners? terminals?
- Do you want us [vendor] to optimize your warehouse structure? We offer that service.
- Do you want onsite training for your workers? Or do you prefer video-based training which costs less?
- Do you want us to do an inventory stock count? We offer this service.
The vendor will gather all such details and decisions in a document. Using this information he will later create an offer to the customer as well as a formal scope statement, which lists all items the company will do for the customer.
PROVEN STEPS TO DEFINE PROJECT SCOPE
Before I go deeper into the scope definition process, please note this: defining the scope is not something you accomplish within one or two hours. Scope is also not something you “fix” in a few meetings alone. Rather, it’s a longer process during which you attempt to get a better understanding of the project and your customer’s needs, clarify any ambiguous points and write down your findings.
So, here’s a general framework I’d use for scope:
Step 1 ― Define your project goal
You can’t really confirm scope if you don’t have a project goal in front of you. If you don’t have a project goal yet then define one first, and don’t make this serious mistake.
Step 2 ― List major project activities and deliverables
Put simply, scope is the sum of all project activities and deliverables. So, the most basic of scope definition would be a list of all planned project activities and deliverables. Just to clarify, deliverables are results or things created in the course of the project, for example a training plan or a software could be a deliverable.
Example:
I’m using the previous example about the rollout of an inventory management system.
In such a project we would list the following scope:
major project activities:
- project planning
- requirement specification
- software installation
- adjust software to client’s needs
- training of warehouse staff
deliverables:
- project schedule
- requirement specification document
- ready-to-use system
- training plan
- training manual
This list is already our first scope definition!
Step 3 ― Clarify scope for each activity and deliverable
So you got your basic scope list from step 2. Your next step is to refine it further. Why is this necessary? The items you’ve listed may require further clarification before you can put down a valid cost and duration value. Also, the client may have additional wishes or requirements that need to be considered for the scope definition (click to learn how to gather requirements).
Example:
software installation
Valid question to ask:
Will the client perform the software installation himself or should it be done by the vendor?
Does the client prefer a cloud-based solution instead of a dedicated installation?
The answers have an impact on project scope.
For example, if the customer prefers a cloud-based platform, then a software rollout on the client’s servers is out of scope.
Maybe the software has different modules, and the client only needs 3 out of 5 modules. Then those three modules are in scope and the other two are not in scope. As a consequence the software installation and configuration will require less effort (and as a result cost will be lower).
As you can see, you have to be quite specific to get a good and complete understanding of the scope. Often it requires you to dig down deep with super-specific questions — almost like going through a checklist and checking each scope-related question carefully.
Documenting scope in a scope statement
The scope statement is a formal document that explains the scope of a project, including the activities, responsibilities and deliverables of the project. Purpose of the statement is to make sure both customer and contractor have the same understanding of what the project is going to deliver. The document is normally signed by both parties.
I recommend using a proper template that already has the right structure and includes the relevant chapters.
My scope statement template
I’ve included the template I used for my projects. You can download the Word file (DOC) here. The template contains all sections you need for proper scope definition with your customer.
To help you getting started I’ve included sample data from an IT project. Note that scope statements are usually a lot more comprehensive than this sample — meaning they contain much more text. So, make the document as comprehensive as needed for your project.
DOWNLOAD THE PROJECT SCOPE STATEMENT (DOCX)
Read this if you struggle with defining scope
Sure enough, you want to make your project a success. But you also need a clear definition of what your project should do and how to accomplish its mission.
You need a FEASIBLE plan: When you define scope for the first time, you may feel overwhelmed sheer amount of options and activities that possibly have to be done. Don’t make it too complicated. Just ask yourself ‘How can we get from A to B?’ and then write down the steps that YOU think need to be taken. The key thing that matters is that your plan is feasible. And the steps are the basis for your project’s scope.
Go from high level to detailed level: People love to discuss details, even though the overall project strategy and approach may not be clear yet. This does not make sense. I recommend you always at the high level, looking at the major activities and deliverables and then breaking those down into smaller tasks and work packages.
Dealing with different options: Your sponsor or your stakeholders may have their own ideas on how to tackle the project. The problem is that their ideas may not be feasible, or they may not be optimal from an overall project perspective. What you could in this case to convince the other parties of your approach is to put each option side by side in a spreadsheet and list all the pros and cons for each alternative. Then, have the team decide on which way to go.
Was this article helpful?
I’d love to hear if this article has given you a better understanding of what project scope is. Also I hope you feel more confident defining scope in your project. If you have any questions, just post a comment below and I’ll give you my answer.
