Editor's Note: Take a look at our featured best practice, Strategic Planning: Hoshin Kanri (Hoshin Planning) (153-slide PowerPoint presentation). [NOTE: Our Hoshin Kanri presentation has been trusted by an array of prestigious organizations, including industry leaders such as Apple, Facebook, Boeing, Shell, Goodyear, Cummins, Johnson Controls, Hanes, Telefónica, Chubb, Discover, Stryker, [read more]
How Do We Create Leadership Pull for Operational Excellence?
* * * *
Editor’s Note: This article is an excerpt from the full How to Create Leadership Pull for Operational Excellence whitepaper, available for free download from Flevy here.
* * * *
Several times a year, over the last decade, in multiple Operational Excellence (OpEx) focused conference workshops, we have asked the same question. What’s the #1 obstacle to successful successfully deploying OpEx? The #1 answer has invariably remained “lack of top management commitment.”
At a superficial level, at least, this answer doesn’t seem to make sense. OpEx activity is in theory something that every business leader should actively want to support. OpEx promises to simultaneously improve quality and reduce costs – both of which are clear drivers for better business results. These are the same business results for which business leaders are directly rewarded and recognized. Additionally, there is significant, indisputable evidence that operational excellence programs have had a significant effect on the business results of not just tens, but hundreds of large private sector organizations [iSixSigma, 2011]. It seems obvious given this evidence and the direct link to what they get rewarded and recognized for that top management would naturally see OpEx as a priority.
The reality however is very different. Our research has shown that over 50% of operational excellence pilots fail [Docherty, A. 2006] and even highly successful programs suffer seismic shocks – we’ve seen top management in multiple companies inexplicably cancel OpEx programs generating hundreds of millions of dollars in savings – including, for example, BT’s Wholesale Division Lean Six Sigma (LSS) program (stopped in 2005) and the decision by Network Rail (the UK Rail Operator) to disband their Operational Excellence program in 2007.
The problem with the “push” model
Clearly we have to look deeper under the surface to understand what’s going on. Our simplistic assumption – that leaders will be motivated to support operational excellence – is based on the view that they will be motivated by the obvious link of OpEx benefits to the things they care about. The reality however, is that the link (particularly when OpEx is seen as a program) is often not that obvious, and in reality, motivation is based on more than just the belief that a link exists. A powerful model that helps us understand what drives motivation of individuals is Vroom’s Expectancy motivation model [Bandura, A. 1977]. This model suggests for us to be motivated to do something we must believe at least 3 things:
- If we do something it will result in an outcome;
- That the outcome that will result is personally valuable to the individual i.e. there is a clear WIIFM (what’s in it for me) and;
- That doing that thing (over all other things) will get to the desired outcome (that we will get rewarded for) faster/more effectively than all other potential things we could do to get to the outcome.
This model helps us understand both why leaders frequently don’t throw their support and energy behind operational excellence and why this leads to the erosion of support for the concept and ultimately why OpEx programs fail.
Consider the following analysis which is based on the insights from Vroom’s motivation model (see diagram below). It links the ‘symptoms’ of lack of management commitment to OpEx programs to the consequences of these symptoms – effectively death of the program by “1000 knives” and “chains back” to the potential causes of this lack of commitment.
Fundamentally this model suggests that there are three pre-requisites that need to be in place for leaders to be motivated to support operational excellence activity:
- Leaders have got to believe that the operational excellence projects are directly aligned with their personal objectives i.e. that the project outcomes will directly contribute to achievements of the outcomes they get rewarded for;
- Leaders have got to believe that applying operational excellence tools and approaches will fundamentally deliver results more quickly/effectively than alternative approaches;
- Leaders have got to believe that the consequences of not delivering improvement activity are greater than the consequences of not delivering the business as usual activity.
With this insight it is clear why traditional “program driven” approaches to operational excellence often fail. Whilst, popular, the “deploy OpEx as a program” approach (as promoted by the initial adopters such as GE, Motorola and Honeywell and subsequently adopted by hundreds, if not thousands, of other companies) is based on some flawed assumptions. This approach, in which a corporate staff function – variously called Lean Six Sigma, Process Excellence, Business Excellence, or similar, is set-up to ‘push’ a training program in which high potential employees are taken out of the line roles and trained in waves to run improvement projects – can easily create a situation where leaders feel little or no ownership for the improvement projects. There are two principle reasons for this:
- The first is the consequence of the widely adopted ‘no project, no training’ rule. This rule which is based on the apparently sound premise that training people without a way of directly applying that training is pointless, has led in the vast majority of organizations to many dubious projects being selected due to the combination of pressure to pick something to work on, and the lack of an easy way for operational managers, who tend to focus naturally on the day to day, to understand which would be the very best problem for their nominee to solve in the context of the organization’s strategic goals. The consequence of this rule is in practice that there is typically a relatively poor alignment between the projects being initiated and the agenda of the top management – with the consequence that whilst the managers often recognize the project as something worth doing it doesn’t make their top 3-4 priorities – which ultimately govern what they spend their time and energy on;
- The second is the consequence of the perception that naturally results from the act of creating a central Program Office to drive the OpEx program i.e. a) That they (the operational line managers) don’t own the OpEx program (it’s “owned” by the head of the staff function that’s leading the program) and b) It is ultimately not their job to deliver the OpEx program benefits. This perception is reinforced by the fact that in most organizations operational managers are incentivized to deliver ‘run the business’ operational outcomes i.e. more outputs for less cost. These managers will understandably then prioritize those actions that they believe will lead to these operational outcomes at the cost of projects – particularly if they can’t see a direct link to the outcomes they are rewarded for and/or if they believe there is a way to pull an alternative lever that will get results more quickly even if it’s not sustainable;
This helps explain, for example, why apparently sane managers would often rather shoot the alligators than drain the swamp e.g. throw people at chasing debt (quicker result, potentially more successful in the short-term) rather than understand and fix the root causes of delay in customer payments (takes longer, uncertain on breadth of impact even if more sustainable).
Of course, there are tactics that organizations can adopt with the ‘push’ OpEx as a program model to help lessen the likelihood of picking projects that managers won’t care about. These tactics include creating a project hopper process and ensuring projects are systematically evaluated against meaningful evaluation criteria and increasing the consequences of not working on/supporting improvement projects by raising the visibility of the money ‘left on the table’ to top management as projects are delayed. My own experience, however, as an OpEx program deployment lead for a major telecommunications supplier, is that these tactics ultimately have limited success as they are trying to move OpEx up a manager’s agenda when all the other pressures they face are naturally forcing it down the same agenda.
Hoshin Planning as a Strategy to create pull
The good news is that there is a proven approach that you can use to turn this situation on its head – one which naturally leads to the situation where senior executives are the principal drivers of OpEx activity and where improvement efforts are more focused on the real objectives of the organization.
Download the full How to Create Leadership Pull for Operational Excellence whitepaper here.
Do You Want to Implement Business Best Practices?
You can download in-depth presentations on Hoshin and 100s of management topics from the FlevyPro Library. FlevyPro is trusted and utilized by 1000s of management consultants and corporate executives.
For even more best practices available on Flevy, have a look at our top 100 lists:
- Top 100 in Strategy & Transformation
- Top 100 in Digital Transformation
- Top 100 in Operational Excellence
- Top 100 in Organization & Change
- Top 100 Management Consulting Frameworks
These best practices are of the same as those leveraged by top-tier management consulting firms, like McKinsey, BCG, Bain, and Accenture. Improve the growth and efficiency of your organization by utilizing these best practice frameworks, templates, and tools. Most were developed by seasoned executives and consultants with over 20+ years of experience.
Readers of This Article Are Interested in These Resources
|
Excel workbook
|
|
113-slide PowerPoint presentation
| |||
About Paul Docherty
Paul Docherty started his career in Marconi, where he held a wide range of senior management roles covering manufacturing, IT, sales, product development, project management, Operational Excellence and corporate strategy as well as having P&L responsibility for the growth of a regional telecoms equipment business. In 2001, Paul founded i-nexus with the goal of building cloud-based software that could help organizations successfully manage the complexity involved in translating their vision into reality. This software is now the "de facto" standard for large enterprises when it comes to driving execution of their strategy. Paul holds an MEng. in Computer Systems and Software Engineering from the University of York and an MBA from the University of Warwick.Top 10 Recommended Documents on Hoshin
» View more resources Hoshin here.
» View the Top 100 Best Practices on Flevy.