So you have finally hired an outstanding offshore vendor with a dedicated software development team? Here’s the thing; no matter how impressive the vendor's record is or how good the recommendations you got from a past client they’ve worked with, there’s still the need for your new "partner" to understand your expectations before jumping on your project.

It’s probably the only way you are going to get what you want from the relationship. With that said, bringing something called a “statement of work” (SOW) might just be what you need if you aim at building a successful software development collaboration. If you want to know more, this article contains everything you need to know about SOWs and the crucial role it plays when developing software projects with the help of an outsourcing company.

Purpose of Statement of Work (SOW)

If you intend to go into a business relationship with an outsourcing company, a statement of work (SOW) is a document that ensures the entire aspect of the contract between you both is devoid of any vagueness or ambiguities. In short, the document helps to clarify each party's responsibility so that relationship can be a productive one. 

Therefore, it isn't a document that only makes you get what you want as a client; it also ensures you will not be unrealistic with demands just because you are the bankroller. 

Furthermore, an SOW makes sure there's no misrepresentation of what the outsourcing company has to deliver. Altogether, your software product will hit the market on time so that you can get returns for all your investments. 

A well-created SOW should ideally cover every "nooks and cranny" of the agreement between a client and the vendor, thereby promoting productivity and minimizing conflict between involved parties. Many companies have handled their  "statements of work” as a casual document, which has cost them dearly. The document will define the length and breadth of your collaboration with the vendor, so it’s best not to underestimate its importance. Aside from covering all aspects of the project, a well-written SOW should be delivered in a clear language that both parties can completely understand. This move leaves very little or no room for personal interpretation. 

What's included in the SOW for software development projects?

Before we go into details of what an SOW should include in software development projects, you may be wondering who creates or writes the "statement of work" between the vendor and client. While in some industries, the bankroller or client initiates the SOW writing and presents it to the hired company, the reverse is usually the case in the tech world. Writing the agreement is typically the vendor’s responsibility. It has become a conventional practice in the tech world because many clients may not know the ins and outs of developing a software product from idea to market. 

So, instead of looking for a person knowledgeable on contracts and also the dynamics of the software product you want to design, the vendor is more qualified to write the SOW since they are responsible for the product’s delivery. The fact that offshore companies have handled many such projects makes them understand a similar project's requirements. 

Now, let’s dive into the contents of a typical SOW. One of the rules of thumb with SOWs for software projects is that the more comprehensive the information is, the greater the chances of covering your needs as a client. While SOW formats may differ from vendor to vendor, most written SOWs are often compliant with proven guidelines, with the contents divided into these major sections. 

Introduction/Objective

The beginning or introduction should contain the objective of the business, bringing both parties together. The introduction should also list the business names of both the client and the vendor. Furthermore, you might want to ensure there's an indication of the document's drafting location. This way, the credibility and legitimacy of the document are not in doubt.

Purpose

This section addresses the "what is it" question. It must contain the goals and everything you aim at accomplishing as a client. There must be no ambiguity or vagueness here. What's more, a clear understanding of expectations is non-negotiable, as this is the only way to ensure collaborative effectiveness between both parties.

Description/Scope

Under this section, the client should look out for a breakdown of the software project, i.e., a step-by-step outline of the project's phase. This description isn't the steps of how developers will write each code. Instead, it will contain different project stages, such as the discovery phase, application development, testing of the application, debug phase, etc. Furthermore, a well-written SOW should go further in dividing the steps into tasks that groups of developers will handle. 

This section of the SOW is a bit complex, so you might want to ensure it covers a whole lot of issues. For a typical software development project, try to ensure the scope section covers the following major information.

• Budget
• Deliverables
• Development phase (testing phase, debugging, etc.)
• Individual task
• Responsibility of client and vendor
• Supplied info
• Security
• Maintenance
• Appointed project overseers
• Each organization's representative 
• Milestones 
• Possibility of sub-vendor input

Software development location

One of the advantages of outsourcing software development is access to a global pool of excellent developers. Altogether, your software developers will work from any location in the world. If you know where the coders work, you'll have an idea of their time zones as well. Whether you are remotely managing or using a middle-man project manager, you can fix meetings during convenient periods to pass crucial information across. If there will ever be the need for an in-person meeting, perhaps with representatives, the SOW must contain the possible locations where discussions about the project can occur.

Standards 

This crucial part of the SOW clarifies the technical execution of the project. The information here should include:

• The programming language developers must use and stick to
• Integration diagram (How finished sections becomes a whole)
• Hardware and software information
• Equipment list
• Protocol for major and minor changes in the development process
• Modalities and channels of communication
• Penalties for the late achievement of milestones
• Extra labor bonus

Deadlines/Schedules

While you don't want your vendor to deliver a poor job because there isn't enough time for developers to do their thing, setting deadlines or timetables can help promote quality. Think of it this way, working towards a specific target in mind can help promote out-of-the-box thinking.  Sometimes, having excess time can cause laxity among developers, which may not be good for the project. Therefore, SOWs should have timelines, i.e., a start and finish time. If the project is massive, you’ll do well to set milestone timelines. Furthermore, the SOW should also have timelines for periodic performance review.

Monitoring 

Another thing clients should not do is to assume your vendor is doing their bit. You'll do well to ensure your vendor adds a “report check-in” period. For example, every week or every other week report. Some outsourcing companies have facilities in place that clients or project managers can use to remotely monitor the project's progress in real-time. Some have video-monitoring systems that help ensure the job isn't pawned off to another developer somewhere around the world. Altogether, a company software development vendor should put in place a project monitoring protocol, which must be in the SOW. 

Acceptance criteria 

Another important aspect of software development is putting in place specific yardsticks to measure success or failure. Determining if a vendor performed less or up to expectations should not be prone to individual bias. Therefore, the SOW should have a detailed description of the acceptance criteria for the software's features. Furthermore, the document should have circumstances under which the client can terminate the agreement due to non-satisfactory performance. 

Payment model 

For software development outsourcing, there are usually two payment models your vendor may adopt in the SOW, and they both depend on the project's scope or type.

Fixed payment: your vendor will likely adopt this method if your project has a detailed and precise plan. A precise and detailed plan is standard with short-term projects. This is normal because small projects are less complex with little or no reason for frequent changes. What’s more, the vendor will likely demand a single, one-time upfront payment. 

Periodic or monthly payment: this payment type comes into play with long-term, complex software projects. While the end goal may be clear, long-term projects may not have a precise execution plan from start to finish. That's because the work may be subject to many changes along the way. Therefore, payments could be monthly or in milestones.

Miscellaneous

This section covers any information that doesn't directly fit into the categories above. Based on the uniqueness of your project, this section can include the following.

• Cost of travel (if an in-person meeting is needed)
• Code ownership discussion
• Continuous support after project completion.
• Liability limits

We hope you found this article useful. Here at Cloud Employee, we assist companies looking to hire dedicated offshore developers across many technologies. Talk to us, learn more how Cloud Employee works, or see our Developer Pricing Guide.