5 SOW Essentials to Make You Look Smart

How often have you heard, “We need to get the statement of work (SOW) signed so we can get started on the program”?  Or perhaps, “We have a tight window to complete the SOW or we could fall behind”?

 

But if you rush to complete the SOW, what will people remember?

• A blown transformation program.
• A blown project budget by 50-250%; or
• A late start to the program because more time was needed to formulate a robust SOW.

You don’t have to be an above-average Program or Project Manager to know the answer to this question.  Anyone who understands the importance of the rock-solid SOW knows that a late start is nothing compared to a full-blown IT disaster.

A SOW is a document routinely used in project management to define project-specific activities, deliverables, and timelines for a vendor that’s providing services to a client.  Typically, the SOW also includes detailed requirements and pricing along with standard regulatory and governance terms and conditions.

While the SOW is a legal agreement between you and your vendor, it is still your responsibility to hold the vendor accountable to deliver value.  But your ability to hold a vendor accountable may be limited to the content of the SOW – regardless of any amount of blood, sweat, or tears shed during the execution of the program.

A project manager will look at a SOW from many different perspectives, including risk management and capturing value.  My thoughts below pertain to the deliverables within the SOW and will discuss how to manage risk and capture value through better deliverables within the SOW.

Remember, the “W” in SOW stands for work, and you are paying an outside firm significant sums of cash to work.  The work they do should produce SMART deliverables — Specific, Measurable, Attainable, Realistic, and Time-Bound.  This goal-setting acronym fits nicely when developing, reviewing, and testing the strength of deliverables within the SOW.

Specific – What Exactly are We Doing?

The likelihood of a “usable” deliverable actually being delivered is low if no one recognizes the name or understands the description of the deliverable.  To ensure your deliverables are sufficiently specific, ask questions such as:

• Are the deliverables clearly identified and the description clearly stated and understood?
• What is the likelihood the program team will readily recognize the name of the deliverable?
• Would your steering committee easily understand the description of functional deliverables?
• Does the RACI (Responsible, Accountable, Consulted, Inform) identify the deliverables, with the description of who is doing what?
• Does the staffing plan that accompanies the SOW provide for enough resources to complete the task?

Measurable – What Does the Deliverable Look Like? Are We Making Progress?

Being measurable is critical from an agile point of view. Keeping teams focused on delivering only what is perceived to be needed by the end users is accomplished by defining the minimum viable product (MVP).  Dissecting the MVP into features or “user stories” allows the MVP to be estimated in terms of effort and it allows progress to be measured.  If the Product Manager and team did their job correctly, they will have set the completion criteria for the features, also known as the Definition of Done (DoD).

Another way to look at “measurable” is the MVP as the puzzle, and the features as the puzzle pieces. As work progresses and more and more pieces are completed, the MVP comes together.  Missing and incomplete pieces quickly become evident and non-fitting pieces are visible.  The work is done when the puzzle looks like the picture on the box.

At the completion of each interval, there is more measuring to be done in terms of work completed based on the DoD towards the MVP, quality of work, and the creation of technical debt (postponed work).  The commentary of qualitative remarks at the conclusion of the interval should be reinforced by the numbers produced in the interval.

We encourage our clients to take time to comprehend the sprint/interval summary report.  Use the data generated by the process to track and understand the progress on providing the end deliverable.  Do not overlook performance history and recent activities.  Understand what is behind any performance spikes or dips and ask questions where data is not presented.  Do not underappreciate the relationship between quality issues and the creation and accumulation of technical debt.

Achievable – Is the Deliverable Attainable?

The SOW must contain evidence of support for the deliverable(s) within it.  Your search for evidence, or lack of evidence, will allow you to identify and address potential blind spots that could jeopardize achieving the end goal.  Your detective work may also lead you to realize the deliverable is not a valid deliverable.

Achievable deliverables are reflected with supportive evidence from the staffing models where resources and participation levels are aligned with the deliverables.  Other places to look include RACI tables that include the deliverable and/or supporting activities of the deliverable.  Ensure that any assumptions related to the deliverable are clearly documented and understood.

Shrewd Program Managers will also reposition deliverables to future SOWs when they recognize the capacity and capability limits of the team or the PMO.  These Program Managers should be considered “above average” due to their ability to recognize the danger of creating technical debt when deliverables in the SOW are not delivered.  In other words, these above average Program Managers know their limits.

Realistic/Relevant – Does this Deliverable Contribute to the Transformation?

Ask the following questions to assess whether the deliverable is realistic and/or relevant:

1. How does this deliverable fit in the transformation program and this SOW?
2. Why are we planning to produce this deliverable now?
3. Why is this a deliverable?

Every SOW deliverable needs a clear link to the overall program and the SOW.  An additional question that could be asked is, “Would the program/SOW be incomplete or fail if this deliverable was not produced?”  Understanding the contribution and value of the deliverable is important.

You can use this same logic with your SI to add deliverables to the SOW.  For example, you can take the position, “X contributes to the success of the transformation/SOW objectives because. . .,” or, “X should be considered a deliverable, because without it, there would be a gap in the program SOW.”

My second point of, “Why this deliverable now?” is important because the timing of the deliverable cannot be overlooked.  I have worked with clients and vendors who decided to postpone a deliverable to a future SOW for many good reasons including limited resources, budget timing or constraints, and dependencies on other deliverables.

Lastly, “Why is this a deliverable?”  A vendor may take the position that what you are calling a deliverable is not actually a deliverable.  The vendor may refer to it as a work product or an activity – and they could be correct.  If you still feel it should be considered a deliverable, your counter position could be, “Deliverables are formally reviewed against acceptance criteria. The company realizes value delivered in “X”, and the review and acceptance process is tied to the realization and capture of program value and support of the cost of the program.”

Time-Bound – Is the Delivery Due Date Achievable?

Your Program Manager training started when you were just a small child and learned to ask, “Are we there yet?”

Knowing when to expect the completion of each deliverable is critical and expectations must be set.  Deliverables without due dates are a deal breaker for the SOW.  Yet, as irritating as it is, I still see vendors list their payment schedule in the SOW but fail to include the timing of the deliverables.

Merely having a due date attached to the deliverables is not enough because the date is meaningless if it is not achievable.  Challenge yourself and the vendor to validate that the deliverable due dates are realistic by demonstrating their planning.  Examine the project plan to understand the critical path for each and every deliverable within the program.  You should also challenge questionable areas within the critical path (an extreme example would be, “Why is the build phase 3 months long and end-to-end testing is two days in duration?”).

Managing risk and capturing value is a huge job.  As the Program Manager, you need to understand the individual and compounded consequences of missed delivery dates of deliverables on the critical path of the program.  Work with the vendor to correct or mitigate the areas of risk.

I am reminded of a project management class taught by a former marine who said, “The more you sweat in planning, the less you bleed in controlling.”  Before the SOW is signed, know your dates.  Mitigate the risk.

Client Responsibility

The SOW is a legal agreement between customers and vendors.  Both the customer and the vendor are responsible to work together under the agreements and both sign the SOW, but only the customer bears the responsibility for capturing the value.

Deliverables are the foundation and building blocks of any program, technical upgrade, or transformation.  As the customer, you must decide where you will compromise during the SOW negotiation.  Negotiate for more deliverables and negotiate for stronger, SMART deliverables to capture more value.

Comment below, follow me on Twitter @UpperEdgeTed find my other UpperEdge blogs and follow UpperEdge on Twitter and LinkedIn. Learn more about our Project Execution Advisory Services.

Related Posts

• System Integrator Risk Mitigation Processes Often Have the Opposite Effect
• The ERP “X” Factor
• Exploring the “Unknown Unknowns” in IT-enabled Digital Transformation Estimates
• Dirty Little Secrets of your System Integrator: Why Companies Still Go Over Budget
• A Hazardous Waste: An Overview of ICL’s Failed SAP Implementation