There are so many variations and types of web projects that it would be a herculean task to give a full accounting of them, and not very useful. It won’t take long before you find one that is completely unique, breaks from the norm, or surprises you with a genius twist.
Despite their variety, all web projects have one thing in common: they start with an idea.
(By “web projects” I primarily mean design and development, but am also including content strategy, dev operations, Internet marketing, SEO, etc.)
What is a scope document?
The idea is communicated by clients to the project team in what we call a scope document. More than just a document, it’s a tool we use to determine what the demands of the project will be: what the deliverables are, what kind of timeline we’re chasing, what technology we’re implementing and testing on, and so forth. Sometimes it’s an 80-page behemoth, and other times it’s just a short email.
Regardless of length, the scope doc should effectively convey the entire project in an organized and detailed fashion for the project team, which, if not done right, can be tricky.
Writing a good scope document
Setting the tone
The scope doc, as the first piece of information passed on to the project team, sets the tone for the entire relationship. As an entrepreneur, writing a scope doc will help you start thinking critically about the project; and as a client looking for a new project team, having a good scope doc will help take the stress out of the sales process.
A scope doc is a living thing. It evolves as new evidence and requirements are uncovered. Not once have I been able to copy/paste a client’s scope doc as they first provided it directly into our Statement of Work. Negotiation is at the heart of a good scope doc.
Asking the right questions
No matter how seriously you take this process, if you’re not asking the right questions you’re not going to make any headway.
I’ve seen both ends of the spectrum: lengthy Word documents that leave me more confused at the end than I was at the beginning; and concise one-page proposals that convey exactly what’s needed in very few words.
What are the right questions? Well that’s a good question. It depends on the project. Following the steps below will get you 80% of the way there. We’ll talk about the missing 20% on the other side.
5 steps to a great scope document
1. What’s the goal of the project?
This can be “design a website”, “develop a plugin”, “write marketing copy for my new business”, or “complete competitive analysis for my company’s branding”. Think of it as the thesis statement for your project — its purpose is to set your purpose. Your goal should be short and to the point, but complete. If your project consists of design and development, don’t forget to go over both.
2. What’s the scope of the project?
Not to be confused with the scope doc, the scope of the project is a list of items that need to be completed. At The Phuse, we often use a list of pages as the scope. For example, here’s the scope for a very basic marketing site:
- Home
- About
- Services
- Contact
These can get far more complex with web applications. I suggest using nested lists and footnotes.
3. What are the deliverables?
Once you have the scope of the project down, outline the deliverables. Again, at The Phuse, each of the above pages listed in the scope would need Wireframes (.png / Balsamiq Mockups), design (layered .PSDs) and development (HTM/CSS or the like).
4. What are the requirements?
Requirements are important in all projects, but especially development projects. Here are a few questions you will want to ask yourself:
- What browsers do I need to support and test for?
- What devices do I need to support and test for?
- Is the website going to be responsive, or have a separate mobile site?
- What stack am I building on? (i.e. WordPress site, Rails app, node.js app, Shopify site, etc.)
5. Who is providing what? Who is responsible for what?
If you’re hiring a designer, someone still has to write the copy and take the photos. If you’re hiring a front-end developer, they’ll need backend support. This is a team effort.
Again these requirements vary from project to project, but generally speaking here are some good questions to ask
- Who is writing the content?
- Who is providing photos/imagery?
- Who is providing hosting?
- Who is providing backend support?
- What is the post-launch maintenance agreement?
All of the above will affect the estimate you receive, so make sure you cover all your bases to avoid change orders, fluctuating scope or a ballooning project.
Bringing it home
At this point you should have taken a few hours to examine your project in detail and ask yourself the hard questions. What you should have now is a pretty solid scope doc that I would be comfortable providing to an agency to get an estimate. If it’s an agency worth their salt, their experienced eyes will pick out any gaps or holes in your scope doc and ask you more questions. That’s the missing 20%. The negotiation process will bring you home.
The scope doc will effectively communicate your idea, but don’t forget to learn about your project team — how they work, who they are, what they believe in. What can sometimes be more important than your idea is whether the team you choose is a good fit for your project. Be honest with them, but most of all be honest with yourself.
