Context & Method: Two Pillars of Business Agile Transformation

By Haydn Shaughnessy and Fin Goulding

Abstract: Transformations are notoriously difficult to manage successfully, with a well known failure rate exceeding 75%. Although there are many analyses of what goes wrong in transformations, none of these address the fact that many companies start from a dysfunctional state that will have engendered multiple conflicts and inefficiencies. The business world needs a method that can explore these dysfunctions and yet render the transformation process as a simple, manageable learning process. We argue that the combination of Transformation Sprints and the concept of generative operating model delivers the necessary method and context for successful change.

Transformation and context

Transformation to truly agile businesses represents a real challenge to executives and their teams but also to the advisors that usually have a solution to offer in difficult times. Context is the source of that challenge.

We find, in our work, that many companies face the same problems when transforming. That would normally be a positive. Common issues open up the possibility of replicable solutions. Companies build experience in a Smithian way, repeating the same activities so that we become expert. In the absence of sufficient experience, consulting firms offer models (Spotify, SAFe®) which sometimes amount to saying, we have to do something and these models are about all we have. To put it bluntly, they offer cookie-cutter transformation.

However, context works against this neat idea. Every organisation is unique in some aspect and unless we explore context, we run the risk of ignoring potential failure points.

Context can be any of the following items, and more: customers and their changing needs, the contours of economic change, a company’s IT infrastructure, relationships within the firm and who gets on well, the vulnerability and safety needs of staff, current ways of working, silo structures, location, hierarchy, governance and decision processes, exposure to regulatory requirements and so on.

These problems can have a common source and our experience points to one main culprit – core platform incompatibilities (basic lack of technical integration, legacy and system replication). Having core platform issues is reflected in a number of ways.

Business people expect their systems to deliver what they want, but often that is a sheer impossibility. There is also a truism that gets overlooked. While IT has a long history of transformation, business tends to have a long history of cost-cutting rather than real cultural change. Business people understandably resist change for this and other reasons.

Dysfunctionality is therefore a key problem for a transformation to solve. The solution, however, will be different depending on how those contextual elements shape up. A core platform resolution might seem possible but there could be such a torrid history of conflict between, say, IT and the business that the chances of a solution are radically reduced.

Or it could be that the core platform problem has a solution but it means retiring old products or services that some key customers still want to have, and insist on.

Or looked at another way, some aspects of an organisation’s applications and infrastructure are now highly specialised so change relies on the cooperation of subject matter experts who, first, may not be flexible enough to guide change; or, second, may be at odds with a transformation that might put them out of work.

These nuances, in themselves, don’t derail transformations. But they make the design more difficult. Faced with difficulties, executive teams are often persuaded to buy into a consulting model or an IT framework.

Consulting models and IT frameworks

The consulting industry business model relies on replicating the same solution across different clients. In the early phases of a new business trend (say supply chain management), a consulting firm does the real solution building. The next couple of assignments allow them to bring more consultants up to speed with the techniques and by the fourth or fifth, the approach to change is like a well-oiled machine.

What gets in the way of replication is the kind of context we have touched on above. Context can also be the fact that a firm has already outsourced too much technical management, or its previous transformation efforts have created enemies within (there is insufficient psychological safety), or it can be the firm really does not understand its markets or the needs of strategy. It knows it needs change but not really why.

The consulting industry has developed replication methods through models like the (mythical) Spotify Model. As a form of change, it usually focuses on the ways of work and, in particular, team organisation. Regular team structures are disrupted and replaced with guilds, chapters and other relabelled collaboration spaces. This partially adapts the company operating model away from conventional team structures to something new.

This is fine, as far as it goes. But what if the operating model infrastructure is fundamentally broken or market insight is poor and strategy is pointing in the wrong direction? Or if actually the needs of a new operating model would be met by a new approach to data?

Spotify and SAFe-type approaches struggle with these infrastructure and upstream realities, which represent the business side of agility, not just IT.

The most popular framework of the day is SAFe®. We say popular advisedly. SAFe® is becoming commonplace in large organisations but our experience is that the people who are asked to work in a SAFe® environment struggle to see the wood for the trees. They are focused on many new steps in the value management process and lose sight of how to change the firm’s relationship with customers. They are good on internal issues but don’t reposition to meet external change.

In reality, SAFe® suits the leadership team because it maintains governance and oversight, whereas the teams crave more independence.This is another source of conflict between leadership teams, consultants and employees.

Finally, transformations themselves can quickly become traditional large projects, with all the dangers that carries. The focus quickly becomes the start-up of work, and tasks such as the project or program plan, acquiring resources, setting out the GANTT chart, agreeing governance etc. The program is up and running but what is changing when you replicate traditional governance structures?

The startup phase is comfortable territory for people and allows them to deploy familiar cookie cutter tools for project management. In effect what happens, is that a project to change the organisation launches with the use of old fashioned techniques.

The Sprint approach

Transformations need to work differently from Day 1 if they are to inspire people with the belief that change will be real. They need to be conceived in a different way from old projects. At the very least, the transformation has to be designed so that it avoids familiar pitfalls from the days of large project failures.

Without listing all the reasons why a transformation might fail, some are obvious:

• They can be big and unwieldy.
• The design of change takes place across many months and can involve inserting all kinds of theoretically nice-to-have elements that get in the way.
• They push value out to the end of the transformation, which can be years in the future.
• They fail to address existing dysfunction in the AS IS state, in particular glossing over core platform problems that often create that dysfunction.
• People are not trained in or skilled at remodelling a company’s basic operating model but are thrown in at the deep end.
• Leaders may have insufficient credibility or interest (the “hospital pass” effect).
• The “model” can be inappropriate and cause serious engagement issues.

Many of these dangers are known to people from the very start. What then could help us get round them?

The requirements for success are:

• We understand our existing operating model (the AS IS) or in other words we have fully explored our own context.
• We have a strong sense of where we want to get to (the TO BE state).
• We are prepared to address dysfunction and its root causes.
• People are bought into the concepts guiding change.
• People are not fixated in administration tasks.

One problem with this list lies in the concept of a TO BE state. There may be a variety of new objectives that arise in discussion of transformation but that’s not the same as knowing what a new operating model should look like.

We contend that the TO BE is bound to be an unknown and cannot be described coherently at the outset. The TO BE state has to be discovered as the program rolls out and as experience builds. So we need to add to that list an item such as: Have the opportunity to discover the best operating model for the future.

We also need to add: Being able to develop the skills to understand operating model design.

And because companies usually have a record of failure with large projects and programs (that’s the reason for moving away from Waterfall projects), then the list needs to include: Having the capacity to deliver value early rather than at the end of a program.

Success therefore looks more like this:

• We understand our existing operating model (the AS IS context).
• We have the opportunity to discover and design an appropriate future operating model (the TO BE state).
• We are prepared to address dysfunction and its root causes.
• We can learn the skills needed for discovery and design of an operating model.
• People are brought into the concepts guiding change.
• People are not fixated on administration tasks.
• We deliver value early.

The basic techniques for aligning behind those success factors already exist in the form of Sprints.

Sprints were introduced in scrum as a way of setting shorter timescales for value delivery. They are also time-boxed so that teams don’t succumb to scope creep and can interact more regularly to discuss objectives and progress. They are an antidote to the problems that arise in big projects. They are also more team-friendly.

The Transformation Sprint and the Generative Operating Model

There’s an additional issue to consider. Transformations usually involve transitioning various aspects of a corporate operating model. In a longer article we would dive into the idea of the operating model but in summary, we believe operating models have to be generative.

The diagram below shows a generative operating model. In place of fixed structures such as logistics, finance, HR and so on, it has activities such as learning mechanisms, value discovery, cyber-security. The elements of this model represent human activities that need to change.

A company might find, as it explores its context, that the set of activities might be different but we think it won’t be vastly different. The idea of a generative operating model denotes simply that we learn about our needs from exploring our context. We then need a mechanism to learn the skills that enable us to make the right changes.

The Transformation Sprint

Creating a transformation in a sprint format could be thought of as difficult. After all, transformations by their nature are comprehensive. Nonetheless, we prefer the sprint approach and we think of it as a valuable stretch goal.

We time-box the Transformation Sprint to four weeks. To succeed in that time scale means being very well prepared, so all meetings and feedback channels are ready and there is no administration to get in the way of sprint activities.

The sprint can also pick off any activity area in the operating model (see diagram) and take a sprint approach to each, in a prioritised way.

Given those prerequisites, here’s how to plan a Transformation Sprint. We already mentioned the four week time-box. Within that there are six phases:

1. Phase 1: Perspective gathering from DAY 1 onwards. We use about ten days on interviews, though patterns emerge early on, which you can record in a draft Issues Document.
2. Phase 2: Concurrent with Phase 1, we access and begin analysing a range of business strategy and technical documents. We will show you later a set of templates for doing this and more are available on our website.
3. Phase 3: The Issues Document. We build a list of significant issues from the interviews and the documentation. The list will start long but eventually, reduce down to 10.
4. Phase 4: Describing the company’s AS-IS state and a draft of any emerging target operating model(s). This usually involves describing dysfunctionality in the firm, often caused by incomplete transformations and the coexistence of two or more operating models. Two or more operating models may be competing with each other, for example.
5. Phase 5: Playback. A day-long or at least half day playback with senior leaders where they prioritise issues and make real decisions.
6. Phase 6: The outline design of a Lighthouse Project that will address dysfunctionality and set the transformation up for success as well as bring you critical experience in thinking in new ways about target operating model design.

Conclusion

The transformation to an agile, digital business is notoriously difficult. There is no agreed method and masny of the analyses of what goes wrong fail to tap into the conflict and dysfunction that characterises many firms and worsens during change. Scaling down from the temptation to run big transformation projects to get from an AS IS to a hard-to-know To BE gives companies vital opportunities to simplify the change, explore their context and learn the skills needed to prioritise and build a new generative OM.