Avoiding Digital Frustration
Digital Transformations are risky. The commonly reported rate of failure is sitting at 70%. Worldwide there are numerous high profile failures reported with significant financial implications.
Let's define failure. The initiative is deemed a failure if it doesn't deliver, is partially delivered or doesn't meet expectations of the org. In this blog I'll cover the common pitfalls and effective approaches I've used to mitigate the risk and impact.
Part I: Non-Delivery
Non-delivery can be attributed to a variety of factors, the most common being: no clear or consistent vision, shifting priorities, simply not knowing where to start, lack of appropriately skilled people, lack of funding and escalating costs.
Vision and Priority
For the first two points, a clear vision and priority are set by senior leaders. The clear vision sets out what is needed in a future state. The priority set at the top of the org needs sponsorship and buy in from all the senior leaders or the initiate is doomed from the outset. An org wide transformation requires sponsorship from the CEO or similar, delegation would occur to the most senior leaders of each org unit that were to take part in the transformation. Anything else will hit a brick wall.
Skilled Resources
Where to start and appropriately skilled people go hand in hand. The trap being paying topshelf rates for a big four consultant who will use a graduate factory to fill out the nice looking template. An appropriately skilled person/team will help you find where to start by understanding the root cause of the frustration and pain points In your org. They will then produce a roadmap of areas to address in a logical sequence.
Look for someone who has experience delivering capability over someone who's just delivered a solution.
A red flag should be anyone pushing a specific product to solve your problems when they don't fully grasp the root cause. A decent consultant will talk in capabilities and outcomes, not products.
Another red flag is a monolithic platform that will do it all. Yes, it will improve integration and remove those data silos, if you had the choice would you assemble a vehicle with a swiss army knife? Then there is vendor/platform lock in. Think ecosystem over product or platform.
Funding
Lack of funding and escalating costs. First of all, unless you've been through numerous Transformations, expect initial estimates to cost more than first anticipated. The second part is scope, as the idiom goes, you can't eat an elephant in one sitting. No one can even eat a decent sized steak in one bite. This is where the agreed and communicated scope is important. The transformation needs to be delivered with a smaller series of projects each with understood costs, timeline and benefits. Yes, projects can and do run in parallel, this would be carefully managed.
Furthermore, any unknown or untested assumption has an associated risk of a cost increase.
Data
Often an after thought until integration is required. Data is an asset and needs to be treated as such. Low quality of data, and a level of data accuracy that simply can't be trusted will throw cold water on any Transformation. As early as possible, have the current data set used by the org profiled. Understand the current state, does it move, is there a single source of truth or multiple copies? Where are the silos, what are the process and customer touch points and how does it impact process. And lastly, understand legacy systems, how will the data be extracted?
Process
Process, the current state of process needs to be captured. What is done daily, weekly, fortnightly, monthly, quarterly, annually and why. Often orgs won't have this documented. We need to understand current state to identify areas of improvement and assist with change management. Furthermore, remember the current wisdom, change the process before you customise the system. Customisations are costly and become a burden to maintain, select this path by exception only.
Change Management
The next point is change. It can be easy to get caught up in the excitement of new technology and not place adequate attention on the people impact. Don't under estimate the amount of change management required to deliver a Transformation. People can be hard work, stubborn and highly resistant to change. Even people who seem on board at first can become a naysayer when they realise that they too will have to change how they work. While there are many frameworks for successful change management, the change needs unwavering senior leader support to get it across the line. While demonstrating value in a new way of working is helpful, top down drives compliance in adopting a new way of working.
Part II: Expectations
Not meeting expectations. At the begining enthusiasm runs high, there is a real risk of getting caught up in the momentum and over promise. A number in the business case could seem reasonable when viewed through the beer goggles of enthusiasm and optimism. There is a fine line to be walked with being realistic and not dampening enthusiasm too early on. Talking risks, realistic benefits and roadmaps will help manage those expectation and keep those Stakeholders grounded in reality. Where possible adopt the mantra under promise and over deliver. Always be clear on the benefits.
Skilled Resource
An appropriately skilled person or team will understand project delivery and how to set/reset expectations. A red flag is anyone who is promising the world and agreeing to everything. Setting and resetting expectations is a real slill, in the past I've had to work hard to reset unrealistic expectations with senior management. A big part of this discussion is based on risk and benefits. Leading a digital transformation isn't for a people pleaser.
Communication
Expectation setting, updates and progress tracking are enabled through communication.
Visual management is an effective communication tool to keep stakeholders up to date with progress. I've used a physical kanban board effectively. If this isn't possible, look for ways to surface out the information via an easily accessible solution. Easily accessible being not requiring a login to yet another portal.
Not a Destination
The other expectation is that a digital transformation is a destination, once XYZ projects are delivered, it's job done. This is a misnomer, a digital transformation should be viewed as enablement. In the past, I treated this as the build of an ecosystem, a secure and interoperable ecosystem that enables the org to adopt and if necessary adopt to new ways of working.
Conclusion
Digital Transformations carry significant risk, engaging the right people and using an approach that suits your organisation will go a long way in delivering a positive result. The likelihood and impact of the common failures can be mitigated if the delivery is designed with these in mind. I've used this approach and it works.
Driving Outcomes Across Cultures | Strategic PM | Multilingual Coach
3moThanks for sharing, Corin
Fractional IT Manager @ Target State Consulting | Driving Digital Transformation
3moThere's a counter point to this as well "A red flag should be anyone pushing a specific product to solve your problems when they don't fully grasp the root cause. " A red flag is also anyone searching for a solution before they've figured out what problem they want to solve. It's the difference between "We want to implement a CRM" vs "We need a better way of trackign our interactions with customers"