You’ve planned and executed your project, conducted end-user testing, and you’re feeling pretty good about things. As a matter of fact, you’re anticipating the team celebration and your next project already.
But then, to your dismay, the customer explains that they want additional things done before they sign-off on the project.
They expected training documents or other features. None of which were part of the scope.
And the scope creep begins.
Project Scope Creep is a Common Problem. According to the Complete Collection of Project Management Statistics 2015, 77% of large IT projects “say they don’t always agree on when a project is done leaving the door open for ongoing rework and scope creep.”
You Can Manage Scope Creep. Though scope creep is a common problem, with the proper planning and tools in place, you can avoid it. I’ll explain how, and even provide a project scope statement template to help.
Why Using a Project Scope Statement Template Can Help Increase Success
During planning, your customer shares information about what the project is intended to accomplish.
There’s a goal and a business need. Maybe your customer has a problem that needs to be solved.
However, customers aren’t always great at getting all their expectations across clearly. Many times a project manager finds himself confronted by clients who want to add more to the scope. This destroys your schedule and your budget, and the team is frustrated that the project is expanding beyond what they expected.
And the project seems as if it will never end.
It’s usually not due to malicious intent. It may just be that the customer didn’t explain clearly, or thought that you understood.
A project scope statement helps clarify expectations between the customer and project team.
Nailing down the scope and ensuring that everyone’s in agreement makes sure that all involved come to the end of the project with the same understanding of what’s to be delivered.
The scope statement will help you as the project manager determine what’s in scope and included in the project.
And just as importantly, it’ll help you and the team determine what’s out-of-scope and excluded from the project.
This ensures that everyone has the same understanding and is in agreement on what to include as part of the project.
According to PMBOK 5th Edition (p. 123) The project scope statement “describes, in detail, the project’s deliverables and the work required to create those deliverables. It also provides a common understanding of the project scope among project stakeholders.” PMBOK goes on to explain that “it guides the project team’s work during execution, and provides the baseline for evaluating whether requests for changes or additional work are contained within or outside the project’s boundaries.”
How To Use This Project Scope Statement Template
PMBOK p. 123 lists the following items to include in the scope statement:
- Product scope description
- Acceptance Criteria
- Deliverables
- Project exclusion
- Constraints
- Assumptions
To fully understand the project scope, you need to understand your key stakeholders’ needs for the project. You’ll start gathering requirements from the key project stakeholders and other key participants.
You can gather stakeholder and customer requirements by interviewing them and having focus group sessions. As you do so, you’ll get a more thorough understanding of what the stakeholders expect and want.
As you start gathering information about your project, talk with the project sponsor, the customer, and any internal team members who may have already done work on the project during feasibility studies. They’ll have background information on what’s been identified as part of the project so far. Gather all this information and have additional conversations with the team.
Requirements gathering itself is outside the scope of this post, but note that it’s important to understand what is needed and expected by the stakeholders.
You’ll also need to determine any integration points required for the solution. For example, if you’re creating a website, and you need to access a database that another team owns, you’ll need to include that as part of the scope too.
Keep in mind that the scope document isn’t meant to be a technical document. Write it in language that can be easily understood by all.
What To Include in the Project Scope Statement Template
Below is a list of each component of the Project Scope Statement, and a description for each.
- Product Scope Description – Description of the product or service that the project will deliver.
- Deliverables: The products or services that your project will provide. It may be a process improvement, or a service, or a software implementation. You might also create and deliver supporting documentation with the product or solution. You might provide design documents and training guides. Be clear on what your team will deliver so that there’s no confusion or misinterpretation during the project.
- Acceptance Criteria – The conditions or criteria that will be used to determine if the product or service met the customer’s requirements. This ensures that everyone has the same understanding of what’s important about the solution at the end. An example might be that a customer must be able to pay with Paypal. If the customer will evaluate the criteria in a particular way, include this also. From the article “The importance of having clearly defined acceptance criteria in your projects”, Sabyasachi explains that the acceptance criteria lay out a “specific and defined list of conditions that need to be met before a project has been considered completed and the project deliverables are accepted by the client. Having clearly defined acceptance criteria can help you…measure, achieve and prove to your clients that the work is complete….”
- Project Exclusions – Just as important as listing what you will deliver, it’s important to be clear on what your team will not include as part of the project. This helps avoid confusion or different expectations among those involved. For example, if you’re delivering software, but won’t provide end user training on how to use it, clearly state that training is out of scope.
- Constraints: These are factors or situations that may limit the team in some way. They’re situations that the project team can’t control. They could be physical, legal, budgetary, or due to policy. For example, if the project is dependent on another service being in place by a certain date, this would be listed as a constraint. If your software must run on a certain platform, you’d list that as a constraint. If the project has a firm budget limit with no possibility of an increase, you’d list this as a constraint.
- Project Assumptions: Circumstances and conditions that must be taken into consideration. For example, if your team will be using specific resources with critical expertise, an assumption would be that these resources will be available.
Once You’ve Completed the Project Scope Statement Template…
When you present your Scope Document to your customer, they shouldn’t be surprised by the content, since you’ll create it with information provided by the customer. Additionally, communications throughout planning will ensure you all know what you’ve included in the document by the time you present it to them.
You can review it with your stakeholders in smaller discussions if you need to gain buy-in and agreement before presenting at a large formal discussion. Ultimately, you want to get the document and content to a state that everyone agrees upon.
Once everyone is in agreement, get formal sign-off. This ensures you all have the same understanding of what’s included in the project, what’s outside the scope of the project, and what “done” looks like. Having this understanding up front helps ensure that you deliver what is expected, resulting in a happy customer, a happy team, and a successful project.
If you found this article helpful, please share! Scope creep can be a frustrating problem, but you can address it early with the right approach.
This is a very nice and informative post.
This article contains useful information. I appreciate the time and effort you put into writing this and sharing it with us.
Hi,
Very good article thanks for sharing, keep up the good work!
Wow ! This is a great resource indeed. I love the scope template 🙂 This can be re-used almost everywhere 🙂
The Real Person!
Author Leigh Espy acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
I’m so glad you found it helpful! It’s a powerful tool that can reduce the risk of scope creep and make sure everyone has the same understanding of what you’ll be delivering (and NOT)! 🙂
Thanks for the kind comment!
Really great article Leigh. Scope is so important to the success of the project. I often find when the scope is done the out of scope (or as you have called it Project Exclusions) is not only missing but have not even been thought about. Having a template like this is a great idea as it stops things such as exclusions being missed. I also think it is far too easy for people to create scope creep and there needs to be a stronger no sorry you have missed the boat you can have that if you ask for it next time.
The Real Person!
Author Leigh Espy acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
Thanks, Barry! I agree. It helps the team think through the scope more clearly, and ensure that everyone has the same understanding of what’s in scope and just as importantly, what is out of scope.
Additionally, if the customer wants to add something, having a scope statement as a baseline allows you all to discuss how the requested change will potentially impact the plan.
I use this document regularly on my projects and it’s been extremely valuable.
Thanks again for your comment!
Excellent template, Leigh. One suggestion: for some projects, it can be valuable to prioritize the scope elements. This is especially true for projects with a “complete by” date or “not to exceed” budget. Agreeing up front can help drive the creation of contingency plans and support later trade-offs. You might include this in the Project Assumptions or among the Constraints, depending on the nature of the project. You can’t deliver a car without an engine or steering wheel, but if the floor mats come in the mail a week later …
The Real Person!
Author Leigh Espy acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
Fantastic suggestion, Dave. I’ve not ever prioritized the scope elements, but I can see how it could be valuable. Thanks so much for the input!