In this article, we’ll define:
- Project goals
- Major deliverables
- Key milestones
- Project management
Every project has goals. This is where we define them. These details are critical to the document because there will be times when the stakeholder (and sometimes the team) requests to creep in and put our timeline and budget at risk. But we can push those risks away if change requests don’t meet the documented business case. Avoid confusion by clearly outlining what will be delivered for approval through the course of the project, as well as the final deliverable.
What are the project goals?
e.g. increase conversion, increase newsletter subscribers, increase CTR, etc.
Give a high-level description of the project.
Who, what, why, how? Up to four lines will be fine.
What is the client’s business case for this project?
Capture the reason for this project. Evaluate the benefits, cost, risks, and rationale for this solution. This should be high-level.
This section should help us to come to an agreement on what will be delivered and when. Every project has its limits and we need to be sure we’re not exceeding those limits to complete on time and on budget.
What limitations can we foresee in this project?
Limitations can come in many forms, but one example would be technology. For instance, if we’re building a website that depends on a specific technology, be sure to mention that. There may be several ways to code that website, but if we’re boxed into a complicated technology, we can cover ourselves by specifying those limitations. Doing so will help us if/when we run into a limitation and don’t have the time or budget to explore alternatives. Think of it as an insurance policy for the project. Bullet points are fine here.
What exactly needs to get done in order for the client to go from where they are to the finished project?
Bullet point individual tasks.
What are the expected outcomes?
What is the business objective that we want to achieve with this project and how will we measure and report on it?
This is where we outline what the project will deliver. Whatever the deliverable is, this is where we clearly identify them. Examples include design comps, a sitemap, etc.
Create a clear list of deliverables for the client throughout the project.
This is where we list exactly what the client can expect to receive throughout the project. Bullet points are fine.
Create a clear list of project completion deliverables.
This is where we list exactly what the client can expect to receive at the end of the project. These should be natural conclusions from the task list completed in ‘Requirements’. Examples are ‘coded, fully functional landing page’, ‘Google Analytics set-up’, ‘Re-designed website’. Bullet points are fine.
In many situations, we might want to combine the deliverables and timeline so that we have an accurate picture of when each deliverable should be finished and what’s dependent on it. This way, we get a better overall picture of the flow of the project and can see where bottlenecks might come up.
Outline the milestones for this project.
Projects can be very long and complex, which is why they’re laid out over a timeline and broken down into more manageable parts called tasks. Larger phases of the project are marked by what is called a milestone. It’s a way to help us monitor the progress of the project to make sure it’s adhering to our planned schedule. Define key milestones, including project kick-offs, meetings, hand-offs, etc. Bullet points are fine.
You know what they say about assumptions, and you probably know it’s true. If we don’t outline them, we’ll end up with confusion, missed expectations, and project problems.
List out all the assumptions you’ve thought about that will affect the work we do or the outcomes of that work.
Examples include time constraints, client delivering by deadlines, and things that might feel ‘obvious’ — i.e. who owns the code at the end of the project. Bullet points are fine.
List the exclusions for this project.
Exclusions allow us to itemise things that we won’t deliver. This helps us avoid awkward “But weren’t you going to…” questions or requests. Really, it’s about setting expectations and avoiding any miscommunication around the work we have planned. Bullet points are fine.
With most of the details on the actual project in place, there’s just a bit of administrative work left to include. This is where we outline and detail any missing information that’s key to keeping our team and the client happy. This means things like:
- Payment: How and when will payments be made? Will it be by milestone and deliverable? Or on a set schedule? What happens if deadlines get missed (on both sides) or scope increases?
- Reporting: Who’s responsible for signing off on deliverables, approving scope changes/adjustments, and handling support and maintenance?
- Terms: What other requirements and standards need to be agreed upon?
Remember, the scope of work is all about clarity and detail. The more you give, the better the result.
Outline any further points worth noting.