As straightforward as it sounds, getting a statement of work (SOW) right is no easy task. But nothing is more fundamental to the success of a project. If the statement of work is too vague, broad or generic, it can leave room for various interpretations, which will lead to trouble down the road. It’s true for an internal project, and doubly true when there are vendors involved.

“The failure to properly execute a statement of work is often the reason parties end up in a dispute,” says David Greenberg, an attorney in the technology, media and telecommunications practice group at Greenberg Traurig.

To get your project right the first time, follow these guidelines for writing an effective SOW.

Understand what a SOW is.

More management tips

Top 11 essential tips for IT managers

Our most popular tutorials and management guides to help IT professionals fix technology products and manage their careers.

A SOW defines the scope of work required and the time in which it’s to be performed. “It’s the cornerstone to an agreement,” says Nick Scafidi, IT procurement manager at energy supplier National Grid US. “It sets expectations, deliverables, what’s acceptable, the price, the pricing schedule. Without that, it’s like saying to a contractor, 'build me a house,’ without telling him when, what kind or how big.”


Know what to include.

Bruce Russell, who signed off on numerous SOWs when he was COO at a software development company, says a good one includes:

  • – Major deliverables and when they’re expected.
  • – The tasks that support the deliverables, as well as which side – the hiring company or the service provider – will perform those tasks.
  • – The project’s governance process, along with how often governing committees will meet.
  • – What resources are required for the project, what facilities will be used and whose equipment will be needed, as well as testing requirements.
  • – Who will pay which costs and when.

“The statement of work pulls together all the elements at the beginning,” says Russell, now an executive professor at Northeastern University’s College of Business. “The more precise you can make it, the more quantitative, the better.”

Define success.

A SOW should clarify for all parties what constitutes success or failure, says Melise Blakeslee, an attorney in the intellectual property, media and technology transactions group at McDermott Will & Emery.

“You have to adequately describe what the work is and the criteria for how you both will agree that something is successfully completed,” says Ruth Anne Guerrero, standards manager at Project Management Institute and a former IT project manager.

For example, she says, if you expect your vendor to develop user requirements, your SOW should state that the vendor must interview specific user groups and have them approve the requirements before the job is considered done. That defines success better than simply writing, ‘vendor will produce user requirements’.

The definition of success depends on the project, Guerrero says. IT project leaders need to specify whether successful implementation is defined by speed, response time, ease of use or all three and then quantify them in the SOW.

Don’t forget a timetable.

Successful implementations can’t be defined by the system’s speed or responsiveness alone, though. After all, what good is a great application if it takes a decade to build? That’s why a SOW needs to include time elements. Guerrero recommends using language that allows some flexibility rather than a fixed date on the calendar. A SOW should specify, for instance, that the end-user requirements are due two months after the contract is signed – wording that still gets the project moving forward while accommodating potential problems such as a delay in signing the contract.

A SOW should also designate specific times for formal reviews, so all involved can confirm that they’re on track, says Matt Liberatore, a professor in the department of decision and information technologies and the John Connelly Chair in management at the College of Commerce and Finance at Villanova University.

Tie payment to milestones.

Another key component to keeping work on track is setting specific milestones in the SOW and tying payment to successful completion, Blakeslee says.

When Scafidi writes a SOW, he specifies that payments to vendors are made upon acceptance of key deliverables. He also notes that he will retain a portion of the pay until the vendor proves that all the deliverables work together.

Use language everyone can understand.

The IT department and its vendors aren’t the only ones using the SOW, Blakeslee says. So don’t write it as if only IT people will see it. “It should be understandable to end users, service providers, management and to a judge,” she says.

Be specific.

Although numerous parties have to understand the statement of work, be precise in describing the project’s scope and requirements, says Blakeslee. She has seen documents that set vague goals, such as “will work to the best of their abilities”. She compares that to a homeowner hiring a painter with instructions to “use the best effort possible”.

“If the painter does that but paints your house purple instead of white, then you wouldn't have a claim against him,” she says.

Scafidi has taken such advice to heart. Instead of saying a task will take “a reasonable amount of time”, Scafidi says. “The specified task will take no more than four hours. Attorneys feel good when we have a clear, unambiguous definition on things like that,” he says.

Remember postproduction needs.

Guerrero recommends including postproduction requirements in the SOW. Spell out the testing and support you’ll need from the vendor, she says. If you plan to have internal folks support the system after installation, the SOW should address whether the vendor will train your staff. Such language, she says, guarantees that the vendor doesn’t “just deliver the system and walk away”.

Collaboration is key to a statement of work

The task of writing a statement of work could fall to various players on an IT project. The best approach is for IT leaders to draft it and then work with the vendor to tweak it, says Nick Scafidi, IT procurement manager at National Grid US. Scafidi works with key internal stakeholders, including lawyers, to draft the SOW. The process can take several weeks but helps guarantee that user requirements, technical deliverables and project goals are understood and clearly articulated.

Scafidi then sends the draft to the service provider for review and revisions, often working with the vendor team in person to fine-tune the draft. That way, he says, “you really feel like it's a team effort”.

Pratt is a Computerworld US contributing writer. Contact her at [email protected]