Simply put, the logical boundaries of your project are your project’s scope and the best analogy for understanding it is to consider it a fence or corral. All the activities and tasks inside the fence will be carried out during the project and everything outside the fence will not.
Suppose something outside the fence should be moved inside later. In that case, it requires a very specific and well-executed set of instructions for opening the gate – namely, your Change Control process or procedure.
Very early in the project, the scope should be defined and documented. That’s the easy part. During the project, the challenge is controlling it.
The Importance of Defining Project Scope
The purpose of defining scope is to clearly describe and gain agreement on the project’s boundaries before the project starts. It seems simple enough. But, sadly, it is human nature to make assumptions.
First, your clients will assume that certain things will be included or excluded from your website development project. This is not their fault. They likely use the internet every day and may presume that all websites include a particular feature that they see very often, so they never think to mention it. On the other hand, they have a business to run and have likely spent very little time learning and understanding the true nature of web development. And don’t even get me started on the ads that claim you can build a website in an hour. Your clients are being misled by such things. But again, this is not their fault.
Your clients need you to educate them about what is included in a website project (specifically YOUR project) and the project scope statement or document is the foundational piece of client education.
At the same time, you or your team members will likely make certain assumptions about what your client understands and expects.
Your agreed-upon scope statement clearly defines what is inside the fence, and what is not, so there are fewer misunderstandings and rework requirements later on. It is only possible to successfully manage project scope IF you’ve done a good job of defining the scope upfront.
Understanding The Risk Of Scope Creep
Scope creep is a dreaded and insidious thing that can happen with any project if measures are not established to prevent it. Scope creep occurs in several ways:
- The client asks for that one tiny (or big) thing, and you agree to do it even though it was not in the agreed-upon scope or estimate.
- You add a feature or element because you “know” the client will like it or because it’s “cool”. While the intent is admirable, this is called gold-plating and is pure, unadulterated scope creep for no reason.
- Your estimate and scope included a particular solution that turned out not to be viable, so you use an alternative solution without updating either.
But you’re not alone. Almost ALL projects suffer from some form of scope creep, and both project teams and clients are consistently frustrated by it.
When Should You Define The Project Scope?
Your project scope begins to reveal itself even in the initial pre-proposal meeting. As you uncover BUSINESS requirements for the website, some things will immediately be considered included – or excluded.
For example, if your retail brick-and-mortar client doesn’t want to sell their products online, but wants customers to be able to view them, then a catalog solution is in scope – while eCommerce is clearly out of scope.
The initial project scope is typically agreed upon via the Project Proposal or Contract either in a single scope section or in several sections covering the necessary information. This section should be as detailed as possible and clearly highlight the activities that are in scope for both your team AND the client. It is essential to let the client know that the scope statement agreed upon in this step is based on what you know at that time, and could change during the project using your Change Control Process.
The Difference Between A Project Scope Statement and Project Discovery
The Project Scope statement is typically included in the Proposal. It includes a high-level list of the major activities that will be carried out during the project. It should also include those activities that are specifically excluded, or out of scope. In other words, it defines WHAT will be done.
Project Discovery, on the other hand, is the first activity to be carried out once the proposal is approved. It takes much longer to perform and document and results in a Statement of Work (or website specification) that includes the nitty gritty detail of HOW the activities in the Scope Statement will be carried out.
Who Should Be Involved In Creating the Project Scope Statement?
The first draft of your Scope Statement is included in the proposal. It should be reviewed with the client during the proposal or contract walkthrough. It is not uncommon for the initial Scope statement to be updated with agreed-upon changes before the final proposal is submitted for approval.
What Should Be Included In A Project Scope Statement?
The following should be included in every scope statement. Some additional items may be needed for some specific project types.
- Timeline – a list of project phases with a high-level description of what is accomplished in each phase.
- Team – a list of individuals to be involved in the project with roles and responsibilities
- Project Activities – A list of major activities with an indication of who will be carrying them out
- Out of Scope – A list of activities that will NOT be carried out as part of this project
- Change Control – your process for controlling scope creep
I once reviewed a student’s proposal where he had done an excellent job defining what was In Scope for the project but had nothing listed as Out of Scope. Instead, he had only this statement: “Anything not mentioned or listed in this proposal will be considered out of scope.”
While I respect the intent, it is much safer to go ahead and clearly define the out-of-scope elements in detail. Remember those assumptions? That’s what the out-of-scope section is about. Make sure there are no incorrect assumptions by listing the activities that will not be carried out as part of the project.
The 6 Steps to Defining Project Scope
Step 1 – Identify Boundaries
First and foremost, boundaries must be established regarding when changes will be allowed to the scope, and how that will take place. This is typically done by including your established Change Control process or procedure.
It’s also important to note that requests for changes to scope should ONLY be considered an opportunity and NOT an aggravation or annoyance. Change is going to happen. You’ll be more successful if you embrace it and invoke your change control process without exception.
Step 2 – Identify Responsibilities
Clients often think that once the proposal is approved, they can disappear for a few weeks, after which you will deliver a website. Most don’t realize that their day-to-day involvement is necessary and that some activities are solely their responsibility. We do this in two ways:
- Project Roles and Responsibilities – we include this in every proposal to drive home how much is involved in a website project, as well as clearly spelling out the client’s responsibilities.
- A Scope Chart – Lists the Activities with an indication of In Scope (for me), In Scope (for the client), and Out of Scope (see step 6).
Step 3 – Include All Items That Are in Scope
Gather the activities from your Project Plan and include them in your Scope Chart. It’s essential to be specific here. It’s no good just saying that your agency will build the client a website.
- How many pages?
- What will be on those pages?
- What functions are needed?
- What devices should the website be optimized for (desktop, tablet, mobile)?
Remember that clients will often tend to assume many things, and won’t always appreciate that, for example, responsive designs don’t just happen, or that contact forms or other interactive content isn’t necessarily a stock part of every website.
If your agency will be building a wireframe, include in your scope the ways in which this design will be approved, and by whom (make sure it’s a named individual). Remember, the client’s responsibilities and roles need to be a defined part of the scope every bit as much as your own.
Step 4 – List All Items That Are Out of Scope
This takes a little more practice, but if you’ve got a standard list of project activities, you can re-use this and designate in the Scope Chart which of those are not included for this specific project.
It helps if you already have a list of elements that could potentially be included in the design and development of a website, and then specify those which will not be included. This may in some instances prompt the client to reconsider the project scope, perhaps not realizing that certain elements would not be included. It is far better to have that discussion at this stage of the project than several weeks down the line when a huge amount of work has been achieved and you believe the project is nearing completion.
Again, just as with the previous step, make sure you are specific about those elements or tasks that will not be included in the project. This can include, for example, the design, redesign, or optimization of their logo (often overlooked), the sourcing of stock images, or the taking of new custom images.
Step 5 – Separate the In-Scope Items to Theirs or Yours
We do this using three columns in the Scope Chart, as shown in Step 6. It’s critical to appreciate when designing a project scope document that it covers both your tasks and obligations as well as the client’s.
Failure to include the client fully in the project scope can give them enough wiggle room to cause all sorts of problems. For example, it will be their responsibility to approve designs promptly. If they don’t, then the project can drag on, taking far longer than planned, potentially costing more, and then overlapping with other projects.
Then of course what you don’t want is for the client to suddenly show up and wonder what all the delay is for. Since there might be no mention of their responsibilities and roles in the project scope, that could make for a very challenging conversation.
Including their roles and tasks very specifically also gives you the opportunity to include statements identifying what actions would be taken in such a situation, such as including a percentage rate for a project kill fee.
Step 6 – Use Charts for Clarity and Brevity
Here is a partial example of the Scope Chart we use and teach the students in The WP Project Manager’s Academy to use. A chart like this allows the client to see where each item falls quickly and easily.
In this table you can see we have four columns, the tasks or elements of the project, which of these will be both in scope and your responsibility, which of these will be both in scope and the client’s responsibility, and which of these are entirely out of scope.
Having a stock table like this produced ahead of time makes it much easier to then work through for each client what will be included and what won’t. If you don’t have something like this now, then building a list of tasks for each project and compiling this into an archived table, to which you add any other tasks other projects may require, will give you a useful resource for the future.
Don’t Forget the Care Plan Scope
If you offer maintenance or care plans to your clients (we require it), it is imperative to spell out what IS and is NOT included in each plan and STICK TO IT.
This includes timeframes, contact methods, and precisely what tasks, elements or features will be supported, and to what extent. Again, make sure that you are as specific about what won’t be included in this care plan as you are about what will be. Doing otherwise can become a costly and time-consuming mistake.
Final Thoughts
Aside from your estimate, your scope statement is the most crucial element in your proposal because it sets the project boundaries and the expectations of all those involved. At a minimum, a well-defined scope statement includes:
- A description of the timeline
- Team roles and responsibilities
- Project Activities
- Activities that are Out of Scope
- A description of your Change Control process
Controlling scope creep is a primary function of managing any project, but you cannot manage it successfully if it isn’t well defined at the project outset. Once approved, any changes to the scope should only be made via an agreed-upon change control process that is invoked without exception. Our proposal template and example inside the Premium membership to The WP Project Manager’s Academy gives a thorough relevant example of how your scope can be defined for ease of client understanding.