HOW TO MAKE A STATEMENT OF WORK (SOW) FOR A DIGITAL PRODUCT

As a digital development company, we have worked with a lot of different companies on a lot of very different projects. What we have noticed over the years, is that the companies who attempted to put together a complete and detailed Statement of Work (also referred to as “Scope of Work” – SoW) for their products – were the ones that were the most successful.

The SoW is a critical starting point for not just development companies such as ScreamingBox, but also for internal development teams. When we get a detailed and well thought out SoW, we can generate more accurate estimations and organize better and more complete teams that make for high-quality development that is more cost effective.

Between the planning and execution, a lot of thought goes into building a digital product. Therefore, having a SoW is essential. While you trust your team of developers, you want to tie up every loose end, removing every chance of mistakes. A project manager’s SoW is one of the most potent weapons in his arsenal—it can also be the worst.

A well-planned SoW will ensure the project goes smoothly, saving management a lot of time and effort. A simple mistake in a SoW may cause a catastrophe—even one as bad as starting over, or wasting development time and delaying the delivery date.

We have received SoW’s from all different management levels within companies. Start-up the SoW might be written by one of the founders or the CTO. In SMB’s they might be written at the executive level, or at the project management level. We have gotten many SoW’s, ranging from a half page paragraph describing the project concept, to a super detailed SoW laying out every feature requirement, data transfer steps, back-end structure outline and UX layout and wireframes.

We have put this article together, to serve as a SoW guide for executive level management and project managers to understand what it takes to create a great SoW, and therefore help them create a Scope of Work that will help make their product concepts come to life easily and cost effectively.

What Is SoW and Why Is It Important?

SoW (Scope of Work or Statement of Work) is an agreement between the two parties involved in building a project. One party could be an internal team, a service provider, an agency or contractor, and the other party would be a client, the actual owner of the project, or the company management. Essentially, a SoW is a document covering the working agreement between these two parties to ensure a successful project execution. The project manager is responsible for building and using the SoW and they ensure expectations are spelled out.

As the project manager, the SoW is the tool for ensuring everyone understands and agrees with their allocated roles and the project objectives. Thus, a well-detailed SoW should include the project objectives, milestones, individual tasks, and maybe payment terms if tied to milestones or other criteria. A SoW differs from a project proposal, although both have one thing in common: building the project. However, while the former is used when you’re working with outside teams, the latter helps you secure buy-ins for the project.

What Should an Effective SoW Entail?

Now that you understand what a SoW is and its importance , you can start making one. An effective SoW should have:

● The objectives of the project, including your problem statement. This is where you list out the issue(s) you’re facing and what you intend to achieve with the project.

● Product details and feature sets. Usually this is provided during a UX/UI phase, but for some SoW and projects, this phase might be one requirement of the SoW.

● Next are the milestones or schedules, including the projects’ start and end dates. Then, include what major phases or milestones you’ll be able to measure progress by.

● Specify the individual tasks—what needs to be done to execute the project.

● Your deliverables, including what you need at the end of the project: a .PSD file or usable code?

● Current project resources. This could be prototypes, established databases, older versions of the product, graphics, development environments, servers, security tools, etc.

● Define the requirements, terms, and conditions that weren’t spelled out or appear vague in the initial agreement.

● Finally, add your payment information, including how much the project will cost and how you’ll pay your project team. Some SoW’s are developed in order to get estimates and budgeting numbers, and in such situations define the max budget limit if known.

How to Make a SoW for a Digital Product

Now that you know what a SoW is, its importance, and what should be in it; you are ready to make one. Follow these simple steps below to create an effective SoW for the project.

Step 1: Write the Introduction

The introduction is the first thing to write before entering the project specifics. Here, you’re specifying the type of work to be done, which, in this case, is building a digital product. Include the business model for the product. How is it expected to generate revenue, how will it be sold and marketed and who is the target market. It is also important to discuss how the users will apply the product to their lives and/or workflows.

Then, you’ll indicate the parties involved and the formal agreements you can use the SoW to create later. For example, those agreements may include a formal contract or a standing offer, which is an agreement to buy the product at a price for a time.

Step 2: State the Problem and Objectives

The next step is to explain the project, its context, and its expected outcomes – what business objectives it’ll solve. The next step is to explain the project, its context, and its expected outcomes—what specific business objectives it’ll solve. Again, you don’t need to go into the details here because you do that later in the SoW. Thus, keep this part simple, summarized, and very easy to understand.

Step 3: Outline the Work

Next, you’ll briefly outline the work you need to do to build the digital product. Let’s emphasize “briefly” because you will still get to the stage of putting in the specific tasks and requirements. You may also include the technical requirements used—the software or hardware you used in building the product. You can provide this information using a simple explanation or list them as bullet points.

Step 4: List the Tasks

This section is the task management aspect, a vital part of digital product building—or any other project. It is especially important when working with an outside team; you’ll be dividing labor here. At this stage, you’ll break down your large scope into more granular actions to ensure everyone agrees with the work. Tasks differ from deliverables; you need to write each task down and explain the specific action to be taken.

Spare no information here, and ensure it is as detailed as possible, especially since you’re building a digital product. List out everything concerning the product, including, for example, a form that will be part of the product; you will need to list out what fields will be included and where you’ll send the form.

It is this section where you really have to think about control, responsibility and involvement. Example: You are hiring a development company to develop a mobile app for your sales and marketing company. You can define that your executive team will handle the marketing content that will be used for the app store, but that the development company will be responsible for getting the app uploaded and approved to the store.

Step 5: The Schedule

The next step is to list the project schedule and milestones – this is more than just listing the start and end dates. At this stage, you’re listing when, where, and how the work will be done and by whom. The schedule section of the SoW should include how long the project will take and the phases. It’ll also cover where you will carry out the project and the required resources for both parties (client and contractor).

Part of this may be unknown, such as you are using the SoW to get a development proposal, and you don’t know the development time frame. You may be able to list some business target dates you would like to achieve though, and that would be helpful.

Step 6: The Deliverables

At this stage, you’ll be listing what you expect to get at the end of the product-building project. The expected outcomes are the natural conclusions from the task list you created earlier. However, you may want to combine the deliverables and schedule for a better overall picture of the project flow most of the time. This gives you an accurate picture of when you should finish each deliverable and what depends on it.

Step 7: Create the Adoption Plan

Most SoWs don’t include this part, but it is as valuable as the other sections. The project’s adoption plan details the process for how you will put the deliverables in place. This is important so that the developments can user stand the distribution and adoption requirements since they may affect the development direction.

Step 8: Managing the Project

You’re almost done with the SoW, but there’s still some administrative work to include. First, at the project management stage, you’ll outline and explain any little but important missing information in the contract.

These details include how and when the client will make the payment and who will be responsible for reporting. You’ll also include other standards and requirements that need to be agreed upon, including security requirements, exclusions, and assumptions.

Step 9: Sign-Off

The last section of the SoW covers how you’ll accept the project deliverables, including who will authorize, review, and sign off on them. It should also contain some criteria and guiding instructions on what you expect and accept.

Ensure everyone involved in the project agrees with this upfront to prevent problems later. There can’t be too many details in an SOW; the more details, the better the result.

Conclusion

A SoW is an important tool to have. Whether building a product from scratch or redesigning it. Creating an effective SoW is like sharpening an ax well before cutting down a tree; it makes things happen quicker and more accurately. As you create the SoW, ensure you’re as detailed but brief as possible. Avoid going overboard. Also, write it at the early stages of the project, ask for help, and clearly state what the project doesn’t include.

Also, once you go to your development team, ask them for feedback and to see if any of the requirements pose technical challenges and will be extremely costly to develop. This feedback will then help you decide on whether to adjust the SoW requirements and scope, or add anything you may have overlooked.