Most projects that fall into the realm of Digital Transformation (DX or DT, depending on your analysts of choice) will fall short or outright fail.
We have cataloged these many mishaps from the stories we gather from Mobile Thought Leaders (MTL) and the Digital Transformation Thought Leaders (DXTL). We collectively refer to their root cause as The M-Gap. The projects we include in this consideration typically involve mobile technology, but it isn’t a technology problem. Its a Management problem. The structure of the organization, the governance models, the budget practices, pretty much everything aside from the technology will actually be what gets in the way and dooms these otherwise strategic initiatives. If you feel like your organization is just getting started in DX, then you ARE behind – and the reasons that you have waited this long are the problem – you have an M-Gap – and you know it.
But knowing you have a problem isn’t getting you much closer to the solution.
It is well beyond the possible scope of a document this length to give you everything you need to diagnose your M-Gap, but we have grouped our stories into some common themes that many members say resonate with their experiences.. In general, M-Gap problems are alignment problems. DX requires that disciplines and practices that might otherwise be lumped into “IT” be integrated deeply into the ways that problems and opportunities are addressed throughout the organization. Likewise, there are very few IT initiatives that should not be reconsidered in terms of their business value return. A balance must be struck between addressing the digitization of each part of the organization and in selecting or designing solutions that fit into a larger framework. Some efforts will be part of the overall strategy and have a multiplicative impact and others will need to be recognized as small tests that may challenge or support the larger strategic thinking.
In the end, the focus of planning efforts will look more like the weekly/monthly cadence of an agile development team than the common current focus on annual budgets. This is a major realignment that may take years, but every step can feed the flywheel of innovation in the organization
We find that identifying a gap in alignment along with a little communications sensitivity can go a long way to help all the stakeholders get a bit more comfortable with the changes that must be made to allow progress. I have ordered the five most common problems in order of commonality and impact. This list isn’t comprehensive but it does cover more than 80% of the problems we regularly encounter.
- BUDGET: More than half of the DX initiatives that stalled or failed did so due to a misalignment between IT budgets and Line of Business budgets and a misappropriation of the costs and potential benefits. Aligning line of business budgets and IT budgets, as well as what returns are measured against them, stalls or kills more than half of the DX initiaitves. While there are some portions of the current IT budget that are predictable and purely a “Cost of doing business,” you will need to structure more of what has traditionally been considered part of the IT budget to be be seen as business investment toward business returns, what Deloitte refers to as Outcome-based budgeting. This means rethinking how investments are made, ROI is measured and how employees are compensated for success. If you are trying to cut budget out of the current IT budget to get started, you are barking up the wrong tree. Organizations have spent the last few decades squeezing IT budgets and leaving almost nothing for experimentation, let alone error. We often see managers with bonus or MBO structures that only recognize cost cutting, up-time, or other metrics that leave no room for experimentation or developing new expertise. This leaves the organization without resources to play with or the inclination to participate in impacting business outcomes, which leads to our next topic…
- FOCUS: Every bone and muscle of the organization has likely been honed to deliver incremental improvement and cost reduction. If this is the case, you can be proud of having an efficient organization, but it wont work for transformation. Gartner analysts have written extensively about the need and the benefit of slicing organizational goals in two and leaving sufficient resources in place to maintain the “lights on” technologies (Mode 1) while creating new structures in the organization for innovation (Mode 2). From the front lines to the board, you need to have a plurality of stakeholders accepting that the past can not be the model for the future. Some sacred cows must die. If you are just now getting around to converting paper forms to apps, it is probably because you had the same people that deliver “lights-on” services trying to find some time to innovate. Converting paper forms isn’t really an innovation anymore. Its an incremental improvement. This approach is both inefficient and error-prone. You need people and budget focused on returning business value through digitization to get to anything that really looks like transformation.
- OWNERSHIP: Should IT own digital transformation? Do you need a new DX Czar? Wrong questions. Digital Transformation is fueled by agile methods, cross-platform teams, and collaboration. The ideas and understanding needed for DX are scattered around the organization and the muscles to make DX effective are new. Many organizations have taken the well-documented route of forming a Mobility or Digital Center of Excellence (COE) or some other new body but this can be a trap. MTL Members tell us that sequestering DX to a separate group without also giving them budget and an executive mandate is a wasted effort. Unless you give this new org resources and authority (see #1 and #2), nothing will change. Lines of Business, IT, and leadership must align around the belief that integrating new applications of digital technology AND rethinking how business is approached can yield significantly better results and that the resulting organization will likely be organized differently – but we don’t know what that structure is yet.
- VENDOR MANAGEMENT: You don’t know enough about what your organization needs to write an RFP. Just admit it now. Small experiments. Fail fast. Your path to Transformation will go a lot faster if you change the way you think about vendors and ROI from vendor relationships. You need to be willing and able to fail and not cut off any heads. You need to trust in positive intent. You are going to have to find new wats of measuring vendor value. The companies that are ahead of you, lapping you in some instances, are the one’s that have gotten good at allowing small bets to fail and MTL members tell us this is hardest to do when it comes to vendors. If you had all the expertise you need you would have already been well on your way. We hear many stories of organizations asking a vendor to help with an initiative, give them lots of ink-conceived guidance, ignore their advice and then fire them for the outcome. Don’t do that.
- LANGUAGE: As with so many aspects of life, alignment (and understanding) requires that we develop a common language to discuss both problems and solutions. Both IT and the business need to learn bit of each other’s terms and ways of recognizing value. For the business, we have seen the most powerful tool for this in the framing of requirements as User Stories. There are plenty of materials available about how to craft a good User Story – some of it written in language that everyone can understand – but the key here is that a User Story reframes a problem or issue as a functional outcome that ultimately is the test of completion and, over many iterations, teaches both the consumer and the producer of the solution to make fewer assumptions about what the other side is thinking. For IT, the big opportunity is forcing them to frame all their activities in terms of business outcomes. Everything has a value and a cost and both IT and the business should agree on both sides of the equation. My favorite tool for this is the Reverse Income Statement. I have posted elsewhere on this tool, but the magic here is that you have to list all your assumptions as numerical values. Even if you don’t know the value, you have to put something down as an assumption. This will be most painful for the security-oriented team members.
The good news about getting a later start is that there are many stories and experiences to draw from as you embark, but the time has come.
These topics will continue to be interwoven with topics of technologies and use cases during 2018. If these issues sounds familiar and you are either seeking insights or have insights to share, we would love to have you join Mobile Thought Leaders. Learn more at http://www.mobilethoughtsleaders.com or our LinkedIn Group https://www.linkedin.com/groups/4687169