It takes a number of documents to manage projects. One of the less user-friendly of these is the Statement of Work (SOW). It’s filled with legalese, definitions and words like aforementioned and hitherto. The following provides some insight into how you can break down an SOW into something a lot more understandable and actionable.
Here’s a story: I had just started my new project management position in a brand new company, and was looking forward to getting up to speed on not only the projects I would be managing, but also the technology that supported them. In more mature companies I had worked for previously, there usually had been a couple of weeks of orientation, some training on the software and meetings with key players to integrate myself into the staff. But those were previous companies.
My first day on this new job had me sitting across from my boss who was clearly busy and very distracted. His phone was ringing, buzzing and chiming every few minutes. People popped their heads into his office to ask if he had a minute, or say something had gone wrong and he needed to get involved. He tried to carry on a contiguous conversation with me in spite of all the interruptions.
“I’m really glad you’re on board,” he said. “As you can see, we’re a bit behind the eight ball here and you’re just what we need to catch up on a number of projects that have been languishing.”
“Great,” I said, while thinking to myself that he’ll lay out what the next couple of weeks look like and how they plan to bring me up to speed.
“Here’s the most recent Statement of Work (SOW) that we need to start on immediately,” he continued, passing a 15-page document across the desk. “You’ll of course want to get a copy of the Master Services Agreement (MSA) that is referenced throughout this document. Let me know if you have any questions.”
And that was it. Consider myself oriented! He had obviously given me all that he thought I needed to know, and seemed confident I was ready to be on my own. Sure he left the door open to come back to him with any questions I would have, but it sure was a paltry start to what I knew would be a rigorous job.
Nonetheless, he had given me my first project and assignment as a project manager. I walked away with the SOW, obtained the MSA and started to dig in. The project went off as well as could be expected for my first solo run, and eventually I became acclimated to the culture and way things were done.
Since then, I’ve come across scores of SOWs and at some point developed a method for converting them from just ideas and legalese on paper to the beginnings of a project plan. Consider the following steps:
Read the SOW from Beginning to End – The first thing you’ll want to do is curl up with your favorite SOW and a hot cup of coffee (or beverage of your choice) and read it from beginning to end. Don’t be disappointed if it doesn’t compare to one of the best-selling novels you’ve recently read. As a matter of fact, it will be directly the opposite. A SOW is tedious, boring, mechanical, and hard to follow. That’s okay; it’s part of the process that gives you the exposure you need to understand the spirit of the project and what the finished deliverables will look like.
Zero in on the Definitions – The next thing you want to do is spend some serious time on the definitions that are usually included near the front of the document. This is your glossary of terms and a shortcut to understanding the SOW in detail. The terms used throughout the document will typically infer a legal context, so an understanding of definitions will shed light on those areas that could cause misunderstandings to arise between the Company (the entity providing the services) and the Client (the entity receiving the services).
Look at What YOUR Company is Responsible For – Now that you have an overview of the entire SOW and an understanding of the legal terms used throughout the agreement, you need to zero in on what your company is responsible for. This section details what you have promised to deliver as a company. It may be the promise of a certain amount of up-time on your servers and equipment. Or it may be delivery dates for product, hours for support personnel, or a list of other deliverables that your company has committed to deliver. Why is this important? Because, if you meet these requirements your company, in effect, gets paid.
Look at What THEIR Company is Responsible For – This is the section that outlines what THEY have promised to deliver. This may be access to subject matter experts on their staff, prompt approvals, their own support personnel, facilities, or other key components project success is dependent upon. It’s important to know this because failure on their part to deliver on any of these areas could negatively impact your ability to deliver on what you are responsible for, which would slow down delivery and, ultimately, payment on the project. This section helps you know which areas to push the client to get their work done in a timely manner.
Dig Into the Details – This is where the fun begins. You’ve been flipping back and forth through the SOW and looking at definitions, areas of responsibilities and commitments made by both your company and the client. It’s now time to pull out a few of your favorite colored highlighters, pens, pencils or writing instrument of choice. Go through every line in the SOW and indicate whether it’s a Deliverable, Risk, Assumption, Constraint, Time Element, Payment Event and whatever other categories may be appropriate for categorizing the project’s SOW. Highlight each of these sections in a different color or put a note in the margins so they can be referenced in the next step.
Pull The SOW into a Spreadsheet – Once your SOW is marked up and categorized, pull these into a spreadsheet with just a handful of columns across the top. This includes Type (deliverable, risk, assumption, etc.), Description (you can copy and paste this directly from the SOW) and another column for Notes.For example, one of the Deliverables in the SOW is “Financial information will be sent in a daily feed at 11:00 PM each night.” This sentence would be pulled into the spreadsheet and categorized as a Deliverable. Then, under notes you may add a clarifying comment that it includes weekend as well as weekday nights. By the way, you’ll want to include a Questions/Issues type as a category for items that may not neatly fit into any of the other categories or that need further clarification.
Sort or Pivot Your Spreadsheet – Once you’ve gone through the entire SOW and extracted all the categorized information, it’s now time to sort or create a pivot table of your work. This is the fun part. You’ll start to see patterns emerge—exactly what needs to be done, when it needs to be done, what risks or issues you need to be mindful of, and any open questions that need to be answered. Get your questions answered and your issues resolved at this point, update the spreadsheet with your findings and resort or repivot.
Create Your Work Breakdown Structure (WBS) – You now have what you need to put a draft together of the WBS that will drive the rest of your project plan. Not only that, you also have a clear and deep understanding of the project as it relates to the legal terms of the agreement, what your company is responsible for, and what their company is responsible for. You’ll find this to be invaluable as months pass and people are no longer referencing the SOW…and may have even forgotten it exists. Keep tracing the requirements and deliverables back to the SOW and you’ll do a great job keeping things on track.
It’s true that SOWs aren’t the most user-friendly document in our cache of project management collateral. Following these eight steps will make the task of digging into one of these documents much less foreboding and, dare I say, almost enjoyable.