Whenever you work with people outside your organization, misunderstandings and assumptions can derail your project. This is why the scope of work (or SOW) is a very important document for project managers. A SOW not only defines exactly what needs to be done on a project, it also pulls together everything from work details to schedules, conditions and expected results. But it’s also to protect you from the dreaded scope creep where features, additions, and nice-to-haves push your project beyond its original plans.
Think of this as a map that can guide you through nearly any project you can think of, from redesigning a website to building new apps and features.
Before getting into the details of the project, it’s important to get some basic information. What kind of work is being done? Is it a service provided or a product being built? Who are the stakeholders? The
introduction can also describe the types of formal contracts that can later be created using the SOW.
A contract to purchase a service or product at a specified price for a specified period of time.
A more formal and legally binding contract based on mutually agreed details.
Project Overview and Objectives
Now that the basics are in place, let’s dive into the reason for this project. Start by describing your project, the circumstances surrounding it, the business goal you are trying to solve, or the expected result. Keep it intentionally superficial and easy to understand, as it will be covered in more detail later in the SOW. As Paul Cannon of Salesforce explains:
“If colleagues and family members cannot explain what scope is and what success looks like, this basic section needs to be updated until it is clear.”
Scope of work
The next section describes what you need to do to complete your project. Again, we’ll keep this at a higher level (to establish specific tasks and requirements in the next section). This can be done as a list of steps or as a brief description.
For example, let’s say you ask an agency to redesign your website. A workspace can include steps such as designing a new website mockup or developing a new website design. In the next section, we’ll break these down into actual tasks such as: B. “Prototype a new landing page design in InVision.”
In some cases, the scope section may also include technical requirements such as the hardware and software used.
Task management is a very important part of any project, but especially when working with external teams. Dividing a larger scope into more detailed actions is the best way to make sure everyone is on the same page about what to do.
The point to remember here is that tasks are deliverables. (that is, what you get) is not. Those are actions that need to be taken. Therefore, each task you write down should describe a specific action that needs to be taken (for example, “Redesign your landing page” versus “. “Landing Page” only)
For software projects, special attention should be paid to details. Think about features and list everything the software does, down to the fields it contains and where the forms are submitted.
It’s also a good idea to divide your tasks into phases.
Therefore, in a website redesign project, the SOW can include a “kick-off” phase full of research and planning tasks. A “design” phase that includes prototyping and wireframe pages. The “build” phase of design development and implementation. Then comes the “testing” phase, where we do usability testing and look for bugs.
The SOW project schedule is more than just start and finish dates. It’s your chance to outline when, where, how and by whom work should be done. The main questions that should be answered in this section of the SOW are:
What are the project durations and phases/milestones?
Time is often one of the more important determining factors when it comes to project pricing.
Does the project have a fixed deadline? Will it take place over a period of time (eg “6 months”)? Or do you have an end date that matches another event? B. Changes in government regulations (e.g. GDPR) impacting business models?
This is often difficult in an agile enterprise. You may be able to estimate a schedule, but it’s repetitive, so picking a date on your calendar isn’t easy.
Instead, try to think outside the box and add structure to your project while maintaining flexibility in rotation and adaptation. One way to do this is to create a timeline for the first phases or milestones and re-evaluate and refine his SOW over time upon completion.
SOWs cannot contain unlimited project plans anyway. If you want to stay more flexible, instead consider setting a maximum amount of time that can be spent without approval/notification.
It’s time to get brass nails. In the “project deliverables” section of the statement of work, list exactly what you expect at the end of the project. These are the natural conclusions from the task list already compiled above.
Coded, Fully Functional Landing Page
Google Analytics Settings and Tracking Metrics
Redesigned Ecommerce Page Templates
Often combine results and schedules to determine when each deliverable should be received You may want to know exactly What is ready and depends on it. This gives you a clearer picture of your project flow and helps you identify where bottlenecks might occur.
This is something that 90% of SOWs omit, but it’s worth including. Implementation planning is the process of how the results will be implemented. Whether migrating a new website to an old domain or introducing functionality to an existing app.
You have accepted the value of the project. Ultimately it’s your responsibility to lead the rollout at your company, but why not hire an expert to help?
With most of the details on the actual project in place, there’s just a bit of administrative work left to include in your SOW. This is where you outline and detail any missing information that’s key to keeping you and the other party happy. This means things like:
When and how will payments be made? Will they be available for shipment after milestones or on a fixed schedule? Wire transfer or ACH? What happens if I miss a deadline or have an expanded range?
Who is responsible for accepting deliverables, approving scope changes/adjustments, and handling support and maintenance?
What other requirements and criteria must be agreed upon? Could be a security requirement. Excluded (that is, not included). Or assumptions (i.e. who owns the code at the end of the project).
Success Criteria and Sign-off
Finally, the final section of the SOW describes how the project’s deliverables will be adopted. That means who approves them and how the deliverables are validated and approved. It should also provide guidance and standards as to what constitutes “acceptable” work.
While it may not seem necessary to make arrangements in advance, it helps reduce the potential for serious headaches later if you receive something unexpected. SOWs are all about clarity and detail. don’t forget to be The more you give, the better you get.
Once that’s done, just a few signatures and you’re good to go.