When you run a web development business, you’re bound to come across some challenges.
You’ll likely find that the biggest obstacle is attracting attention and convincing anyone interested in your services to become an actual client. This is a very time-consuming and expensive process, considering all the marketing and reputation-building that’s required.
So it’s hard enough just to get someone who needs help with a web development product to actually contact you. But even once you’ve achieved that victory, your work isn’t over yet.
Before you can start working on a project for someone, you’ll have to sit down and draft a scope statement that details what exactly you’ll be doing for the project – that can take a lot of time.
This is the big issue with scoping projects. It allows you to reach a detailed yet clear agreement with a client, but it’s also a lot requires a significant time investment, especially for something that’s not guaranteed to work out.
In fact, in most cases the deal falls through and you don’t end up making a sale, even when you’ve taken the time to scope the project.
That’s just frustrating. If scope statements take so much time to make and there’s not even a guarantee that all your efforts will pay off, what’s the point of even bothering with them in the first place?
To answer that question, let’s first take a more detailed look at what scope statements consist of:
What’s in a scope statement?
I’ve already started ranting about scope statements, but you might not even know what those are exactly.
Allow me to explain:
A scope statement details the “scope”, i.e. all the relevant information, of a project. This usually includes:
- Justification: a brief sentence or paragraph that explains why the client needs the project completed (for example, they need a more polished website to improve their search rankings and bounce rate and ultimately attract more customers)
- Deliverables/Objectives: a detailed list of what you’re expected to deliver to the client
- Acceptance Criteria: Quality benchmarks, deadlines, etc.
- Constraints: Limits on how and when you’re expected to meet objectives
- Non-goals: Objectives that fall outside the scope of the project and are not expected to be completed. This is where you can avoid conflict in the future by establishing exactly what you can’t do upfront before it’s an issue.
- Cost estimate: An accurate assessment of how much the project will likely cost. Be careful with this one – if you underestimate the cost initially, the client very well may get upset when you end up going over budget. Upset clients are unlikely to become repeat clients
What makes a good scope statement?
Using the SMART method is a good way to write a clear and effective scope statement.
- Specific: Specificity is, basically, the entire point of scope statement. Being vague at first leads to misunderstandings and disagreements later on
- Measurable: Deadlines should have specific dates, and there needs to be a verifiable way to determine whether you’ve met other objectives or not
- Achievable: Make the project as small it can be while still accomplishing all the objectives. Promising too much and then failing to deliver will ruin client relations
- Relevant: This point ties into making the project as small as it can be – don’t promise to do anything that’s not relevant to the project. The less you promise, the less of a chance there is that you’ll disappoint
- Timely: Nobody likes delays. The faster you complete a project (without sacrificing quality, of course), the more impressed the client will be. Structure your scope statement so that it allows you to progress through the project as quickly as possible
If it takes so much time, why scope at all?
Well, good luck finding clients that are willing to hire you for a project without first defining what you’ll be doing.
It’s in the best interest of both you and the client to work out a detailed arrangement that defines exactly what’s expected of you for a project. You’re liable if you don’t hold up to the agreement, but you also have something to point to if the client starts being unreasonable.
And even if you’re still somehow convinced that scope statements aren’t worth your time, you should know that you don’t live in a bubble. You work in an environment where other businesses, the vast majority of other businesses, in fact, are willing to provide scope statements. So if you tell a client that you’re not willing to provide such a statement, they’ll just abandon you and find a web developer that will. It’s just not a viable option.