Monday, 23 November 2015

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!

Wednesday, 23 September 2015

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.

Sunday, 13 September 2015

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.

Friday, 28 August 2015

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.