The presentation slides are at the bottom of this post.
Face it, most people don’t like doing documentation. It’s about as appealing as the sound of fingernails on a chalkboard. But, it’s also a vital part of doing business. When new projects come through the door, the customer brings with them a list of expectations, assumptions, and (usually) misconceptions they then try to communicate to you with the hopes of turning their ideas into a product. This laundry list of “stuff” needs to be documented, clarified and generally sorted out so a clear idea of what they’re really wanting can be formed.
When that time comes, a Statement of Work document should be your go-to tool. It’s a formal, structured document with legal standing that isn’t hard to write and provides benefit to your team and clients. For your customer, it’s:
A) Professional. They like getting paperwork like this. It shows they you’re serious about your craft.
B) Reassuring. It forces all involved parties to make sure both have a clear understanding of where the project is heading and what is involved. When everyone is on the same page, life is easier.
For you team, it is even better. The benefits for the customer carry over in many cases, but your team also benefits in these ways:
A) Eliminate Waste. A SoW means details that are important to the client have been sorted out. There’s no need to waste time working it turns out the client doesn’t want.
B) Minimize Creep and Bloat. Your team can fall back on the document to determine if what they’re doing is meeting what was agreed upon or if it’s going too far above-and-beyond. That’s not to say that you can’t do extra to really keep your customer happy. What it means is you have nice, safe, defined bounds to retreat to if things get hairy.
C) Protection. Sometimes customers become a nightmare. Nonpayment, perpetual “hey, do this too” requests, etc… it happens. The SoW is a legal document you can use to determine if you’ve met your contractual obligations.
My RefreshOKC presentation covered it briefly, breaking down the individual parts and giving some examples of what to include in each section.
It’s important to understand that even though it’s a formal document, you have leeway in its creation. Not every section covered in the presentation belongs in every SoW document. If it’s a small project, you probably won’t have Special Requirements or Miscellaneous, and you could likely combine the Period of Performance and Deliverables Schedule into one short section. For a small job, it’s just not worth it to write a War and Peace-length document.
Another thing to keep in mind is you don’t need to know EVERYTHING about a project to write a Statement of Work. Nine Collective is big on Agile principles and LEAN development. So, to come out a say “Hey, find out everything about everything and then write it up” goes directly against what we like to preach. Instead of following the standard waterfall development model mentioned above, we buck the system by writing multiple Statements of Work.
WHAT?! That’s unpossible!
For big projects, we recommend getting a general contract signed and then using a SoW to line out each sprint, release, or SCRUM cycle. It’s okay to write more as you progress. It’s also okay to go back to your client and update the document as the project progresses if the need arises and both sides agree.
I’m sure other companies have their own ways of documenting project requirements, but this is what works for Nine Collective. Over the past year we’ve found it to be very flexible and highly beneficial for our team so we hope that other creatives will find it as useful as we have.
If you have questions, hit me up on Twitter: @PeterAt9C. I’ll try my best to help you in 140 characters or less.
