Strategy, Transformation & IT: Why Haven’t they Worked – Part 2 How to Succeed
In Part 1 of this series we looked at the research on how many and why Strategy, transformation and IT projects have such a high failure rate. Collectively we grouped these initiatives under the title ‘transformation’. In this part we investigate the underlying reasons why there is such a lack of success and offer what we believe is – and have proven multiple times – a much better way that should, at the very least, reverse the statistics.
What is true, however, is that if they could all be done properly it does not follow that success will occur. Our insights, gleaned over 20 years of being involved in all sorts of transformations lead us to believe that there are two key missing.
- Focus. No one would say that one should be unfocused yet there is a common misunderstanding in that Focus is not a synonym for prioritisation. How often has the following scenario happened to you? You are in a meeting to discuss a new project. This project has the highest priority from the top and you are told by your boss to focus on this. You then go to your boss and say ‘OK, here are all the other things that I’m supposed to do – who will take them on? Here’s all the meetings I should attend, will you cancel them, or shall I? Oh, and I assume you’ll be hiring a temporary PA to take care of my and my team’s admin’. To most people, the above scenario would either be the equivalent of signing a resignation letter or, far more likely, would elicit a laugh and a response of something equivalent to ‘in your dreams’. No you still have to do all the other things but you have to ‘focus’ on this. The more senior one gets in an organization, the less likely it is that a proper degree of focus can even begin to be attained. We sort of understand that focus is not so much about what must be done but to at least as great a degree what must not be done (even if it’s a very good thing to do).
The above rests on two wrong assumptions: The first assumption is that because of the nature of organizations and the pace of change is that what can be changed for the better should be changed for the better. This is flawed on two accounts; firstly because there will always be more to change than there are time and resources to do them and secondly because when we try to change many things at a granular level, even if we succeed in making the changes, because of the complexity of organizations we are very unlikely to make the organization as a whole better. We can see this at a macro level where we see many organizations trying to become both more flexible, sensitive and agile to meet changing and demanding customer requirements yet at the same time are pushing operations supply chain and admin functions, in the hope of generating more efficiency, to become less flexible and more rigid. Not necessarily impossible but there is a strong tendency towards leaving the personnel who have to make the ‘new’ way work left with an impossible compromise to manage. The actions people then do to try and manage against this impossible compromise is then – most often – called ‘Resistance to Change’.
The second assumption is that if we need to do many things then the best way to ensure that they all get done is to start each as soon as possible. Organizations are adopting more ‘agile’ ways of working within projects and this helps but typically these devices are only used within projects and are widespread at an enterprise level. Multi-tasking is becoming more and more prevalent even though there is more and more research that shows just how damaging – and self-defeating it is.
- Fast Feedback
The second area is related to what we call ‘fast feedback’. By their very nature, transformation programs are leaps into the unknown. We need to know quickly what is working, what is not working and, very importantly, to ensure that we don’t repeat the same mistakes because of the wrong starting assumptions. In many transformation programs – especially those with a heavy IT component – we mistake the ‘deliverable’ with the change itself. Because of this the feedback, even if fast, tends to be mostly related to schedule or deliverable quality and not so much on whether the change itself is working. In fact, in many IT driven transformations the efficacy in terms of improved business performance is never even part of the overall program!
Succeeding with Business Transformation
We have covered the elements of why ‘transformations’ fail; understanding causes of failure is necessary, but not sufficient, in succeeding with business transformations. We believe there are six key steps to ensuring success with transformations:
- Really understanding the ambitious end-state.
- Allowing focus on achieving this
- Be fast – break the end state into manageable, implementable, ‘chunks’
- Have fast feedback on the outcomes of each ‘chunk’.
- Fully understand and manage the changes
- Allow effective project / program management
We can imagine many of you saying to yourself “That’s it? These are the big new insights?” Before passing judgement please allow us to go into each area in a bit more detail.
Really understanding the ambitious end-state
The end state should be ambitious – very ambitious. There are a few reasons for this:
- Why do something so potentially disruptive if the potential returns are not many times more than the outlay.
- A highly ambitious target reduces choice. There will, in general, be many more ways to obtain a 1% improvement than a 100% improvement. In this case having less choice is a good thing
- A highly ambitious target – once it’s believed to be realistic – has a very strong focusing and galvanising effect on an organization
- Success will be easily measurable. It will be obvious that this must be down to the transformation efforts rather than due to natural business variation.
Really understanding the ambitious end state means being able to see what the organization will be like after the transformation. We need to be able to say:
- What are the key assumptions in our industry paradigm that should be challenged?
- What are the positives (over and above the highly ambitious target) of the end state? Is there anything that can be done to accentuate / further capitalise on these positives?
- What are the potential negatives of the end state? Is there anything that can be done to minimise or eliminate these negatives?
- What new capabilities will we need?
- What existing capabilities will we not need?
You can probably already determine that this is, from the start, an iterative process.
Really focus on achieving this
Given the rate of change, there are scarcely any parts of an existing organization that cannot be improved. Focus means choosing between the many things that can be improved and only doing what MUST be improved to achieve the end state. This, as should be evident, also means clearing the decks of existing projects. This is one of those things that sounds simple in theory but in practice is anything but and is the hardest piece, but also one of the most necessary, things to do.
It is relatively easy to stop projects before they start. It is a much harder thing to stop a project or program that has already consumed money, resources and, most likely, a significant amount of emotional and political capital. It becomes even harder when the initiative does, in and of itself, look likely to have a good payback. We have worked in organizations that have multiple big programs and hundreds or even thousands of projects and initiatives going on. There are several reasons for being ruthless:
- The most obvious reason is that the other project will consume scarce resources that should be available for the focus program. Available resources include not just the sponsor and the core team but also people who will be needed for input or will be affected by the transformation program. Almost by definition the transformation program will affect large parts of the organization.
- The ‘law’ of unintended consequences. Because most organizations are very complex, it is often difficult to see ahead of time the consequences of one initiative on another. Rather we should say it is difficult to see the consequences of many initiatives on many other initiatives. In order to successfully execute a transformation, we must understand the starting conditions. These starting conditions will, of course, change due to normal changes in the business environment but we are making things immeasurably harder for ourselves.
- The real world exists! The reality is that there will be urgent, unforeseen circumstances that affect either the whole business, those assigned to the program or those whose input / involvement is required one way or another. It is very important to ensure there is sufficient ‘buffer’ for these events.
Does this mean that we should do nothing other than the transformation program? The short answer is ‘it depends’. If an organization can ensure that resources will always be available when needed and that there is sufficient protective ‘program capacity’ and that it is absolutely certain that there will be no ‘unintended’ consequences, then the answer is it is possible to do other things but the certainty should be there. After all, you have a transformation happening, when it succeeds will change the organization massively for the better, the sooner it happens the better. The question that should always therefore be asked is not ‘can we do anything else?’ but ‘why should we do anything else?’.
Be Fast – Break the end-state into Manageable ‘chunks’
This is really simple, yes? After all we already break programs into projects, initiatives and tasks and a lot of organizations already time-box individual tasks or even projects to make them more manageable. So, what more is there here?
We should begin by defining what we mean by ‘manageable chunks’. For a transformation program each chunk is likely to equate to a project. A project will consist of two things; the ‘artefact’ being delivered, for example, new technology, a new process, new skills, new organization structure or, quite commonly, one or more elements combined. As has been previously remarked there is also the outcome of the project that is delivered. When we talk about manageable chunks we therefore need to be aware, in the sequencing, of both the delivery of the artefact and the delivery of the intended outcome. The intended outcome should always be measured in terms of improved business performance.
Secondly, we want the changes to happen ‘real-time’ in the business as much as possible. Therefore we should avoid, wherever possible, time-consuming analysis and design and be ‘agile’.
Thirdly, we want to make sure that we do as much as possible in sequence and not in parallel for ‘in programme’ reasons similar to those given in the above section. This means that we have to spend more effort in the original planning and sequencing.
Have Fast Feedback
We assumed when we wrote this that the necessity to have fast feedback during the artefact build phase was self-evident and already being done. We have seen major programmes, when they run into roadblocks, can escalate very quickly to get these removed. This can be one of the main roles of the program sponsor. It is, of course, vital that there is no need for a delay in meeting with the steering committee to remove these roadblocks.
Our reference to ‘fast feedback’ here more means feedback when, even though the project has delivered the artefact, the results are not what we expected. Each building of something new should be treated as an hypothesis>experiment and then result. When the result is not what was expected we need to check our assumptions. Was the hypothesis correct? Was everything necessary and sufficient implemented as part of the project. We need to be able to quickly learn from the experience and build the necessary changes into the next phase. It is important to note that we are here checking for substantial differences to our expectations. We should never expect our ‘predictions’ to be absolutely accurate. This is another reason why having bold objectives are important – it allows us to check whether our starting assumptions are correct. So, for example, we might have a project whose aim is to improve service levels to customers while decreasing inventory. Maybe we expect a jump in service reliability from low 80s to greater than 98% and inventories to fall by 40%. If service levels only increase to, say, high 80s and inventories only drop by 10% then we need to go back and check. On the other hand, we can allow some tolerance in the objectives to account for natural variation.
Fully Understand & Manage the Changes
Of all the areas where transformation failures are most often laid ‘change management’ is the one that probably comes up more frequently and with most importance. While our cynical side might say that’s because there are more individuals and consultancies offering change services there should be no doubt that Organizational Change Management, or OCM, is very important.
This is a very large and important area and here we will just touch on a few of the more important areas of Understanding, Buy-in & Resistance and Communication.
Fully Understand the Change
If we have followed the steps above then we should already understand the end-state that we want to achieve. This will likely still be at a relatively high level
Buy-In & Resistance
These are two sides of the same coin and the reasons why buy-in is not obtained often said to be is because people naturally resist change. People resist change – that’s a commonly accepted truth. We question whether this is actually true, while not denying for a moment that ‘resistance to change’ is a very real phenomenon in organizations. In the world of individuals, people embrace and actively try to change all the time. Changes in personal circumstances like entering a relationship or marriage, having children, accepting promotions and trying to improve their financial circumstances. Changes in use of technology from embracing the internet to smart phones – all of these are changes that are viewed mostly positively. Why then do organizations suffer from this phenomenon?
Firstly, we should point out what ‘Resistance to Change’ is not. Resistance to change is not trying to do something that is either impossible or will lead directly to either a severe reprimand or the loss of a job as well as damage to the organization. We have seen many examples, especially with regard to IT implementations, where people on the front line were put in an impossible position simply because of how badly the system was being implemented – largely along the lines of forcing them to choose between entering data into the system or doing their jobs. We have seen examples where the flow of deliveries would have been massively curtailed or, in one extreme case, where airline safety operations would have been severely jeopardised if people had gone ‘system first’. Of course on all of these occasions the prime reason for failure of the implementation was put on ‘Resistance to Change’. It is not change resistant to refuse to do something that is manifestly stupid and / or impossible!
There has been a lot of research on Change Management over the last few decades and especially interesting are the advances we have seen in our understanding of human psychology and how the brain works. This is exacerbated by the fact that change is now a constant – we are no longer moving from one stable state to another but there will be a constant flux. Given that background, however, there will also be discrete ‘bite-size chunks’. If we start from the assumption that people do not inherently resist change if they are convinced of the benefits to them we can see three fundamental ‘layers’ of resistance. These were defined over two decades ago by Dr Eli Goldratt, the discoverer of the Theory of Constraints:
- Agreement on what to change
- Agreement on what to change to
- Agreement on how to cause the change
These in turn can be broken down into a further line layers:
- There is no problem
- Disagreement on the problem
- The problem is out of my control
- Disagreement on the direction of the solution
- Disagreement on the details of the solution
- Yes…but – the solution has negatives
- Yes…but – we can’t implement the solution
- Disagreement on the details of the implementation
- Risks associated with the solution
- “I don’t think so” – external reasons
There are key steps that should be taken to go through each of the layers and in any case these are well documented elsewhere. What should be noted, however, is that there are underlying elements associated with each of the above layers. It should be noted that people can have legitimate reservations across four areas
- They may not agree the future state is sufficiently enticing or has negative ramifications for them
- They may not agree that the current situation is bad enough that they should change
- They may perceive the risks of getting to the end state to be too risky
- They may be required to leave desirable circumstances behind when moving to the change
In Theory of Constraints these are defined as ‘the pot of gold’, the alligator, the crutches, and the mermaid. Each of these reasons not to change need to be borne in mind as we go through the layers of resistance and craft the overall change program.
Most people would agree that communication is different from simply ‘telling’ – or ‘yelling’. Mirriam-Webster defines communication as “a process by which information is exchanged between individuals through a common system of symbols, signs, or behaviour”. A problem here is that much of the ‘communication’ we have seen on a lot of large change projects has been one way and seems more akin to a marketing campaign than a genuine attempt at exchanging information. As shown above with the layers of resistance and buy-in we need to ensure that communications happen all the way and importantly that both successes and ‘failures’ along the way are noted and communicated. Most importantly, that the communication deals with the changes and not merely the ‘artifacts’ of the change.
Allow Effective Project / Program Management
If we have followed the advice given earlier then we are well on the way to allowing effective program management. Far too frequently we see the following problems:
- Required resources are not available
- “Unexpected” issues are not dealt with quickly
- Progress is tracked against time taken, not time to complete
- There is the wrong sort of financial management
Resources are required to progress projects. Resources are required when needed by the project to avoid delays. Resources are required to give sufficient time to ensure quality. Resources are required, period. Would anyone argue with this? Yet, time after time, and seemingly irrespective of the size, complexity or budget of the project, we see that necessary resources are not available when they are needed. There are three main reasons for this:
- Resources are working on other things when they are needed
- We underestimate the time to review work
- We underestimate the time to correct / finalise work
Project and program managers typically do a wonderful, if thankless, job of trying to ensure resources are in place. However, this really is the accountability of the executive sponsor as it’s a key leadership decision to make regarding organizational priorities and clear rules should be put in place for knowing what business as usual activities take priority and when the program should take priority. Realistic amounts of time should also be given to reviewing work and, if possible, avoid having to do reviews all at once. Furthermore, it is naïve to expect that everything will be done perfectly the first time. We have seen many project plans where design work had some review time allowed but then not the second iteration.
Without going into the pros and cons of various project management methods we would say that following the steps outlined above – especially regarding focus and fast feedback, together with using the Theory of Constraints Critical Chain approach together with many agile techniques provide a very good framework to manage the work and avoid multi-tasking provided that the ‘rules of engagement’ have been formalised in advance.
We have shown that much of the standard advice on being successful – or avoiding failure – with business transformations is well-meaning but ultimately unhelpful because its not so much ‘what to do’ but ‘how to do it’ that is hard. We have given guidelines above on how to be successful. The advice is simple, but we would not claim that it is easy – especially in today’s environment when there are so many things that we could be doing to improve that it is not so much finding something to do but deciding what out of so many alternatives should we choose. The key takeaway is in the final word. We must choose and be ruthless in that choice. As Steve Jobs said “People think focus means saying yes to the thing you've got to focus on. But that's not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully.”