Six Degrees of Separation Between Good Projects and Bad – Bad Statement of Work (SOW)
Six Degrees of Separation Between Good Projects and Bad – Bad Statement of Work (SOW)
By Sean kenney
If you read my last post, you know that I have 6 things that I believe have the largest impact on success in client projects:
- Bad Client
- Bad Statement of Work (SOW)
- Bad Requirements
- Bad Process
- Bad Leadership, and finally
- Bad Resources
In this post I will address the 2nd item, Bad Statement of Work (SOW).
I have been on many projects in my 18 years as a software professional and I have seen many statements of work. Some have been very clear and concise and other have been downright appalling.
I have 5 general rules when writing/reviewing statements of work:
- Don’t do it all by yourself
- Be SMART
- If you don’t want to put scope in, you should put it in.
- Read it assuming that you are the client.
- Have someone else read it.
Don’t do it all by yourself
The worst problem that I have seen in SOWs is that the author tries to tell the client that they are going to do everything. This is a critical mistake as every project needs client interaction, Let me write that again – Every project needs client interaction.
When I write a Statement Of Work, I outline what we deliver to the client, along with responsibilities of all project staff (including the client’s resources), and critical assumptions.
You must plan time to review deliverables with the client, both before you deliver them, and after. The only way that you will be able to close a project is if the client signs off on deliverables, which you cannot do all by yourself.
Be SMART
What I mean by being SMART is actually that acronym that it stands for: Specific, Measurable, Assignable, Realistic, and Time-bound. This mnemonic is typically used when setting goals or gathering requirements and it is a great tool to use when writing the deliverables for the SOW.
If you wrote a statement like: “We will deliver custom software that meets you needs.”, you are just asking for trouble. Instead you should write the statement like this: “We will deliver custom software based on the timeline and requirements agreed to in Section X.X.” Of course that statement is not bulletproof, but it is much SMART-er than the first.
Review each statement with the SMART mnemonic and you will be amazed what you can catch.
If you don’t want to put scope in, you should put it in.
I know this may sound counter-intuitive, however, I have found that when I don’t include things that I should have – they end up coming up anyways. This is when the conversation start becoming uncomfortable, and you have to tell the client why it is not in the SOW.
Resolution: Put any scope not defined, in the assumptions area.
It will save you from some uncomfortable conversations in the future. You need to keep in mind that it may prolong the sale of the project, but I would prefer a longer sales time with less risk than to have something come up that may double or triple the actual project time.
Read it assuming that you are the client.
Have you ever read a contract that is so one-sided that it makes you want to walk away from the deal? Yeah me too, so let’s not do that. If you don’t read the contract with the clients interest in mind, you may end up losing before even starting.
You should keep in mind that a contract, or SOW, is not a deliverable. What do I mean by that? Let’s look an example:
When you ask a plumber to come to your house to look at a plumbing issues, do you want a detailed design and list of materials that the plumber is going to use? No of course not. You simply want to know how long it will take, and how much it will cost and that it will be fixed.
Keep that in mind, when writing your SOWs. A SOW is not a design document, so do not include detailed design specs, reference architectures, potential deployment topologies, or other detailed documentation that do not fit.
When questioning, use the plumber analogy first. If that does not work, you can always ask the client. However, be careful when asking the client, as they typically have an agenda when reviewing a SOW as well! J
Have someone else read it.
When I write, I proofread the content generally 3-4 times. Typically by the 3rd time, I am not so much reading as I am rattling off in my head, what I wanted to write. This is when I ask someone else to read what I have. I understand that you don’t always have time for someone else to do this, and everyone is busy, but this is a truly critical step in the process. I have even bribed some coworkers with a lunch or adult beverage to get them to help me. I am not saying that you have to do that, but it certainly helps their motivation.
Summary
When I review SOWs, I try to read it at least 4 times, each time focusing on a different rule:
- Don’t do it all by yourself
- Be SMART
- If you don’t want to put scope in, you should put it in.
- Read it assuming that you are the client.
- Have someone else read it.
I know that sounds like a lot of time, but getting a SOW correct is something that takes a bit of time upfront, or a long time after it is signed.
Sean Kenney is a software architect in Houstan, Texas. You can read more from Sean on his blog.