Statements of Work Need a Village, and Sometimes a Dictator

A Statement of Work (SOW) is a document that is used to define and outline project scope, and may include a staff plan, pricing details, and assumptions based on a specific project. Professionally, they are a contract between two or more parties on the respective responsibilities of each party, during a specified amount of time, for a specific price with specific people involved.?

Normally, there are two kinds of SOWs:

1. Fixed Bid
2. Time and Materials

Fixed Bid

Allows clients to? better plan their budgets, and provides greater clarity on timelines and delivery schedule.

Time and Materials

Can be viewed as giving an entity a blank-check for hours of work without a clear end-date in sight.

You can probably guess which SOW is preferred by the client.?

There are benefits and drawbacks to both, but the biggest concern with drafting any SOW in either case: how well do you understand the client’s needs before you get into a deep-dive of a potential solution? At best, when you draft an SOW initially it is an educated guess. This is why you need the right people contributing.

Years ago I was sequestered to a hotel conference room many-states away from my home. I was told I needed to be there ASAP. I jumped into my car, headed south, pulled into the parking lot in Texas that evening, and didn’t leave the hotel conference room for a week.?

Subject Matter Experts (SMEs) flew-in from all over the country to contribute sections of content for this SOW. The document was well over 100 pages, $24,000,000.00 in-total for pricing, and had more workflow examples than I have ever seen in a single file. 30+ contributors in total, but one document owner. It was one person's responsibility to take all of the fragments, voice-types, disjointed content and wrap it up into a cohesive story with a singular voice. A village contributed, but a dictator made sure the final deliverable was sound.

Extreme? Yes. Did it work? Yes, we won the project. When you add up the cost of time and travel (hotel stays, meals, gas, tolls, etc.) $24MM was a nice win.?

Not all SOW drafts need to be an in-person exercise. We have tools that allow us to create files at any location globally, post them and share them with a group of people. The very old way of doing this was to have a PM or BA take an SOW template and build out the skeleton of the document and share it with a group via email. What a nightmare; version control was non-existent, people would overwrite one another, no one knew which version was the latest. A better solution was/is to share the file in a folder that a group of people have secure access to. Important note, to reduce frustration with this approach, ensure? all participants have access to the shared drive. Now you’re able to? tag people to sections they are responsible for or tag individuals asking clarifying questions. Digital collaboration can be a beautiful thing, when everyone has access.?

It also helps when those that are tagged actually know they are tagged. Yes, they get notified via email (and often, other integrated platforms), but for many of us, our in-boxes get overflowing by noon. Therefore, any communication your stakeholders aren’t expecting can get lost. It isn’t enough just to tag people and expect them to contribute. Communicate with your core team before you start a group collaboration. Make sure your core team has bandwidth to contribute. When they do not, quickly find someone else. Nothing is worse than sitting on a draft SOW that needs an Architect to map out a plan and they never join a planning meeting.

The SOWs most likely to backfire are those that get drafted by a very small group of people, and are then shared with the client, without key stakeholder oversight. I have heard countless excuses for why this happens; timing, it’s a draft, client needed it ASAP, they just wanted an idea, we are collaborating and this is the first stab. Once you share an SOW that has a team structure, deliverables, pricing and a timeline you are stuck. Sure, the SOW language can change, but any edits or adjustments by groups that have yet to be involved will cause friction with the client. Usually, these SOWs are created by an Account Executive (AE). Sometimes those AEs grab a Content person or an Architect (pick your flavor) to fill-in gaps. When Project Management (PM), User Experience (UX), Development/Delivery (DEV) and other key groups aren’t involved, the result is a client gets an SOW that is incomplete and inaccurately “fits” the scope. These are SOWs that have the greatest potential to blow-up budgets, timelines and team structures.?

A simple fix? Prior to sharing even a draft SOW with a client, make sure you get the correct people to look at it and provide feedback. The amount of push-back I have received on this simple process is incredible. I do not care how quickly the client wants to see-something. I do not care that the usual group of SMEs isn’t available. Find the appropriate group of people, have a quick meeting, discuss concerns, document questions, do not include timelines or pricing yet, and then share with the client. Save yourself the embarrassment of having to walk-back a document that was never ready in the first place. Plan better. Your team and your clients will thank you.

Am I suggesting a successful SOW should have a team of experts pulled from all over the world into a physical location? No. What I am suggesting is principles from that scenario should be applied to how all SOWs are created:

1. A small group of SMEs understand the ask from the client
2. A draft outline is established by a lead content strategist and SME input
3. Other SMEs are identified to contribute
4. Those SMEs are briefed on the client ask
5. Every SME drafts questions for the client to clarify the ask (when questions are not allowed, your assumptions section gets huge)
6. The lead content strategist owns the flow of the SOW, and each SME is responsible for content related to their section
7. Draft SOW is ready for review?
8. Project sponsor (Partner) reviews, comments, requires edits, pushes back on the team
9. Team cleans up SOW, lead content strategist shapes the document into a cohesive narrative
10. Partner reviews and signs-off on the draft
11. Draft is shared with the client for feedback
12. Back-and-forth ensues

It can be done remotely. It can be done in-office. It can be done over the phone. It can be done in a hotel conference room. Each and every SOW is different, yet they tend to get easier, per client, once you get the first one approved by that client. You now know what language to use, how assumptions should be broken down, how they like staffing plans, etc. Once you get the first one out of the way, the next set is usually faster.

More bodies doesn’t make an SOW better, but you need the right voices to draft a solution that represents deliverables from multiple teams. The dictator should have the final say in the structure and completeness of the document both before and after the client has shared feedback. A dictator gets the file out the door, and it falls to the dictator to make sure when that SOW is signed by all parties. The village is ready to make it all happen.