Statement of work. As straightforward as it sounds, getting one right is no easy task. But nothing is more fundamental to the success of a project. If the statement of work is too vague, too broad or too generic, it can leave room for various interpretations, which can lead to trouble down the road. That's true for an internal project, and it's 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 M. Greenberg, an attorney in the technology, media and telecommunications practice group at Greenberg Traurig LLP 's New York office.
To get your project right the first time, follow these guidelines for writing an effective statement of work, or SOW, as it's affectionately called.
Understand what a SOW is.
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 USA in Westboro, Mass. "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 chief operating officer at a software development company, says a good one includes these things:
- 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 in Boston. "And the more precise you can make it, the more quantitative, the better."
Define success.
A statement of work should clarify for all parties what constitutes success or failure, says Melise R. Blakeslee, an attorney in the intellectual property, media and technology transactions group at McDermott Will & Emery LLP in Washington.
"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 Inc. in Newtown Square, Pa., 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 saying, "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 F. Connelly Chair in management at the College of Commerce and Finance at Villanova University in Villanova, Pa.
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, Blakeslee says. 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 writes, "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. And 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."
Pratt is a Computerworld contributing writer in Waltham, Mass. Contact her at marykpratt@verizon.net.