A Scope of Work or SOW for a website, web-app, mobile-app, application, or software-as-a-service (SaaS) has a few specific aspects which we’re coving in today’s article.
These are the:
- Contract
- Creative brief
- Information architecture (IA)
- Project flows or wireframes
- Project plan
The Contract
The contract questions such as:
- Who’s paying for what?
- What are the milestones?
- What are you responsible for?
- What is your client responsible for?
- When are payments required?
- What happens if you don’t do your work?
- What happens if they don’t pay you or pay you on time?
- What happens if they aren’t happy with your work?
- What is the process to ensure they are happy with work as you go along?
- What is the process to build or complete the projects?
- What happens if someone tries to sue the other group?
- What happens if you or the client need to change the scope of work?
- What happens if the timelines or deadlines aren’t met?
- What happens if you get killed halfway through the project? (Although it does not generally cover what happens if you kill your client halfway through)
To name a few things.
There’s so much stuff that goes into a contract, and if you’re not familiar with how to do a website contract or an application contract, there’s a whole section on how to do this in the BrainLeaf book. I highly, highly recommend you take a look at it if you have questions.
The Creative Brief
The creative brief, which you can take a look at here, is a document that has similarities across different kinds of projects, but generally has or discusses:
- A brand statement
- An overview of the project objects.
- Challenges that the project will resolve.
- Direct & indirect competitors
- What is your target market and how do you identify those people?
- Why you’re doing the project.
- Project goals
- If the project is a marketing project, it will also have things like advertising mediums, tone, and messaging.
Here is a great article on what goes into a full creative brief.
It is very important to clarify a muddy point that I have heard a number of times over the years. The Creative Brief is for YOU as well as the client. It is so that YOUR TEAM understands how this project needs to be completed.
It also accomplishes the goals of clarifying communications between the client and the team. It establishes key aspects of what is being done and why, but at the end of the day it is reviewed time and time again by the build team to ensure that key points in this document are being addressed.
Information Architecture
The information architecture (IA) is a page-by-page and/or feature-by-feature, section-by-section, element-by-element description of everything that goes into the application.
For each item the IA should generally list the number hours for each task insofar as design, development, management, testing, and content production as well as a variety of other tasks. Each hour estimate should be broken down granularly in order to produce an accurate estimate.
If you take the time to write out your full, in-depth information architecture, the project will generally move very smoothly. This is because answers will have been provided up front and as you progress through the project you will be building, not waiting for questions to be answered.
A great analogy for this is that of building a house. No builder would even consider starting on a house without a set of blueprints. Why would you start building an application without the same kind of document? But for anyone who has ever built a house, you know that there are a lot more decisions that have to be made other than what goes into the blueprints.
Example questions that pop up AFTER the blueprints are done on a house:
- What color are the tiles on the floor?
- What kind of knobs do you want added to cabinets?
- What color will the walls be?
- How about those sconces in the hallway? Do you want the chrome or brushed nickel ones?
- Do you want the metal, wood, laminate, or stone counters in the kitchen? And once you choose that, what kind of sink do you want? Did you know that sink is going to cost a lot more in plumbing costs?
You get the idea.
An ounce of prevention is worth a pound of cure.
For each of these questions, some worker has to stop, ask the question, make a trip to Lowes, Home Depot, or another store, and it’s going to cost you more time and more money. If you knew the answers to all these questions before you got started your costs and timeline could be substantially lower.
Exactly the same thing applies to application and web development!
It’s a critical, critical piece of your planning, and it’s one of the biggest things, in my opinion, that most teams don’t do well enough.
See how BrainLeaf helps you build your information architecture.
Project Flows and/or Wireframes
The project flows are wireframes or general mock-ups. It depends on what you’re building and the system’s complexity as to whether you’re doing just wireframes or full on mockups. Some teams don’t consider this aspect a part of the planning documents as they come after the other items are done, but if you are building a large project, the design phase is sometimes a much smaller aspect than the development potion.
No matter when you do this step, it is a critical step in the process, and having the wireframes along with that information architecture makes the project so smooth when you get into the development of the system.
Project Plan
Once you’ve got your information architecture with all project hours, the wireframes showing how everything’s going to flow, the creative brief that tells you what questions you’re answering and what problem you’re solving, and as many questions as possible are answered, then you can put together a thorough project plan.
The project plan document shows you and your client:
- Who’s doing what.
- When they’re doing it.
- What things are going to get done at what time.
- How much money each thing is going to cost.
Once you have all these questions answered, then you can put together a thorough Gantt chart as well as a backlog of tasks and initial sprint. Using these, you can prepare your burndown charts.
If you don’t know what a burndown chart is, be sure to take a look at the Atlassian Agile Guide online. It’s a great resource for agile development method education.
Now You’re Ready To Start!
The problem that so, so many teams have is that they don’t do the right amount of planning before getting started on build. This causes no end to trouble for both them as well as their clients.
“A well-planned project is a smooth project.”
Jason Long
After, and only after, you have these five documents thoroughly written, reviewed with both your team and your client, and approved by everyone, then you can get started on the design & development of your project.
If you need more help with this, ask some questions in the comments. I’m happy to help you guys out. If you’re looking for a way to develop that information architecture, please take a look at BrainLeaf!
