Have you ever managed a project where you had to deliver above and beyond the resources available to you? Above your budget, or the time available?
Where your boss or your client keeps calling because you haven't delivered on all their expectations?
Then you might not have negotiated a well-defined project scope with your project's stakeholders.
So, how do you go about creating a solid project scope?
In this article, you can get a complete walkthrough. And you get a how-to guide to help you create a bulletproof project scope.
Let's first agree on what the project scope is.
The project scope is a definition of what you should deliver within the project. And – just as important – what you should NOT deliver.
You might say your scope is the size of your project and the specified details of its delivery.
It refers to the work that your project team needs to do to deliver a specified product, service, or result.
As a project manager, you never define the project scope yourself. You need to involve all the project's stakeholders and get them to agree on what the project should deliver and what is outside of scope.
This process is complicated, as different stakeholders have different agendas, priorities, and opinions. However it is vital to involve them in defining your project's scope, as adjusting scope further into the execution stage highly increases your risk of overrunning deadlines and budgets.
This often results in a lower quality project deliverance, as the project has become compromised of too many stakeholders having to be pleased as you execute.
The project scope statement is the document that defines all aspects of the project scope.
As a project manager, you often need to revisit the document as stakeholders try to push the boundaries of your project. Or when you get lost in the details of executing the project.
The statement should be accessible to all stakeholders, and you must get them to approve the final formulations before you start executing your project.
Often projects develop uncontrollably when too many agreements have been made verbally. The project scope statement is your guide to keeping the project on track and avoiding scope creep.
Even though all projects are different – both the nature and size of the project and the organisational capabilities - project scope should always include certain elements to define the objectives and clear limits to the project.
Here are some project scope examples of the most used elements:
Description and final deliveries
Project objective and value creation
Constraints and exclusions
Statement of work
Project milestones and timeline
Acceptance criteria
Scope creep occurs when you gradually add more or expand the agreed deliverables to the project.
We refer to it as creep as it's not something that intentionally happens or is outright stated. It just happens as your stakeholders come up with (perhaps quite good) ideas as your project progresses.
Of course, you shouldn't always fight changes to the project as it progresses. Often you learn more as you execute, and there can be a perfectly good reason to expand the project and its deliveries.
Just make sure you formalise this expansion in a revised project scope that all your stakeholders approve before going on.
If you are to modify your project's scope, you should be very aware that the other parts of the project triangle should be adjusted accordingly.
Otherwise, your project's cost or timeline gets out of balance with the scope.
When you adjust the scope, these adjustments should be formulated and approved by your project's stakeholders. Often clients will push to expand the scope without pushing for an increase in budget or extending the timeline.
As a project manager, it is your responsibility to get new estimates based on the new scope and negotiate a new budget and timeline.
If you don't do this, your project risks running out of time or budget before being able to deliver what's in the scope.
Creating a well-defined project scope is the first thing that should happen in the project management workflow. It outlines and gives direction to the project, and all subsequent planning, negotiation, and evaluation should be based on the initial scope.
And it provides your project team and your stakeholders with a clear roadmap and shared understanding of what the project is – and is not.
Projects without a clear and approved project scope have a high risk of suffering from:
Because you can (and should) always consult the project scope state throughout the execution, you can make sure you and your team's decisions align with what's agreed.
Also, the statement gives you a robust negotiation platform for changing the budget and timeline when your client (or manager) request changes in the delivery.
So, let's look at how you create a project scope.
The scope should always be completed and approved before the project starts.
Writing a good project scope involves a bit more than simply grabbing your laptop and start typing in a blank document.
You must go through the different phases and get every stakeholder involved in the process.
Fortunately, if you stick to these four steps, you are off to a good start.
As a project manager, you often don't have the luxury of being present when the project is sold to the customer.
Or decided in the boardroom.
So, your first step is understanding the rough edges of the project – and preparing your research for your project scope. You need to talk to your sales team in this step if you weren't involved in the sale.
In this step, you map out:
And you create the outline for the project scope statement that you will use as your go-to document for the rest of the project.
At this stage, you must reach out to all stakeholders and project executives to clarify and document expectations and requirements.
As a rule of thumb, you can never involve too many interests, as new requirements might emerge from unexpected sources throughout the project. A good requirement collection ensures that everybody is heard from the start and is aligned on your project.
It is essential to document everything at this stage – including the expectations you might consider unrealistic – so you have a complete overview of expectations and requirements. This way, you can spot the differences early and work on alignment of expectations in the final scope statement.
Some of the interests that should always be heard at this stage:
What kind of requirements should you collect?
When you have gathered all requirements, it's time to turn them into a clear scope.
This is an easy step if all stakeholders are aligned in step 2.
If stakeholder requirements do NOT align, you must do the best scope definition you can (on areas where they align) and map expectations and requirements that don't align. Call in your stakeholders and negotiate everything they don't align on until you have a clear definition everybody can get behind.
At this stage, the statement should be formulated as clearly as possible without room for interpretation, which can lead to discussions and disagreements later.
Get the final definition validated, approved and signed by all stakeholders.
After these initial stages, you have a document you can consult and refer to in all later stages of the project. You can keep coming back to your scope as complexity accumulates throughout the project and scope creep is ever-present.
A project scope that gathers dust is useless, and you miss out on one of the best tools in your toolbox.
Often, there can be a need to revise the project scope as you execute your project.
Maybe you come across a technical difficulty that alters the final delivery. Or your client requests additional features to the project.
You must go through steps 2+3 again to ensure that everybody can get behind the changes whenever this happens.
And that a new budget and realistic timeframe are also negotiated in place.
So, now you got your project scope, and all that's left is to execute your project
Wouldn't it be nice with a proper project management tool to help you?
TimeLog gives you all the tools you need to get your projects to the finish line – within time and budget.
You get: