Website Process - Scoping [Phase 0]

When creating a website, the first and most important step in the process is defining the scope. It’s usually not something that shows up as a typical project milestone, but overlook it at your own peril. You will be tempted to jump into discovery or strategy, and maybe even straight to designs, but if you haven’t properly defined the scope, you’ve left the door open to vaguely defined expectations that can lead to strained client relationships, and projects that aren’t profitable. I know that sounds dramatic, but it’s true. I know because I’ve lived the results of too many poorly scoped projects.

What is a Project Scope? #

The Project Scope provides clear guardrails around what is included and what is not included. It should define the features, timelines, and specific deliverable that will set the proper expectations, and keep the project on time and in budget. The scope of a website may include:

• Specific functionality
• Documentation or other deliverables
• Number of web pages built
• Matters of process like the number of revisions
• Predefined number of hours invested in a specific task

Why is a well-defined scope important? #

A well-defined scope is important for both the client and the provider of the service. It brings clarity to the client and defines expectations and is essential to creating a profitable project for the provider. Conflicts arise when expectations are mismatched. A clear and documented scope can be the key to a successful and long term client relationship.

How do you create a project scope? #

The elements of a project scope should include the following sections

• Objectives
  • The goals that the client has expressed in the pre-sales process
• Deliverables
  • The things that the client will receive over the course of the project.
• Functionality
  • Description of the expected functionality included in this project, and possibly clarification on the limits of that functionality—what won’t be included.
• Timeline
  • A rough outline of milestones with the necessary caveats to make sure that you’re setting some expectations without making promises that you don’t have the ability to deliver on. This should be provided in time increments and can include ranges (2-4 week), not hard dates.
• Cost
  • The cost of the project, and add-ons or maintenance costs.

The creation of the scope is really a problem-solving exercise that start with listening to the client’s requirements and goals, and crafting a solution that will help them achieve those goals. The scoping document is a reflection back to the client that you heard their needs, and have the expertise to provide a solution.

How detailed should the scope be? #

Everything should be made as simple as possible, but not simpler. – Albert Einstein

It can sometimes be difficult to determine the level of detail required for a scope document because it needs to be clear enough to address all of the project objectives and flexible enough to address unexpected challenges. Within the project scope you may have a document that defines the technical specifications of the project, a Tech Spec. The Tech Spec is an extension of the Project Scope that continues to clarify expectations for both parties. A typical Website Project Scope will not include a Tech Spec up front, because technical requirements are often uncovered in the strategy and design phases of a website build. However, if your website has specific functional requirements outside of the norm, you may want to define that in order to properly scope the time and cost, so having a tech spec up front may be necessary.

Scope Secured… Right? #

With the scope document above you’ve shown that you’ve listened to the needs of the client and have provided the solution to their problem. So are we done? Sorry, no. This scope is just a starting point, and you’ll fill in details as you go throughout the phases of the process. The scope of the project is defined enough to get you started, and that’s all it needs to be for now, but the deliverables exist to clarify the scope further, and eliminate possibilities until you have a final product to launch.

Stick to the scope #

Once you have a scope, it’s important that all of the work that you do down the line is subject to that. You need to hit timelines, profit margins and client expectations, which means you can’t underdeliver, but you also should not overdeliver, at least not in terms of features. I can think of only a small handful of times when my extra work was appreciated. In reality, that extra feature became something that either put the project behind schedule, created a mess for me to support, or became the new expectation for future work. Instead of bringing additional value, it devalued what I could do because I did it for free.

What to do when requests are not in scope? #

First, the fact that you have a scope is the reason you can identify what is not in scope, so give yourself a great big pat on the back. Having a scope means you and your client know what you are doing and—more importantly—what you’re NOT doing. Sometimes things change, and new ideas arise over the course of the project and you’ll need to have a way to account for that. That’s where the Change Request comes in.

Hooray for Change Requests! #

Change Requests are a great thing! It can mean that you inspired a new idea that will bring additional value to your client, and bring in more revenue. (Remember, if you didn’t have a clear scope, you might have thrown this in for free, or the client may have just expected it to happen because all websites do X, right?) If your client has a clear understanding of the scope, they’ll know that what they’re asking for it outside of it, and when they come asking for an additional feature, they’re more likely to expect to be charged for it. When they’re already primed, it makes that conversation really easy. “That’s a great idea, I’ll put together a Change Request together and get an estimate for the additional time and cost to make that happen for you!” you’ll say excitedly. So many times I’ve seen account managers with an unclear scope hear a client’s additional request and get scared. Instead of excitedly bringing valuable solutions to their client, they feel like they are springing bad news on them. A client will come with a new feature request, not knowing if it’s in scope or not, and the AM will have to check with someone, and come back apologetically telling them that they could do it, but they would have to charge for it.

Components of a Change Request #

A change request is a mini-scope document, so all of the same elements of the scope document should be reflected in the Change Request, just at a smaller scale. You still need to outline the objectives, deliverables, timeline and cost for all of the same reasons we needed them for the greater scope doc. One thing that is often overlooked in a Change Request is accounting for the impact on the overall project timeline. Be sure to make that clear in the document, and let your internal team know about the change as well.

Legal reasons for a clear project scope #

In addition to clarifying client expectations, and giving the production team proper guardrals, defining and documenting the scope can help protect you legally. We always want to finish a project to the satisfaction of our clients, but clients are not always as reasonable. Usually missing expectationg will only lead to a dissappointed client that won’t refer more work, but sometimes it ends in a legal battle, and non-payment. A clear scope can’t eliminate this problem completely, but it certainly strengthens your legal position should it go there.

The scope is the finish line #

A project scope is the expression of Franklin Covey’s second habit, “Begin with the end in mind.” Having a clear scope lets you know where the finish line is, and crossing the finish line is the best part of every endeavor. It’s also the hardest. For a website project, it’s where all of the theory becomes a reality. The world gets to see and experience all that you’ve been working toward. A project’s success if you can answer “yes” to the following question: Did you deliver an effective website on time and within budget? There are other metrics that will be measured like user adoption, conversion rate, and how it accomplishes other business goals, but that’s a strategy problem, not a project management problem. It’s important to make these distinctions up front and deliver on the things you can control, and not make promises about things that you can’t. This brings us to the next phase of a website project, the strategy.

Photo by Jp Valery on Unsplash