With a database of system implementation projects totaling $20B 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 are 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 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.”
Too Many Assumptions
It’s not uncommon to hear our clients say with a bit of disbelief, “There are so many assumptions!” This statement is usually a reflection of the limited experience of navigating transformation negotiations or that their most recent experience could have been with just a single vendor from over 10 years ago.
There are many things that contribute to the number of assumptions. Consider a program scope that includes expected functionality, technical architecture, timeline, statutory requirements, and more than one party involved in delivering the solution.
It was not too long ago that “traditional” transformation programs were composed of a software provider and a system integrator (SI) from a limited, but traditional, set of SIs. Today, it is pretty much the norm to see multiple vendors, both traditional and specialized boutique SIs, and multiple platforms, participating in transformation programs.
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 AWS, IBM, Microsoft, SAP, Oracle, Salesforce, ServiceNow, Workday, and others. The multivendor program is complex to manage, with more risk and more assumptions. We often see companies needing to manage several sets of assumptions, one from each vendor.
Warning: Do not overlook the fact that the sum of the vendor’s assumptions represents the entire program. Consider the potential that the number of assumption gaps can expand exponentially with each vendor participating in the program.
Does the Vendor Have Skin in the Game?
Another common comment 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 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 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 and 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 – Assumptions like this example, left unaddressed during SOW development, can be 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 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.
Manage the Assumptions During the Program
Your work on assumptions is not finished with the completion of SOW negotiations.
The PMO should load the assumptions 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 investment during SOW negotiations and lower the program risk profile.
Invest Time to Understand and Act on Assumptions
These examples are just a few, but there are many additional points that fall under assumptions. As you can see, 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.