Why your Change Efforts are Unsuccessful

Being able to recognise, plan and implement change is a critical success factor for almost any organisation. Organisations are subject to various forces both within and outside of their control, known as ‘internal’ and ‘external’ forces. For the most part, internal forces, can, to some extent, be planned for and “controlled”, however, often, external forces can be the largest drivers for unplanned change that the organisation needs to respond to, often quite quickly; take Brexit as an example. External forces may relate to regulatory and legislative change; increased competition in the market; the unavailability of a resources and anything else that derives from outside of the organisation.

John Kotter, a Harvard Researcher, studied more than one-hundred companies, analysing their change processes, reviewing how successful/unsuccessful their change efforts were relative to initial objectives for that change.

Synthesising all that information from successful and unsuccessful projects, he came up with the following most common errors that were detrimental to effective change delivery:

  1. Allowing too much complacency: Complacency is a virus that should be rid of immediately. There is absolutely no space for an organisation to remain stagnant, nor subject to external forces without at least a little bit of control. Therefore, it is imperative organisations remain both vigilant and responsive to their environment, both internally and externally, to ensure any change can be recognised early on, managed and delivered effectively. This is to ultimately ensure maximum value can be gained in response to ‘late-in-the-day’ or retrospective implementation.
  2. Failing to build a substantial coalition: The team are the drivers for change and need to be wholly bought in to the change, its vision, deliverables and objectives. They need to maintain the necessary mindset, skills, team spirit and drive to get the job done irrespective of circumstances. The coalition may include project team members, but may also include supporters and stakeholders that may have an interest in the project. In any event, the stronger the coalition, the stronger the likelihood of success.
  3. Underestimating the need for a clear vision: The vision is critical; if the organisation doesn’t know where it’s going, how is it going to get there? Time should be spent early on in the project, to define, understand and plan the project. Naturally, the vision plays a critical role in this definition. The largest cost to projects are change requests raised during the project delivery, so if extra time is invested at the outset, understanding the vision and how to achieve it, this will save resources further down the line.
  4. Failing to communicate the vision: No brainer, right? The problem is around individuals involved not understanding the wider impact of the change. The word, ‘Vision’, itself is not a short-term idea; vision relates to the wider objectives of the project that may impact profitability, business processes, customer service, learning and growth for the organisation and more. It’s critical for the stakeholders to understand this vision, so they can see the benefit and value to be gained from it. If the coalition doesn’t understand the vision, how can they be expected to communicate it to others, so the coalition is certainly a good place to start to ensure buy-in can be gained across the board, from all stakeholders.
  5. Permitting roadblocks against the vision: Roadblocks are unacceptable and should be completely removed from the journey as quickly as possible. Naturally, if they can’t be removed, a strategy should be in place to manage them, so to prevent any potential detrimental impact on the achievement of the change. The coalition’s key objective should be to deliver the change and therefore, the review of risks that may affect that delivery should be clearly identified, managed and preferably removed. The more aggressive a team is around this, there is an increased likelihood of successful change delivery.
  6. Not planning: Again, a no brainer; we’ve all heard it: ‘if you fail to plan; you better plan to fail!’ There’s truth in that; we’ve all been in that position where we’ve not thought something out thoroughly and regretted it once we were in the thick of it. On this basis, it’s so important to plan the change to ensure successful delivery. This may include understanding risks, milestones, people involved, what we need to produce, by when, whose support we need and more. The idea of planning is to increase the level of ‘control’ we have over a project, to ensure we’re driving it in the right direction and that we’re subject to as little roadblocks, problems and issues as possible preventing us from achieving our change objectives.
  7. Getting short-term wins: Getting those short-term wins in as quickly as possible can support in the morale, momentum and team spirit of the coalition, further increasing the drive and ambition for success. Soft-skills and emotional intelligence are of course critical, but often overlooked elements to successful change delivery and this should be managed by the guiding members of the coalition, facilitating and encouraging team morale, spirit and happiness. No recognition, sense of achievement or short-term wins can often result in burn-out, drainage and a coalition not feeling motivated. The coalition members are the drivers of the change and their attitude and motivation towards the achievement of the change is, some might argue, the most important thing.

With these errors all under control and managed, you will have drastically reduced the probability of your change efforts being unsuccessful. Change is an essential part of life and business and the quicker we can learn how to best manage the wider delivery of change, the more effective, efficient and productive the change and its delivery will be.

Good luck you change experts!

Blog Downloads

Here’s How you Identify & Manage Stakeholders

One of the most important elements to successful project delivery is, Stakeholder Management; stakeholder management is the management of all parties that have an interest or stake in a project, ranging from, the people responsible for the project; subject matter experts; key decision makers; the do-ers, to the end users.

Effective stakeholder management can either make your job really easy or really hard; the better you are at stakeholder management and managing people’s expectations, requirements, input and perceptions, the more value you will get from your dealings and interactions with your project stakeholders.

Below I highlight effective and well-established ways of identifying; analysing and managing stakeholders.

Identifying Stakeholders

If your role includes working in ambiguous project environments, with uncertainty or you are charged with delivering a project that is at its very early stages, identifying stakeholders is a high priority task. Some of the ways in which they can be identified is by first of all consulting with the individuals responsible for the sponsorship of the project, which one would assume would hold some basic or detailed knowledge around who the individuals or teams that may be affected by the project.

Although this is certainly a good starting point, it would also be value-adding to review project documentation produced to highlight the scope, benefits and value of the project, as these documents such as the ‘Project Initiation Document’ or ‘Charter’ will highlight the direction for the project, individuals/teams impacted and much more, which will give you good indication and direction on the people/teams/departments you may want to consider.

The project may be closely interlinked with other already established business processes, which may be owned by related stakeholders who would be a good source for information on interested parties.

You may want to reach out to core departments such as ‘Legal’; ‘Risk’; ‘Compliance’; ‘Customer Experience’ and other related teams if available to simply ask if they would need to have an input on the project; you may need to send them project documentation; it will typically be common knowledge however if you need to get certain teams involved.

Stakeholder Analysis

Based on the above activities, it may be that you’ve now generated a list of thirty stakeholders that need to be considered as part of your project. Sometimes stakeholder lists, depending on the size of organisation you’re working with can grow to be quite big, so it is imperative that we employ a sustainable system that (1) enables the project team to understand stakeholder input/requirements/involvement etc, as expecting the project team to remember who’s-who in their head is of course unsustainable; (2) allows us to individually mark who requires what level of updates and involvement, as they are two important items, that are independent of each other.

Interest/Influence Analysis

The first part is to understand from your list, which stakeholders wield high levels of ‘Influence’ and high levels of ‘Interest’. Lucky for us, there’s a simple matrix that’s typically employed to understand where people on your stakeholder sit as follows:

The matrix below brings to your attention four quadrants that should all be managed accordingly:


‘High Power; Low Interest’: Little level of updates/input required, if any. The people in this group are considered to be passive, but may become more actively involved depending on interest and move in appropriate quadrant.
‘High Power; High Interest’: Should be kept informed throughout, as typically decision makers or high impact influencers.
‘Low Power; Low Interest’: Need little monitoring, as stakeholders are not interested, however may benefit from the odd periodical update.
‘Low Power; High Interest’: Should be kept informed of project activity, as may be able to influence powerful stakeholders.

With this information and your better understanding on the impact of individual stakeholders, it’s important to set up a Stakeholder Register/List and classify each stakeholder based on the results from (1) your influence/interest matrix and (2) knowledge on the level of input the stakeholders will have. I’ll talk about the register further.

RACI Classification

RACI classification is system used to understand the what involvement, responsibility and/or accountability stakeholders have for project tasks/deliverables/updates etc. The RACI system is broken down as follows:

  • Responsible (for): The “do-er” who is responsible for delivering the item in question.
  • Accountable: This is the person who “owns” the project/task/activity who the buck ends with, who has responsibility for the activity/project/task at hand. This can also be stakeholders with decision-making abilities.
  • Consult (with): This is a person who will have an input on the project, which could include a Subject Matter Expert; end-user or decision maker
  • Inform: These are individuals who you are to keep informed of project/task/activity progress, who may be impacted by the project, mainly end-users or low power; high interest stakeholders.

A stakeholder can belong to more than one classification, however, be warned, this can get a little messy if you’re filtering with Excel, which we’ll talk about later. May be easier if you’re using a software package.

Nonetheless, this approach to classification will make it easy for the project team to identify individuals who need to be updated according to the stakeholder management strategy.

Stakeholder Management

Here’s where you set the tools up to effectively manage your stakeholders. There are two key elements to effective management; they include (1) a coherent and useful Stakeholder Register and (2) Stakeholder Management Strategy.

Stakeholder Register

This is the register that will list all of your stakeholders with respective RACI classification, along with any further information or insight in to that particular stakeholder. This typically works best as an Excel spreadsheet, with filtering capabilities. The spreadsheet may have the following headings for columns:

  • Name
  • Department
  • Title
  • Role on Project
  • Expectations
  • Level of Interest
  • Level of Influence
  • Involvement (Level of)
  • RACI Classification
  • Date Added
  • Sign-off Required
  • [Deliverable #1] Signed-off (if required)
  • [Deliverable #2] Signed-off (if required)
  • [Deliverable #[…]] Signed-off (if required)

You can download a template I’ve put together for you here.

Stakeholder Strategy

The stakeholder strategy will inform the project team on the level of detail of updates; frequency; who will be responsible for updates; detail of any walk-throughs to be delivered; when they will be delivered e.g. before sign-off requests; what to do if stakeholders are non-responsive, which will happen! And any other detail around the complete process of managing stakeholders.

Naturally, keeping all of this information in a centralised location and incorporating updates, deliverable releases etc in to your project calendar would be useful, as related tasks like this will ensure the correct stakeholders receive the correct information at the right time. It is also equally as important to maintain strict professional, based on a friendly, courteous and respectful approach, ultimately resulting in sustained relationships over the long-term that goes beyond the project. Remember, you may be working with the same stakeholder in the future and it is extremely important to maintain credibility, a quality reputation and good relationships for subsequent projects.

Not forgetting soft skills as part of your stakeholder management, the book, ‘How to Win Friends and Influence People‘ is certainly a must read. It drives the idea of emotional intelligence and has great techniques in how to get more value out of your relationships. Soft skills are an essential skill to a good stakeholder manager and developing these soft skills, by reading such books, or further learning, will certainly add value to your project delivery skills.

Good luck with managing your stakeholders.


The Business Analysis Process: 3. Analysing Needs

So you’ve now done your perspective analysis and have documented stakeholder perspectives in to relevant diagrams, such as the Business Activity Model (BAM). The BAM is basically the model outlining and describing the system as it is envisaged by the stakeholder, based on their CATWOE analysis.

Once you have reviewed all BAM’s, including the CCCRUTT, which are Conflicts; (In)Consistencies; (lack of)Clarity; Relevance; Uniformity; Testability and Traceability and you have come to a final conclusion on what is important to the stakeholders and what items take precedence over others, in order to meet the goals of the project, divisions and wider company’s objectives, you can finalise you BAM.

So the next step is to create what’s called the ‘Gap Analysis’, which is basically an analysis of the needs of the division, department, product etc.

Okay, right, so with the BAM in your right hand, the process for creating your gap analysis/needs analysis is as follows:

  1. Review BAM to see how each activity is supported by systems and the resources available
  2. Identify activities that may benefit from reviewing and change
  3. Priorities activities based on the following: Time, Cost, Quality, Risk – the one that has the highest ratings for all four, will be higher up on the priority list for addressing
  4. Once you have determined your activities that need addressing, you will need to model ‘as is’ business process maps; I would use swim lane process maps because they present more data.
  5. Next, create ‘to be’ process maps based on your BAM, again in swimlane format
  6. Analyse the gaps between both process maps and
  7. Document a list of potential solutions that would work towards reducing the above variables (time, cost, quality and risk).

The next step includes analysing the defined options, using a range of techniques from cost-benefit analysis, risk analysis, heptalysis investment appraisal techniques to any other tool that would allow you to effectively appraise an option.


The Business Analysis Process: 2. Considering Perspectives

You’ve now completed step 1 and you’ve now got a good understanding of the situation and are ready to progress your business analysis activities. The second activity within the business analysis process is to consider the perspectives of your stakeholders.

Here’s what you need to do:

  1. Find out who your stakeholders are. You can typically do or should have done this this by gathering details on the situation, from the first activity within the process. With this information you can then decide how to manage your stakeholders by conducting stakeholder analysis. A good way to do this is by using the power-interest matrix; the power-interest matrix will give you a framework for management.
  2. Once you have considered who your stakeholders are, it would be important to conduct the CATWOE analysis to understand what the stakeholders thoughts, feelings and values are with relation to the system/process addition/update/closure. The CATWOE analysis gives the analyst good details on the system from the users perspective; it takes in to consideration, why the stakeholder thinks the system should be implemented, what the definition of the system is, who the customer is, who plays a part within the system implementation, the owner and the environmental factors that need to be considered in which the proposed system will sit. You will conduct the CATWOE analysis with your stakeholders that you have identified as value-adding.
  3. Each perspective that you gather from a stakeholder, would be documented in a business activity model that outlines the main activities within the system, from the individual stakeholder’s perspective.
  4. Once you have gathered the above details and produced the business activity models, the next step is to determine one unified business activity model that synthesises all business activity models gathered. Now, naturally it may not be possible to create a synthesised model that incorporates every single requirement of all stakeholders. BA’s must recognise that stakeholder play a part in systems development because they have good context and understanding of user requirements; naturally people will have different opinions, however it is up to the BA to understand which activities within the documented business activity models that add most value, while meeting each stakeholders requirements. Often negotiations will need to take place, as it may not always ben feasible to deliver all requirements as outlined by the stakeholders. The way negotiation facilitation is highly personal and for that reason I won’t discuss this much.
  5. Compile all information gathered and document all of the details including the business activity models for reference, if required.

This will then take you on the next stage of analysing the needs within that one business activity model that you have now created, amalgamating most, if not all of the activities outlined in all stakeholder business activity models.

The Business Analysis Process: 3. Analysing Needs


The Business Analysis Process: 1. Investigating a Situation

One of the Analyst’s key activities will be to understand the context/situation in which a project sits, in order to gain a better understanding of what implications and impact the project will have. The analyst is responsible for gathering all requirements of the project that are (a) relevant to the project and (b) meet the deliverables of the project, which could typically be defined by any or all of the stakeholders ranging from, shareholders, employees to customers. The requirements document will then form the basis of the project.

In order to create a  requirements catalogue for the project, a couple of activities within the process need to be conducted; the first of which is:

1. Investigating a Situation

This is the stage in which you gather high level information about the problem, issue or gap that needs addressing. This data is important because it will provide a good reference point on which to build upon. The situation will contextualise the problem and the potential solution’s practical application within the business.

This can typically done through gathering details on the following:


  • Speaking with stakeholders on the issues, gaps, problems they are facing, that the project will help  to achieve
  • Consider company strategy and strategic objectives
  • Consider the Project Initiation documentation (if there is one) to gather further details on who the stakeholders are, who will be using the system, risks, costs controls, business case 
  • Consider the terms of reference (if there is one) which will provide details on Objectives, Scope, Constraints, Authority and Resources (OSCAR)
  • Stakeholder analysis


  • Understand documentation that is related to the project
  • Review process maps
  • Review non-documented processes with actors
  • Speak with relevant stakeholders


At this point it is worth considering what problems, issues, gaps etc the output is facing. You might want to refer to the following to gain a better understanding of this.

  • Quality control documentation
  • Issues Log
  • Complaints received
  • Performance management reports; KPI’s etc
  • Speaking with relevant stakeholders


Some of the techniques you might use to gather the above information are:

  • Interviews
  • Workshops
  • Activity Sampling
  • Document Analysis
  • Updating/creating draft Business Needs Log

This above gathered information can be documented under the following headings:

  • Summary of information gathered
  • Data gathered
  • Draft business needs
  • Draft world view 
  • Mind maps
  • Use case (as-is)
  • Rich picture diagrams
  • Create a draft business needs log, documenting the high level business requirements based on the stakeholders you have spoken with; this may need revising based on subsequent activities
  • Fishbone diagrams
  • Knowledge on structure, management, policy and change processes
  • Any other details that may come in handy for later stages to help support with questions, interviews, workshops analysis etc
  • The input vs output analysis would be equip you to create a draft gap analysis

With the above information you would be able to document the very high level requirements you will be able to review for the compilation of your business needs log and consider when doing further analysis; you may alternatively encapsulate gathered thoughts, comments etc in to a general “world” view. You will also have good information on the organisational structure, divisions, policies, strategy and more to have a better understanding of the process of change and management within the company when doing further analysis, which is always useful, for context.

And there you have it; you’re now ready to move on to your second activity; considering the perspectives of your stakeholders. The next stage is concerned with analysing stakeholders and their perspectives on the situation/project, to get a better understanding of their values and beliefs for the project. 

The end result of the complete business analysis process will be a clear, non-ambiguous, relevant, reasonable and testable requirements document. The document will take the company’s internal structure, management and policies in to consideration, meeting all relevant requirements and deliverables of the project and your stakeholders, hopefully getting them to buy you a drink at the end of it. Or in my case a can of Dr Pepper; I love that stuff.

The Business Analysis Process: 2. Considering Perspectives