02November

In part 1, last week, I described how a Change Management Framework can be used to consider and plan the activities needed to implement your proposed change. This week in part 2, I will describe more about what’s involved to help sell your change and actually get the organisational commitment to do it. Unfortunately, with so many competing demands, a good idea by itself often isn’t enough. You need to fight to get attention, and to get commitment from your management team that the idea is worthwhile pursuing.

Leading the Case for Change

Establishing the need for change is your first major task. You need to define the problem, and the risk or cost of not changing, then outline a potential solution (i.e. what the change should look like when it’s done).

Consider the motivation for your proposed change. Typically it will be one, or a combination, of the following:

• Product or service expansion: Adding new capabilities to take advantage of new opportunities or remain competitive in a changing environment. This could also include changing processes or systems to fit with an adopted business strategy.
  

• Increase capacity: Allowing for system and transaction growth, or increased complexity. This investment may be needed to ensure future stability for systems, and the business, to remain viable in the future.
  

• Cost savings: This could either be a direct reduction in business costs, or that the introduction of new systems or processes will improve efficiency/effectiveness – resulting in a better value – and a reduction in cost for future expansion or maintenance.
  

• Risk reduction: This might include systems stabilisation (reducing loss of service risk), or the new capability to improve the reliability of external business and compliance reports.
  

Usually, the idea by itself isn’t enough, so you’ll need good supporting evidence for your claims. Although you can use external studies, white papers and recommendations, these often lack the impact needed for management to take any immediate action. You can add extra emphasis using internal examples of significant issues (and costs) which might have been avoided, or opportunities that have been missed. It might also help if you can point to internal prototypes or examples where the change was implemented on a small scale. Essentially, you need to put enough of a story together to help swing your case and get people to put their funding and resource behind it – and in preference to other competing projects.

Justifying the Change through Benefits Analysis

Next, you’ll need some sort of Benefits Analysis to clearly define (and quantify) the benefits that your project will bring. This analysis is likely to make or break your project since, unless you can show the project makes economic sense, its unlikely you’ll get funding to proceed.

In traditional projects, the “benefit” delivered by the project is something tangible - such as extra revenue or measurable cost savings. However, benefits for Business Intelligence projects are almost always intangible. You'll generally get a new set of reports, and these reports will provide new insights into the business … but how much are these worth, and how does this compare with the anticipated cost of your project? In some cases your business management will understand the value of the business information that your proposed system will deliver, but in other cases they won’t. Explicitly linking your project to real business issues is one method to help build your case. Consider the following approaches:

1. Compliance. If the project delivers reporting and analysis capability (or audit quality) needed for compliance, then it may be that the business has no option other than to proceed. Failure to meet government or stock exchange regulations means risking big fines or lost of business certification.
    
2. Risk reduction. This helps if you can point to recent failures or "near misses", and costs associated with those occurrences, illustrating how these could be avoided by systems delivered by your project. These systems are often linked to ensuring stability and quality of service for your organisation and its customers.
   It helps if the "risk" you're attempting to avoid actually has a reasonable chance of occurring, and is something that you can demonstrate. If that risk is seen as having a low probability or just isn't immediate enough (for managers' whose focus is on the short term) then you might find your project gets deferred, or is written off by a manager who is prepared to "accept" that risk even if its something potentially catastrophic.
    
3. Linkage to specific business cost reductions. You can estimate the savings that can be achieved by shaving a percentage off some significant business costs. For example, the mining industry is capital intensive, and its not unusual for large mining companies to have hundreds of millions of dollars of inventory and spares tied up in their warehouses. This is dead money that's depreciating – plus there's the risk of inadvertently maintaining spares for equipment that's no longer being used.
   Introducing systems with better reporting for inventory and procurement management can potentially pay for themselves if they help shave just 1-2% off these inventory stock levels. Of course, you still need to prove this will happen (e.g. through case studies) and include post-project measurement.
   Trying to justify the project through time saved on your old manual reporting processes probably won't be enough. As painful (and slow) as these processes are, they're often carried out by clerks and administrative staff who still work out cheaper than the developers, hardware and software needed to implement your new systems.
   

Ensure the Need for Change is Visible

For most business people, Business Intelligence just isn’t sexy. Telecommunications company will prefer investment in new technology that adds capability to their network, mining companies will invest in new trucks and mining equipment that helps them move and process more dirt, and retail companies prefer investment in new locations and new product lines. Irrespective of your business, it’s likely that your management team prefers investment in things they actually understand and which they see as having a direct impact on their bottom line ... not Business Intelligence and reporting. Many managers still perceive IT simply as an administrative overhead, and a cost to be minimised.

Therefore, although the Benefits Analysis described in the previous section helps, you’ll also need to ensure that the need for change is clearly visible to those on the business management team. I learned this the hard way. An organisation where I worked had a variety of data warehouse, reporting and analysis applications, which had become critical to its operations.

• Over time, various operational teams within company had used our data warehouse platform and reporting tables as a basis for key operational systems in marketing, service installation, customer support and billing. This hadn't been part of the plan. However:
• The platform had been left open for user-developed applications (via Oracle Application Express, Discoverer, Oracle Application Server, SAS and other mechanisms) with read access to our datamarts and users' own custom datasets.
• This made it extremely useful for business teams and projects to construct their "home-built" applications for reporting and operational transactions. These flew under the radar of the IT and business management teams for years – but they also delivered a variety of small systems delivering on real business needs that wouldn't otherwise have been addressed by IT.
   
• Therefore, despite the management team's perception was that we were just a "reporting" system, and we didn't matter much for maintenance and upgrades, we actually had a significant number of business operations teams reliant on us.
• We estimated that a major system outage would cost the company tens of millions of dollars in lost revenue, customer dissatisfaction and customer churn.
• But, being seen as (relatively) low priority meant major upgrades and enhancements projects were deferred. System performance and stability degraded over time until the system reached near collapse.

Those of us in the support team had a close relationship with the business teams, and we understood the impact of outages and data feed issues on those business areas. Hence, we’d often be working weekends and into the early hours of the morning applying fixes and workarounds as best we could to keep the systems running and mostly stable. With the platform dead-ended and at capacity, we’d managed to extend its life, but came to the conclusion this approach was unsustainable and ultimately self-defeating. Essentially, we were just hiding the problem – since our (successful) efforts to avoiding major systems failures meant that management just didn’t believe us about how bad things were. Our fear was that we’d soon have issues that were too big for us and impossible to patch ... and which would effectively halt critical business operations. Additionally, continual unplanned out of hours work had worn thin on the patience of our systems engineers, with the risk that the few people who actually knew how to fix things would soon move onto easier (and better paying) jobs.

To avoid our worst-case scenario, we worked out a plan with the business teams. We’d scale our support back to just the official support hours. This meant that when systems broke in the weekend or at 3am (i.e. outside of official support hours), we’d do what was necessary but we wouldn’t call people in unless it was a genuine business emergency. We also made sure that, instead of just complaining to us when things broke, the business teams reliant on the system would highlight the issues and impacts to their own managers and further up the management chain.

• The result was more business inconvenience in the short term.
  

• The approach generated more "noise" within the business, and more visible evidence that the system was sick. There was now more demonstrable proof of the negative business impact that occurred when things broke.
  

• Increased visibility, and urgency, of the need for change helped us get through the business case for the system replacement.

This replacement took another year for us to build, test, and migrate. We managed to still keep the old system functioning in the interim – right up until the migration weekend, when the old system finally (and dramatically) broke. The fact that we had the new system ready and waiting meant that we’d avoided our worst-case scenario, and were able transition things across with significantly reduced business disruption.

Politicking 101

The Change Management textbooks talk about managing resistance. Essentially, this means that you’ll need skills to survive and navigate the inevitable office politics – ensuring that your proposed project gets the attention, support, approval and funding to succeed. There will be detractors – not necessarily because they think your idea is bad, but it may simply be that they have another competing project which they’d like to see get priority. As such, you need a strategy to get to the head of the queue.

Firstly, my background is as a technology manager. This means that people trust me so far as their computer systems are concerned but they really don’t see me as particularly knowledgeable about running their business. If I say that they need to upgrade Business Intelligence Application X, the business management team will take this under advisement – but if that upgrade is going to cost $500K, they’ll carefully consider if they can defer that “expense”, and if the funds might be better spent on retail development or purchasing new capital equipment which directly boosts revenue or brings in new customers. Business managers are typically more familiar with these latter two investments, so are likely to give them more attention or priority. By contrast, the concept of Business Intelligence is often not well understood, or seen as something akin to voodoo, and therefore it’s more likely to lose out in the funding priority stakes.

The Grassroots Approach:
My strategy to get around this has been by developing close relationships with my peers in the business operations teams. These are typically the users and the business managers who rely on my systems (i.e. the people who scream at me when things go wrong), or the operations guys who’s working lives suffer due to lack of useful/accurate information or endless mind-numbing manual processes due to no existing automated system being in place. I engage with these teams to learn about their business, their priorities, and their problems. Since my role is as a technical manager (i.e. supporting the business), I ask them what they need and what can be done to help.

• We focus on defining the technical systems that need to be in place to deliver the right business solution for them. I know that the first priority is the success of the business, and that my job is as part of a team delivering the right tools to help ensure this success.
  

• It's also about defining common goals, and building trust.
  

• This trust, common goals, and an understanding of what I can do for them can help bring the operations guys around to seeing why the change is a good idea, and why its going to help them.
  

• I then remind the operations guys that, in order for the change to be delivered, they'll need to tell their own managers, and suggest the urgency in getting things done.

This means that the business management team get a consistent message from multiple angles. And, more often than not, the message coming up through the operations teams carries significantly more weight than my own recommendation.

Involving business operations in defining the need for change helps in another respect. It builds a sense of joint ownership, which helps when getting the business to commit to time and resources for requirements specification, testing, training, and deployment.

The Visionary Approach:
Another approach is getting support from respected champion at the upper levels of your organisation. This should be someone with organisational clout (i.e. the ability to help mandate the change) and who, ideally, has the charisma or professional standing to sell the change vision to the general populace. Having a respected Business Executive saying what’s needed ensures that people listen, take note, and take action.

When going for this option, everything depends on the credibility of your champion. Get the right person. A less credible champion can result in your being perceived as snake oil project.

Building Alliances:
Alliances are important to get the business operations and management aboard. These relationships help you gain valuable insights into what’s needed to properly plan and monitor the change. They also bring in talented people with ideas and experience to get things done – and who’ll suggest refinements or take care of issues than you’d never even considered. However, this is really only possible if you’ve created that common vision, with a sense of engagement and shared ownership for the change implementation. You’ll also need to have earned the trust of those involved – which means (1) be realistic, (2) listen, (3) manage expectations, and (4) deliver on your promises.

Dealing with Resistance:
Even if you do all the above, you’ll still run into people (at all levels of the organisation) who either don’t agree with what you’re doing, or who simply aren’t going to make the transition easy. This creates roadblocks and other challenges for you to overcome. There are various reasons why people might oppose the change you’re suggesting:

1. The risk of change is seen as greater than the risk of standing still.
2. People feel connected to other people who are identified with the old way. This can include peer pressure not to change, and opposition to the change on the basis that it's seen as externally driven (AKA: Not invented here syndrome).
3. People have no role models for the new way, or fear they lack the competence to change.
4. People feel overloaded and overwhelmed with what they're doing right now. The additional work, re-education, and uncertainty associated with the change is simply too much to deal with.
5. People want to be sure the new ideas are sound.
6. People fear hidden agendas among those driving the change.
7. People fear a loss of status, confidence or quality of life.
8. People genuinely believe that the proposed change is a bad idea.

Understanding these motivations can help you respond.

Open communications and education about your project is one of the best ways to reduce resistance. You can reduce people’s fears by giving them a clear picture of your plans and how you propose to deal with key issues.

• Be honest about the challenges, but also show that you've got good ideas, the right people, and the willingness to tackle any tough issues.

• Show that you have support and monitoring mechanisms in place to help people through the transition. This helps alleviate fears and lets people know that they won't be left to deal with issues alone.

• Show that you're prepared to listen to criticisms, concerns and take on good suggestions. Listening shows respect, and sometimes people just want to know they've been heard.

You probably won’t make everyone happy - but openness and responding to issues in a professional manner will build respect, trust, and maybe even some grudging acceptance. In other cases, these actions won’t be enough – either because there are groups that disagree with the change, or there’s another drama being played out for political influence.

In his book, 10 Steps to Successful Change Management, George Vukotich lists the following strategies for dealing with resistance:

Strategies for Dealing with Resistance

Approach	Potential Advantage	Potential Disadvantage
Ignore	Not giving attention to the issue may make it go away.	The issue may become larger and more difficult to overcome if not addressed immediately.
Inform	Providing information and educating individuals on what is happening may eliminate their resistance and inspire their buy-in.	It may give the resisting group more information to strengthen its point of resistance.
Dialogue	Direct conversation with individuals and groups that are resisting change can allow for an exchange on the issues and how to possibly resolve them.	Dialogue acknowledges that an opposing group exists whose issues are enough of a concern to be addressed. This could lead to the resisting group gaining more power.
Confront	Direct confrontation can address issues openly and show that the resisting individual or group has no substance behind its resistance.	If the resisting individual or group gets the attention of the general population, it may strengthen and reinforce its claim that there is an issue.
Discredit	Addressing the source of the resistance rather than the issue can discredit the individual or group. Depending on the past record and credibility of the individual or group, this may be an approach worth taking.	Attempting to discredit an individual or group may bring sympathy from others in the organisation. It may also be seen as a less than ethical attempt by the change team to thwart resistance.

These options are good to know and can assist your planning – but realise that your opposition might also choose to adopt these same approaches against you.

Understanding Workplace Politics
Workplace politics is something that I was previously blind to. I really couldn’t personally understand why people would do things which (in my view) made no logical sense and damaged the longer-term welfare of the organisation we worked for. Maybe I had rose-tinted glasses – like many other geeks, I grew up with Star Trek:TNG and thinking that altruistic ideals and working to the common good were the norm. Experience taught me that other factors are often at work, and that survival sometimes depends on tuning your political radar – watching and carefully listening. I’m not that great at it, but I’m learning.

The problem with office politics is that it can be hard to read. I’ve come out of meetings where different groups have heard the opposite message based on the same comments. I remember one pivotal meeting several years ago where:

• Our sponsor walked out feeling elated believing he'd finally gotten Divisional Finance Manager X on board to support our program.

• By contrast, the local operations guys (and more politically astute members of our project team) had just heard that Finance Manager subtly telling his staff that their Divisional Manager thought our project was a bad idea, and that they shouldn't risk his displeasure by providing any serious resources to assist us.

This foreshadowed a particularly difficult period for the project, with a series of roadblocks and a political struggle behind the scenes. Although our adversary had voiced his “support”, he was doing his best to set us up for failure. Our failure would have been a political win for him, illustrating that the ideas he opposed wouldn’t work - enabling him to take control of our project resources, and gain promotion. This is a situation that’s difficult to confront directly – but advanced warning will help you see what’s coming, so you can strengthen alliances and have a better chance of overcoming whatever gets thrown at you. The trick is learning to listen for hidden messages, and surveying other team members or meeting participants to understand their interpretations. Beware of hearing only what you want to hear.

Developing a Communications Strategy

The Communications Strategy is another element critical to change success. Your change needs a purpose to get people to commit. It also needs goals, clarifying activities and responsibilities, giving your organisation something to set their sights on. Communicating clear (and correctly targeted) messages is the best way to make things happen.

Consider your key messages: What are they?
As a starting point, try answering the following questions:

• What is the change, and what's your future vision?
• What's driving the change?
• What impact will this change have? Specifically, who will be impacted and how?
• Are there new opportunities delivered by this change?
• What's the impact of NOT changing?
• How will people be supported through the change?
• How will people be kept informed, and who can they ask if there are questions?
• Who's responsible for managing the change?
• What's your project timeframe?

Pay attention to your audience and tailor the delivery accordingly. Put yourself in their shoes and consider their “what’s in it for me” viewpoint.

Identify and understand your audience. Your Communications Strategy should identify stakeholders and key influencers. These are specific individuals or groups that you should be concentrating on to (a) inform them about the project, and (b) get them on board or supportive. These stakeholders may be instrumental for your project gaining access to resources, approvals, running key activities, and building wider public support.

Of course, not all your stakeholders will be sympathetic or easily swayed. Some may be caught up with other higher priority activities, such as managing operations. Others may be (silently or overtly) hostile if they perceive that your project is detrimental to their own influence or aspirations. For this reason, its a good idea to draw up a Stakeholder Map listing all your stakeholders, categorising them by their role, and their perceived level of project support: i.e. Supporters, Detractors, and Undecided.

Stakeholder Matrix

Stakeholder	Role Responsibility	Background
Customers	Define needs.	Need input from customers to determine what to produce: product, service, output of change initiative.
Organisation members	Identify capabilities and make changes.	Conduct day-to-day operations. Can provide input on what works and what does not. Will end up implementing changes decided on.
Sponsors	Provide resources.	Have goals to change. Provide resources to get things done.
Management	Control resources	Need management to coordinate activities and initiatives between the functions working to make the proposed changes.
Change Team	Determine what needs to be done and how	Need to work with all stakeholders to get things done. Coordinate activities and manage relationships. Responsible for making overall change effort successful..

When drawing up your stakeholder list, be sure not to forget about those who are external to your organisation such as Customers and Partners (e.g. IT support partners and vendors)

This list gives you a starting point for planning your communications - enabling you to define your target audience, and consider strategies for bringing them over to your side (i.e. what would it take to win over your detractors or, at least neutralise them?). You’ll find that different stakeholders respond to different approaches. For instance, some may be happy with email communications and project status updates, whereas others will need a more personal touch to get them on board, with their continued support then being maintained through regularly scheduled phone calls and meetings.

In addition to the list, I’ve also created linked communications logs and feedback notes so that I can recall comments, concerns, and issues notes by those stakeholders in our meetings and conversations. This has been useful helping me remember important details - and ensuring that questions asked have been addressed in subsequent communications or project planning.

Understanding environment and culture. Several of the projects that I’ve been involved with have been global. For these, its been important to recognise and take account of different cultural values. Different cultures (or simply different offices) may respond in different ways. For example, on a global project involving South American countries we found that managers were likely to be helpful and supportive (albeit not necessarily vocal) if they knew their own managers were behind it. By contrast, our dealings with the French-speaking regions of Canada were different. Even with the managers behind the project, their staff often wanted more information and more detail explaining exactly how the transition would take place. They were also more critical about the quality and nuances of our newsletter and documentation translations into French - much more so than the South Americans had been with our Spanish language translations (our guess was that maybe the South Americans were more use to dealing with the variations between Argentinian, Chilean, Peruvian and Castilian Spanish. I even got away with running our face-to-face presentations there in my dodgy Portunhol). Of course, generalisations don’t always hold true. For example, you’ll find some South Americans who are just as interested in the practical detail of a project as French Canadians ... but knowing the cultures that you’re deploying into will help you tailor your message so that it better resonates with the majority of stakeholders for that region/office.

If you have offices with different cultures (even within the same country) its useful to have representatives of those offices/cultures within your project team. They can give you a heads-up of what will/won’t work, along with other valuable inside information. It’s also handy to have these locals provide the “face” of your project in that location, as they’ll generally be someone who’s well known and respected locally ... plus it helps get around the perception of being an external project.

Listening is an important (but often overlooked) component of any Communications Strategy. Get to know your audience and establish relationships. Go out and talk with people, invite them for coffee or morning tea, run meetings, forums and website/email submissions. Gather feedback, and build an understanding of your audience’s concerns. This builds familiarity, trust, understanding … and it helps ensure your audience’s concerns are addressed effectively in your communications and project plans.

Consider how to make your message interesting. Maybe you’re lucky enough to be working on a dynamic and inspiring project that everyone wants to be part of. Sadly, these are very rare. Most work projects and projects just don’t capture people’s imaginations.

• Most people don't care if you're going to implement OBIEE on XYZ server, or some wonderful cloud-based technology from the latest and hottest new BI vendor. Truth is that (outside of IT) the technology just isn't sexy or well understood.

• Maybe your project is going to result in cost savings. This is great … but most people aren't accountants.

You may need to look for other areas, not directly related to the change topic, but which are of interest to the population. Maybe your project involves or impacts a well-known or respected personality within your organisation, or maybe there’s another human interest factor you can use.

Finding an “angle” helps you weasel your way into corporate newsletters, magazines and web articles. Getting attention and positive publicity (in whatever way possible) gives you a vehicle for getting your message out. Don’t rely on emailing project status updates to the wider community because most people don’t read them. If all else fails, resort to the tried and tested method of bribery through competitions (e.g. win an iPad) to help raise your profile and build interest in what you’re doing. If people have heard of your project, and know what you’re doing, then they can cater for the change in their own future work planning. Drumming up enthusiasm also helps with your deployment and training activities downstream.

Consider communications formats and frequency. Individuals in your organisation will vary in their level of “need to know”. But even if it’s at a minimum, most people still like to be informed. As you build your communication strategy, keep in mind not only what you can share, but how you can best share it. It must be ongoing; even a weekly report to state that not much has changed is better than no report at all.

A different message format and frequency is usually required for different stakeholder types. For example:

• Those closely involved in the project will generally want weekly updates containing detail about specific activities in progress or planned.

• The Senior Management team or Steering Committee generally meets monthly, and require a concise update immediately prior that meeting. This update omits the activity detail. Instead, it highlights the "big picture" by tracking schedule and spend against plan, and showing any key issues or decisions to be made.

• A monthly update might also suit your community of users and interested business teams - since sending updates too frequently risks your messages being perceived as spam. However, there may be points where update frequency needs to be increased for target groups - such communications associated with deployment and training.

When considering communications formats, its also advantageous to have a variety of channels since different people respond in different ways. Your plan might include face-to-face meetings with key stakeholders, scheduled site visits and presentations, regular meetings and phone catch ups (e.g. with Project Steering Committee, Business/Process Owners and Stakeholders), plus email, social media sites, and newsletters.

Consider your approach for communicating bad news. The biggest irony on projects is that it takes a lot of effort to get your message out there - but bad news gets spread far and wide with no effort at all.

The reality of project work is that unexpected things happen and schedules sometimes slip. This happens despite everyone’s best efforts because we can’t foresee or control all factors. Key resources are called away, business emergencies arise taking precedence over your project, server shipments don’t arrive when they should, or your analysts uncover higher than expected business logic complexity which will take longer to resolve. Although you don’t know specifically what will happen, there will be issues of one sort or another - and you’ll be judged on how you handle them.

• You want to be honest with people, informing them of issues when they need to know. Its best that the message comes from you, since people will find out anyway.

• The professional approach is to acknowledge that an issue has occurred - but also let people know that you're working on a resolution, a revised plan, or some way to mitigate the impact if you can.

• It's good to nominate someone that people can contact if they have concerns or need further information.

• In situations where information is scarce or unknown, try giving an ETA for your next update. When that time rolls around, issue an update statement even if nothing much has changed (and then provide an ETA for a subsequent update).

Essentially, you also want to convey the image that you’re still in control and not entirely derailed. Most people realise that issues occur. In general, they want to see evidence that all isn’t lost and that you’re effectively managing a way through the situation. Your updates are also an opportunity to remind people that, despite the current issue, most other things have gone right and that you’re still in a position to deliver ... even if a little later than originally planned. If you do things the right way then you’re more likely to get offers of help and suggestions for potential solutions, rather than having people knock you back for something you didn’t foresee.

That being said, you don’t want to air all your dirty laundry in public. There will be project issues and risks which have you nervous - but which aren’t (yet) worth broadcasting to the wider community. You can keep people advised of current issues and risks by maintaining a public version of your project issue and risk register. This is useful to give stakeholders a heads-up of key dependencies without necessarily drawing a high degree of attention to them. This has the advantage of openness - plus, if things go wrong, you can justifiably say that nothing’s been hidden. The issues and risks noted in this register don’t need to highly specific ... or you’ll spend forever updating them. Just mention each one at a suitably high-level, along with an “owner” and a high-level description of the plan to manage or mitigate. Additionally, because its a public document, you should ensure that its edited for public consumption. Therefore, if one of the risks is that Manager X isn’t on board or is a source of particular difficulty, generalise the description a little so that Manager X isn’t specifically named and won’t get upset in the event they’re reading your register.

Feedback and evaluation. Getting and using feedback (and evaluation) should be a priority. This should be collected both during and post-project. These help you track perceptions, communications, and effectiveness through the project - and to verify whether the project actually delivered the benefits that it promised. Frequent feedback can help you refine the current project, and apply lessons learned to improve future projects. Respond to this feedback, both good and bad. Showing individuals that leadership cares what they have to say strengthens the culture within an organisation.

Remember: Crises Can Bring Opportunity

Although crises are difficult and stressful for organisations, these also bring opportunity for change. In these situations, the organisation is generally aware that the old ways of working are no longer enough, and are more open to people suggesting new approaches which might help get them through the challenges presented. In essence, a crisis can significantly lessen the resistance you’re likely to face compared to proposing the same changes during in the “good times”. Therefore, if your organisation is facing turmoil, demonstrating that your change offers the solution (or a part, thereof) is a big advantage.

Useful References:

The following books are useful references for anyone wanting further information.

10 Steps to Successful Change Management
Author(s): George Vukotich
ISBN-13: 9781562867539
Link to Amazon.com page or Read on Safari Books Online
This is my favourite Change Management book so far (I’ve read a few). I discovered this one after working on a few projects, and found that it nicely summarised some of my hard-won lessons I’d learnt plus gave a few new insights. Small, to the point, and practical.

Leading Change in Business Intelligence
Author(s): Maureen Clarry
Link to article

Tags: Change Management, Business Intelligence