Planning Your Transformation
We often have clients ask us about work they can do before a business transformation program gets underway, given how complex, cross-functional, and time-consuming major changes can be.
In response, we’ve compiled a transformation preparation playbook, including the various facets that are helpful to think through in advance of starting an operational or technology transformation. These include:
Phase One: Preparing Your Organization
Decision-making and prioritization
Work management
Structures and processes
People and roles
Communication and alignment
Capacity and expertise
Phase Two: Defining the Transformation
Customers and success criteria
Strategy and goals
Value stream / customer journey mapping
Financials and risk management
Transformation roadmap
Phase Three: Planning Your Transformation
Program structures and practices
Transformation teams and cadences
Key enabler readiness
Testing approach and defect management
Training approach and change management
Implementation approach
Today’s blog addresses the third phase: planning the transformation.
It includes questions to ask in each of these areas. Since every organization and every business transformation is different, there is no one right answer. It’s more about getting on the same page throughout your organization. We’ve included guidance where we can, and we’ve included real-world examples to illustrate how this can look.
The transformation preparation groupings build on each other, so it’s typically most effective to address them in the order listed. If needed for timing or buy-in, #1 and #2 can be tackled in parallel.
Program Structures and Practices
Clarifying how the program will be managed and what progress looks like will contribute significantly to success.
Identify Program Approach
Is the organization following Waterfall or Agile?
Waterfall: Check for appropriate artifacts, accelerators, and governance protocols
Agile: Validate frameworks, community of practices and backlog health.
Stakeholder Inventory
Building on the Decision-Making work you did in step one, inventory the players in the game using one of two common approaches:
RACI: Responsible, Accountable, Consulted, Informed
DARE: Deciders, Advisors, Recommenders, Execution Stakeholders
Is there a formal governance structure or hierarchy to get scope approved or changed?
Product or Project Based
Will it be more effective to follow a product or project approach?
Product managers typically lead the development of products, prioritizing initiatives and making strategic decisions about what gets built, in collaboration with customers.
Project managers oversee approved plans, managing schedules and resources to drive progress forward.
A good project manager is not necessarily guaranteed to be a good product manager – and vice versa. Both roles require good communication, organization, and presentation skills. Beyond those characteristics, the scope and breath of the roles are different.
Transformation Teams and Cadences
Resource Planning
Who is assigned to the program?
Are they fully dedicated or is this on top of their day job? What takes priority?
Assess how these factors will impact delivery velocity/ schedule.
Release Cadence
How are you releasing deliverables of value?
Does that need to increase or decrease to manage the transformation?
Status Reporting
Define templates and accelerators to consistently report out and report up from throughout the transformation program.
Define early on what constitutes moving between color notifications.
Define how we are measuring success; status should speak to progress against that direction.
Given that status updates will be repeatable, and likely frequent occurrences, design your status read-out with a template that can be easily updated. Overly ornate or descriptive read-outs that are time-consuming to update will become unwieldy as the project progresses. Start with something simple from the beginning and save yourself time.
Key Enabler Readiness
Investing in foundational components of the transformation program will pay off for months and years to come.
PMO Maturity Assessment
Determine how true teams are sticking to their chosen program approach. Coaching may be required if maturity is low.
Waterfall: Are artifacts stored in a single, easy to access location? Are they adhering to their change control process for scope changes?
Agile: Validate ceremony integrity, backlog hygiene.
Change Readiness
Have we clearly defined each of these?
A reason for change: clearly defined benefits and objectives
Leadership and sponsorship: how the effort is governed, and how teams get their direction
Project management: the technical side of the effort, focused on designing, developing, and delivering a working solution
Change management: the people side of the effort, focusing on getting people to engage, adopt, and ultimately use the solution
Gap Analysis / Business Readiness
What processes need to be put in place to track any gaps from current to future state?
Any known differences should be agreed to and logged for future reference.
Part of ‘readiness’ includes being prepared for the unexpected. While no one can see the future, what you can do it set-up processes and procedures in advance for how to handle issues when they arise. Something as simple as an escalation chart can set expectations with stakeholders on who gets told what, when they are told, and how frequently (or infrequently) stakeholders can expect updates when issues arise.
Testing Approach and Defect Management
Testing Approach
Is the team going to rely on automated testing or is it going to be more manual?
Do customers want a full-blown UAT?
Who is going to draft the test plan, test use cases and create the needed test data to execute the testing approach?
In the same way you test new code or functionality developed to support the transformation, be sure to bake in time to practice an entire data migration start-to-finish. The further into the process you get, the more the process for how to best support a data migration may need to be tweaked or refined. You’ll need time to make that pivot so account for it up front.
Defect Management
When defects are found, where will they be tracked? Who is responsible to triage and rectifying the defect?
What defects can be deferred? What defects need to be addressed now?
How will the team report out on progress?
Environment Management
Are there environments established for Dev, QA, UAT, Training, Pre-Prod, Prod?
Which are needed? How do clients integrate between environments?
How is integrity being managed when code upgraded are pushed/ released?
Word to the wise, always keep an exact back-up of what is running in production today available in a non-production environment for testing. Between defect fixes, and juggling different release schedules, it’s important to have a copy of what’s currently running so it can be iterated on as-needed in real-time.
Training Approach and Change Management
Taking a concerted approach to change management, implementation, and support will drive adoption.
Training
New tools mean new training.
How will that content be created?
When will it need to be delivered?
Does the team want in-app support like Spekit or Walk-Me?
Will we use Train the Trainer and/or onsite support after launch?
Organizational Change Management
We want to address the people side of transformation.
Change leads need to ride shotgun on all transformation efforts to help drive preparation of the pending changes.
How ready is the team to adopt what is coming?
How do we prepare them?
Application Rationalization
What is staying and what is going?
Determine where tools are duplicative and recommend which to keep.
If any loss of critical functionality or impacts to ease of use, look for a new way to meet needs.
Implementation Approach
Implementation / Conversion Approach
Is there a preferred method on how to move any legacy data to the new databases? Big Bang or Phased?
What are selection criteria for implementation approach?
Are there billing blackout considerations?
How will data be mapped, migrated, and tested? What are entry and exit criteria? How will defects be managed?
Rollback Strategy
What is the team prepared to do if something meaningfully goes wrong?
What is the rollback strategy?
How will version control be managed?
Post-Implementation Support
How long will hypercare support be in place?
How will defects be tracked and addressed? How will you report out?
What criteria are needed to move to standard operating procedures?
At the end of the day, a transformation will have many moving pieces. None of this can happen overnight, and it’s highly unlikely you’ll complete the project without hitting a snag or two (or three!) Being organized, communicative, and documenting along the way will set you up for the smoothest ride possible over the bumps and bruises.