Media Query Source: Part 12 Connected Futures (Cisco blog)Classic digital transformation blundersOnly viewing success in light of original visionTakin
My responses ended up being included in an article at Connected Futures, Cisco's executive insights magazine (September 5, 2018), entitled "5 Classic Blunders of Digital Transformation". Extent of verbatim quote highlighted in orange, paraphrased quote highlighted in gray. Above image from cited article. Note that this article is seemingly no longer available at Cisco, but was archived by The Wayback Machine here.
The responses I provided to a media outlet on May 24, 2018:
Media: Looking for experts on digital transformation to comment on the top classic blunders companies make while trying to digitally transform. What are the classic blunders and why do they happen? Please also share tips/steps to avoid making these blunders and/or on correcting course.
Gfesser: The first grouping of classic blunders includes (1) not communicating what "digital transformation" means, (2) limiting scope of transformation to technology, and (3) taking on too much at once.
A few years ago, I sat in a "digital transformation" discussion presented by a consultancy. The key visual that the presenter had to share was a high-level architecture diagram that they said represented digital transformation. The main topic of discussion prompted by the audience can be summarized as follows: "How does this diagram represent digital transformation? I'm not seeing anything different here than what we're already offering to clients."
In a nutshell, the presenter responded that business development needs to start using the term "digital transformation" because this is what industry research firms such as Gartner are using in their reports, and because client execs read these reports, there needs to be alignment with everyone speaking the same language.
As the discussion evolved, the audience began to ask whether this was just marketing, and while this presenter did not explicitly state as such, many presentation attendees came to this conclusion: quite simply, they didn't see anything materially different.
Unfortunately, this presenter provided a wanting definition of "digital transformation". While it is quite alright to use this term, the reality is that because it has become an industry buzzword with varied, often vague definitions, it needs to be defined for all stakeholders involved in any way with such efforts.
Regardless of definition, most typically agree that the scope of digital transformation goes beyond technology, beyond modernizing technology. Application functionality, for example, can be rewritten with modern technology stacks. Efforts such as this are often very needed, but rewriting doesn't explicitly address how work is being done, and doesn't necessarily address the business or how users might want to operate. Additionally, modernization itself doesn't in itself focus on how the problem space might be reimagined for additional monetization or a shifting of marketplace strategy.
Don't get me wrong: technology is an important component of digital transformation, oftentimes encompassing a large component of such efforts, because technology can have an immensely transformative effect. The likely questions that need to be answered by companies can probably be summarized as follows: "What is the end goal of our digital transformation?" and "How do we reach this goal?" If the result doesn't holistically address the company, the means to this end likely doesn't involve digital transformation.
Lastly, taking on too much at once is a very real risk. For a long time many have had the sense of what a "big bang" effort entails: essentially an attempt to do everything in one go, and oftentimes trying to perform all planning up front. While much progress has been made with iterative planning, defined scope can simply end up being too large a goal. While scope can be broken down into iterations as well, the risk here is to only view success in light of the original vision.
While I tend to agree that one needs to think big with respect to digital transformation, it also makes sense to take steps. Agile practitioners often talk about the "minimum viable product" (MVP), but sometimes forget that this approach is intended to deliver a minimally functioning product in order that feedback can be used from users as input to evolve the product as it is built.
En route to the MVP, I typically build one or more proofs of concept and/or proofs of technology, which feed into the building of prototypes on which the MVP is later constructed. So in my view developers are also users because applications need to be proved out. But these are all incremental steps. I've seen clients take on too much and fail because their concept of "minimum" was a bit too aggressive.
Keeping in mind that failure can be a good thing that feeds subsequent efforts, there is also failure that takes too long to be realized because an incremental approach was not adopted.
The second grouping of classic blunders includes (4) not fostering relationships between departments, and (5) not fostering an open company culture.
Because digital transformation involves more than the technology that is being used within a firm, relationship building between departments needs to be fostered. In addition, firms with fragmented or matrixed teams can benefit from restructuring so that teams are cross-functional and in many cases organized around output viewed as products rather than projects.
Cross-functional teams are more agile, which means that changes are more easily made to enable what is needed, especially in reaction to input from customers. And the distinction between products and projects is important because products are long-term company assets that typically have extended lifecycles.
While the concept of "project" will likely never go away, a project focused culture often leads to short-term thinking due to fixed end dates, with these dates prioritized above the actual work product. A product focused culture enables continued reassessment of priorities for the work product. Dates are still involved with such a culture, but timelines are typically much shorter in order to react to user feedback, and to enable continuous delivery.
I mentioned to a recent client that open company cultures help foster digital transformation: this goes for access to source code, documentation, and all other forms of communication. While changes to culture can come more easily to some firms, some period of time should be expected for most, especially for long-lived organizations.
Clear visibility is a key reason for the rapid and widespread adoption of open source software, which routinely offers code and product roadmaps, as well as the participation that it welcomes from the developer community in terms of general feedback, bug reporting, and the ability to submit changes. And these principles can be holistically applied to firms.