Change Management Do's and Don'ts

By Kevin Behr, Gene Kim and George Spafford


 The goal of a successful Change Management process implementation is to reduce the amount of unplanned work as a percentage of total work done. 

Stabilize the Patient and Modify First Response
The goal of a successful Change Management process implementation is to reduce the amount of unplanned work as a percentage of total work done. Organizations that are in a constant firefighting mode can have this percentage at 65 percent or even higher.

The first phase of a Change Management implementation as outlined in the Visible Ops Handbook (a useful guidance and prescriptive roadmap for organizations beginning or continuing their IT process improvement journey) resembles the triage system used by hospitals to allocate scarce medical resources. In a similar fashion, IT must identify the most critical systems generating the most unplanned work and take appropriate action to gain control.

The primary goal of this phase is to stabilize the environment, allowing work to shift from perpetual firefighting to more proactive work that addresses the root causes of problems. Start by identifying the systems and business processes that generate the greatest amount of firefighting. When problems are escalated to IT operations, which servers, networking devices, infrastructure or services are constantly being revisited each week (or worse, each day)?
These items are your list of "most fragile patient" which are generating the most unplanned work. These are the patients that must be protected from uncontrolled changes, both to curb firefighting and to free up enough cycles to start building a safer and more controlled route for change.

For each fragile patient (i.e. server, networking device, asset, etc.), do the following:

1. Reduce or eliminate access: Clear everyone away from the asset unless they are formally authorized to make changes. Because these assets have low change success rates, you must reduce the number of times the dice are rolled.
2. Document the new change policy: keep the change policy simple: "Absolutely no changes to this asset unless authorized by me." This policy is the preventive control and creates an expectation of behavior.
3. Notify stakeholders: After the initial change policy is established, notify all of the stakeholders about the new process. Make sure the entire staff sees it: Email it to the team, print it out, and add it to login banners.
4. Create change windows: Work with stakeholders to identify periods of time when changes to production systems can be made. Your goal will be to eventually schedule all changes into these maintenance windows. Amend the change policy accordingly. For example, Once I authorize the changes, I will schedule the work to be performed during one of the defined maintenance windows on either Saturday or Sunday between 3 and 5 pm.
5. Reinforce the process: By now, you have defined a clear expectation of how changes are to be made. Make sure that people are aware of the new process and reinforce it constantly. For example; "Team, let me be clear on this: These processes are here to enable the success of the entire team, not just individuals. Anyone making a change without getting authorization undermines the success of the team, and we'll have to deal with that. At a minimum, you'll have to explain why you made your cowboy change to the entire team. If it keeps happening, you may get the day off, and eventually, it may prevent you from being a part of this team."

Electrify the Fence
Put a fence around the systems where unauthorized changes are causing the most carnage. Next, you will electrify the fence in order to keep everyone accountable and responsible for playing by the rules.The goal is to start creating a culture of change management.

To do this, proper change monitoring must be in place so you can trust, but verify. You will use this instrumentation to detect and verify that changes are happening within the specified change management process, and also to negatively reinforce and deter changes that are not.

You must be aware of changes on all infrastructure that you are managing: servers, routers, network devices, databases and so forth. Each detected change must either map to authorized work, or it must be flagged for investigation.

Critical questions that need to be answered are:

• Who made the change?
• What did they change?
• Should it be rolled back? If so, then how?
• How do we prevent it from happening again in the future?

The key to creating a successful culture of change management is accountability. If the change process is repeatedly bypassed, management must be willing to take appropriate disciplinary action.

Create the Change Team 
In this next step, you will continue to develop the change management process by creating a Change Advisory Board (CAB), comprised of the relevant stakeholders of each critical IT service. These stakeholders are the people who can best make decisions about changes because of their understanding of the business goals, as well as technical and operational risks.

Create a Change Request Tracking System 
A prerequisite for any effective Change Management process is the ability to track requests for changes (RFCs) through the authorization, implementation, and verification processes.

Paper-based manual systems quickly become impractical when the organization is large or complex, or when the number of changes is high. Because of this, most groups use some computerized means to track RFCs and assign work order numbers. Some refer to these applications as ticketing systems or change workflow systems. The primary goals of a change request tracking system are to document and track changes through their lifecycle and to automate the authorization process.

Secondarily, the system can generate reports with metrics for later analysis. Each change requester should gather all the information the Change Manager needs to decide whether the change should be approved. In general, the more risky the proposed change is, the more information that is required.

For instance, a business as usual (BAU) change, such as rebooting a server or rotating a log file, may require very little data and oversight prior to approval. On the other hand, a high-risk change such as applying a large and complex security patch on a critical production server may not only require good documentation of the proposed change, but also extensive testing before it can even be considered for authorized deployment.

Start Weekly Change Management Meetings (to Authorize Change) and Daily Change Briefings (to Announce Changes) 
Now that you have identified the change stakeholders by creating the CAB, the next step is to create a forum for them to make decisions on requested changes.

The CAB will authorize, deny, or negotiate a change with the requester. Authorized changes will be scheduled, implemented, and finally verified. The goal is to create a process that enables the highest successful change throughout the organization with the least amount of bureaucracy possible.

While they may seem unnatural at first, with practice, weekly 15 minute change management meetings are possible. Take special care to avoid an attitude of "just get it done," which allows people to make changes that circumvent the change approval process.

If you make it easy for all changes to flow through your process, it will soon be easier to use the process than to circumvent it, even during emergencies. CABs must meet on a regular published schedule that all stakeholders understand. To start, each CAB should meet weekly.

Miscellaneous Change Management Do's and Don'ts
Here are some tips for change management.

Items to do:

• Do post-implementation reviews to determine whether the change succeeded or not.
• Do track the change success rate.
• Do use the change success rate to learn and avoid making historically risky changes.
• Do make sure everyone attends the meetings, otherwise auditors have a good case that this is a nonfunctioning control.
• Do categorize the disposition of all changes. In other words, all outcomes must be documented once a change is approved. Three potential outcomes are:
• Change withdraw - the change requester rescinds the change request along with the reason why. This should not be flagged as a failed change in change metrics.
• Abort - the change failed, accompanied by documentation of what went wrong.
• Completed successfully - the change was implemented and is functioning appropriately.

Items not to do:

• Do not authorize changes without rollback plans that everybody reviews. Changes do fail, so be proactive and think ahead about how to recover from a problem rather than attempting to do so during the heat of firefighting.
• Do not allow rubber stamping approval of changes.
• Do not let any system changes off the hook - someone made it, so understand what caused it.
• Do not send mixed messages. Bear in mind that the first time the process is circumvented, incredible damage can be done to the process. "Well heck, we did it last time" or the boss said, "just do it" - both send the wrong messages.

Do not expect to be doing closed loop Change Management from the start. Awareness is better than being oblivious, and managed is better than unmanaged. Start with a particular class of changes and constantly refine the process.

The Spectrum of Change:
The management of change is an evolutionary process. Groups should not become discouraged as they start developing their change management processes. The solutions may require changing people, processes, and technology. The following illustrates the stages of change management:

8.            Oblivious to change - Hey, did the switch just reboot?

9.            Aware of change - Hey, who just rebooted the switch?

10.          Announcing change - Hey, I'm rebooting the switch. Let me know if that will cause a problem.

11.          Authorizing change - Hey, I need to reboot the switch. Who needs to authorize this?

12.          Scheduling change - When is the next maintenance window? I'd like to reboot the switch then.

13.          Verifying change - Looking at the fault manager logs, I can see that the switch rebooted as scheduled.

14.          Managing change - Let's schedule the switch reboot to week 45 so we can do the maintenance upgrade and reboot at the same time.

The Change Management goal is to reduce the amount of time spent on unplanned work down, by reducing the number of self-inflicted problems and modifying how problems are solved so that change is ruled out early in the repair cycle. By increasing the change success rate and reducing MTTR, you not only decrease the amount of unplanned work, but also increase the number of changes that can be successfully implemented by the organization.

Excerpted from - The Visible Ops Handbook, Starting ITIL in 4 Practical Steps by Kevin Behr, Gene Kim and George Spafford. Copyright 2004 by the IT Process Institute (ITPI); all rights reserved.

Technology Change Management

Introduction
This article takes an objective look at Technology Change Management (TCM). It
covers a number of topics such as:

• What do we mean by TCM
• How companies carry out TCM within their IT systems. (Detailed steps are
not included) .
• How their investment can bring a high Return on Investment (ROI) and a low
Total Cost of Ownership (TCO)
• How management should make a decision to invest in technology and how to
bring the change
• It analyses various factors in evaluating the technology and suggests paths and
parameters to successful TCM.


Benefits of TCM

TCM program can be seen as an investment. TCM program should have a vision
statement where, they continuously evaluate new cutting edge technology, find
answers to customer issues, and develop and demonstrate POCs. This will ensure
that, whatever investment is undertaken by the IT division of an organization will
prove to be fruitful. It adds value for the customers by providing them ‘state of the
art’ technology features. It creates the product and service sector with more userfriendly
approaches and provides a rich user experience.


Impact Analysis

Whenever organizations decide to implement a technology change, product upgrade
or technology migration, the first step is to carry out an impact analysis. By impact
analysis, we mean the following questions need to be answered:
A) Why do you need the change?
B) How much effort is involved?
C) What will be the cost of the change?
D) What will be the benefits of the change?
E) Will it suit our requirements? What are we going to achieve, if we implement
the change?
F) Which vendor is best suited and placed to carry out the change?
G) When will the ROI be achieved?
H) Which other systems will be impacted by the change?

The impact analysis will provide a holistic view as to whether the change should be
implemented or not? It is worth spending enough time to carry out an impact analysis
before making any decision.

Market Trends for Technology

Whenever an organization finalises technology, it is worth looking at market trends.
It will give cues as to whether the technology is worth adopting? To what level the
technology has matured? Whether the technology is emerging or old?
Answers to these questions will provide an organization with both the latest trends
and shortcomings. It is sensible to go through reports from Garner, Forrestor, AMR,
Butler, Delphi and Meta groups etc.

Identifying Leaders

It is important to identify who are the leaders in the market, and who are niche
technology providers. Who sets the trend, carries it forward and who reaps the
benefits? There are innovators, early adopters, early majority and laggards. E.g. SAP
is leader in ERP technologies; Microsoft is leader in desktop technology whereas,
BEA and IBM are competing in Java/J2EE based SOA technology. Google is
competing against Microsoft on web based solution by providing Web 2.0, AJAX
technology, search engine, gmail, talk, Google maps and the latest web based spreadsheets.
These are all generic examples. There are many specific packages and applications.
There are also specific niche players. The idea of going along with the leader is that,
it should provide better solutions. There will be not only the latest features but also
better support. It is also important to know, whether those features are useful to your
organization and what is the extra cost you are paying to get those new features.
It depends upon the business requirements. How much growth you see in the
business? How much you can invest? What is the size of the business?


Resilience to Change

Resilience to change starts with an attitude. It is the STRATEGY.
• Whether management wants to incorporate the needed change?
• Whether the organization would like to have the latest technology?

It all depends upon the efforts, cost and what benefits it brings to the table. It also
shows the dynamism and efficiency of the organization to deploy agile methodology,
ready to ‘go to market’ strategy, time-boxing and speed to market. To resolve the
pain area, shed off the burden and meet the global challenges in today’s world. It also
can be termed as, Business Process Re-engineering.


Technology Evaluation

Technology should be evaluated with respect to the following 10 factors. This can be
applied while evaluating the vendors and COTS suppliers. The ultimate results give us
a strategic stack of IT systems.

1. Scalability

Scalability is a measure of, whether you can scale the application on multiple servers
across geographically separated machines. This will make sure that, in event of
expansion of the business, additional hardware capacity can be installed at multiple
locations without affecting the performance of the system. Without changing the
application, the load bearing capacity of the system can be increased by increasing the
hardware capabilities in fragments. Can the various components be installed on
different machines?


2. Extensibility

This tells you whether the application is extensible to take additional load if it needs
to be extended for high volume and additional functionality?
Extensibility also implies that, if new functionality can be added to the application
without making any major changes.


3. Backward Compatibility

This will mean that, if you buy this solution and if you already have the earlier version
of the application, if it will run with the earlier developed components or pose issues?
A good COTS supplier will always make sure that the application they offer has
backward compatibility. If it does not, it is not a good idea to buy its products even if
the vendor is a market leader!


4. Flexibility

Flexibility can be defined as the application’s capacity to configure as per the user’s
requirements and allowing the user to change the code, looks, architecture and design.
Flexibility offers lot of scope for making changes effective without worrying about

how to do it. Is it possible or not? Mostly all open source technology provides
enormous flexibility. E.g. struts and tiles framework using java MVC architecture.


5. Adaptability

Adaptability is how well the application can integrate with other systems and
applications, either existing or planned for future. Also reusability is kind of
adaptability. Whether component developed are reusable?


6. Performance

How good is the response of the system on submitting a request? How good is the
CPU throughput and memory utilization? Is it suitable for real time application?
What is the architecture adopted by the supplier to support high performance?

7. Features / Usability

Are all the functions and features required by the stakeholders offered by the
application? Can these features be customized for the specific needs and user
requirements? How well are the features placed in terms of user interface, simplicity,
availability, intuitiveness, navigation etc? What are the additional features, which
could be useful in the future and which come free with the software?

8. Maintainability

How good is the maintainability? What is the support available from the vendor?
How good is the documentation? What are the issues in maintaining the systems? Is
maintaining the system an automated activity? How much time is required to
maintain the systems on daily basis? If there is a system crash, how fast can the
systems be up and running again? What is the data loss? Is there any fall back and
recovery of data?

9. Simplicity

How well is the system designed for simplicity of use? How easily can it be
modified? How much time is required for any new development, enhancement or a
change request? Is it simple to maintain? How many steps are required to configure
the systems to localize the use? How good is the personalization feature? Has the
principle of separation been applied? Are the business logic, presentation tier and
database handling separated?

10. Reliability

Reliability is the most important factor which tells us, how sturdy is the system?
Does it crash or throws exceptions very often? When does it throw exception? Are
the reasons valid? Is the behaviour of the application stable or weird?


Calculating the Weighting

All these factors are listed; their scores are calculated after applying appropriate
weights. The total score and individual scores are compared for all the suppliers
before making any procurement decision. Management can have a review meeting,
sit together with the lead architects, and decide the strategic stack.
The review can be done considering the business requirements e.g. A real time
systems needs more reliability, performance, scalability, extensibility, simplicity and
adaptability whereas, a static system needs more features, maintainability and
flexibility.

Management Direction & Budgets

It is up to Management whether; they are dynamic enough to meet market demand,
changes and evolutions. In IT, there are continuous upgrades and innovation taking
place. To be a global leader, the organization has to always be on its toes to perform
and stay competent. Industry has seen the success of implementing innovative
solution in Supply Chain Management, Transportation & Logistics, Retail, Banking,
Health insurance, Telecom and other domains. ERP, SCM, BPM, Portal, EAI, CRM,
DW/BI vendors provide ranges of products with the latest features which makes
technology obsolete in no time at all. Management has to be vigilant and sensible
regarding what is happening in the market. Companies should have their Lead
Enterprise Architects evaluating technologies all the time and seek their advice and
suggestions.

Bundling IT applications and solutions, and offering it to the internal and external
client is an art. Proper use of budgets and agile & iterative methodologies will bring
success to the organization. The benefits and the direction of management go hand in
hand, if management is willing to invest.


About the Author

The author is currently working in a company known as, Tech Mahindra as a Project
Manager in Mumbai. He has 15 years of industrial experience including 9 years in IT.
He has handled fortune 100 clients and their service delivery for projects of varied
range and scope. He has implemented various technology stacks and worked as an
Enterprise Architect for different clients.
Project Perfect is a project management software consulting and training organisation
based in Sydney Australia. Their focus is to provide creative yet pragmatic solutions
to Project Management issues.
Project Perfect are project infrastructure specialists. They sell “Project
Administrator” software, which is a tool to assist organisations better manage project
risks, issues, budgets, scope, documentation planning and scheduling. They also
created a technique for gathering requirements called “Method H”, and sell software
to support the technique.

NB: This Article from www.projectperfect.com.au

For more information on Project tools or Project
Management visit www.projectperfect.com.au

Business development driven change

Business development potentially includes everything involved with the quality of the business or the organization. Business development planning first requires establishing the business development aims, and then formulating a business development strategy, which would comprise some or all of the following methods of development.

• sales development
• new product development
• new market development
• business organization, shape, structure and processes development (eg, outsourcing, e-business, etc)
• tools, equipment, plant, logistics and supply-chain development
• people, management and communications (capabilities and training) development
• strategic partnerships and distribution routes development
• international development
• acquisitions and disposals

Generally business development is partly scientific, and partly subjective, based on the feelings and wishes of the business owners or CEO. There are so many ways to develop a business which achieve growth and improvement, and rarely is just one of these a single best solution. Business development is what some people call a 'black art', ie., difficult to analyse, and difficult to apply a replicable process.

Fast changing environments

Planning, implementing and managing change in a fast-changing environment is increasingly the situation in which most organizations now work.
Dynamic environments such as these require dynamic processes, people, systems and culture, especially for managing change successfully, notably effectively optimising organizational response to market opportunities and threats.

Key elements for success:

• Plan long-term broadly - a sound strategic vision, not a specific detailed plan (the latter is impossible to predict reliably). Detailed five years plans are out of date two weeks after they are written. Focus on detail for establishing and measuring delivery of immediate actions, not medium-to-long-term plans.
• Establish forums and communicating methods to enable immediate review and decision-making. Participation of interested people is essential. This enables their input to be gained, their approval and commitment to be secured, and automatically takes care of communicating the actions and expectations.
• Empower people to make decisions at a local operating level - delegate responsibility and power as much as possible (or at least encourage people to make recommendations which can be quickly approved).
• Remove (as far as is possible) from strategic change and approval processes and teams (or circumvent) any ultra-cautious, ultra-autocratic or compulsively-interfering executives. Autocracy and interference are the biggest obstacles to establishing a successful and sustainable dynamic culture and capability.
• Encourage, enable and develop capable people to be active in other areas of the organization via 'virtual teams' and 'matrix management'.
• Scrutinise and optimise ICT (information and communications technology) systems to enable effective information management and key activity team-working.
• Use workshops as a vehicle to review priorities, agree broad medium-to-long-term vision and aims, and to agree short term action plans and implementation method and accountabilities.
• Adjust recruitment, training and development to accelerate the development of people who contribute positively to a culture of empowered dynamism.

 'Troubleshooting' tips for investigating apparent poor performance

If you are ever give the job of 'troubleshooting' or investigating (apparent) poor performance, perhaps in another location or business belonging to your own organisation, or perhaps as a consultancy project, here are some simple tips:

Actually 'troubleshooting' isn't a great word - it scares people. Use 'facilitator' or 'helper' instead. It sets a more helpful and cooperative tone.

On which point, you could well find that the main issue will be people's resistance and defensiveness to someone coming in to their organisation do what you are doing. When you overcome that challenge, then you can start comparing what's happening with what the organisation sets out to do (mission, values, goals, priorities, targets, key performance indicators, processes, measures); how the people feel about things (staff turnover, retention, morale, attitudes); and how customers and suppliers feel about things too (actually go out and visit customers, and ex-customers particularly).

You must observe protocols very diligently - introduce yourself properly to people and explain who you are and what you are doing. Don't assume that your task gives you the right to be secretive, or to have access to anyone or anything without permission. Ask for help. Ask for introductions. Ask for permission. Be polite and courteous. Respect people more than you would do normally, because they will be sensitive, understandably so.

Look at the Sharon Drew Morgen facilitation method, which helps with the style and approach you should use. You must aim to help, enable and facilitate discovery and clarity, not work in splendid isolation, as an outsider, who's come to 'sort things out'.

And then be led by the people there as to what can be improved. You should adopt the role of a researcher and enabler rather than a problem solver.

Plan lots of questions that will help people to tell you how they feel about things - customers and staff and suppliers - and what they think can be done to improve things.

Avoid asking 'why' unless they're really trusting you and working with you. Used early, 'why' puts people on the defence and you'll not find out anything.

Look at the customer relationship materials as well - customers will tell you what's best to focus on, and will give you an early opportunity to facilitate some improvement responses. Also look at the employee motivation survey material.

It's likely that you'll have to write a report and recommendations afterwards, in which case try wherever possible to involve the people in what you say about them. Let there be no surprises. Be constructive. Accentuate the positive. Be straight and open with people.

Enjoy the experience. Be respectful and helpful to people and they'll be respectful and helpful to you.

Other points about people and change

Strong resistance to change is often rooted in deeply conditioned or historically reinforced feelings. Patience and tolerance are required to help people in these situations to see things differently. Bit by bit. There are examples of this sort of gradual staged change everywhere in the living world.
The Psychological Contract is a significant aspect of change, and offers helpful models and diagrams in understanding and managing change - potentially at a very fundamental level.
Also, certain types of people - the reliable/dependable/steady/habitual/process-oriented types - often find change very unsettling.
People who welcome change are not generally the best at being able to work reliably, dependably and follow processes. The reliability/dependability capabilities are directly opposite character traits to mobility/adaptability capabilities.
Certain industries and disciplines have a high concentration of staff who need a strong reliability/dependability personality profile, for example, health services and nursing, administration, public sector and government departments, utilities and services; these sectors will tend to have many staff with character profiles who find change difficult.
See the personality styles page to help understanding about different types of people.
Age is another factor. Erik Erikson's fascinating Psychosocial Theory is helpful for understanding that people's priorities and motivations are different depending on their stage of life.
The more you understand people's needs, the better you will be able to manage change.
Be mindful of people's strengths and weaknesses. Not everyone welcomes change. Take the time to understand the people you are dealing with, and how and why they feel like they do, before you take action.

Job reorganization, task analysis, job transfer due to IT development or outsourcing etc

First see the modern principles which underpin successful change. It's not always easy or perhaps even possible to consider matters at such depth, but try to if you can, or try to persuade others above in their ivory towers to think about the fundamental integrity of the situation, instead of short-term profit, or satisfying greedy shareholders.


There are various approaches to task analysis and job reorganization, whether prompted by outsourcing or IT development. Generally change process of this sort is pragmatic, and it's difficult to identify transferable processes, templates, etc. Examples of projects don't generally find their way into the public domain, although the likelihood is increasing of government project pdf's becoming available on the web as this sort of information is increasingly required to be available to the public. IT vendor case studies and trade journals of the IT and outsourcing sectors can also provide indicators of best practice or transferable processes. There are some useful software tools now available, which are helpful, especially if the change involves a high level of complexity and a large scale.


As a broad guide when managing this sort of change, these aspects are important for the process:

• Really understand and clarify mutual expectations about the level of detail and cost that the project requires. Sometimes it's possible to see it what you need on a table napkin. The organisational context, and other strategic drivers, personalities and politics are often more significant influences than the task analysis.
• If you are a consultant or project manager, agree expectations on a pragmatic basis. Agree the templates and systems to be used and the the level of report data required for the decisions to be made.
• Assume that the situation can be improved - it generally can be, so while it's essential to capture all activities based on current jobs, many of these can be absorbed, superseded, updated, etc., when you begin to look at the ideal situation ('blank sheet of paper') possibilities, so;
• A new overview analysis enables fresh unencumbered look at the whole, which suggests new and better ways of doing things. A flip chart and a few creative minds are the main pre-requisites. It makes a great workshop session and is good for creating ownership and buy-in for major change. It's a good process also to cascade down to departments to bring out ideas for improved processes and new ways of doing things.
• In terms of capturing all current processes and inputs, the individual job analysis templates need to enable jobs to be broken down into sub-tasks, and elements within sub-tasks.
• This is a tricky one, and not practicable in certain X-Theory cultures, nevertheless, be aware of the high probability of upsetting people whose jobs are threatened by change and try to develop a way of anticipating and reducing damaging fall-out. Treat people at risk with the respect they deserve and avoid keeping them in the dark - involve threatened people wherever possible so they can see what's happening and why. If possible encourage the executive team to take the same humane approach, and try to establish counselling and support resources if none exist already.
• Analyses are more helpful if they identify critical vs essential task elements - this will help you to help the decision-makers to be more pragmatic (not least because by applying pressure to some of the 'essential' elements will reveal them to be habitual dispensable or traditional replaceable elements).
• Flow diagrams identify subtask linkage (inter and intra), variation and chronology.
• Behaviour needs identifying aside from processes.
• Standards, performance tolerance, % reliability, etc., should be indicated in task analysis as applicable to the sub-task or activity concerned.

Ideas on illustrating change management issues

When people are confronted with the need or opportunity to change, especially when it's 'enforced', as they see it, by the organization, they can become emotional. So can the managers who try to manage the change. Diffusing the emotional feelings, taking a step back, encouraging objectivity, are important to enabling sensible and constructive dialogue. To this end, managers and trainers can find it helpful to use analogies to assist themselves and other staff to look at change in a more detached way.


On this site there are several illustrations which can be used for this purpose, depending on the type of change faced, and the aspect that is to be addressed. Here are a few examples, useful for team meetings, presentations, one-to-one counselling or self-reminder, particularly to help empathise with others facing change:


On the Stories section look at 'Murphy's Plough' (negative thinking = obstacle to change) and 'We've always done it that way' (not questioning need for change). Both good aids for understanding and explaining why people - all of us - find it difficult to change assumptions, conditioned thinking, habit, routine, etc.
Look also at the Monkey Story, as to how policies, practices, attitudes and even cultures can become established, and how the tendency is to accept rather than question.


Just as the state of 'unconscious incompetence', needs to be developed into 'conscious competence' to provide a basis for training, so a person'ssubjective emotion needs to be developed into objectivity before beginning to help them handle change. None of us is immune from subjectivity, ignorance or denial. The lessons and reminders found in stories and analogies can help to show a new clear perspective.


Aesop's Fables section has other short and beautifully simple analogies useful for illustrating aspects of causing or dealing with change, for example (all on the Aesop's Fables section):


The Crow and the Pitcher (change being provoked by pressure or necessity)
The North Wind and the Sun (gentle persuasion rather than force)
The Lion and The Ass (enforced change - might is right)
The Crab and his Mother (lead by example and evidence - or you'll not change people)
The Miller, his Son and the Ass (no single change is likely to please everyone - everyone wants something different)
The Oak and the Reeds (the need for tolerance - changer or 'changees')
The Rich Man and the Tanner, (time softens change - given time people get used to things)
The Ass and the Mule (agree to reasonable change now or you can risk far worse enforced change in the future)

John P Kotter's 'eight steps to successful change'

American John P Kotter (b 1947) is a Harvard Business School professor and leading thinker and author on organizational change management. Kotter's highly regarded books 'Leading Change' (1995) and the follow-up 'The Heart Of Change' (2002) describe a helpful model for understanding and managing change. Each stage acknowledges a key principle identified by Kotter relating to people's response and approach to change, in which people see, feel and then change.


Kotter's eight step change model can be summarised as:

• Increase urgency - inspire people to move, make objectives real and relevant.
• Build the guiding team - get the right people in place with the right emotional commitment, and the right mix of skills and levels.
• Get the vision right - get the team to establish a simple vision and strategy, focus on emotional and creative aspects necessary to drive service and efficiency.
• Communicate for buy-in - Involve as many people as possible, communicate the essentials, simply, and to appeal and respond to people's needs. De-clutter communications - make technology work for you rather than against.
• Empower action - Remove obstacles, enable constructive feedback and lots of support from leaders - reward and recognise progress and achievements.
• Create short-term wins - Set aims that are easy to achieve - in bite-size chunks. Manageable numbers of initiatives. Finish current stages before starting new ones.
• Don't let up - Foster and encourage determination and persistence - ongoing change - encourage ongoing progress reporting - highlight achieved and future milestones.
• Make change stick - Reinforce the value of successful change via recruitment, promotion, new change leaders. Weave change into culture.

Kotter's eight step model is explained more fully on his website www.kotterinternational.com.


Related to Kotter's ideas, and particularly helpful in understanding the pressures of change on people, and people's reactions to change, see a detailed interpretation of the personal change process in John Fisher's model of the process of personal change.