One of the areas we have been working on is exactly how to implement Digital Transformation projects.   At Agile Elephant we are all old enough to have seen many implementations of software, processes, ways of working etc., and have seen flops, failures, fads that come and go, and even some successes.  One of the things that has exercised us is the best approach for Digital Transformation.  As our approach is to look at “what works, what doesn’t” when designing “what’s next”, we thought it may be useful to share some emerging thoughts.

To no one’s great surprise, we found failure by and large followed the “Anna Karenina Principle” – i.e. there are multiple modes of failure.  But some are more obvious and predictable than others, and one of the major ones is using inappropriate project planning, implementation and progressing approaches.  It’s worth looking at the pros and cons of the main approaches, the relative benefits are summed up conveniently in Wikipedia:

(Wirth’s law is a computing adage which states that software is getting slower more rapidly than hardware becomes faster.)

To summarise these approaches:

Agile methods  are essentially adaptive, a broad plan is laid and development adapts to situations as they occur – very good for building things that don’t exist, but can go haywire and build up costs fast.

Formal methods mostly try and anticipate plan for every contingency in advance, and do value and risk analysis to prioritise and cater for unknowns, and everything is modelled.  Work well in known environments but often go badly wrong trying to do new things.  They are still essential where cost of materials and people is very high and quality of outcome is critical, e.g. Aerospace.

Plan-Driven is the approach of defining a project plan upfront, then putting a team together to manage it in all its vicissitudes over time.  It lies somewhere between these other 2 approaches.

As Digital Transformation is fairly “new fangled” and many different and relatively new tools are being tested in practic at the same time, one thing that is certainly true is that these projects will be very hard to plan in great detail upfront, will need a lot of change during implementation, and there will be a lot of iteration.  That suggests a need for a strong element of the Agile approach.  Unfortunately, that’s not enough as some of these projects will be of high criticality, and the initial culture will probably be more comfortable with some form of order, so a plan driven approach is important. (My own experience of Agile development is it is very good AFTER you have set up the overarching frameworks, but in more detail than Agile likes. They may change, but at least you have an original yardstick to measure variance from). The highly disciplined Formal approach is probably not appropriate in the majority of cases.

There are hybrid models, trying to allow some form of adaptability within a structured plan.  To us the most useful of these are encapsulated in the term Agile Management, which is essentially the combination of Agile software production with elements of the well tested Just In Time / Lean Operations operating model (or more accurately, the disciplines within it – data transparency, self solving work teams, continuous improvement, designing out errors etc.) and we believe this approach holds the best hope.

But even Agile Management really only focuses on software and methodology development, and not implementation of new ways of working, which is more a change management process.  And if there is one thing any Digital Transformation will have, it’s a lot of new ways of working.  If you look at the lasting principles of change management, any approach must be able to get over the “Machiavelli barrier”, i.e.:

There is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things. For the reformer has enemies in all those who profit by the old order, and only lukewarm defenders in all those who would profit by the new order this lukewarmness, arising partly from fear of their adversaries … and partly from the incredulity of mankind, who do not truly believe in anything new until they have had actual experience of it.

Any plan thus needs to show people why you are doing this and what’s in it for them, that they won’t get shot if they do it, and that it will work – thus, as well as A Plan and a reasonably agile execution approach, there needs to be a WIFM and a WYSIWYG:

WIFM – What’s In It for Me?

Any change programme must have these elements to persuade the “luke-warms”

• Benefit management objectives (those that align to business realities, anyway)
• Define measurable stakeholder aims
• Create a business case for their achievement (which should be continuously updated), and monitor assumptions, risks, dependencies, costs, return on investment, dis-benefits and cultural issues affecting the progress of the associated work.  No can do, no will get resourced for anything more than pilots
• Effective communication that informs various stakeholders of the reasons for the change (why is this necessary?), the benefits of successful implementation (what is in it for us, and you) as well as the details of the change (when? where? who is involved? how much will it cost? etc.)
• Devise an effective education, training and/or skills upgrading scheme for the organization
• Counter resistance from the employees of companies and align them to overall strategic direction of the organization
• Provide personal counseling (if required) to alleviate any change-related fears
• Monitoring of the implementation and fine-tuning as required

That’s not enough though – to really effect change, the luke-warms need to know they will be protected from their detractors, and the detractors/resistors/nay-sayers/profiters from the current situation also need to know that it is not a risk-free option to throw tomatoes.  This is important, most people know that many projects lure in the enthusiastic, they are backfilled in the line, and when the initiative is strangled by the Old Order, they have no job to return to or go to and a suspicion they are now tainted anyway.

The approach to this that seems to work best is for the business to put out, in game theory terms, Strong Tells – ie signals that This Is Important To Us – for example:

• Top Management Support….  that is seen to be supportive
• Real commitment to protect those involved from repercussions, in hard terms (aka career and/or financial protection)
• Some form of “air cover” from the detractors

WYSIWYG – What you see is what you get

Piloting is critical as well – people need to see that this can work.  There has to be an early demo, pilot, lab, test, whatever – partly to show people it can work, partly to iron out bugs.  How to pilot is usually the thorny issue.  In general, the pilot needs to be:

• Something that can be “cordoned off” so it doesn’t require root and branch replacement of all the main business systems to make it work
• Important enough for a lesson, but not so important that failure cripples the whole enterprise

In addition to the above, to quote Steve Denning’s useful summary of the “Do’s and Dont’s” from past change management lessons, there are some “Anna Karenina” basics that one should do to avoid the most obvious types of failure:

• Do come with a clear vision of where you want the organization to go – and promulgate that vision rapidly and forcefully with leadership storytelling.
• Do identify the core stakeholders of the new vision and drive the organization to be continuously and systematically responsive to those stakeholders.
• Do define the role of managers as enablers of self-organizing teams and draw on the full capabilities of the talented staff.
• Do quickly develop and put in place new systems and processes that support and reinforce this vision of the future, drawing on the practices of dynamic linking.  (Dynamic Linking is Denning’s term for an essentially Agile style planning & execution approach)
• Do introduce and consistently reinforce the values of radical transparency and continuous improvement. (Radical Transparency is the idea of making a lot of real time information available to all, essentially the white collar equivalent of Japanese, Just In Time style production approaches, without which Continuous Improvement can’t really happen)
• Do communicate horizontally in conversations and stories, not through top-down commands.

And the critical Don’ts:

• Don’t start by reorganizing.  First clarify the vision and put in place the management roles and systems that will reinforce the vision.
• Don’t parachute in a new team of top managers.  Work with the existing managers and draw on people who share your vision. (Agile Elephant Caveat – the “soggy sponge” of resistant managers is a time honoured fact, some replacements probably will be necessary, but let that occur organically).

In large enterprises we have never really seen radical, innovatory change happen “in the line” – there usually has to be some form of “skunk works”, even a remote start up or spin out – the power of the “Big Barons” – those who profit from the Status Quo – should never be underestimated.

A Proposed Approach – the Agile Elephant “7E” Model

We have made an initial approach to combine Agile Management with these lessons, plus our experience into what we call the Agile Elephant 7E Model

It has 7 major components, and, as is the rule with all good consulting models, it is alliterative 🙂

The phases are shown in the cycle diagram above, and in summary are:

Envision – Understanding the factors driving the need for transformation, and describing the post transformation business and model.

Enable – Put into place the resources, processes, plans, ROI’s etc. that will make the transformation possible.  Also decide how/where it will be executed initially.

Engage – Get the people involved and onside, trained and ready to make the transformations happen.

Execute – Break the transformation into bite size pieces, and execute using an Agile methodology.  Pilot!

Evaluate – Continual examination of what works and what doesn’t, to drive dynamic change and improvement and optimise efforts.

Evolve – If things change, or don’t work, then plans need to change.

Educate – Educate, Educate – this is central to the whole process, from the envisioning process through training the teams, continuous learning, capturing information, evaluation and re-envisioning the transformation where necessary

It’s a cycle to demonstrate that continuous and cyclical iterative nature of the process, but also to note that the central hub is Education.

In more detail for each area considered:

Envision

The aim is to create a vision of the future that the project will aim at, as a guide to what is in the right direction and what is a diversion.  Part of this is the creative, no holds barred brainstorming/thinking out the box/lateral imagineering etc. visioning, but part is the testing of this against the pragmatic reality, i.e.:

• Understand emergent market situation
• Understand economic drivers of the industry & company
• Understand impact of new tools & techniques – and their limitations
• Define new business approach & model (we use the old McKinsey 7S model as it looks at both hard and soft issues)
• High level economic analysis (Value analysis, set high level strategy to achieve this)

The endgame is a vision that is transformative, but bounded in the reality of the achievable, and ensuring each actor’s part in (and reason for the part) is readily understandable.

Enable

Before jumping into the Agile mode of actually executing, it is critical in any change management process to set up the support infrastructures, especially:

• Map existing business processes in detail so everyone has a common view of what is actually going on
• Create a more detailed exposition of the new business model, and how it impacts what exists
• Define the who/what/when/where will carry out the transformation
• Define ICT tools to be used, and how they will be implemented
• Create programme and project plans, at least to an initial iteration.  Yes they will be wrong, but they need to be a “best guess”
• Define where and how the Pilot will take place
• Create business case & ROI – no serious business will commit serious resources without one.

As General Eisenhower noted in Word War 2, about the Allied landings on D-Day – Plans are worthless, but planning is everything.

Engage

Before taking any initial steps of actual implementation it is essential to start to bring people on board, to gain support, neutralise opposition, and create a climate for change.  Key steps are to:

• Understand current skills mix and staffing profile…
• ….and what changes are required to these.  You need to know what resources you can afford to lose, and what must be retained
• What approaches will be used to engage staff, get buy in for change…and protect the involved
• …and where/who the barriers to change are, and what can be done to mitigate these
• Define new ways of working, new styles of behaviour required, Training / Education
• Recruitment / retrenchment plans (if any) need to be carried out humanely – and quickly
• Define the “Shared Vision” – what it is that will unify everyone’s efforts, what people need to do about it, and why it is essential.  As Denning notes above, it has to be a storyline, shared every which way and not a top down dissemination of vague nostrums.
  

In short unless a critical mass has bought into a “Whats in it for me” and believes they will be OK in the New World, and the major blockers are neutralised, the project will probably fail before its begun.

Execute

The “Go Do” phase – first for the Pilot, and then the Roll-Out:

• Train & Educate for Agile approach – Agile approaches are probably the best when dealing with hard to quantify/not done before/high iteration work
• Break project plans into appropriate size work packages as per the methodology
• Execute Programme via Agile Sprints/other approaches (most Agile approaches use small incremental “sprints” of functionality development, in frequent drops, which – usually – are easy to absorb incrementally.  Usually. Sometimes there has to be a singular “get the system to this state before we cut over” and its important to identify those).

But there also needs to be an override to make sure the “sprints” are going in the correct direction rather than all over the field, key tasks will be to:

• Define Key Performance Indicators (KPIs) that each work package is required to hit to be accepted
• Conflict/Resource resolution
• Priority setting when there are multiple operations and limited time/resource (the norm for all organisations in the real world)

Evaluate

Just as there is iteration in the Execution phase, there needs to be an iterative Evaluation phase, incorporating:

• Progress reporting data generation
• Impact assessment – actual v planned
• Quality Assurance
• Human factors impacts
• Cost monitoring

At a minimum it measures actual vs predicted, and some form of examination into the “why” of any major discrepancies, to predict future problems so the surprises are seen as soon as possible.  Given a Transformation project will, by its nature, not go according to plan it is essential to accept this and have a strong acceptance of the need to adapt.

Evolve

This process looks at the tasks as they are executed and examines “what works, what doesn’t” and sets up the changes to define “whats next?”:

• Review process – what works, what doesn’t & why
• Are the tasks moving towards the strategic goals? Are those goals still realistic?
• What still needs to work even though it doesn’t?
• What has changed?
• What is no longer important?
• What is now important/urgent?
• What’s next?

There is some criticality in the frequency of these reviews – Weekly/Monthly/Quarterly/ 6 monthly/ Annually – too frequently and the execution phase is overwhelmed by producing reports and interference, but too rare and major problems can sink a project before they are even surfaced.  There are quite a few useful lessons and approaches from Lean operations that can be used.

Educate (Educate, Educate)

Essential before the project, during the project, after the project. Some key requirements in each phase are:

• Envision – Basic education of senior team, core project team; key organisational players
• Enable – Educate wider group involved in process mapping and new process design
• Engage – Education and communication throughout enterprise
• Execute – Training
• Evaluate – Understanding of data, what it means, how to analyse it
• Evolve – Training in analysis and decision making e.g. Value Analysis, Continuous Improvement etc.

Continuous Learning is necessary in an environment where change is the constant.  What is learned throughout any cycle is re-diffused back into other areas – it is continuous.  Learning by doing becomes a continuous loop.

End Notes

And remember, to quote that great sage of complex project execution, Norman Augustine of NASA, that at all times the chances are that things will be worse than planned:

Ninety percent of the time things will turn out worse than you expect.  The other 10 percent of the time you had no right to expect so much.

…i.e. put in contingency.  Even Agile is not immune to this, to paraphrase Augustine again:

Rank does not intimidate systems.  Neither does the lack of rank.

So in summary, we see a lot of the discussion around Digital Transformation putting too much emphasis on technology, or on organisation change, or on an approach that adds digital as an ingredient, rather than recognising that change will be necessary across the whole of the business and the business processes.  We see an agile management approach as the only one that is viable, but it needs to be addressed holistically.  That’s why we are recommending the 7E methodology, and why education, at all levels, is the lynchpin to successful change.