Transformations are flavor of the month. It is no longer enough to launch “initiatives,” “programs” or “projects” to undertake work. Instead, we launch agile transformations, digital transformations and productization transformations. They sound more revolutionary, more dramatic and further reaching. Our organizations will emerge reborn, uniquely positioned to compete in a new world of opportunities and growth. Like a larva transforming into a butterfly, we can now fly!
Well, that’s the idea and the promise of the consulting companies that sell transformation services. However, what really happens? Can the average organization actually become a disruptive leader just by adopting the structures, tools and processes from the real disruptive leaders? Or, is it like buying the same shoes as our basketball heroes wear hoping they will transform us into slam-dunking superstars? The reality is somewhere between these extremes. Any company can improve, but we should not expect to become something we are not.
Let’s look at some of the popular transformation services on sale and examine the promise and truths they hold.
The goal: Agile transformations move organizations from working with traditional project management approaches to using agile approaches. They also seek to change the way organizations are structured and run from a top-down, command-and-control model to a more business- and customer-led, value-driven approach.
They aim to instil lean concepts of respect for people, minimization of waste, and value delivery. They employ a more trusting Theory Y view of workers as willing contributors rather than the traditional Theory X view that workers need close supervision to work hard. They encourage workers through intrinsic motivators such as empowerment, autonomy of work, and belief in a worthy purpose rather than carrot-and-stick approaches.
The claimed benefits: Agility allows organizations to respond to change more quickly since plans and work are done in smaller batches with frequent checkpoints. This allows changes in direction to be made when feedback indicates it would be desirable. The evaluate-as-you-go and learn-as-you-go aspects of iterative and incremental development help organizations manage complexity and uncertainty.
Agile approaches allow for the delivery of value sooner since work is prioritized via business value. The empowerment and intrinsic rewards offered result in happier, more engaged employees. Allowing workers to design their own workplace and work practices results in a more loyal and productive workforce. A mantra of one agile approach is to “Change the world of work.”
The reality: Agile is much easier to implement at a team and project level than it is at an organizational level. Teams quickly see the benefits of frequent collaboration and business engagement. Tools like product backlogs, kanban boards and release roadmaps bring much-needed visibility to design work and problem solving that often manipulates invisible data and ideas. Iterative development of small batches of work, with frequent reviews, provides better insights into progress and issues than sequential, large-batch development. While some people find the “let’s try something” approach counter-intuitive to rigorous upfront planning and design, most understand the risk reduction and true requirements validation benefits.
At the organization level, it’s a tougher sell. The initial confusion and apparent chaos that comes with establishing empowered, self-organizing, self-managing teams can seem like the inmates are running the asylum. What happens to supervisors and managers? In some organizations, departments are built around functional silos. If I was head of the quality assurance group and now all my people report into individual teams, what’s left for me to do? How do I justify my yearly budget (and position) with my headcount down to zero?
Organizational structures often reflect their culture and decision-making style. This may be hierarchical, flat or distributed. Truly transforming the organization to be agile requires a change of structure, which means changing the culture. Not an easy task, and not something to be undertaken lightly. It requires sufficient buy-in from the very top through every layer to the bottom.
Agile transformations often stall at the organizational level. Instead, we see pockets of conversion and pockets of resistance. It often takes changes in roles for the transformation to occur. However, just changing the way teams operate brings many benefits. While not really an agile transformation, a “switch” to agile project operation within a traditional organization can still be very beneficial.
So, while true agile transformations are rare, agile implementations are common and still worthwhile. The organization may never grow wings and fly as promised by consultants—but if it learns to wiggle more efficiently, avoid danger, and eat faster, that might be all it needs.
The goal: Digital transformations aim to convert and grow business in the self-serve digital domain. They do not have to involve websites, but many do. Rather than visiting offices or calling in for service, customers self-manage through apps and websites that greatly reduce labor costs and offer almost unlimited scaling opportunities.
The claimed benefits: Cost reduction and closer engagement are the main claimed benefits. They use websites and AI-powered chatbots to handle the majority of customer questions and interactions. This reduces the need to have as many people employed at physical locations and answering phone calls. Banks and insurance companies are undertaking digital transformations to offer services in convenient formats for customers (mobile phones) as well as reduce overheads.
Encouraging customers to manage their services via mobile apps also opens up options to ping, notify and promote upsell opportunities. It is cheaper and easier to push promotions and “exclusive member benefit offers” to people who install apps than compete for attention in traditional advertising channels. Apps also let companies gather additional marketing intelligence like location, contacts, spending habits, etc.—all additional fuel for promotions and potential sales.
The reality: Building compelling websites, apps and AI services is no small undertaking. Many organizations go through the significant expenditure to discover that only a portion of their customer base embraces the new options. Organizations then try carrot-and-stick paperless discounts or paper-based account fees to incentivize the desired behavior.
These new websites and app projects will never be finished or done. Since they now represent the organization's face and communications vehicle, expect ongoing investment in their upkeep and technology refresh cycles. When looking at the potential savings, do not underestimate the likelihood of initial build costs to spiral—and integration into existing back-end systems to be orders-of-magnitude more costly and time-consuming than anticipated.
However, it seems an inevitable trend. Using established content management systems and app frameworks can help rein in costs. Being at the forefront of technological capability is only paramount if your core business is selling technology services (Amazon, Apple, Google, Microsoft). For everyone else, fast-follower (or even majority-adopter) is probably fine. Digital transformations are real, already here and unlikely to be fading anytime soon.
The goal: This is the transition from using projects to build software systems to building and viewing software as long-term products. As organizations realize software represents a market differentiator, they recognize their systems will never be “done.” If they were to finish, it means they are no longer innovating, improving or competing.
So, they move from the start-stop world of software development through projects and instead adopt continuous development and drip-feed funding models. Historically, organizations staffed and funded projects through vendors and contractors using capital expenditure models. The switch to software as a long-lived product or service changes both staffing and budgeting. The increase in cloud-based hosting also raises the question of opex (operating expenditure) versus capex (capital expenditure) funding.
Organizations often reach out for help making these changes to development, staffing and funding models. This is the new and emerging world of productization or “continuous digital delivery.” It involves restructuring and forming long-lived product teams with everyone present to develop and maintain the software products over its entire lifespan.
The claimed benefits: By eliminating the handoffs between development teams and sustainment teams, more knowledge about the system, and how to extend it, is retained. Fewer handoffs in general is one of the biggest benefits of switching to products instead of projects. Handoffs are very wasteful—they contribute to the eight lean DOWNTIME wastes…
…all of which can occur when one group hands off work to another group.
By creating stable teams that are aligned with developing and sustaining long-term products, organizations can wean themselves off unpredictable vendor models. From a budgeting perspective, estimating the burn rates and capabilities of stable teams is much more reliable than estimating how long a new vendor-based team will take to complete some work.
Stability, continuous development and better knowledge retention are all compelling reasons to trade projects for products. The difficulties come in the transition and available support.
The reality: Switching from running traditional stop-and-start software projects to continuous product development is still a new idea. Usually, organizations have a suite of currently executing projects that still need to be delivered on schedule. Existing vendor contracts may make it difficult to switch to the onsite execution approach favored by continuous digital delivery.
Finance departments are typically set up to evaluate and approve requests for expenditures based on one- or multi-year ROI projections. In the continuous development world of productization, the spending never stops.
Instead of project-based funding, small teams create minimal viable products for evaluation. If they show promise, they get additional funding in more of a venture capital-style model. New metrics like customer market share and profit-to-funding ratios are used.
The benefits are real and don’t require a major upheaval to organizational culture or structures. However, experience is thin on the ground along with books and training courses. It’s like using what we today call agile approaches in the 1990s. There are early adopters, conference sessions and blog posts, but far to go before the idea even approaches the chasm (let alone crosses it).
“Transformation” is probably too grand a word for the degree of change most organizations achieve. However, as so many ideas compete for our limited attention spans, it would seem crazy to merely name a change initiative a “rollout” or “improvement” these days. People have become desensitised to reasonable names and seek revolution and excitement to generate the interest they need to participate.
We should not expect traditional organizations to truly match digital-first companies like Spotify. They were founded to disrupt existing businesses and came without the baggage of a traditional client base to support. (Also, they are led and staffed by people that share different values than most North American institutions.)
Their ideas may be great for other organizations to experiment with and adopt what works, but what makes them truly powerful is that the ideas were created internally and vetted through experiments. Copy the concept (internally generate new processes to solve local problems), but not Spotify’s actual procedures.
There is nothing wrong with buying the same kind of shoes as Michael Jordan wore (heck, if the placebo effect gets you exercising more, they were likely a good purchase). However, don’t leave your day job to sign up with a basketball team until you’re sure you are world class. Today’s transformations bring many benefits—as long as you take the “transformation” claim with a grain of salt.
[Note: I first wrote this article for ProjectManagement.com here]