- Ted Rogers
- Reading Time: 6 minutes
Recent program transformation blogs have focused on symptoms of an ailing program and often overlooked blind spots in your transformation program testing. I’d like to now bring to light the assumptions section in the Statement of Work (SOW) that you must ensure does not result in negative consequences to your program.
From my perspective, assumptions and malware have similar characteristics. Malware is executable code intended to create havoc within vulnerable computer systems. While assumptions are not designed to wreak havoc in your transformation programs, these should be looked at as “executable code” within the SOW. Assumptions unchecked or misunderstood will inject requirements and timing expectations by your SI. The executable code of the assumption will unleash their impact in early stages of the program, sometimes as early as the planning phase, and always in the design and architecture stages.
No Assumption Protection — Just Good Practices
While it is not uncommon for MSOW and SOW discussions to be led by procurement teams and senior program management, also use project managers and architects engaged in the process. The assumptions area requires a diverse and comprehensive team that would review these statements for its impact to program, architecture, and risk management.
Assumptions are:
- Dependent on client resources, often unbudgeted, and outside of the immediate program team
- Contractual expectations and deliverables the vendor has placed on the client
- Required client actions often without due dates, and frequently the root cause of program delays
Snowflake, Snowball, Avalanche: Something Seemingly Small Can Morph into Something Big
Here are a few examples of assumptions taken from real SOWs that appear to be innocent on first pass:
- Client is using “XYZ” for program management
- Client is responsible for end user testing
- Client is responsible for system environments for program development and production
All three of these assumptions have one thing in common, the word, “client.” Given the client owns these assumptions, the client is obviously responsible for them. That can quickly become complicated and the consequences can be expensive.
Like ransomware, program problems related to assumptions can appear to clone themselves and quickly spread, impacting other areas which appear to be unrelated. In extreme but not uncommon situations, the problems can compound, and in some cases, lock up the entire program. Remediation is not cheap, and it does not involve payment to a rogue party in Bitcoin. The “ransom” payment is in the form of a change order to your SI, and the added cost can reach the magnitude of board approval.
A simple test in protecting your program against an assumptions hack is to look for these items in your SOW:
- Assumptions are reflected in the RACI table (Responsibilities, Accountable, Consult, Inform)
- Assumptions are supported by staffing model expectations in the staffing table
- Assumptions that are not included in the RACI or staffing model are acknowledged and accepted as supported outside of known program resources (Unsecured Assumptions).
Reliance on non-program staff or an external budget for execution of an unsecured SOW assumption is a dangerous supposition on your part. Although these resources may already exist in the company, I would advise you to get written commitment of timing, level of support, and any expected financial budget. This formality will lower the risk of contention for resources with other company initiatives.
Let’s discuss the three assumption examples that can lead to a ransomware-like experience:
Client is Using “XYZ” for Program Management
Many programs use products like SharePoint®, JIRA®, and Smartsheet® for tracking, recording, and reporting of program activities such as:
- Project plan tracking
- Deliverable tracking
- RAIDD (Risk, Action, Issues, Deliverables, Dependencies)
- Numerous agile KPIs (e.g., burn down charts)
As a leader of the PMO, you suddenly realize at the start that the “XYZ” program stated in the assumption is not ready for your use because either:
- The tool has not been purchased or installed
- The tool has not been configured for team use including data collection, reporting, and general program management
- The tool does not reflect the SI’s methodology.
The problem you have will not easily be solved in the first week, in fact, programs could struggle with this assumption for months. The impact of the realization of this assumption is almost as if you have said to the SI, “Come work on our program, I will pay your fees, but I will have great difficulty understanding if we are making progress.” You realize the PMO has now fallen victim to assumption ransomware.
Lowering your risk profile on this assumption could be achieved by adding language to the SOW that addresses:
- Who advises on the environment configuration and plan
- When the environment will be configured
- When the end deliverable environment(s) will be ready
- What the interim environment will be, and what the transition process to the target environment will be (if needed).
Under-reporting or misreporting of program activities and achievements are a leading indicator of SI and company resource mismanagement which can result in expensive change orders, extended program timelines, product quality issues, end even program termination. But who is at fault when the SOW assumption states, “Client is using “XYZ” for program management?” [Hint: The client].
Client is Responsible for End User Testing
While this is not an uncommon assumption, let’s look at the issues on this simple assumption and what may not be included in the project plan or the resource plan.
Would you be able to answer just these five questions if your SOW had this simple statement included?
- What are the required deliverables for client testing to start?
- Who owns the testing strategy?
- Who owns the testing plan?
- Who reviews and who approves the testing strategy and plan?
- When is the testing plan due for approval?
Testing is a crucial part of any program. End-user testing activity can provide cover for problems that occurred earlier in the program. Here are a few scenarios I have seen:
- Testing gets a late start due to countless reasons, however the SI expects the client to complete testing on the project end date
- Development is incomplete, resulting in extending end-to-end testing while the client waits for the SI’s completion of work
- Client testing is extended due to a late realization that client-developed testing scenarios and scripts were never compared to newly designed functionality.
These and similar scenarios result in late completion of client testing. While all eyes are on the client due to these testing delays, the SI can use this extension to complete other late deliverables. But don’t be surprised to also see the SI present a change order to cover the program extension under the guise the client is responsible for end user testing, even though the root cause may be something related to the SI.
Client is Responsible for System Environments for Program Development and Production
Chances are your transformation program’s new architecture involves moving from a known on-premise environment to a cloud situation involving hyperscaler providers and one or more software vendors. This assumption can be overwhelming for clients and can escalate to “red” status on your steering committee report after the first week of development.
Complexity of this architecture will probably not be fully understood by the procurement team. SOW review participation by your internal architecture and security teams should be sought, but they could also be challenged on the first few projects. The client teams may not fully realize they have “unknown unknowns” — problems and concerns that include security, user access, system performance, and the potential for contrasting vendor requirements and constraints. This problem becomes painfully ugly when integrating a new environment with existing customized applications and boutique applications.
The ransomware effect to the program will be realized by one of more of these scenarios:
- Development is delayed because the environments are not configured correctly or are not accessible
- Regulatory and security clearance is delayed due to concerns for PII, financial, and or proprietary information
- End user testing is delayed due to user access rights, etc.
- When moving to production, you suddenly realize external users and/or their systems cannot access your environment.
Your payment to remediate these problems can be expensive, ranging from change orders to retain SI staff to potentially seeking the addition of SI, software, and other external parties to solve the problem. But if you realize the problem only when you move to production, the amount of damage to your company reputation and the loss of revenue will quickly exceed the cost of resolution. While you probably should have anticipated and planned for these additional resources during architectural planning, the cost becomes higher due to the compounded effect of program delays and the risk of availability of resources.
What to Do?
The “assumptions” section of your SOW may not garner the same attention as other sections like “deliverables” or the RACI tables. Yet, the value the client seeks to create as a result of the execution of the SOW can be diminished or never realized if assumptions are not fully vetted by a diverse team during negotiations and managed throughout the program.
It is imperative to realize most SIs have transferred the responsibilities embedded in the assumptions to the client, however, it is important to lower your risk profile in these types of assumptions and to include SOW language to share responsibilities with your SI and other parties. The opportunity for problems to arise as a result of a stated assumption will not be removed, but you will go into your program with a planned mitigation strategy rather than falling victim to assumption ransomware.
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.
