How to prevent scope creep on web design projects
by Rachel Greene
Anyone who’s worked on a web design project can probably look back at a project or two (or three) and wish they’d developed more finite project scope when the work first came to them. Having a well-researched, clear, and agreed upon project scope before work begins can go a long way in preventing a multitude of unfortunate client situations as production progresses.
What is a Project Scope?
Essentially, a project scope outlines and defines what the deliverables for a project are going to be.
That said, a project scope itself shouldn’t necessarily be a barebones document. The more thorough the scope, the less room there is for miscommunication with the client later on. A good scope will clearly state the expectations of the client and describe the steps you’ll be taking to meet those expectations.
Documenting these expectations at the beginning of a project is important, as it will give the client an understanding of what is and is not included in your agreement. These definitions will also keep scope creep at bay.
What is Scope Creep, you ask?
Whether you’ve referred to it by its proper name, or by throwing your hands up in exasperation and despair, you’ve probably already dealt with scope creep at some point. A client comes to you in the home stretch of a project and asks for one little bitty additional feature. That tiny addition leads to another, and another, and soon you have an entirely new set of things you have to consider and deal with on a project that should have been done weeks ago.
If it wasn’t discussed and agreed upon in your initial arrangement with the client, it’s a creeper, and chances are you could have avoided it.
To Be, or Not to Be? These are the questions.
Developing a project scope involves not only planning for what will be included, but also agreeing upon what will NOT be included in the project. Ideas and items that come up, are discussed, but then decided against are often referred to as negative scope. This also applies to elements that are typical of similar projects, but that the client does not want.
Clients, especially those unfamiliar with web technologies, tend to assume that certain things are included with your work. This list may include things like domain registration, hosting, SEO optimization, marketing and social media. If there are project elements you expect the client will need, but that are not included in your agreement, be sure to make the client aware of this before production begins.
Outlining negative scope in your initial agreement helps to ensure that the client understands what they can expect; this can also be a safety net for you later on, should a client claim that an item was to be included when the scope specifically states that it was not.
Get it out of your head.
Discussing the project scope and documenting it are not the same.
Our memories are not failsafe; people interpret and remember events differently. What may have been perfectly clear at the beginning of a project can quickly evolve into a nasty misunderstanding.
Create a document that can be used as a template for future projects. Identify the overall scope of the project, detail out any specific features that will be included, and set specific dates for the various milestones and deliverables; be sure to also make note of elements that will not be included in your work.
Deliver this document to your client, have them review it carefully and give you an official sign-off before any work begins on the project.
The template you create for yourself is a living document. As projects come and go, you’ll learn more about client expectations and project limitations. Take those lessons and apply them to your notes and process when developing scopes for future work.
It may seem like a lot of work to do before you can actually get your hands dirty with the good stuff, but having a good project scope base to work off of will save you from plenty of headaches in the future.