Think Global, Act Local - How To Sub-optimise Your Global Operation

I think it was sometime in the early 2000s when I first came across the expression "Think Global, Act Local". The phrase has been attributed to Patrick Geddes, a Scottish town planner and social activist, and originated way back in 1915. These days it is a rallying cry for global corporations, and it has appeared in nearly every leadership presentation I have seen over the last 10 years.

At the time, I was working for a major IT outsourcing company, whose business was truly global, and where corporate shared services were already being farmed out to 'low cost centres' across the world. In Applications Development and Maintenance, we were also beginning to talk about 'follow the sun' development, whereby developers would work in relay teams around the world to build software systems 24x7 in a factory model - but that's another story for another day.

I remember being quite excited about the 'Think Global, Act Local' paradigm, mainly because I had my fingers in many pies. I was a member of a number of global task forces looking at various elements of our software development activities, whilst being responsible for all business improvement activities across Europe, and also looking after a team of UK based process improvement experts. And for a while things were hunky dory...we achieved an enormous amount, it was fantastic collaborating with people from all over the world and we actually worked in an environment where people understood how the paradigm should work but more importantly what the limitations were.

When I came across the phrase more recently, I started thinking about how jaded it now seemed, and more importantly how it has been so poorly interpreted by so many management teams that it has probably caused more harm than good. On top of that I realise how naive I was to be taken in by some of these slogans, although I'm pleased that I now finally see them for what they are and that I'm able to think around the consequences of these and other management hypes, although that is largely the result of seeing how things have evolved in the real world, and the problems that have ensued.

I have two main examples of where the paradigm breaks down. Both involve the transfer of work to places with relatively lower cost bases, which is possibly a very desirable thing to do if you are an accountant, but less desirable when seen from other perspectives.

In the first example, let's consider the situation where highly skilled knowledge workers form an operational hub in a low cost region. Depending on the location, it is possible to hire very skilled people (often contractors) at slightly lower rates than they might expect from their home base, but who benefit from the reduced costs of living abroad. The company benefits from lower wages bills and generally lower operating costs by setting up such hubs. A win-win situation it would appear.

It's only when you start working that the problems become evident. And in my experience the single biggest issue is that all collaboration and communication is done electronically. You rarely, if ever, meet the people you support, and your lives are spent working in sound bytes of information, struggling to catch people for a few moments of their time.

In other words, support staff can only provide a sub-optimal service to their front line colleagues. No matter how hard we try, we are limited by the problems inherent using in electronic communication alone - technical issues, misinterpretation of messages, misunderstandings, language issues - all of which are potential issues when working face to face, but compounded horrendously when our only interface to our colleagues is through a computer.

[The irony of this situation is that often the work could easily be done by contractors tele-commuting thereby dispensing with the need for office space and the associated costs of doing business. Personally, I would be perfectly comfortable working from my own home, on a lower day rate, than having to relocate to an office on the continent, incurring the costs of renting an apartment, paying management companies to represent me and still not having face to face collaboration with the people I support]

In the second example, whole functions are relocated to a low cost centre. These are often administrative functions, such as invoicing, procurement or payroll. It may seem quite obvious that these ‘self-contained’ functions can work remotely, servicing requests from across the globe. However, this assumption fails to take into account the biggest single weakness that is inherent across all organisations, regardless of size, longevity and maturity. Most organisational dysfunction occurs at departmental interfaces.

Some organisations have taken this relocation of function to an extreme. Payroll is located in country 'x', procurement is located in country 'y' and invoicing is located in country 'z'. And of course, all the transactions originate locally and then start their long and intricate itinerary across the world. Even some seemingly trivial activities that used to be performed locally in a matter of seconds now take a week or more to fulfil, assuming there are no issues with the original request. If an issue does arise the error has to be backtracked through it's travels and then start all over again.

Many of the organisations who have divested their back office activities across the four corners of the world are simultaneously embarking on 'Lean' and 'Agile' initiatives. Because they have no real understanding of what 'Lean' or 'Agile' really mean, they fail to see the irony of their actions.

Think Global, Act Local, in many respects, is the antithesis of Lean and Agile. Saving money by relocating certain functions at the expense of operational efficiency and effectiveness is almost certainly not going to lead to a net gain against the bottom line. People in higher cost centres are being hindered by the delays in transactions preventing them from realising their own operational effectiveness. Time is spent chasing up requests, often being passed from function to function, as there is no longer any clear overall ownership of the process. In fact, the whole thing smacks of an exercise in job creation, whilst at the same time, hundreds of skilled people with unique domain, customer and product knowledge are being made redundant (before being re-employed as much higher cost contractors).

If businesses took a moment to map out their end to end processes, looking at such things as value chains and process topography and topology, before they shipped out their support functions, they may realise the potential folly of their actions.

As usual, there are more dimensions to executing business processes than that of cost alone! And any Lean expert, worth their salt, will understand that optimising all your sub-functions in isolation, out of context, and without a holistic overview, will lead to the overall process being completely sub-optimised...and probably completely dysfunctional...especially to the people who depend on it!

A Lean Excuse for Not Thinking

Recently a former colleague posted an article on a social media network entitled "The History and Simplicity of Lean Process Improvement". The author, Brian Hunt, suggests that elements of modern 'lean' can be traced back to ancient and mediaeval times. He then goes on to talk about modern Lean implementations and specifically Six Sigma techniques are often shoe-horned into an organisation with little thought for the people who actually do the work. Having had first hand experience of this, where both management and external consultants colluded to create a version of Lean that bore no resemblance of anything remotely approaching process improvement I couldn't help but chuckle at his example of a UK Government implementation of Lean which included marking out the required position of pens, telephones and other desk furniture for optimum productivity.

But my comment to Bianca, was more along the lines that we've a long established tradition, especially in IT, of jumping on bandwagons like Lean, Agile and a plethora of other 'methods' over the years, whilst at the same time throwing common sense and considered thought into the wayside.

Now I'm all in favour of new ideas, old ideas being regurgitated, or even incongruous ideas being thrown in the mix and muddled together to create something innovative. What I'm not in favour of is the latest fad being seen as a silver bullet to solve every problem regardless of how suitable or unsuitable it may be.

If you look at the job market for project managers these days very few of the advertised positions do not include Agile in them. For process improvement positions, a black belt in Six Sigma is pretty much a mandatory requirements, although Lean Six Sigma is preferred.

The reality is that very few organisations operate a truly agile environment (those that have adopted Scrum shouldn't even be advertising for project managers) and in fact some good old fashioned project management and good governance improvements would be a much better way to improve results than blindly deciding that 'we need to be Agile' without genuinely understanding what that means.

Similarly, organisations with a track record of failed process improvement initiatives would probably be better off looking at their organisational change management processes (or lack of them) than attempting to implement a Lean Six Sigma improvement programme (whatever that is!) and expecting it to succeed in spite of history....select your favourite maxim

• those who fail to learn from the lessons of the past are doomed to repeat them
• stupidity is the practice of repeatedly doing the same thing in the expectation of getting a different outcome

Unfortunately there are too many managers and leaders out there who behave like the relative who gives you green jumper every birthday because you twenty years ago said you'd like a green jumper.  They jump on ideas and inflict them on their people, because they've stopped thinking properly in the internet age. It's easier to find out about a new idea by reading an article on LinkedIn and stamp it across the business without a second thought than it is to actually work out what the problem is and determine the best approach to solve it using the most appropriate tools and techniques before then implementing the change using good change management practice.

I'm still amazed at the number of organisations that launch an improvement programme, or roll-out a new tools without actually doing any analysis of the problem, let alone putting together any requirements. And absolutely not thinking about the consequences of their actions!

The best consultants and practitioners are not the ones who pigeonhole themselves into a trending method or ideology. The most successful people are those who keep an open mind, understand how different concepts, principles, ideas and tools actually work and how to get the best from the synergies between all the ingredients in the melting pot. They won't always succeed overtime, but at least they'll have a better chance than the trend followers and the ones seeking out the next silver bullet.

Trying to "Implement" Lean? - Think Again!

This weekend, I spent a couple of hours reading Henrik Kniberg’s book “Lean from the Trenches - Managing Large Scale Projects with Kanban”. The book relates the author’s experience using Kanban on a large project for the Swedish national police authority. I always enjoy these kinds of true life experiences, but this one had some personal resonance for me because of my experience with Lean and Kanban in an organisation a few years ago.

I was contracting as a Quality Manager for a global Financial services organisation in western Europe and the software development department I was working in was selected as the pilot for a new Lean IT Management initiative. The development team consisted of a mixture of employees, contractors and in-sourced staff and numbered about 70 altogether. The development work was primarily feature based enhancements across a portfolio of products.

An external consultancy (a big six outfit) was brought in to lead the initiative (at enormous cost!) and a small group of internal employees were selected to be the navigators for the initiative. Their training consisted of a 5 day bootcamp and they were joined by the department head and another senior manager.

After the bootcamp there was a frenzy of workshops over the next couple of weeks. Team members were invited to participate in the workshops but had no input into the design activities which followed. Within four weeks a new set of operating procedures were “implemented” across the team. The consultants left and the department was left to fend for itself under the watchful eye of the navigators, who were effectively the blind leading the blind.

The new operating processes were a disaster. Key principles of Lean (not to mention basic change management principles) were ignored, and staff ended up doing twice as much overhead and admin work as before. Morale plummeted, confusion reigned and productivity went south.

Despite my role as quality manager, I was not engaged in any part of the process, and as such shared the despair of the staff. However, with good understanding and experience of Lean and Agile and as an experienced change leader I felt duty bound to try and do something to help resolve the situation.

I put together some notes and recommendations and spoke with the Lean IT initiative leader. He agreed with my observations and recommendations and we set about repairing some of the damage.

Which is where Henrik’s book starts to resonate with me. The most visible new process that was introduced was the daily stand-up meeting around a team white board. Ah - Kanban - you start thinking. Only this wasn’t a Kanban board or even a Scrum daily stand-up. This was a simply a highly visible (and time consuming) task and time tracking system for each team member which duplicated existing corporate time tracking tools and project schedules. The teams were given no understanding of the purpose or how the information would be used - they were just told that filling in task sheets and attending the meeting was mandatory. Not surprising then that there was almost complete resistance to the concept and the practice.

Over the next few weeks, I worked with the management, the project managers, the navigators and most importantly the team members to try to convert the activity into something more akin to a Kanban board, and to change the daily stand-up into something that could add genuine value to the projects rather than a dreaded inquisition of each team member. We succeeded, and the teams took more and more ownership of the activity by adapting it to each of their specific needs.

There were some real take aways for the management from this whole exercise:

• Lean is not something that you implement - it is a set of principles and there are tools and techniques that can be used to support the objectives that you collectively wish to address
• Trying to enforce change without involving the people who do the work will usually fail dismally and have significant repercussions 
• Don’t use a Lean or Agile improvement opportunity to try and drive through personal management agendas - there is every chance they will backfire
• Don’t let a consultant blindside you with an off-the-shelf blueprint for success. The chances are that it won’t fit your existing culture or mindset without significant tailoring and adaptation

It was a real eye opener for me to watch a very expensive initiative being undertaken without due diligence and with precious little respect for the basics of change management. It was also extremely satisfying to be able to help turn it around - and full credit to the management for realising their problems and to the staff who actually did eventually turn a sows ear into something resembling a silk purse!