The Scope of Work

Your most important document
The full Scope of Work (SOW) is blueprint to the factory you're planning on building, the message you're delivering to your customers, the process of building the system, and the drawings that show what it will look and and how all the machines will fit together. It's easy to see why you need this document. But understanding the process to building it is as much an art as it is a science. 
The full scope of work consists of the following documents:
The Creative Brief
Project Contract and/or Worker Contracts
The Information Architecture
Project Flows & Wireframes
The Project Plan
Creative Brief 
A creative brief will help you understand the project objectives and help guide your planning of the project in the right direction. This document answers the following questions:
What are the goals of the project?
What problem or problems does the SaaS solve for your target markets?
Does your SaaS solve a knowledge gap, time gap, or both?
What value does the SaaS bring your target market or markets?
Why do you want to build this system?
Who will be using your SaaS? This will be paired with an in-depth description of each user profile.
Why and how will each user type use your system?
What are recommended methods of reaching your target market and why?
What is the tone and message of the project?
If the project is ongoing, what Key Performance Indicators (KPIs) will determine success of the project?
What are benchmark competitors that also deliver a similar message or provide a similar service?
What are benchmark designs from other companies or projects that you will be aiming to match in this project?
Who develops the creative brief?
A marketer or marketing team in lockstep with the SaaS stakeholders (you) are usually responsible for developing the creative brief. This MUST be done to a large part before moving forward with the project.
Contract or Contracts
You need this to make sure everyone is one the same page and to protect yourself legally in case something goes wrong. If you are hiring a team to build this or if you are paying people you hire to build this system, you still need a contract that covers the questions noted below. 
The contract answers the following questions:
What are both parties agreeing to?
Who is responsible for what on both the build team and client sides?
How much is being paid?
When are payments due?
What are specific project deliverables?
What happens if project deliverables are not met?
Who are the decision makers?
What is required of the decision makers for each company?
What is each group responsible for?
What information can and cannot be shared with other people outside of the company?
Who is responsible for the contracts?
The SaaS system leadership in tandem with an attorney will create the contracts necessary for the project. Very often, experienced development teams will have extensive contracts that cover the build of these systems. 
Information architecture
This is your blueprint. You need this to make sure everyone knows what is being built as well as how each part should function, look, and interact with other areas. This will serve as a way to sort out all the pieces to the puzzle. 
​Here is a great article on how to build a Scope of Work document for a project.​
The information architecture includes:
Features
Subfeatures
APIs
Integrated systems and future integrations
Pages
Sections
Subsections
Views
How each feature, page, section, etc. should work.
Non-functional aspects (ie. load time)
Plugins or widgets
Development platforms
Development environments
Design frameworks
Content Management System(s)
Section by section, page by page, and feature by feature times estimated by the team members building the system, double checked by other team members, discussed with all team members, and approved by the department lead. These times should be as GRANULAR AS POSSIBLE. 
PROTIP: When we estimate large projects, we try to take tasks down to as little as 15-minute increments and as large as 4-hour increments, but never longer than 4 hours.
Who builds the information architecture?
The Information Architect will write up the initial Information Architecture with help from the project stakeholders, developers, and designers. 
Project Flows & Wireframes
This set of designs show you how the system works by demonstrating how a user flows from one place to the next in the system you’re building. An intuitive UX and ease of use is key for any SaaS and mapping out how all the moving part interact is a critical step in planning.
Project flows and wireframes should include:
Designs for each page in the system. 
The connections between interactive objects on pages and views and how a user will flow from one to another.
The different states of pages and views of the project.
Who builds the project flows and wireframes?
A UX designer or design team will create the project flows and wireframes for the project. 
Remember, the more experienced your designer, the more they have messed up in the past, the more they know how not to mess it up in the future.
Project Plan
The project plan sets expectations for the timeline of the project as well as who is doing what when. It tells everyone their tasks, deadlines, milestones, dependencies, etc. You need this to make sure the project gets done on time and within the budget. Without a thorough project plan, your team will not know who is doing what when and what they are responsible or not responsible for.
What questions does the project plan answer?
The project plan answers the following questions:
Who is doing the work / on the project team?
What task or tasks is each person doing?
What are the deadlines for each person?
What are the milestones for the project (also covered in the contract)?
When will payments be due (also covered in the contract)?
What systems are being used to manage the project?
How often will regular team meetings occur?
What is expected of each person or group for the project?
What tasks have to get done before other tasks can start?
What items must get done in order to determine the project is complete?
The lack of a thorough scope of work is probably the number one reason, outside of completing the validation process that projects fail. It is also the primary reason that projects run over budget, scope creeps, and projects fail.
Who builds the project plan?
The Project Manager (PM) will build a project plan before your team can being developing, and preferably designing the project. This is often confused with an information architecture by clients, but is a completely different document. 
A SaaS project plan is a general set of timelines, tasks, responsibilities, deadlines, and expectations for all team members and stakeholders. The project manager will meet with everyone to discuss this project plan and get everyone’s consensus on it before getting started.
​