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!

The Change Centre

I read an article a couple of days ago called The Change Habitat: Why 70% of Change Managers Are Wrong by Jurgen Appelo. I’d need a lot of convincing before accepting much that was written in the article, but it got me thinking about a problem I’ve seen in many organisations struggling to succeed with their change initiatives.

A common denominator in many organisations where there is a history of problematic change is a lack of a change management competence. By that I mean that there are :

• no corporate change method or common approach to change 
• no recognised subject matter experts who can assist in change initiatives
• no change management tools or assets to help change leaders and teams
• no lessons learned data to help future change programmes

In other words, change is usually performed in an chaotic way and is dependent on the skills and ability of the individuals leading any specific change project.

Most IT organisations involved in project work have a set of project management standards and some form of development/support lifecycle in place, along with supporting governance processes. They usually have a set of standard templates for key deliverables - a project plan (not just a schedule), status reports, budgets and outlooks, and requirements and specification documents. They have mechanisms for raising change requests and recording defects and issues. New projects and new members of staff use the materials already available rather than having to reinvent them every time.

Very few organisations I’ve worked in have a similar set of assets available for managing change initiatives. People who are asked to manage change initiatives either have to try and make do with the existing project management templates or need to build their own. The problem with using standard project management assets is that they are rarely adequate for projects other than technical ones. And as I suggested in my post from August 2014 (Unifying Technical Project Management with Management of Change) there are significant differences between the two types of project, and there are additional things that need to be considered for change projects.

By establishing a Centre of Competance (CoC) for organisational change, with a defined lifecycle, toolkit and group of dedicated change management professionals a company can begin to establish a consistent approach to running change programmes, large or small, thus greatly increasing the potential success of any individual initiative.

There are some caveats with such an approach. Exactly how you set up your CoC will depend on your organisational culture, history of change, and operational structure, but here are some ideas.

The lead of any such group should be a recognised expert in organisational change management, with a reporting line to a C-Level executive. It should be understood that the team as a whole acts in a support capacity, like internal consultants. Individual change initiatives are owned by their executive sponsor who is responsible and accountable. Members of the team may act as change managers for specific initiatives and in that capacity become responsible and accountable to the executive sponsor for that change.

The centre of compentance maintains records of lessons learned and continuously improves its change management assets over time. It is subject to the same quality controls as other parts of the business, including business/quality assurance, internal audit and organisational governance. The group is centrally funded as a shared service across the business as part of the 'change the business’ budget.

There should be a consistent core of team members and other members of staff may be co-opted into the team on specific initiatves to increase the knowledge, understanding and awareness of change management through the wider organisation.

An additional responsibilty for the Centre of Competance is to co-ordinate all change within the organisation. This enables the CoC to manage the big picture of change within the business. The CoC performs basic impact analysis and due diligence against all potential changes before they launch. This is critical to understand where effort is being potentially duplicated (or worse!) and to establish where there may be synergies between apparently independent initiatives. It helps the business establish priorities and most importantly makes sure that the change is adequately thought through before being launched. Recommendations are fed back the steering board who make the final decisions on which initiatives should proceed, be put on hold or cancelled.

The role of the CoC should be communicated to all staff - and they should be encouraged to interact with it. Having an open and transparent change organisation is key to getting people on board. If the CoC is kept behind closed doors its very purpose will be undermined.

Building a  Change Centre will take some time and success certainly won't happen overnight. There may still be issues regarding change projects, but fixing these issues should become easier and your change initiatives should become less painful. More importantly you are setting a foundation for sustainable change in the future - and you can be sure there will be plenty more change to come.

Teamwork - Eight Characteristics to Describe a Great Team

Back in March this year I wrote a post about Teams where I suggested that the managerial obsession with team building is sometimes not only inappropriate but actually has a negative effect on the individuals being shoe-horned into an artifical construct.

I’ve continued thinking about teams and teamwork and recently started reading "Teamwork Is an Individual Skill: Getting Your Work Done When Sharing Responsibility” by Christopher M. Avery. I’m not very far through the book but I’m already beginning to agree with what I’ve read so far. Whilst reading on the train back from London last night a thought struck me about what a team means to me.

• Trust
• Empathy
• Acknowledgement
• Motivation

What struck me as I wrote this down was that it applied to both a team in the ’traditional' sense of the word - namely a group of individuals collaborating closely to achieve a shared end result - as well as a bunch of people pigeon-holed together for organisational convenience.

I don’t believe there’s any need to look at the words individually. They are common enough and dictionary definitions should suffice. But when you take the words collectively it doesn’t take long to notice that they are the words we implicity think about when we think of friendship and social interaction. In other words, the people we like to choose to hang out with in a non-work environment are the people:

• who we trust and who trust us
• who we have some empathy with and who can empathise with us
• who acknowledge us for who we are 
• and who motivate us in our daily lives - who support us when we’re down and urge us on to bigger things

I recently spent some time working in Prague with a group of project quality managers from various parts of the world. None of us were acquainted before we started working and each of us was assigned a set of projects to support. We primarily worked as individuals but were classed as a team from an organisational perspective. We started as strangers and when I left at the end of my contract we had become good friends. We had also become a ‘team' because each us were exhibiting those characteristics in my list. I don’t believe that it’s a coincidence that some of the best sporting teams and business teams are largley made up of people who have close social ties.

No matter how much I would like it, the characteristics of a successful social circle are not enough to build a successful operational unit. There are some other characteristics required, the characteristics that determine how successful teams achieve their goals. The whole concept is commonly called teamwork and there are four important characteristics that help teams do great work.

• Win-Win
• Opportunity
• Results
• Knowledge

Successful teams look for Win-Win situations. Compromise on anything less is deemed a failure, so great teams are exceptional optimists who find ways of working where everyone gets something and no-one comes out a loser. Crucially, win-win situations are achieved by honest means, there's no bluffing, everything is open and transparent.

Good teams look for opportunities - how can we do this better? What else do we need to help exceed our customer's expectations?

Great teams are results oriented. They understand implicitly what is required and they use measurement carefully and wisely to ensure that what they deliver is what is wanted and to the expected standards. They don't do stuff that doesn't add value to the end result - sometimes even going below the corporate governance radar to achieve the desired results (without breaking the law!).

Continuous learning is an essential characteristic of any individual who wishes to succeed. In a team or collaborative environment it's all about how the individuals share that knowledge and how they urge each other to look further than their existing boundaries and concepts.

I still believe that much of the material written about high performing teams is garbage, written by people who have never experienced how a high performing team actually operates. I'm lucky enough to have that experience. I'm sure there's much more to be said on the subject, but for now I'm comfortable with my eight characteristics that help describe TEAMWORK.

Quality - What's It Really All About?

I've spent a lot of time recently (far too much I fear) looking and occasionally participating in some of the LinkedIn Quality Forums. Most of these have been the ISO 9001 type forums rather than domain specific. With ISO 9001 being a generic quality standard, it’s not surprising that the participants in these forums come from all walks of life, from aerospace to telecoms, from supply chain managers to certification body auditors, and from quality directors to quality engineers. Occasionally there are people like myself - who are primarily involved with knowledge workers.

The biggest take-away I’ve had from these forums is that consensus amongst quality professionals is rare, that tempers seem to flare far more than in other forums I frequent (including some of the ‘agile’ oriented groups) and that you could lock a group of quality folk in a room for a month and they’d still be no closer to defining what quality really is!

So, if there’s so much discord between people who actually spend their lives and earn their keep from working in quality, what chance do the rest of us have. I include myself as one of the rest of us quite deliberately as these days I think of myself as a business person who happens to have some hands-on understanding of quality matters in some very specific situations - namely the IT industry and more specifically in software development.

Looking for a standard definition doesn’t really get us very far. I’m not even going to bother with a dictionary definition because it’s so vague but here’s Wikipedia’s entry:

Quality in business, engineering and manufacturing has a pragmatic interpretation as the non-inferiority or superiority of something; it is also defined as fitness for purpose. Quality is a perceptual, conditional, and somewhat subjective attribute and may be understood differently by different people. Consumers may focus on the specification quality of a product/service, or how it compares to competitors in the marketplace. Producers might measure the conformance quality, or degree to which the product/service was produced correctly. Support personnel may measure quality in the degree that a product is reliable, maintainable, or sustainable. A quality item (an item that has quality) has the ability to perform satisfactorily in service and is suitable for its intended purpose.

The clue as to the problem is clearly stated in the second sentence which is so important that I’ll quote it again.

Quality is a perceptual, conditional, and somewhat subjective attribute and may be understood differently by different people.

My experience of quality is mostly internally facing, supporting the group of people who collectively have responsibility for developing the IT product or service, be they managers, developers, testers, analysts or even salespeople, HR, and finance. This is my set of primmary customers, and there is usually some interaction or interface with a client side quality person. The products I have traditionally had responsibilty for are the processes, artifacts, workflows, data and tools that my customers need to be able to produce the best products they can for their customers.

It’s been evident for many years that trying to apply traditional product and manufacturing quality tools in a knowledge working environment is somewhat futile. Conceptually, there are great ideas that can be applied in both manufacturing and knowledge based industries. A great many quality principles can be applied universally, but principles, ideas and tools need to be aligned closely to the environment they are to be used in. In other words, they are almost always contextual.

An inspection process (let’s not get involved for now about whether inspection is a good or bad thing) in the software development environment is very different to the inspection process on an automotive production line. Six Sigma out of the box, doesn’t work well in the software development environment - if for no other reason than the original principles were designed to work with highly repetitive automated processes where human interaction is much less than when developing software which is highly dependent on individuals. We have a similar situation where Lean Manufacturing ideas applied to an office environment without some serious tailoring and adaptation leads to the type of nonsense I described in my previous post where desks were marked out with the 'optimised' positions for computers, keyboards, mice, telephones, etc. regardless of whether a person was right or left handed.

Ultimately, it doesn’t matter too much if there isn’t consensus between quality folks coming from different contexts. What’s important is that people in the same organisation have a consistent view of what quality means in their very specific context. I’m not talking about the slogans and banners that seem to adorn so many office corridors and walls, but a real shared understanding of what is expected from your people when it comes to quality in the workplace, and an up front statement of what your people can expect from their quality department. And then we all need to act and behave accordingly.

If we work on the old adage that "quality is everyone’s responsibility", then this is the very least we can do.

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.

Blueprints for Success or Recipes for Disaster?

I've seen a few articles recently about using 'blueprints' for the successful implementation of organisational change, especially in the IT industry. I rarely read beyond the title because I believe there is a fundamental problem in the concept of using a blueprint for anything other than what the original term designated, namely: 

A blueprint is a reproduction of a technical drawing, documenting an architecture or an engineering design, using a contact print process on light-sensitive sheets. Introduced in the 19th century, the process allowed rapid and accurate reproduction of documents used in construction and industry.

I know there will be people out there accusing me of being pedantic and that over time the term blueprint has come to mean a template, plan or design that may or may not be reusable. But the fact is that many people will associate the concept of a blueprint as being a very detailed schematic without which certain projects will be doomed to fail. From there you might be then be forgiven in thinking, that if you have a proven blueprint, you are guaranteed success for future undertakings. You probably couldn't be further from the truth.

As a leader, it took me precisely two change initiatives to work out that blueprints don't work in that context - and in fact very rarely work in IT projects of any description, unless they are relatively simple, repeatable infrastructure projects. As soon as the level of complexity is increased, the blueprint becomes a millstone rather than an aide.

Having worked within organisational project and process improvement teams for some years, I eventually found myself responsible for setting up and managing a new team from scratch. Having built a very successful group with a global reputation, I was asked to repeat the process with a larger organisation. Over-enthused with my previous success I made the assumption that I could use the 'blueprint' and repeat what I had previously achieved. What I failed to take into account was that even a few hundred miles away, the culture within the same organisation was completely different from where I'd come from. My 'blueprint' failed and so did I. 

Except in very small companies, cultures are often very different across the business - different attitudes and sub-cultures prevail between departments, and even within the same department there may be further sub-cultures between different buildings or even different floors in the same building. When companies go across countries or continents, the differences will magnified enormously and any previously successful blueprints will be mostly worthless.

There are, however, alternatives to blueprints which can help enormously to tilt the scales of change in favour of success. Using a change management framework, either homegrown or from external sources is a necessity not an option (yet many large organisations still fail to understand this and wing it with all their change programmes). Integrating good project management practice into your change process will help enormously. 

The greatest chance of succeeding with change initiatives is to make use of the expertise in your organisation that is hidden in plain sight - the people who do the day to day work, not managers and consultants who have their own agendas. Involving people from the outset will help prevent you from making dumb decisions, from disenfranchising the work force, and for misunderstanding or misinterpreting the organisation's ability and desire to handle specific changes. 

Blueprints are fine if all the materials and conditions and constraints defined within those blueprints are available or can be met as specified. If they aren't, then the blueprint is probably no longer valid and needs to be modified. 

A half decent cook will be able to follow a recipe and adjust things as they go along to allow for deviations in ingredients, number of diners, time available and a myriad of other variables. If you are leading change initiatives you need to follow the same principles. It won't take long to find out that it's the recipes that help you succeed and the blueprints will guarantee your failure!

Standard Disillusionment

I've been getting increasingly disillusioned with standards and certifications as I've grown more experienced, older and wiser. And it's not always the standards themselves, though increasingly that is also the case. It's the bodies that own and curate the standards, the organisations that administer them and the people who act as judge, jury and executioner for all things related to a standard.

I used to think that standards were useful. There are probably some standards which still are useful. These are the ones regarding industry specific rules and regulations which are designed to benefit people's safety and well-being. But generic quality standards appear to be being continually dumbed to such an extent that they are becoming increasingly meaningless and irrelevant.

ISO 9001 in particular has had a chequered history. When I first started using it many people were of the opinion that it didn't matter how you interpreted it. As long as you did was you said you were going to do - even if it was plainly wrong - you could gain your ISO 9001 certification and be a 'quality organisation'.  The 2000 release did much to regain faith in the standard, but the forthcoming release appears to be propelling it back into the dark ages.

Much of the current problem with today's 'standards industry' is just that - it has become an industry in its own right and responsible bodies are milking their consumers for every penny they can get. For example it will cost you $79 (about £50) to purchase the 56 page draft version of ISO9001:2015 which isn't due to be finalised until the end of the year.

The key word with a generic standard is interpretation. I've suggested on more than one occasion that quality people fall into one of two camps - those who focus on compliance and telling people what to do (not necessarily ever having done it themselves) and those who understand that the world isn't black and white but made up of many shades of grey and a multitude of other colours, tints and hues. These are the people who have actually done the job, look for pragmatism over compliance and add genuine value to the people they support. They have no need to hide behind rigid interpretations of standards because they understand that different situations require different interpretations and approaches. You only have to look at some of the LinkedIn quality forums to see this for yourself!

When I'm in the role as a quality manager this disillusion with standards can be seen as both a curse and benefit. As a standard becomes more woolly and vacuous it does allow more scope for interpretation which enables me to promote some of my personal business agendas - like reducing organisational tendency to focus on things that really benefit no-one (not even the people pushing them!). At the same time, I have to be careful about voicing my dissatisfaction which could be seized on by the anti-process brigade as an excuse not to adhere to any process - even the good ones.

I'd like to think that the worm will turn - but I'm not going to hold my breath. We seem to go from one extreme to the other. The draft ISO 9001:2015 standard as stated previously runs to 56 pages and gives little guidance regarding interpretation. The ITIL version 3 framework (we can argue another time over whether this is a genuine standard) now runs to just under 2000 pages and costs over £250 - but is summarised in 300 pages for a tenner (as in the ITIL Foundation Handbook) and far less in some of the pocket guides. Much of the rest is simply padding. I wonder if the authors thought that they needed to create hundred of pages of documentation simply to justify the cost.

Standards need to be precise enough to be of value. They need to be affordable enough to find global acceptance, not just in big corporations but in small, one person businesses, and the cost of applying useful and relevant standards needs to be clear and transparent to the business owner.

I've recently worked in a number of major corporations in financial and pharmaceutical domains where they see no need for ISO 9001 amidst the other regulatory standards they have to adhere to - and it believe this trend will increase unless the people writing, publishing and administering the standards begin to get their acts together and start thinking of their customers and the folk who have to implement standards in their own organisations.

Meetings - Corporate Procrastination

Hands up if you've been in a useless meeting this week. It's Friday, so I'm guessing most people reading this have probably been in several useless meetings by now. If you're very lucky your useless meetings may have been interspersed with some useful activities some which involve people other than yourself but would you call them meetings?

I could write a few paragraphs about how you could make your meetings more effective. They'd include having an agenda, an outcome, the right people invited, and having those people prepared for your meeting.

I could extend that list of good things to do in advance of your meeting with some advice on how to run your meetings more effectively. They'd include turning up on time, sticking to your agenda and purpose, keeping people focused and included, not having laptops and phones in use, and keeping brief minutes, at the very least recording any actions arising and decisions made.

But the best solution, is simply to consider the alternatives to having the meeting in the first place.

Even when scheduled in advance, every meeting you convene is going to cause someone an inconvenience, including yourself sometimes.

• Since they accepted the invitation your lead engineer may have suddenly come up with an idea to solve a problem that's been nagging around for a week and now has to break their train of thought to up sticks to attend you useless meeting
• Your product manager may have spent most of the day in useless meetings and hasn't had a break or even lunch and is becoming less and less engaged whilst thinking about his evening meal
• The marketing manager is on leave so you'll have to update her on the outcome of your meeting as soon as she gets back - so you've already scheduled another meeting for the two of you

There are dozens of valid reasons why people have something better to to than sit around talking about stuff when they could be doing useful stuff. Admittedly, the options almost always involve disturbing someone, but it's almost always better to annoy one person at a time than a whole bunch of people simultaneously. So here are some alternative options:

• Put your discussion items in an email and ask the most appropriate people to comment on them within a specified time. This at least allows the individuals to schedule their time to suit them rather than finding a mutual time that is inconvenient for everyone
• Go and talk to someone over a coffee (or pick up the phone if you're not co-located) for an informal chat when it is convenient for you both
• Save your topic for inclusion in another meeting where a suitable action can be taken on how to proceed - you might not need a full meeting to get a resolution
• Allocate a fixed time every week to discuss a bunch of little things that don't each need the disruption of a full blown meeting
• Consider whether the subject matter itself actually needs to be discussed in the first place. Half the meetings that take place in the office are about things that are so unimportant that they don't warrant further discussion let alone a whole meeting!

Meetings are great for making you look busy, and great for giving you something to do when you're bored but there are better solutions to cover both those situations. If you can cut down on the number of useless meetings you set up and have to attend, it might even make the useful meetings work even better!

Orchestrated Knowledge - not really a book review!

• I'm not big on technical book reviews, not reading them and definitely not writing them. And I'm not really going to start now, because in my opinion, technical books tend to be either useful or not, and my reviews won't add to their usefulness or lack thereof. However, I do feel quite happy recommending books, articles and other useful sources of well thought out argument in pursuance of understanding - 'orchestrated knowledge' if you like.
  
  
  Peter Leeson is a veteran process improvement and change management expert and a very popular speaker on the conference circuit. I've been fortunate enough to hear him speak on several occasions and I invariably come out of his talks wishing I had his ability to get my messages across in plain English, without worrying about political correctness and without mincing words. 
  
  
  
  
  
  I've often wondered why Peter has never published a book - his website is filled with papers and presentations which he has been generous enough to share with anyone who cares to seek them out - and he has enough experience to fill several volumes of anecdotes alone.
  
  At last I can stop wondering as Peter recently published "Orchestrated Knowledge - Managing the organisation through knowledge".  Orchestrated Knowledge isn't a large book at a tad over 130 pages, but it's a big book in terms of practical advice, background information into why things are the way they are, and explanations of theories regarding process and change management. There are plenty of anecdotes as well and the whole package is based on Peter's exposure to many real issues faced by companies trying to improve the way they work.
  
  If you want to help improve your organisation and you only read one book this year I would suggest you go out and buy a copy. Now. Because the sooner you read it, the sooner you'll be able to put some of Peter's suggestions into practice.
  
  
  
  

You Don't Know What You've Got 'Till It's Gone

"Don't it always seem to go
That you don't know what you've got
Till it's gone " 

are lines from the 1970 Joni Mitchell song "Big Yellow Taxi" which was an early reflection of environmental blots on the landscape.

Those lines work on so many levels from reminiscing about personal relationships, missed opportunities and regrets about leaving situations or places. But it struck me that they can apply equally well in a business context, particularly during organisational changes.

I can think of numerous situations where I've felt this way, and where I've thought (futilely) about the reasoning behind the decisions which caused these feelings. The helplessness when groups or teams (or even whole departments) are broken up or disbanded and their members reposted to different parts of the organisation. The despair when talented professionals with unique subject matter expertise are made redundant, whilst drifters and far less talented individuals keep their jobs. And the sadness when great managers and leaders choose to leave because they no longer feel they can live with the direction the business is heading.

What I find most disheartening is that these events rarely provide any genuine benefit and, at least in my experience, have generally had the opposite effect of what was intended. Why? Because the people responsible for making the decisions didn't think carefully enough about the consequences of their actions, or if they did, they didn't ask the right questions of the right people who could help them see the potential error of their ways.

One of the problems of organisational reshuffles (which I'd argue are often changes for changes sake) is that incoming managers are often more keen on imposing their vision of how things should be than taking a few weeks or months to understand what they are inheriting. As a result of this zealotry to change (which is often driven by arrogance), the proverbial babies get thrown out with the bathwater.

I remember in one organisation where I was contracting, a new manager, with no operational experience in the area he was taking over, explained to his inherited team that he needed an additional manager to run the team because he personally had too many other direct reports - but none of the permanent employees in the team were experienced enough to take on the role - despite each of them having twenty years subject matter expertise and most of them having managed similar teams in other organisations. All but one person either left the company or sought alternative positions. The knowledge base, value of the group (and moral) in that group plummeted over the course of three months.

In far too many situations the people that make the decisions ultimately end up reversing them and attempt to rebuild the teams or groups they previously broke up (although they might make some name changes to try and save face). The problem is the damage has generally already been done. Once you lose the trust of those key people and the bonds and networks they have built up, nothing you can do will rectify what has taken place. (And rest assured, bringing people back to their old roles as contractors won't help, and will prove just how wrong you were in the first place!)

When it's gone it's gone, and you can only rue the fact and hopefully learn enough that next time you find yourself in the same situation, you don't make the same mistakes.

I Am Not A Resource...I Am A Person

The most frequently repeated quote from the 1960's cult TV series, The Prisoner, is probably "I am not a number, I am a free man". Much has changed since then, and global corporations now rule the world. I'm repeatedly find myself getting drawn in to discussions resonating around a similar theme in this brave new world where managers insist on calling me a resource. I am not a resource, I am a person!

Some folk say I get too worked up about this - they make counter claims that terminology doesn't matter, or that the groups that look after people are Human Resource departments (didn't they used to be Personnel Departments?). But, to me, words are important, and just because some groups have redefined certain words to suit their own agendas doesn't mean that they are right and it certainly doesn't mean that we don't have the right to complain. But let's get back to the point.

According to Wikipedia, the first use of the term Human Resources, in a modern connotation was in 1958 by E Wright Bakke - an American economist (which I guess says it all!). In my view a resource is passive, an inanimate or insentient object, like a computer, or a milling machine or a desk. It may require due care and attention to keep it functioning effectively, but it doesn't have needs that it can articulate or negotiate. A resource, in this sense of the word, can be moved around, redistributed, taken apart and rebuilt for a different purpose.

This dispassionate use of the word resource to describe people only continues to fuel the apparently insatiable appetite of institutional shareholders and market/financial analysts to demand head count reductions as their key measure of how to cut operational costs. It's a lot easier to tell the CEO that they need to cut out 1400 resources to improve productivity than it is to sack 1400 people and screw up their lives. Resources feature on balance sheets, people don't. I was recently incensed by an article about Yahoo where a Wall St. analyst was demanding that Marissa Meyer needed to fire a further 1400 staff in order to match Facebook's or Google's productivity rates. Because that's the only strategy he could understand. He couldn't appreciate that in a organisation already suffering from morale issues, further job losses would almost certainly lower productivity even further. And he certainly couldn't seem to understand that productivity can be improved by different means, far more effectively and successfully. And in a sustainable way.

Next time you look in the mirror, will you see a resource staring back at you or will you see a reflection of yourself; a real, flesh and blood person with needs, emotions and feelings?

5 Facets of Change - Revisited

[I first wrote about the 5 Facets of Change in October 2009 and followed up later in that month with some updates to the model. The two posts have been among the most popular and well received, but it occurred to me that I have never published the combined posts and explained the model in its entirety. So this post rectifies that oversight and includes my most recent thinking. I'm intending to publish an ebook in the summer describing the model and its implementation]

Managing change at the corporate or enterpriselevel is not trivial, which means it cannot be left to chance. The larger or more complex the organisation, the greater the impact of changes and the greater the possibility of things going badly wrong unless due care andattention is placed on the process of making the change.

The 5 Facets of Change is a mechanism to enable agents of change, from the senior executives, through the middle management and the people most impacted by change, to understand how change initiatives need to be organised and executed to ensure the greatest likelihood of success.

5 Facets of Change

We often talk about change management life-cycles in the same way that we think about a project management life-cycle. The problem with this approach is that change doesn't work in neat phases quite the way that a project does. Sure, we can think of start-up, execution and closure phases, as we might do with a project, but the reality is that there are a number of activities associated with successful change that are on-going throughout those phases. The amplitude of those activities in any phase will depend on the nature of the change and the environment into which the change is being introduced.

The 5 Facets model uses the Change itself as the central theme. This is supported by 5 key groups of activities which need to take place to enable the change. When we define the change in this central theme we need to look at not only the objectives and reasons for the change, but we need to anticipate how the change will integrate into the existing organisation processes, tools and culture. We can then use the five facets as strategic and tactical management activities to ensure that all aspects of change are dealt with during the transformation and transition period (and beyond).

The 5 Facets of Change are:

1. Lead the Change - brings together the requirements for driving the change through the organisation, including sponsorship, change leaderships, change agents and the change team
2. Communicate the Change - examines how to ensure consistent and effective communications during the programme of change, including education and training
3. Manage the Change - describes the activities required prior to embarking on change in addition to the specific management activities required during the change. As well as general planning and management, an important component of this is measurement - understanding how the change initiative is meeting on-going goals and ultimately how successful it is
4. Deal with the Change - focuses on how to manage reactions to the change and specifically how to minimise negativity and resistance. A failure to manage the human aspects of change are often neglected, at great cost to the enterprise especially in terms of performance
5. Relate to the Change - looks at how to manage the stakeholders associated with the change programme, particularly those not directly impacted by the change but who still need to be aware of the plans and progress, and what the change will actually mean to them

Because of the complexity of many change programmes and the sheer number of variables that need to be considered, change is not trivial, and even good change management will not guarantee success. But good change management will reduce the risk of failure, make the transition easier to deal with at all levels of the organisation, and pave the way for further change which is essential in today's dynamic and constantly shifting world.

Thinking Big Is Brilliant But...

I read a couple of interesting posts this week. The first was Are We Too Focused On Incremental Improvement by Bill Fox and the second was You Have To Think Anyway, So Why Not Think Big by Karen Rutter.

They are both interesting posts in their own right and well worth a read. Bill's post reminded me of my own Continuous Tinkering Is Not Continuous Improvement from a few years ago. Karen's post was inspired by a quote by Donald Trump and really struck a chord.

Over the years I have managed numerous change initiatives - both big bang and incremental. They have mostly been successful, although inevitably there are a few projects where the results could have been better. In recent years I've not led the initiatives but I've been able to exert some significant influence in trying to steer them back on track when they looked like they were doomed. Without exception, the key to success has been to have a clearly defined vision and set of desired outcomes and a supporting strategy and tactical plan to help achieve those ends.

What is astonishing, at least to me, is that given the amount of material available to leaders and how the subject of management of change now has such a high profile, why some huge business transformations fail to use even a modicum of the subject matter expertise and knowledge base and are often destined to fail almost right from the start. They often have the vision and some ideas of where they want to be, but little else.

In my very humble opinion, and from my personal experience, it would appear that the common denominator in every case is the use of big external consultancies and the expense of home grown talent. Organisations bring in this "expertise", at enormous cost. Swathes of consultants potter around the place, running staff workshops and "interviewing" managers, and present their findings and recommendations. Often, the recommendations are to implement a standard toolbox solution - a Lean offering, or maybe an Agile offering. They leave a set of folders full of instructions, decks full of pretty PowerPoint slides and a point of contact on site, and journey off to the next engagement to make a shed load more money. They also leave the organisation with a sense of achievement but absolutely no idea what to do next or how to interpret the pretty slides into tangible activities, outcomes and results. (I'm reminded for some reason of Arlo Guthrie's song Alice's Restaurant and the "twenty-seven 8 x 10 coloured glossy photographs with circles and arrows and a paragraph on the back of each one explainin' what each one was").

In the absence of a coherent strategy and tactical change plan, these organisations now do what they understand best - they rebuild the organisation charts, put the same old faces in different boxes and let them get on with it. And twelve months later...they wonder why there is no improvement, or even why some things appear to have got worse and why good things are now broken.

External consultancies want to sell neatly packaged solutions - tailoring these solutions to specific organisational requirements eats into their margins and takes time which stops them moving onto the next client. Even tailored solutions probably don't meet the real organisational requirements, because they rarely take into account the prevailing culture of the target organisation. And in really big organisations, the leadership is so far removed from the people who do the real work, that these "transformations" end up throwing the baby out with the bathwater.

Really successful transformations need to use the internal knowledge, understanding and expertise of the people who do the work. The idea of thinking big is fine - start off with a clean sheet and build a model of where you want to be given no constraints. Work with the people who know best to understand how to transform your as-is, to the to-be, trying not to eliminate the hidden gems within. Think how certain decisions will create dysfunctionality up front and make the necessary adjustments. Model and remodel, understand interdependency and interfaces, clearly define the transition and transformation strategies and tactics and involve the right people at the right time.Lots of transformations talk about harmonisation but end up with discord and incongruent organisational structures, usually where one set of silos is replaced with a different set.

Thinking Big is brilliant, but requires discipline, patience and time. It needs fantastic attention to detail and clear and transparent strategic and tactical planning. Most of all, it demands that leaders trust the workforce and enable them to participate. Above all, forget the idea that you can build a successful transformation on the fly. Despite consultancies claims that they can help you build an aeroplane while it's in the air, would you really want to fly in one?

Leadership - A Duty of Consistency and Common Sense

I read a newspaper article today about a Japanese academic, an expert on China, who works at my old alma mater, the University of Nottingham. She has been forced to leave the UK because she has failed to meet the home office requirement of living in the UK for more than 185 days a year. She was unable to meet that commitment because she had to travel for her work and spent 270 days in China in 2010 and 202 days there in 2011. She has an Australian husband and a one year old son born in the UK. After initially being denied the right to stay in the UK, a judge declared that it was not in the national interest to deport her given her expertise (she advised the UK Government and some of her research was government funded). The Home Office in its infinite wisdom appealed and she has abandoned her claim because of increasing legal expenses.

Meanwhile the country pays host to scores of foreign criminals, often ruthless and violent, who manage to evade deportation, even after serving lengthy prison sentences because they have conned the increasingly useless justice systems over their human  rights.

Before you turn away, this isn’t another article about the nonsensical human rights regulations and their constant abuse and deliberate misinterpretation by our liberal elite. The problem is more that we have lost sense of consistency and common sense in so many parts of our daily lives.

The problem occurs in government, across the civil service, in local authorities but is also rife in private companies and corporations. The larger the instituition, the larger the problem. As systems get bigger, they get exponentially more complex, and as complexity increases inconsistency is almost inevitable. The failure to address inconsistency is largely because we fail to use common sense.

How often do we see businesses embarking on massive redundancy programmes, eliminating their valuable, knowledgeable and loyal staff, only to take on more useless managers and expensive contractors with no loyalty, and with no experience of the real and specific organisational issues that face them.

If we could use a little common sense every time we spotted an inconsistency, we could start to eliminate the inconsistency at least, and maybe even fix the root cause of the problem that gave way to the inconsistency in the first place. In my circles it’s called Continuous Improvement. By fixing problems as you encounter them it is possible to start to control complexity by reducing the number of problems that can occur in the future.

But instead of fixing the right problem, our leaders cover up the issues by creating new rules and regualations and introducing more complexity and more inconsistencies. And the vicious cycle starts over.

As we head towards the general election our politicans should seriously think about policies that end these nonsenses and engage their frontal lobes with a bit more rigor before they embark on the next round of rules and regulations that make our blood boil.

Sadly, it will be too late for Dr Miwa Hirono.

Teams In the Workplace – Flogging a Dead Metaphor?

You could probably wallpaper a small city with the amount of material that has been written about Teams in the Workplace. That search term alone provides 112,000,000 items to browse through. It seems that nearly every day a new article pops up on LinkedIn or HBR or some other illustrious business compendium about how to better manage your teams,  the dangers of underperforming teams,  how to rebuild a failing team and the like. And, inevitably, a good percentage of these articles will make reference to the sports team metaphor.

I’ve been lucky enough to have worked in some very high performing teams whilst simultaneously being part of some very high performing management teams. Conversely, I’ve worked in some highly dysfunctional teams, almost always under even more dysfunctional management. Since I’ve been self-employed I’ve spent most of time my working with groups of people who are referred to as teams, but who are really more a bunch of people thrown together organisationally, geographically or functionally (or a mix of these). The distinguishing feature of these people is that they primarily operate as individuals supporting other individuals, groups or even 'proper teams'.
In the circles I operate in, mainly the quality and process management and consulting world, there are plenty of lone wolves like me. Auditors, project quality managers, process evangelists and consultants often act as one man bands – working with and amongst many teams, but almost always on the periphery of the teams themselves. The nature of the work sometimes necessitates this, but often the people who take on these roles do so because it fits their personalities both in and out of the workplace.

For extroverted introverts like me, this is an ideal situation. I get to focus on the things I do best, for the people who matter the most – namely my customers. I’m not generally subjected to random time-wasting team meetings, and rarely have to suffer the humiliation of clichéd team building exercises like bowling night or a two day outward bound course, both of which fill me with utter dread – the former because it’s a showcase for my total lack of bowling ability, the latter because I used to spend much time in the mountains in the company of my dog or with just a few close companions.

That doesn’t make me anti-social – I’ll go and share a beer and good conversation with my colleagues any day of the week – I’m just averse to being organised in the name of team building when I’m not a member of a genuine team. (Some people might say that I take this aversion even further, and that I’m actually averse to being managed, but I couldn’t possibly comment.)

Good, competent individuals know what needs to be done to achieve the appropriate synergies between themselves and their colleagues. Good leaders are able to see where there may be deficiencies in skills (hard or soft) and plug the gaps accordingly with additional staff or through coaching and mentorship. Likewise, they see where there is discord and take appropriate actions. With good people and good leadership, teams actually become self-forming and self-managing.
 

I often think we have taken this whole sporting metaphor too far when we’re dealing with the workplace. Shoe-horning a group of individuals into a ‘team’ when it isn’t necessary is a waste of time and effort by all parties. I often see it as (yet) another management indulgence – because the books and the articles say it’s a good thing, so a manager does it. The reality is that the vast majority of professional sports people fit into this category of 'groups of individuals' rather than teams. Squash and tennis players, swimmers and athletes, golfers and cyclists are primarily individuals brought together on occasion to compete under a flag - an artifical team - Team GB, the Ryder Cup team or the Davis Cup team. There may be some strategic pairing or tactical placement of individuals to boost the overall 'team' achievement but ultimately it is always about the performance of the individual, regardless of the team. Even soccer, cricket and rugby teams are ultimately teams of individuals and even the best managers are powerless to do anything about a group of players who can't produce the goods on the day.

I said at the beginning that I'd worked in some very high performing teams. Those 'teams' were made up of hugely talented individuals and guided by hugely talented leaders. None of them indulged in puerile team building exercises - they succeeded because of mutual respect, and the  desire to do the best for themselves and the people they worked for, and with, both internally and externally.

The witicism says that there's no 'I' in team.  I'm not so sure about that. The best teams are full of 'I's!

 

 

 

Can Outsourcing Quality Really Be A Good Thing?

After twenty two years climbing corporate ladders I decided to go freelance back in 2006. On several occasions I have taken on a contract as a Project Quality Manager. Generally, this means working as a team member of one or more projects, helping the team, and mostly the project manager, to make sure they are following corporate standards, using good practice and generally steering them in the right direction to ensure that quality is built into the end product.

One of the contuining conversations I have with myself, is whether this kind of outsourcing is a "good thing". My accountant and bank manager would certainly say that it is. With my experience I can command a decent daily rate, and usually I'm protected from political shenanigans which means I can leave my work in the office when I leave the building. I enjoy working at the coal face, engaging with project teams, and even occasionally facilitating beneficial changes in the organisation. Above all, I always try and make a difference.

But my passion is about helping organisations improve, especially in areas which seem to have fallen out of favour as core functions within the business, like quality and process management. More and more businesses are outsourcing their quality and process activities, either to individuals like myself, or to larger outsourcing consultancies like Wipro, Accenture or Cognizant. And this causes me a great deal of concern. In fact I touched on this very dilemma back in 2011.

On numerous occasions I have sat in on Town Hall meetings where the senior management extol the importance of high quality and effective processes and in the next slide indicate that these functions are being outsourced. What sort of mixed message is that? They are basically saying "These are critically important to us but we're going to outsource them to the lowest bidder because cost savings trump everything else"!

When organisations make their quality and process specialists redundant it makes me feel that part of the organisational conscience is being ripped out. These people form a part of the glue that keeps many of the other parts of the business together. When I have been privileged enough to lead quality and improvement activities across the organisation, myself and the members of my team have been among the very few people who interacted with everyone in the business, pretty much on a daily basis. We also had strong connections with other related organisations, mainly other UK delivery centres, but with other global teams. We were uniquely positioned to help teams and individuals reach out to other people who had knowledge that could help our people.

Outsourcing these roles and functions may still ensure that core activities are performed. Contractors can undertake audits, assure compliance, identify and even lead improvement activities but as outsiders they will never be treated in the same way as genuine peers to the engineers and delivery team members. And the little bits of knowledge they accumulate, and the networks they build, will disappear out of the organisation at the end of the contract, leaving the next person to start building up those relationships all over again.

I've often commented that I believe there are two types of quality staff. There's the old style manager who hides behind dusty old standards and checklists, focusing on policing the business, and avoiding change. Then there are the proactive, modern quality leaders who drive change and improvements, strive to add value and work closely with people to help them meet and exceed their objectives. In some ways both of these are preferable to itinerant quality staff, like myself - who have probably been driven to ply their trade like modern day quality mercenaries because their traditional roles have been outsourced.

I've been very fortunate that I learnt my trade as a permanent employee, and managed to embrace all kinds of quality related disciplines on the job. I can double up as a project or programme manager, a process improvement lead, a communications manager or even an operations manager, and I can lead major business change initiatives. But some of the younger people I work with who are starting out on their first quality contracts will not be so fortunate. They won't be offered the same types of opportunities that I was, because those opportunities won't be available to externally contracted quality staff (no matter how good they are).

A dedicated, effective, value added quality service, culture and mindset takes a long time to build in an organisation. And like a reputation, it takes very little for it to be shattered beyond repair. So, if you are considering outsourcing your quality function, think again. Do you really want your reputation to go down the pan in order to save a few overhead costs?