Filed under: metrics
Last year, we spent the bulk of our time talking about a variety of what I’d call “base-level” contract terms. Term, termination, breach, warranties, assignment, indemnification, etc. But these are just usually the starting points for the relationship with the other party. In almost all cases, you’re going to have at least one other document that actually describes what the other party is going to do for you (especially if you’re a buyer of services). So, for 2008, I want you to improve your ability to write SOWs.
A Statement of Work (or a Work Order) is an add-on document to the base-level agreement. It really only needs four simple components: 1) A description of the work; 2) A time-frame in which the work will be completed; 3) A way to measure that the work has been completed; and, 4) A description of how payment will happen.
Unfortunately, each of these four areas can get a bit tricky, even when you’re talking about a single piece of work. When multiple SOWs start interacting together, things go from bad to worse. In the next few weeks, we’re going to talk about each of these areas in sequence. However, before you start writing SOWs for your customers or clients, I suggest you always, always, always, step back from document to talk with the project manager.
The reason for this discussion is that you need to have a perfectly firm grasp on what goals you seek through the creation of this SOW. We’re going to do this with Peter Drucker’s SMART mnemonic, which we’ll use again in measuring the work (because at the end of the day, you’re writing this SOW for the measurement of the work).
SMART is an acronym that stands for Specific. Measurable. Achievable. Realistic. Timely.
Specific: You need to be VERY clear. You can’t just say, I want a content management system. You need to say that you want a particular vendor’s particular version of a content management system. This throws a lot of people off, especially the project folks. They know what they’re talking about. They believe that the vendor does, too, so why be this anal-retentive?
Measurable: It’s hard to have a goal when you can’t tell whether you actually achieved the goal. Telling the vendor to install the content management system isn’t enough. You need to be able to say that you actually crossed a finish line somewhere. Most contracts use dates – the content management system must be installed and in production by March 1, 2008. Now you can say whether or not it actually happened per the agreement.
Achievable: It might sound obvious that you want to achieve your goals. But you might be amazed to discover that many goals simply aren’t achievable because no one has wanted to admit that the goals, as stated, can’t be reached. If you’re trying to install “the best” content management system, you’ll have a much more difficult task than if you’re trying to install a content management system that has 5 key business features/functions and is compatible with your 3 related key existing systems.
Realistic: If the installation of your content management system is supposed to happen by March 1, 2008, but it’s actually today and no work has been done, it’s not likely that all the work that has to happen can really happen by March 1. Sometimes it’s easy to get swept up in the excitement of a new project and over-deliver… this is not a wise move.
Timely: Well, I used the dates in the Measurable section above, but they’re true here, too. You have to use time as a way to bind the parties. Otherwise, some projects seem to take on a life of their own. We use deadlines as a way to drive to successful project completion – and as a way to check and see if milestones have been reached.
Leave a Comment so far
Leave a comment