- Ted Rogers
- Reading Time: 5 minutes
With a database of system implementation projects exceeding $40B in project cost, UpperEdge has reviewed and supported the development of numerous Master Statements of Work (MSOW’s) and individual Statements of Work (iSOW’s). While the program scope and content are different for each, every MSOW and iSOW contains an “Assumptions” section that is sometimes under appreciated.
As a Program Leader, you know assumptions are expected in a SOW. You also realize that not every program member or enterprise stakeholder realizes assumptions need to be appreciated and understood for the important role they play within the SOW and in the execution of the actual program.
Assumptions should not be perceived as only one-sided unless you choose to concede your position of responsibility. Assumptions should be leveraged for additional clarity and transparency in all facets of the program. The Assumptions section in a SOW provides what assumptions both parties agree to in order for the work to be performed. Your first takeaway is that “both parties agree.”
Why Do Assumptions Matter in Your SOWs?
Rather than focusing on the Assumptions in their SOW, I often find that my clients focus on scope and cost without realizing how the Assumptions can influence the delivery of scope and the management of cost.
There are many things that contribute to the content of assumptions. Consider a program scope that includes expected functionality, technical architecture, timeline, statutory requirements, data, including master data, transactional data, and historical data to be loaded, as well as multiple parties involved in delivering the solution.
Examine the Assumption section of your statement of work. Do you see content that only focuses assumptions on the client? A typical program vendor environment contains a combination of business integrators, one or more SIs, hyperscalers, and multiple solution providers. Most companies are dealing with associated complexities and benefits of a proposed solution landscape composed of various combinations of vendors like AWS, Microsoft, and Salesforce. The multivendor program is complex to manage, with more risk and more assumptions.
Warning: If the Assumption section does not include assumptions by the client on the various service providers or does not clearly state the expectations of the client on work to be performed, then your assumption section could be understated.
Does the Vendor Have Skin in the Game?
A common comment I’ve heard form clients is, “The vendor does not have any skin in the game,” or “Seriously! They are not going to help us with that?!”
Do not be blinded or biased by the number of assumptions. Pay particular attention to both the content and context of each of the assumptions.
There are two common examples that are often misunderstood:
1. The Client is Responsible for Addressing Software Errors from the Software Provider
Delays to the program resulting from a provider’s software are the responsibility of the client, and they are responsible for addressing these issues with the software provider. Since they selected the software, they own the relationship with the software provider.
Reality Check – In this assumption, the integration vendor does not own the software. The client owns the right to use the software through a license or subscription. It is highly unlikely that the integrator would totally abandon you in presenting your issue to the software provider, but you could incur additional fees if the program is delayed.
What You Can Do – First, modify the assumption with this verbiage: “Integration vendor will assist and support the client in this process.” You own the relationship with the software provider, but you need everyone supporting you if this situation manifests.
Next, be aggressive in quickly reaching a manageable solution with the software provider – a solution is your goal. Immediately contact your software vendor to escalate assistance. Contact your Procurement and Legal teams to review your software contract language to present their best options. Draw in your integration vendor to support you on this matter, including voicing your expectations that the integrator will leverage their highest executive relationship with the software provider on your behalf.
Do not overlook your project status and project plan. Project status matters because the client can lower their system integrator cost exposure to a software vendor’s product error delay if they know the level of program timeliness/latency. Estimate the degree of existing program lateness and the root cause of lateness at the time of the software event.
Review the project plan and identify tasks and deliverables that are dependent on the software matter being resolved. Continue work where it makes sense, manage your work and plan appropriately. Be able to account for any technical debt you could be creating during this period.
2. Named Functionality (e.g., Payroll) Scope is Limited to X, Y, and Z Modules.
The integration vendor scope is limited to the listed functionality and modules and the vendor’s estimate is based upon the listed parameters.
Reality Check – When assumptions like this example are left unaddressed during SOW development, it can leave the assumption open to many interpretations and can result in an unexpected change order in the early stages of the program.
What You Can Do – There are many options, including requiring the integration vendor to include functional capabilities and models that are out of scope. Clients should ask for additional functionality attributes to be listed within the assumptions. Geographies, legal entities, business units, and subsidiaries, both in and out of scope, should be listed.
There may be gray areas of “potential” scope that the client does not want within the scope of work as well as in the budget. However, be aware of the possibility of a change order that may be required for these gray areas. The client can leverage their negotiation position and create a level of future costs by asking the vendor to provide a separate proposal for potential scope items.
Assumptions unaddressed in SOW development will lead to program disruptions and steering committee agenda items. Expect a regular cadence of expensive change orders if they are not addressing gaps or requiring clarity in the assumptions section. The assumptions section is the ideal place to clearly state your assumptions of the vendor.
Managing SOW Assumptions at the Start of the Program
It is better to manage the assumptions at the start of the program, rather than to find out later from a resulting change order that the assumptions were not managed.
What You can Do – A useful exercise that both the client and vendors can do at the beginning of the launch of their program is to assign named individuals or workstreams to each assumption in the SOW.
This activity can provide two important roles. First, the discussion between the client and the vendor on each assumption can address any misunderstanding or incorrect “assumptions” made by either party during SOW development. The second benefit of this activity is it allows the client to see if a particular person or workstream has too many assumptions, allowing the client to make appropriate changes to the assignments of assumptions.
Managing SOW Assumptions During the Program
Your work on assumptions is not finished with the completion of Assumptions assignments. The PMO should load the assumptions and named assignments into the program risk management frameworks (e.g., RAID log) at the beginning of the program and assign each assumption to a workstream leader or team. This exercise will accomplish several important items, including:
- Ownership and responsibility to manage the assumption
- Opportunity to prepare and plan to mitigate potential negative impact from assumption realization
- Reduce exposure to program contingency spending
Inclusion of the assumptions into the risk management tool provides the PMO and others the opportunity to regularly review the assumptions and take action as needed. Assertive management of assumptions during program execution allows you to harvest your investments during SOW negotiations and lower the program risk profile.
Invest Time to Understand and Act on SOW Assumptions
These examples are just a few, but there are many additional points that fall under assumptions. As such, you absolutely cannot skim over this section of a SOW. Investing the time early could save you hours of extra project time, increased costs, and smoother relationships with your vendors.
