The Old Joel on Software Forum: Part 3 (of 5)

Statement of Work

Hello everyone,

I'm putting together a training presentation about Statements of Work (SOW's). In our business (web consulting) we use Statements of Work to define the initial scope of our projects, briefly describe the methodology, and describe the various things that are to be delivered (including design documentation, training workshops, and final working code and applications). In this sense, the SOW is a contract between us and our clients. We create SOW's to variying degrees of detail, from "We'll deliver X services for $Y for T time" to "We'll deliver 7 modules in 40 days for $gazillion, and along the way you'll get an 80-page Micrsoft Word design document and 12 status meetings".

In many cases, the SOW has served to help us deal with clients that want lots and lots of change requests. In other cases, it's been merely a formality.

Since many of you are consultants and/or probably have hired consultants in the past, I'd like to get a sampling of your experiences with Statements of Work.

1) How do you use SOW's in your consulting enterprise, or when you hire consultants? Do you call it a "contract" or a "Statement of Work"?

2) What type of things do you wish had been in an SOW, but weren't? What type of things do you regret putting in?

Cheers,

Anca.

Anca Mosoiu
Monday, January 12, 2004

==> 1) How do you use SOW's in your consulting enterprise, or when you hire consultants? Do you call it a "contract" or a "Statement of Work"?

Ours is called a "Work Order", and rarely, if ever, exists by itself. Every single one I've worked on references the larger "Project Specification Document" -- which I imagine is our version of your "Statement of Work".

Basically, we have a "Consulting Agreement" for the general relationship issues. This "Consulting Agreement" outlines the process whereby work is created and billed -- that being the "Work Order" for a give project. The "Work Order" is an authorization to begin work on a particular project, as described in the "Work Order's" "Project Specification Document".

==> 2) What type of things do you wish had been in an SOW, but weren't? What type of things do you regret putting in?

So far, haven't regretted anything that's there. Ours is a multi-year WorkInProgress, and evolves slowly over time, every few months adding something we wished we'd included on the previous one. Early versions were missing, in a big way,

(a) Authorization: Who, on the client side is authorized to request and approve changes. Who, on the consultant side is authorized to add those changes to the schedule.

(b) Written indication that deviates from the Work Order, and associated Project Specification Document, would cause deviations in the originally specified schedule and budget. Sounds like common sense to you and me, but you'd be amazed at what people want to change "for free".

(c) Payment terms and schedules, as well as remedies/penalties when payment is late.

(d) Who *owns* the work product and associated deliverables.

(e) Any associated warrantee period.

(f) Dispute mediation. Where and how disputes will be handled relating to the meaning or interpretation of anything in the "Work Order" and "Project Specification Document".

I'm sure we were missing a lot more, but those stand out in my mind -- I can still remember the exact incident that drove our decisions to add each of the above.

Sgt. Sausage
Monday, January 12, 2004

Also add (or address):

-- Factory Acceptance Test/formal qualification test: [contractor] shall demonstrate the software performs according to specifications, and document results in a test report to be delivered to customer; [customer] will be responsible for all travel costs to witness the test (if desired, some do, some don't).

-- Who pays shipping or travel costs for delivery of final product

-- System acceptance test: contractor shall install the software at client's location and perform the formal qualification/factory acceptence test procedure to demonstrate the software meets the specifications

-- Training: contractor shall provide 2 sessions of training at contractor's location after delivery and acceptance

-- On-site support: contractor shall provide on-site technical and administrative support for 4 weeks at customer's location following system acceptance and technical training, not to exceed 2 trips, as mutually agreed by contractor and customer.

-- post-installation support: contractor shall provide unlimited technical support via phone and email for 2 years

-- maintenance releases: contractor shall provide new releases if necessary to fix deficiencies from the specification for 2 years

The numbers are just examples, but what we commonly use.

Ron
Monday, January 12, 2004

Other stuff that we usually put into our SOW's are things like:

- What type of resources the client provides (computers, access to people, etc). This is especially important if the whole project hinges on us being able to speak to certain stakeholders.

- What are the important dependencies and milestones. Are we tied to a particular conference date, for example.

- Is there some kind of training that should be provided for?

- What is the process by which a client accepts our deliverables (i.e. "signs off")

We may reference a specification document, or other such plans, if we have already made them.

Anca Mosoiu
Monday, January 12, 2004

1) How do you use SOW's in your consulting enterprise, or when you hire consultants? Do you call it a "contract" or a "Statement of Work"?

In my case Statements of Work are generally requested by the client as a means to secure financing. Once financing is in place, the statement of work was used to create a contract.

2) What type of things do you wish had been in an SOW, but weren't?
School of hard knocks taught me to put rates and expertise but keep description of outcome vague. Except for government work, you do not want to get into describing what you will deliver without any real specifications. If they won't sign specs, it is an estimate.

Always put an expiration date on it. Funding is a funny thing. You don't necessarily want them coming back 14 months from now and asking you to live by the SOW. (Again personal experience)

What type of things do you regret putting in?
Arbitration. Better to worry about lawyers and keep it boilerplate.

Now, I am not really sure where this goes, but either create a template that a lawyer can review or put a lawyer on retainer and run all contracts past them. I went the template method as it was cheap, but I also knew it would not fall apart if for some reason they failed to pay. Law and logic are not the same thing.

Also, ALWAYS get a Non-disclosure agreement signed before sending a SOW and include it with the SOW. This will prevent the company from using your SOW to get a better deal from others. (not really, but it makes your attorney feel better)

MSHack
Monday, January 12, 2004