Business Transformation is hard!
But it's sure easier using good problem-solving techniques
Over the past few weeks, I've been asked to illustrate a methodology I use for business transformation. Well OK then!
One simple approach I use is to start with a top-down view of where the organization is now (current state) and where you want it to be (future state). From there, you can develop a transition plan or road map to get your organization from its current state to future state.
It sounds like a cliché, but if you don't know where you are now and where you want to be, then don’t spend time, money and effort to try and get to some undefined end state with undefined and unquantified outcomes.
There are lots of good tools for approaching business transformations - both short-term (tactical) such as RACI problem solving tools, and long-term (strategic) such as customer journey mapping and value discovery tools.
I've put together some tips to illustrate a short-term methodology I use to “get the right stuff done,” and bring structure to a problem-solving process. Let's leave a discussion about long-term (strategic) business transformation methodologies for another day. As always, this is what works for me. I am always keen to know what works for you so please let me know.
Business Transformation: Where to start?
The image below illustrates the challenge: Where to start?
There is no silver bullet, but a process-driven methodology is often a good place to begin.
Apply a process-driven framework
I often use a simple five-step process illustrated below. It might look corny or overly simple, but having good visibility on your "North Star" or desired end-state brings clarity for everyone involved on a transformation to the many tasks at hand.
Step 1
Get consensus on the problem, or problems. Often, there are many problems. Some are more severe than others. Some are a manifestation of others. Some are external to the organization and others are internal.
Don’t start problem-solving until everyone around the table agrees on the problem or problems you are hoping to solve. A simple workshop or survey with impacted stakeholders is a good way to ensure you have a system-wide understanding of the problem or problems facing the organization. Not all problems are as important as others, and identifying the ones to solve first need to be carefully thought out.
Step 2
We often start solutioning a problem before understanding how it presents itself. If the problem is not observed and does not impact the organization, then maybe it isn't really a problem?
On the other hand, by understanding how the problem presents itself to the organization (think delayed or incomplete client reports), everyone will be better aligned on what needs to be solved and what happens to stakeholders until the problem is resolved (think lots manual workarounds to fix client reports).
Step 3
How many times have you started solutioning a problem only to find out later the root cause of the problem was not what you thought it was?
How often have you heard someone say, "this analysis will cost too much?" Or, "we don’t have the time to set up a dedicated technology environment or sandbox?” Or simply, “we know what the problem is so we don't need to do all this work?"
From my experience, organizations that rush to solutioning before truly understanding the root cause of their problems waste valuable time, effort and money when they do get to the solutioning phase.
As a project sponsor, I've always found it worthwhile to understand how your team determined the root cause or causes of your most complex problems. If you are not satisfied that the work is up to par, best not collect $200, go past Go and proceed to the solutioning phase.
Step 4
How often have you found yourself in a group working on a problem and hear different interpretations of what success looks like?
As a project sponsor or project manager, aligning resources and plans is a given, but aligning on what the expected outcome is can be just as important.
How often have you heard, “don't try to boil the ocean” - and for good reason. Transformation is an incremental process. You never get to the finish line. Delivering quick wins around a minimum viable product allows the organization to stay nimble, gain credibility, learn as it goes and, most importantly, develop internal working relationships.
Starting with a smaller problem that is isolated and can be fixed in a relatively short period of time will get the people involved on the transformation to start working together, build momentum and establish your credibility.
Step 5
The best-laid plans are paved with good intentions. Business transformations often span years. Infusing a sense of urgency and near-term tasks is always a challenge.
If you can’t agree on who (person accountable) is going to do what (clear deliverable), by when (time-bound date) and how they are going to do it (resources, procedures, etc.), project milestones will slip. A few slips are fine, but when those slips get ingrained and accepted as the norm, your ability to meet your scope, schedule and cost is just about impossible.
Lessons Learned
Agree on the problem you are solving, which problems are worth solving and in what order.
Spend the time to understand how the problem manifests itself. Some problems manifest themselves in obvious ways (computer system crashes due to insufficient memory) and not-so-obvious ways (think inaccurate foreign exchange rate because of truncated data in another system that you incorporate into a report).
Understand the root cause of your problem - and equally important what it isn’t. This is typically a time-consuming and detailed piece of work, but essential to avoid wasted effort.
Agree on your North Star. It might sound corny, but you don’t want to have three people on a team thinking they are all landing the same plane but on different runways. Course corrections along the way are fine as long as you are moving toward your North Star (directionally unchanged, but can move around a bit).
Action plans need to be brutally prescriptive and clear to everybody. Business transformations require great execution over multiple domains (technology, business process re-engineering, change management, etc...). If you are not clear on what needs to get done by who and when, well then, let's just say it ain't pretty.