TechTalk Daily
The rapid pace of change. Velocity. Many use those terms to describe what everything about business feels like today. Despite the global pandemic slowing down parts of the economy, the transformation to digital seems all the more obvious and more critical. The time to wait is over, and now is the time to act. While engaging in digital transformation quickly and with purpose is absolutely necessary for most businesses, doing so with overly rosy expectations of express returns and swift transformations might prove more the first step toward failure than the first step toward success.
Digital transformation takes time. It is an enormous undertaking with many moving parts. It requires a deep understanding of the organization’s current state and a plan for evolving strategy, customer experience, measurements, work experience, operations, technology—the organization in total—toward a new way of thinking, acting, serving, and reflecting. In addition, organizations need to undertake design work that includes strategies and experiences.
The assessments, planning, and design work does not happen overnight. Fail to do that work, and a transformation initiative falters on a shaky foundation. Plans won’t tie to reality—and accomplishments may implement the wrong thing or deliver the right thing at the wrong time.
Even if the organization constructs a large, detailed plan, that may not be enough. The pace of change is fast. Velocity does overtake the slow. Ideally, digital transformation involves agile ways of working that drive incremental change, learning, and adaptation through smaller projects that offer clear benefits against the backlog of organizational needs.
Big plans promise a lot. But, mostly, they offer visibility into the future for which they can’t deliver. What is more constant than an overly detailed plan for everything is a highly detailed, prioritized list that reflects a vision for the organization’s needs. Agile projects can pick off the most critical areas, working in parallel when necessary and coming back together for integration.
Becoming agile requires a new mindset. It may require an agile project to adopt agile thinking. Because agile approaches to work drive valuable but incremental change, they rarely over-promise, but they do under-plan to a traditional manager. Every leader living in a world of rapid change needs to accept lower visibility to the future, shorter timeframes for execution, and more incremental value realization.
A good transformation project will be able to see a few months forward, but unlike big projects that offer huge returns years down the road, an agile approach will provide clear wins every few weeks. Realizing value will come by looking at accumulated actual results, not false promises against a backdrop that may invalidate the plan long before its value sees the light of day.
Organizations can be good at anything they invest in. But at the onset of any work, an organization is what it is. And if it doesn’t understand its capabilities, it runs the risk of attempting to deliver in areas where it lacks competencies, not to mention expertise.
During the assessment phase of digital transformation, organizations need to capture their capabilities clearly. Capability mapping will inform sourcing and hiring strategies.
Depending on the limitation, the effect on the project may be immediate or longer-term. Organizations need to map their capability against time, not just required skills. If the initiative specifies agile work and agile competency is low, the effect will be immediate. Expertise in machine learning (ML) may not be required for several months, as non-ML sprints fill the queue.
The map will also suggest partnerships, from general leadership for transformation to more specific skills with no internal career path, may play a role.
Organizations can be good at anything. They have to decide how to fund their competencies, either through hires, outsourcing—or taking the time to bring current staff along. Starting a project without understanding limitations will too often find the project standing still.
Low hanging fruit often drives project thinking. The definition of low-hanging fruit, however, often lies in the speaker’s mind. For example, is the low-hanging fruit a quick technical win? A rapidly transformed function already halfway down a path? An immediate cost-saving? A quick new way to engage customers?
Sometimes low hanging fruit seeks to model success back, attempting to transform an isolated part of the business in service to prototyping and learning. The problem becomes apparent, eventually, and none too soon, that the silo isn’t a model for the remainder of the organization. While the learning may be valuable to that operation, it may not have broad applicability to the entire organization.
Strategy and vision, and the prioritized list of component items to build, change, or implement, should sequence transformation efforts. Low-hanging fruit becomes a distraction, not a way of proving conceptual value for digital transformation.
Choose instead to prioritize the transformation of underlying functions that influence the fundamental ways in which the organization works—this will drive change throughout the organization. For example, rather than implement window dressing on a customer experience, perhaps prioritize the Point of Sale systems that underlie abandoned shopping carts. If the engagement doesn’t convert, then it doesn’t add value. Reducing abandoned carts leads directly to higher revenue—across the organization, not just in a silo.
Executives distanced from projects by distraction, interest or responsibility are ill-placed to force deadlines on transformation projects. But, on the other hand, those responsible and accountable for leading transformation need to be prepared for stressful negotiations when executives want something they can’t have when they want it.
Star Trek’s original engineer, Montgomery Scott, often hinted at his secret of looking like a miracle worker. He overestimated repair time and always delivered well ahead of his estimate. Disney does the same thing by posting very conservative wait-time signs in their park queues like “60 minutes from this point,” knowing full well it is only 45 minutes from that point on most days. As a result, guests feel like they won some time back when they reach the ride’s seat ahead of expectations.
Sharing these examples doesn’t imply that you lie about plans or deadlines, but that you provide insight to executives about what can be accomplished and how unrealistic deadlines translate into missing features and lower value. The Disney executives inline (if they stand in line) know full well that the queue signs are conservative. Executives funding digital transformation require the same level of transparency for their projects.
If an organization adopts agile approaches, agile thinking needs to find its way into the executive suite, perhaps earlier than elsewhere. Executives need to understand ideas about incremental value, even if they don’t become ensconced in more arcane agile terminology.
With all of that said, one of the reasons agile works is because it doesn’t over-prioritize into the future—when things change, priorities change. If something is actually needed sooner than later, an agile approach is more likely to deliver it with less turmoil than a project that just gets put on hold in light of a new requirement. In agile, the backlog gets updated, and new priorities move to the top. Other transformation work likely proceeds in parallel to the new condition.
Sometimes reality does force hard deadlines. Transformation leaders need to sort critical requirements to business continuity from those prompted by an executive just trying to assert control.
Pushing too hard often becomes a distraction for the steady pace that a transformation project requires. As outlined above, digital transformation initiatives may be subjected to nudges arriving from multiple vectors. Those leading digital transformation projects need to be vigilant, as teams executing on work may not see dangerous patterns emerge until it’s too late.
– Daniel W. Rasmus, Serious Insights