Scope of work
A Scope of Work approach

A Scope of Work (“SoW”) approach is a project management document that regulates the cooperation between two companies. Usually, it is part of the contract or a service agreement.

It defines and clarifies every aspect of the project, including schedules, terms, work standards, payment method, as well as acceptance criteria for deliveries.  Many samples are freely available.

As a matter of fact, a high-quality SoW should cover every critical point of the work. So, what exactly should this document include?

1. Purpose

Before starting a project, every party must make sure that they understand methodology, objectives, deadlines, payment, responsibilities, and requirements.

A Scope of Works (“SoW”) approach in software development and support is a business document that covers every nuance of the agreement between XX as the client and the service provider to boost cooperation and minimize the chance of conflict or confusion between organizations. 

Aside from the scope of work, schedule, project’s objectives, standards, and success definitions, the SoW document may include other miscellaneous information, like security considerations, hardware and software restrictions, post-project support, penalties for late or poor-quality deliveries, and clauses to terminate the contract early.

Although SoW is usually considered more of a business document than a legal one, you shouldn’t underestimate its importance because it defines the full extent of your collaboration with an outsourcing company. Therefore, SoW should be explicit, clear, and written in an understandable language, leaving as little to interpretation as possible.

As a rule of thumb, the more information Statement of Work for software development contains, the more chances the customer’s needs will be met in the most time- and cost-efficient manner. Formats may vary based on vendor, but the majority of SoWs adhere to proven guidelines where content is divided into the following sections.

2. Who should write the SoW?

It’s difficult to find a writer qualified enough to understand the specificities of your contract. However, the service provider responsible for the project at XX is far more likely to compile a quality document promptly to give to the client.

3. Introduction

Start by stating an objective and a list of parties involved in the project. It’s important to indicate the date and location of drafting the document to avoid concerns about its credibility and legitimacy.

4. Purpose (What is it?)

This section must state the goals of the project and the objectives that XX wants to accomplish. A clear understanding of its expectations will increase the effectiveness of collaboration with your organisation.

5. Scope of work and description (What is going to be done?)

Given the complexity of this chapter of the SoW for software development, it’s more efficient to outline the project into several steps, like “project discovery phase”, “application development,” and “testing phase.” Then, these steps should be divided into extensive and comprehensive tasks, which you may want to further break into phases if the complexity of the product calls for it.

Upon reviewing, make sure that the Scope and Description section identifies the following information:

  • General budget overview.
  • Expected tasks and deliverables.
  • The individual tasks.
  • Phases of certain tasks.
  • Responsibilities and roles of each party, including figures accountable for configurations and software input, supplied information, security, as well as approval of system maintenance and performance.
  • Appointed project managers, representatives of each organization, and other key figures.
  • People with an authority to accept the completed product provided by a software developer.
  • Conditions about possible force majeure or issues in functionality implementation.
  • Specifications and limitations for subcontracting development, and the company responsible for the quality of subcontractor’s work.
  • Requirements or certifications for developers or sub-contractors.

6. Location of Operations (Where will it be done?)

When contracting with a service provider for software development, you can gain access to a worldwide pool of talented and vetted engineers. It means that some vendors can work for you from various countries with different jurisdictions. Therefore, it is essential to list facilities where the programmers operate from and time-zones under which they operate. If a customer wants to have real-life meetups with a vendor’s representatives, the SoW must specify the locations where meetings can take place.

7. Standards (How will it be done?)

If the Scope and Description sections are all about the nature of the project, this part of SoW is all about the process of operations, which includes the following information:

  • Technological limitations (coding languages and platforms).
  • Industry standards software dev should stick to.
  • CI/CD pipeline diagram.
  • Information about the testing of the product, involved parties, and necessary hardware or software.
  • List of accepted devices, screen resolutions, and browsers for the testing process.
  • Means and tools for communication between the client and the outsourcing vendor.
  • Procedures for minor and major order changes.
  • Penalties for late deliveries and bonuses for extra labour.

8. Deadlines and Schedule (When is it going to be done?)

I think you would agree that development shouldn’t be rushed. However, having a set of deadlines and tight timetables can improve the product’s quality and give the project more flexibility. Having a thorough schedule helps to keep the project moving forward with some room left for trial-and-error or potential issues during development.

Therefore, every SoW must state a start date and timeline for the project. To streamline the prokect, both sides need to have a detailed list of tasks and milestones with set dates of deliveries. Furthermore, the documentation should set a timeline for routine reviews of performance.

This section should also specify the contract’s duration, which measures by date or by a specific period. Additionally, this section may include the maximum weekly or monthly payable operating hours of the service provider.

9. Monitoring (How to control it?)

As mentioned above, the SoW should state deadlines for performance reviews if a company wants some control of the development. The software development vendor must adhere to his responsibilities and give regular reports.

Companies can also implement management software. Some of the most popular applications for supervising and reviewing operations are Jira, Basecamp, Asana, although all tools and applications to be used should be clearly stated in the agreement.

10. Acceptance Criteria (How will we know the job is done?)

The document must clearly define success and failure, which means it should cover what criteria constitute successfully completed tasks and deliverables the client should accept and pay for. Also, it should include circumstances under which the company can terminate the agreement without paying the full price. A detailed description of the features’ acceptance criteria will also help to cover the risks of change requests.

Additionally, Statement of Work should include an attachment with information about the process of submission, as well as people authorized to review and accept deliverables.

11. Contract Mode and Payment Model (What does the payment process look like?)

After reaching an agreement about preferred payment terms, companies must outline them in as much detail as possible. 

In software support outsourcing, there are usually two price models that vary based on the scope of your project:

11.1          Fixed-coast contracts are best suited for companies that have a detailed plan, strict delivery dates, and defined requirements. This model also fits smaller projects. With this type of contract, the vendor usually takes full responsibility for the results, but your project compromises flexibility. Payment is typically set up by schedule, or after reaching certain milestones or deliverables, or it can be conducted as a single-sum when the job’s done.

11.2          Dedicated cost-plus model is appropriate for long-term or complex projects with a non-identified scope of work, which can involve rapid changes during development. It’s a more efficient type of payment for both parties because it allows for shifter requirements adjustment, feature replacement, and allows the customer to effectively manage and monitor an engineering team. The client typically makes monthly payments based on hours programming team devotes to work.

12. Miscellaneous (What else should we clarify?)

Are there some questions left that you find useful for your collaboration that doesn’t suit the categories mentioned above? Some of these questions can be specific to your project and can include:

  • Questions about security regulations and standards.
  • Travel payment (in case a real-life meeting is needed).
  • Details about code ownership.
  • Composition of the engineering crew and program evaluation team.
  • Post-completion support, communication with clients, and further testing.
  • Final admin duties (how and where the document will be signed).
  • Estimated effort level.
  • Liability cap and warranties.
  • Timeframe for applying changes in the engineering team composition.