- Ted Rogers
- Reading Time: 6 minutes
Digital transformations are very complex, costly, and risky. Before diving into project timelines, budgets, and issue review meetings, leaders need to think through their digital transformation resiliency. Perhaps your last transformation steering committee report included a little more “yellow” than “green” from your previous update. This is not the first time the steering committee has seen yellow, but it might appear as a slow-growing trend toward red.
Is it just a sniffle, or has the program contracted a deadly performance virus that could spread team-to-team? Could there be larger concerns of a “program-to-enterprise” performance virus crossover that could jeopardize the operational and financial health of the entire company?
As we watch the world’s governments respond to the Coronavirus, what can we learn in our smaller world of transformation programs?
Imagine thinking about your industry as the world, your company as a continent, business units as regions, and your transformation program as a country, with program functional teams as cities and the team members as residents in the city. Then ask yourself these questions:
- How quickly would symptoms show to be able to identify, contain, and remediate a “performance virus” within your transformation program?
- Will transformation program DNA increase exposure to team performance vulnerabilities?
- Does your company’s culture promote denial or truth?
- Who is Patient Zero?
- How do I get vaccinated?
Symptoms of an Ailing Transformation
Like a virus, problems within a transformation program can often be ignored or misdiagnosed. Bias reporting happens, intentional or not, and also exists in all reports.
Your role and responsibility in the Steering Committee, as a Program Leader, or in the PMO, is to look for symptoms of program performance issues or new risk factors in the status report. The company has selected you to assist in monitoring program health, and question, prescribe, and/or make suggestions based upon your role.
Just like a virus, problems, risks, and issues left unchecked can lead to bigger problems. Look at the program as if it is wearing an examination gown and the status report is the lab report. Look past the artwork of the status report and digest the content. Set expectations for any status presentations you are expecting to see. Ask questions for items not provided on the status reports like, “Tell me where the next change order will result, and why it is needed?” Asking good questions will also demonstrate your level of understanding and engagement in the presented material, and your commitment to a successful program.
Contributing factors leading to missed or understated status reports include:
- Heavy reporting on accomplishments, with limited discussion on issues and risks — While I can’t recall a program that was late or over-budget due to the accomplishment of planned and budgeted activities, there are many programs that have failed due to unaddressed issues and realization of risks.
- Lack of collaborative and cross-referenceable data which would report current status – Can you see evidence of other team’s contributions or dependencies within a team’s status report (e.g., the data team report includes functional and integration references pertaining to dependencies or blockers)?
- Limited visibility of progress on the MVP (Minimum Viable Product) – Does the status report lead you to believe what you will expect in the demo session and the sprint summary report? Does the team have a history of underperformance, contributing to questionable accumulation of technical debt?
- No performance forecast, and often undefined qualitative scales (red, yellow, and green) – Velocity performance comparing current vs. history and forecasted performance are never discussed or presented, and often elicit surprises. A high reliance on qualitative measurements (RYG), often without definition, is another indicator a status report is misrepresenting the health of the team and the program.
Your Transformation Program DNA
The DNA of the transformation program of today is different than the team that built the system being replaced. New generation software providers like Workday and Salesforce are winning more business against older vendors like SAP and Oracle. Architecture decisions remain, but in this program, you will likely move to a cloud solution that is not under your control. What you will quickly realize is that the vendors are willing to infect each other with their requirements while at the same time claim immunity against outside assumptions.
The system integrator (SI) partner selection is critical and complex and can be a life or death decision for the program. Expected program scale and complexity should be a key determinate in selecting your first group of potential vendors. You may think the constant of the program is your company. This is an incorrect assumption made by many. Your company has mutated to a new organism, due in part to the impact of the legacy system you are about to replace and your company’s need to exist in a dynamic digital marketplace. Additional changes to consider are new faces in company leadership, new products, higher customer expectations, a lower tolerance for service disruptions, and expectations of a quick and smooth transition.
Your failure to recognize the dynamics of the different stakeholders in this transformation will be a huge miss on your part. The potentially fatal mistake would be not asking the SI candidates to demonstrate how their methodology will identify and address:
- Enterprise stakeholder expectations – In conflict or with a shared vision.
- Inter-team dependencies, performance deficiencies, and assumptions.
- Conforming to out-of-the-box functionality, low code, or customization due to a “not invented here” philosophy.
- Organization change management.
The potential for vendor and team conflict is high. Require the SI to show you the treatment options.
Culture of Denial or Trust
A recent New York Times editorial questioned if China had not learned their lesson from the SARS epidemic of over a decade ago. The editorial cited alleged local official health reporting in December and early January 2020 were either underreported or intentionally misreported.
If company values “stay hanging on the wall rather than exercised in the halls”, then the program is likely to fail. Company culture is contagious and will infect your program. Small problems will not be addressed and will be underreported. Teams will be expected to present green status reports that are actually like watermelons which first appear to be green then are discovered to be red when you cut into them.
A contributing factor may be how information has been presented to the PMO, steering committee, and other senior leaders. Perhaps driven by fear or need for affirmation, reporting is often limited only to historical program events — backward looking or “rear mirror” reporting.
Trust, confidence, and an invitation for active participation by your audience is evident when the reporting process is balanced, comprised of:
- Program historical data
- Change orders underway and their notable impact
- Potential change orders
- Forecasted resource requirements
- Key decisions recently made – and those needed to be made
- Risk profile of the critical path and deployment cycle
- Solicitation for different fact-based point-of-views, based on what your audience knows and what was presented
Patient Zero is Your MSOW/SOW
Programs fail for many reasons. You may be struggling with performance within your own program. The usual suspects are data, integrations, and eventually testing and defect management.
Additional functional respiratory restriction could be experienced in product demos which could contribute to program “arrhythmia”, when stakeholders realize the fit-gap analysis of out-of-the-box functionality was incomplete during the planning phase.
However, the most common root cause (Patient Zero) for program threats and failures are weaknesses in the Master Statement of Work (MSOW) and/or the Statement of Work (SOW). The MSOW and SOW are where the initial program struggles reside. Weaknesses in the SOW are magnified in the program when gaps exist in missing staffing plans for vendors and customers, poorly constructed deliverables, lack of clarity in assumptions, and vague descriptions of roles and responsibilities.
Get Vaccinated!
If you are heading towards any role in a transformation program, you will be exposed if these problems are not addressed. Surviving the transformation program will provide you and your company with antibodies to protect you from many challenges that your peer companies will not be able to withstand in the marketplace.
An ideal way to intellectually vaccinate yourself and your company against current and future problems is to talk to potential or currently selected vendors on these and other topics. Your comprehension of their demonstrated abilities, methodologies, risk migration, multi-vendor management skills, metrics, etc., will provide insight into what is ahead for you and your company.
Your program may still develop a cough, and perhaps a fever. There are no guarantees your program is not going to get sick. However, a good MSA (Master Service Agreement) and SOW arms you with better knowledge of what is ahead and is your best dose of preventive medicine.
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.
