We’ve recently made our language clearer around what a Project Brief and a Scope of Work are. In product design, as well as many other fields such as user experience design, mechanical engineering, and website design, both terms are used frequently. It’s important to understand what they both mean. While they can be interchangeable, depending on the use, they are in-fact different, and we use them as such. Each one has a place and while similar, if effective at a different part of the project. So, I’d like to share a bit about both of these terms and explain how we use them, and when. Here’s a short description of what each one is.
When starting a project, a Project Brief is one of the first things that needs to be created. Often these are called Scope of Works as well, which can be misleading. I’ve learned the hard way when not clarifying this to clients. A Project Brief can contain any amount of information and can fill several roles. We use ours partly as a new client intake form. It allows us to gather all the information we need to create a Scope of Work and then a proposal.
Project Briefs are typically word only documents. However, you can always attach images or sketches with it for reference. They define what the project is, any special requirements, and with ours, gives us an understanding of the entire project as a whole from the clients perspective. This is not what we use to define the project in terms of a proposal, however, as there are often additional details we need defined for that.
Scope of Work
One of our posts, The 4 Things Your Scope of Work Should Have, goes over some of the things a SOW should have. But, that didn’t cover everything. We use a Scope of Work as our outline for the project. It’s something that we include in all our proposals, even for the smallest project. They include technical details and requirements and are typically not as wordy as a project brief. They are succinct, definitive, and leave no room for error or interpretation. That is part of their purpose, to provide absolutely clarity on a project as much as possible.
They will contain a list of all deliverables and outline the what, when and how of those deliverables. It’s important to remember that the SOW is the end document. To get there may take a lot of information gathering before it can be created. A Project Brief is something created in the beginning. It is made not necessarily by people who understand the technical details required to make the project happen, either. SOW can change, but usually only with a cost if the project has already started. They are often the cornerstone on which the proposal is built and a guide to ensure the project is being completed properly.
By using these two components, we can ensure greater project success and an easier process for all parties involved. I’ve found over my years of product design that having both creates better clarity through the entire start of the project. It also helps ensure the project is managed correctly from all sides. Information gathering through a Project Brief makes for creating better and clearer Scope of Work for a project. This in turn helps to keep things on track and on budget.