Change in the real world

Managing change in your organisation is a real challenge - lets talk about it, develop ideas, and rant and rave. Let's remember that change in people's business lives affects their real lives too.

Thursday 14 June 2007

Change fatigue, kissing frogs and eating elephants

You have to kiss a lot of frogs to find your prince (why is it never princess?). This is the same with change in a lot of organisations - you have to make a lot of changes to get to your optimal position, some will be successful and others won't. Sad really that we continually flog ourselves in our business lives to get to a position of 'optimality', but achieving this is often a meandering slog.

And worse, we're never sure when we've kissed enough frogs and found enough princes/princesses to achieve our goal - perhaps you can never have enough, perhaps we don't know what our goal is, or someone keeps moving the goalposts?

That's enough about frogs. The real point of this note is to try to write down the reasons why organisations experience perpetual change, and what can be done to minimise change if appropriate. I hope readers have their own ideas to add.

Change fatigue is experienced by most of us at points in our professional (and personal) lives. You can see it in other people when they roll their eyes, slump their shoulders, drag their feet, gossip and whinge etc upon announcement of another change - somewhat unexpectedly the small changes to things like organisational design often get the same reactions as more significant changes (shock, anger, etc). People are people - they have egos and personalities and whatever is changing around them they're looking at the following questions;
  • what's in it for me?
  • was I asked?
  • when and how?
  • how does it really affect the things I care about?
  • why is it happening yet again?
Let's look at why perpetual change happens;
  • because it can. Cynically it gives managers something to do. I don't really think this is common in the real world though, it is often about 'eating the elephant' - lots of changes ('bites') need to be made to enable the ultimate goal ('eating the whole elephant') to be achieved.
  • Using the elephant analogy further, do we really know what the scale of the elephant is? Is there a corporate strategy that elaborates the desired end-state, and what the journey is to get there in terms of underlying operational strategies ? If this isn't clear, then there may be false starts, and false end, leading to the perception of piecemeal change and hence change fatigue.
  • Will the elephant stand still? Clearly a lot of changes are foisted upon organisations by regulators, governments, local authorities, professional bodies etc, and these cannot always be planned for. Some of these changes will be planned, others will not. There are a number of other external factors that cause organisations to have to implement unscheduled change, such as competitive pressures, new products, business opportunities, M&A and the like.
  • How many elephants do we have? Nursing a herd is harder than just one, particularly when the want to move at different rates, go off on diversions, sleep and eat at different times.... The elephants will always need a different degree of nursing too - how much management time does each project require, and can they be managed collectively?

I'm sure that I could continue talking about elephants further, but the point is that there are good and meaningful reasons often why there is perpetual change (sometimes there is not), and I'll list the things that can be done to minimise the change fatigue.

  • Ensure that you have a strategy and a lucid desired end-state. And communicate it so that everyone knows where they are going and can learn to deal with it, and participate! If you tell a group of people that their roles are to be outsourced, then tell them everything (as far as you can), get them to meet their counterparts, understand the implications, get involved in the transaction and transition etc, as there will be a huge number of things that have to happen before the final transfer happens. It is in everyone's best interest that the change is a success.
  • Have detailed operational plans and strategies that map into corporate level strategy. Makes sure that the managers responsible stick to agreed plans.
  • Manage all change in one place - you should aim to get one view of all change across your organisation, and manage it as a cohesive whole at a macro-level. If anyone wants to change their plans, make an announcement or accelerate/decelerate, there is then a means of governance and ensuring that the implications of any adjustment are considered. This is a programme management or change director role.
  • Ensure that there is clarity of sponsorship - knowing that there is a senior sponsor (or the Board for significant change programmes) overseeing what is happening helps calm nerves. But sponsorship must be earnest and visible, otherwise it will not help.
  • Continue to communicate to all stakeholders throughout - once you've set along a path, keep coming back and telling stakeholders what is going on, and ensuring that there is two-way communication, websites, announcement plans and so on. This stops a lot of the worry, angst, gossip and wasted effort. If plans change, then communicate to people as soon as you can. If new things need to happen, communicate as soon as you can. You need to ensure that all key relationships are managed explicitly - if relationships fail, then you are more likely to fail.
  • Design your plans such that there are 'islands of stability' - periods where nothing new happens, everyone has a rest, focusses on the job. This will pay dividends.

Of course, the list above is just a list of things to do for well-managed change initiatives, but that is what makes them well-managed and what helps prevent change fatigue. It is people that stop change, so if you don't deal with the people aspects of change there is the real risk that your change programme will fail.

Friday 8 June 2007

The perils of not dealing wth the soft stuff - an IT perspective

John-Paul Kamath writing for Computer Weekly has laid down various opinions on the importance in managing stakeholders from an IT viewpoint.


I've blogged on this before, but the bottom line in the article is that if you fail to get people behind your development it will fail. There isn't a huge amount of further insight that anyone can give.

Wednesday 6 June 2007

Neglecting to manage change..a poignant article

Dr Andrew M Jones of Lancaster University has published an interesting article in this month's Consulting Times entitled 'Neglect cultural issues at your peril'. Paraphrasing hugely, the article talks about the need to map cultural change aspects to changes in strategy, and indeed that shareholder value is often destroyed where people issues are not dealt with up front.

It surprises me somewhat that there is a need for this type of article in the professional press, and that the enlightenment is still only drifting through amongst leaders of large organisations (see previous posts). Dr Jones quotes Merck's CEO, Dick Clark

“The fact is culture eats strategy for lunch. You can have a good strategy in place, but if you don’t have the culture and enabling systems that allow you to successfully implement that strategy, the culture of theorganisation will defeat the strategy,”

I summarise this a 'people stop change'. You can have a great strategy, all the technology and cash that you could ever wish for, but if you don't manage your stakeholders you are setting yourself up to fail.

Let's think about a mythical organisation that has a new strategy for world domination. What could go wrong? Here's a short list;
  • top managers don't understand the strategy, or indeed buy into it - they carry on working as before;
  • clerical people didn't understand the previous strategy (any of them?), and don't understand this one or care - they carry on working as before;
  • middle managers (the 'nougat' layer) don't worry about strategy, they just need to maintain their bonuses by turning out widgets - they carry on working as before;
  • and so on.

People stop change - you cannot avoid addressing these people issues as a fundamental part of whatever your strategic change is - otherwise there is a real risk that nothing will change, or if it does it won't endure. Culture is a difficult thing to change overnight of course, and a huge amount of planning and execution effort needs to be applied, starting at the same point that the consultants come in to help you map out your change plans.

What isn't change management?

There's loads of confusion out there about what change management is (or isn't), so here's a summary;

It is;

- doing whatever needs to be done to make an event/change happen, with focus on getting all of the practical aspects and people aspects aligned. One needs to ensure that the change happens and sticks - it is people that stop change, not technology. Change management in this sense applies to cultural change, organisational design, behavioural change etc.

It is not;

- Change management in an ITIL, IT, project sense - this is better labelled change control and/or configuration management whereby the control is ensuring that all aspects of a change (to an IT component, a form, process etc) happens, rather than whether people buy into the change and it actually endures.

Rant over.

Thursday 24 May 2007

Networking to deliver change

There is a lot of fuss around on the on-line networking sites at the moment that is basically asking 'what's the the point of networking'. Here's the response I gave to a LinkedIn question on this subject...

"...The point of networking in my view is to build trusted relationships, providing a support and 'friendship' infrastructure - you have to give, give, give and occasionally you get to 'take'. Building these relationships might lead to sales, but it may not be direct sales, rather leads and referrals from folks that trust you to deliver. "

If we apply this to managing change, answering the question of 'what's the point of networking in managing change', I wouldn't change my answer much...

"The point of networking IN MANAGING CHANGE in my view is to build trusted relationships, providing a support and 'friendship' infrastructure - you have to give, give, give INFORMATION and occasionally you get to 'take' THE DESIRED (BEHAVIOURAL) CHANGES. Building these relationships might lead to CHANGE, but it may not be direct, rather STEPS ALONG THE PATH from folks that trust you to deliver. "

The point is that we need to build relationships with people, and build a network of colleagues, suppliers, partners etc that can help us achieve the ultimate goals of our projects - the enduring change that creates the value required. When I worked for a major corporate it was clear that my network helped me deliver, and working on a shorter-term assignments still requires these relationships to be built-up, only more quickly.

I deliberately left the term 'stakeholders' off of my list above - depending upon what you need to achieve, the stakeholder groups that are most affected by the change are probably those where your networking skills will be most valued. You need to nurse those affected by the change, whether as the sponsoring community (who might get fired if it fails!) or those directly impacted through the new systsem, company acquisition, outsource or whatever. It is ultimately 'people that stop change', so you need to ensure that you understand their fears, worries, crises and how you might steer them in the direction of accepting and embracing the change.

There are of course a lot of techniques to help you do this, but that is for another day!!

Monday 23 April 2007

Developing relationships

Sorry for not posting for a while!

I was talking to a colleague about developing business relationships. I thought I would list my initial ideas for the real world....

  • talk don't email - not easy sometimes, but relationships are built from trust and hiding behind an email persona is not going to build a trusted relationship
  • network - link up with as many relevant people as you are able - maybe electronically at first (Ecademy, LinkedIn etc). You need to know people and be able to support relationships with introductions and information
  • market - depending on the degree of transience that you expect business relationships to have, there is nothing wrong with advertising - it is how you turn the responses into long-term relationships if that is your goal
  • join - clubs, professional organisations, rotary etc
  • sponsor - put some money up for a 'good cause', business event or publications - particularly good where you need brand awareness in a reasonably small market place

That's enough for now.

Wednesday 7 March 2007

Driving stakeholders to change

Rick Maurer commented on my previous post around the importance of building trust with stakeholders (also see Rick's great blog Change Management News).

Building trust is key to any human relationship. The stakeholders in a change programme will all be worrying about different things, if they're worrying at all, and will probably have different perceptions of what is actually due to happen, what status the change programme is at, and whether the desired outcome will ever be achieved. They need to see who is helping them through the change, giving them certainty and comfort, and it is important therefore that change and project people spend time and effort building trust through the human relationships.

In the real world people will be less worried about the interesting new system that you are developing that will save the company £xm, they will be worried about what it means for them. Our job is to act as the trustworthy 'oracle' or at least ensure that the senior stakeholders trust us and are trusted by those affected.

There are of course many things that one might do to build that trust, that extends well beyond the 'social' relationships. Here's a few suggestions - the importance of these will depend upon the stakeholder individual or group, where they are in their acceptance of the change etc;

  • Always do what you say you will do;
  • Be seen to deliver;
  • World class project management of risks, issues etc
  • Plan everything, with detailed stakeholder analyses, communications plans etc
  • Communicate (in all its forms)

Tuesday 27 February 2007

How important is being a 'trusted adviser' to clients?

I was asked this a few days ago, so thought I would quickly articulate my views here.

Without trust, it seems to me that relationships are ineffective. Individuals will never achieve optimum performance and the benefits from the relationship will not achieve their full potential.

As a consultant, one strives to become a 'trusted adviser' - as a professional person a consultant strives for client satisfaction as well as personal satisfaction - in a change environment one would gauge this as benefits delivered (exceeding those required if possible) along with the behavioural and process changes that ensure that those benefits endure. As a trusted adviser the consultant is taking the client relationship to the next level - not necessarily for mercenary reasons - endeavouring to use their skills and 'wise counsel' to support their client through whatever challenges faces them.

It seems to me that this is critical to development of a long-term professional relationship, with potential benefits to the consultant of further work and referrals.

Tuesday 6 February 2007

Defining change management

I wrote on 4 January about the tensions between project and change management. The Change Management Learning Center have a great (short) paper aimed at giving a definition of change management.

Wednesday 24 January 2007

Managing the financial impacts of change

I've had a few discussions lately about financial control in a change and project environment. Too much to discuss in detail here, but here's a 'top of my head' list of the things that you might do to keep financial control of your project;
  • Build a narrative business case, and detailed plan;
  • Align that to detailed numbers - implementation (revenue) expenses, capital expenses phased to show cashflow (cash is king!), and benefits case - what will be delivered when and what will the real impacts be;
  • Develop a risk weighted NPV - use factors such as 'do we know how to do this?', 'do we have the resources?', 'budget?' to show an NPV - over time improve the NPV by adjusting the risk factors as you satisfy yourself that you can achieve it. The NPV (or ROCE) is a great measure to show expected financial outcomes.
  • use qualitative measures to support your numbers (which of course you will monitor in detail weekly/monthly!) - are deliverables being completed or is there a bow-wave of activity building up with consequent cashflow impact, are the numbers and criticality of open issues/risks increasing etc
  • Use graphs to compare measures - see the relatives as well as the absolutes.
  • Make sure any numbers that you use are reconciled to source data (ie; are accurate), and preferably 'triangulated' to two sources

With proper (basic) systems and processes, much of this monitoring can be automated!

Enough for now!