This entry was posted on Wednesday, December 5th, 2007 at 9:30 pm and is filed under Business. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
How I Learned to Stop Worrying and Love the SOW
In order to deliver what you promise, you have to understand what you’re promising. The fundamental piece of this puzzle is a statement of work. Any good statement of work should protect the interests of both the service provider and the client. Key components of the SOW include:
- Stakeholders (Client and Provider personnel involved in the project)
- A name and description of the project
- Listing of tasks and milestones (if the project is lengthy or requires client approval before proceeding)
- Listing of deliverables and any caveats to the use of those deliverables (more on this later)
- Project start date and estimated duration (including duration of effort by hours)
- Estimated fees
- Project assumptions (the catch-all, more on this in a bit as well)
- Execution statements and signatures
So, at this point, you’re saying to yourself, “Self, I’ve had Business Law 101, I know you need a contract and those things just make sense.” And you would be right, its pretty basic stuff that SHOULD be common sense. But common sense is like that lazy guy in the next cube who golfs with the boss and seems to be on vacation every other week.
Say you write an iron-clad SOW that follows the text book example to a tee. What’s the worst that can happen? Allow me to share a few of my own experiences. The three biggest pitfalls lie in the middle of the SOW: tasks and milestones, deliverables and caveats, and estimated duration. The biggest takeaway for this article is to really think through things when you write an SOW. Certainly, the statement of work will be derived largely from the proposal and negotiating process. But even once frameworks and milestones are agreed upon, there’s still quite a large margin for error. It’s important to keep these things in mind that I’ve learned over the course of my career.
1. Don’t include a task/deliverable that you aren’t completely sure you can carry out in the time allotted for the project.
2. Don’t include tasks/deliverables that go above and beyond what’s required to fulfill the terms of the contract. There’s plenty of chance to go above and beyond anyway if time and resources allow, but the contract should not stipulate this.
3. Tasks/deliverables included in the SOW should be clear and specific. You don’t want to leave any room for interpretation of what a task truly means. This can lead to significant financial impact in project delays, additional resource requirements, or worst-case, litigation.
4. Stipulations should be included as to how the client can use your deliverables, reports, findings, and intellectual property once the project is complete. This includes sharing with third parties, use of findings for strategic and tactical planning, etc.
At this point, I need to say that I’m not a lawyer, this is not legal advice, and any such guidance should be obtained from a lawyer when developing a generic statement of work for future use. Now that that’s out of the way, just a few personal stories on how these things can impact the people actually doing the work.
I’ve found myself on numerous occasions doing work that wasn’t part of the original scope because of vague statements about deliverables or tasks to be completed. In managing the daily activities of the project, I often find myself referring to the SOW to make sure we’re doing everything we said we would. Nothing is better than getting to a line item and saying to yourself “What the hell does this mean?” Because you know the client has a very specific idea of what it means, and of course, the client is always right.
I’ve also experienced cases where the someone wanted to get flowery with the description of a deliverable. If you can promise a report that shows site traffic over the past 6 months, you don’t need to promise a novel that shows the traffic, slices and dices the data 10 different ways, contains pretty pictures, and contains an instant weight loss remedy. If time allows, you can certainly deliver the novel, but then its seen as value-added, and not expected.
In the end, the SOW can determine the success or failure of a project before it even starts. It’s important to set yourself up on the right foot. The nature of projects is that there’s plenty of things that can happen out of your control, make sure you do everything that IS in your control right.
Have you experienced a situation where unclear statements of work caused project headaches or worse? Have you experienced a situation where a provider promised one thing and you were expecting something else? Let’s hear from you.