Implementing change is difficult. Implementing change without a methodology is very difficult. This article will discuss the basics and provide a structure to guide your projects. It will have sufficient detail to be a stand-alone article, but when used in conjunction with the other content from my blog, it will definitely come alive and you will have all the models and structure you need to deliver a successful business improvement  project.

The methodology comprises seven steps. It is important to note that while they are broadly sequential in nature, it is common for two or more steps to be tackled concurrently. This is particularly true for steps 4a and 4b.

Sixfootfour methodology

Step 1: Agree project plan, scope and benefits.

This is a crucial step in successfully establishing a project. Taking the time to get it right will provide a positive return on investment through minimising scrap, rework and failure.

Typically the focus of this step is the preparation of a document describing the project. These documents are normally termed Statement of Work (SOW), Project Initiation Document (PID), or Project Memorandum. Irrespective of the name they include the same generic contents:

  • Business context
  • Project purpose
  • Scope
  • Methodology
  • Approach
  • Timeline
  • Risks and risk management
  • Constraints
  • Change management
  • Staffing
  • Roles and responsibilities

Depending on  the  author  and  company, additional headers may be included  such  as  budget,  success measures, related projects, and  a methodology for  handling  change requests. Traditionally the  project manager is  asked to  prepare the  SOW  and  the  document  is  then presented to the project sponsor and other stakeholders who review and approve it.

The biggest issue with this approach is that the focus is always on the document rather than what it represents; and it is typically always written in a hurry, often within a week. The sponsor reads the document and validates that all the information you would expect to see is there and that the timeline and budget are within bounds of acceptability and then accepts the document.

What is seldom done is for the stakeholders to formally put aside time to workshop the completed SOW to subject it to a rigorous level of due diligence. This workshop would ask questions such as:

1.   Is there a common understanding of the project purpose? Even if there is a purpose statement, does everybody interpret it the same way?

2.   Is there agreement on what success looks like?

3.   Does each stakeholder understand and accept what is expected from  them  throughout  the  course of  the  project and  more importantly, after the project?

4.   Is the risk table complete? Does it include project and business risks? Are the mitigation strategies considered practical or are they merely a cut-and-paste from the last statement of work?

5.   How will risks be managed? Merely writing them into the SOW is not managing them.

6.   Is the change management plan aligned to the risk plan?

7.   Does the resource plan make sense?

8.   Does the budget have contingency? How is it calculated?

The sponsor should allow ample time for this workshop. The desired outcome  is  confidence that  the  project is  considered and  that  the stakeholders are fully enlisted in  the  project. Not  just engaged, but enlisted. That is, they are fully and actively committed to its success.

Step 2: Establish project governance.

The due diligence workshop is the first activity in establishing active project governance. Governance is the active mitigation of risk through the proactive management of compliance and performance. Merely to be in business requires the acceptance of a degree of risk. This is no different when embarking on a business improvement project.

Good governance requires the establishment of a hierarchy of committees to manage the project. I have covered these committees in detail in other articles so I will be brief here.

The  phrase “change management” is freely used on  all projects. The reverse, “the management of change,” is not. There is an important distinction between the two concepts and it is oft-times overlooked.

Frequently committee members will attend project meetings, participate in discussions, and then mentally park the project in the back of their mind until the next meeting rolls around. They forget that their role is the active management of change and this requires a substantially higher level of involvement than merely attending a weekly project review meeting.

I suggest that change is managed through a three-tier structure.


The steering committee is a group of senior managers responsible  for ensuring the overall change program stays on strategy. A key point is that there should only be one steering committee. They are specifically responsible for steps 1 and 7.

The working committee is responsible for driving the tactical change initiatives. There may be two or more working committees depending on the size of the company and the breadth of change. The working committee is specifically responsible for step 6. By comparison, the steering committee is to ensure that the working committees output will meet and promote the company strategy.

Both committees can manage risk, budget, and change, the difference being the scope of authority.

The  project teams are responsible for the  day-to-day delivery of the project activities represented by steps 3, 4 and 5. A common mistake is treating the project committee as the working committee.

Step 3: Determine process metrics.

The purpose of step 3 is to collect and analyse primary data. Typically this step involves mapping business processes. In the methodology, this step is termed “determine process metrics.” This is an important label in the sense it does not say “business process mapping” as is frequently the case with business improvement methodologies. The  essence of this distinction is that it is equally or more important to understand the metrics behind the process than it is to understand the process itself. A methodology to calculate these metrics is covered in the article on process reengineering.

These metrics should be seen in the context of the unit of measure for the process. This step could produce a table as shown.

Path analyis table (2)

In terms of benefits realisation, this table can be used to calculate the benefits and priority of the change to be addressed in step 4a.

Step 4a: Critique and improve the process.

Once you have established the  process  flows  and  associated  metrics for the current mode of operation, you are in a position to determine improvements to the processes. The data will guide the analysis and quantify the benefits of  change.  Without  this  data,  it  is  difficult to confirm that any of the recommendations tabled will result in a substantial improvement. Different is not an improvement.

Business improvements can be achieved from changes associated with people, process or technology and any of their sub-components. The following table illustrates the primary sources of change.

Frequently improvement requires changes to more than one component.

 100 (3)

 Once you have worked out your business improvement strategies, you can quantify the benefits of change by determining the impact of the change on the same base data set from step 3. The results can be tabled as follows.

image005 (2)

Step 4b: Install refined process controls.

The problem with “businesses”  and “processes” is that they don’t  exist, or at least, they only exist in the abstract, as concepts. Fundamentally, businesses  are groups of people working together towards a common objective and processes are the habitual routines they follow to “process” the demand customers place on the company. To change a process requires changing the familiar routines people follow in their daily behaviour.

The guiding principle is “show me how you are measured and I will tell you how you behave.”

This is an important principle as it links steps 4a to 4b. In step 4a the focus is to reengineer the flow of activity through the business. In step

4b the focus is to review and reengineer the measures (KPI’s) used to manage the processes. Frequently there is no need to change the activity sequence (business process) as it is efficient. Rather change is required in the behaviours associated with the activity sequence in order to remove productivity issues such as pacing and “territory disputes.” This change can be achieved, in part or in full, through changing the way the process is measured.

Should the project objective be to specifically  review and improve the business processes, then this activity needs to be completed in conjunction with a  review of the  process measures. This  will prevent substantial investment being spent on defining new processes without concurrently establishing the means to drive the necessary behavioural changes.

Steps 5 and 6: Install and drive behavioural change.

The purpose of these steps is to operationalise the agreed changes. To install change is to change behaviour. Occasionally, changing behaviour is straightforward and happens without difficulty. Frequently this is not the case. To mitigate failure, a project requires effective change management.

The primary purpose of change management is to assist the company to  migrate from  a  project environment to  “business as usual.” My observation is that change managers often worry more about completing the standard activities of change management such as communication and training plans, than focusing on the primary purpose.

Strict management of the relationship between steps 5 and 6 is crucial for a successful project and moving to step 7. Measurement is mandatory to reach the highest levels of success at this time. There are two areas of measurement. The first is traditional operational KPI’s. These need to be aligned to the future state. This may require changing existing scorecards or even introducing new scorecards.

The  second area of  measurement should  be  aligned to  the  change program itself. The change scorecard should include metrics on skills development and staff attitudes. The intent is to measure both axes in the following matrix.


Examples are: number of people trained; number and  organisational profile of  staff communicated to;  number  and  nature  of  questions received; survey results; and awareness sessions held.

Step 7: Realise benefits.

This step is the consequence of the prior steps. Success is measured against the business objectives described in the project statement of work and the extended objectives that will have surfaced through the life of the project. 

An oft-missed aspect of change is the need to be uncompromising. As the project “gets real” and staff members are asked to change their behaviour, the sponsor will come under significant pressure to relax their position on what success looks like. A culture of “close enough is good enough” is typical at this time. The point here is to emphasize that resistance to change is frequently invisible. It manifests itself in perfectly logical and plausible arguments that are all aimed at reducing the scale of change and the benefits realised. The staff making the arguments may not even realise that they are being resistant to change.

Mitigating resistance to change requires the manager to be aware of the three stages of change:

Stage 1: Mechanical compliance

Stage 2: Conceptual compliance

Stage 3: Utilisation 

                                                                             Source: Proudfoot

Mechanical compliance is characterised by instructing staff to follow the new procedures and being intolerant of reasons as to why it can’t be done. As staff become comfortable with the new way of working and establish the new routines of working, they will start to better understand the new order and, if the project has been done well, they will start to see the benefits. They are now at the point of conceptual compliance and once they are comfortable with the benefits of the new procedure they will move to the “utilisation” phase and will own the new way of working. When this happens it can be said that the project has fully migrated to business as usual and the benefits will be realised.


Recently I spent a morning with a colleague discussing ideas for a new business. He is working on a number of excellent business models and if he can commercialise them, he should do very well.

He asked if I could assist him to “clear his head.” He was too close to the detail and the ideas and concepts were beginning to blur.

My immediate suggestions were:

1.   Draw the business.

2.   Follow the money.

We spent the next two hours on  exactly these two points. What  he initially thought  was a simple question, and one that  he already had straight in his head, proved to be quite complex. It is amazing how a person can jump large chasms in a single bound in his/her head.

Our conversation produced a new and annotated picture of the proposed business depicting how it would work and the flow of money. It was completely different to  the  picture he initially had  in  his head and it  substantially changed the  business case and  intended  architecture. Importantly it resolved a number of the mental blocks he had about the business. The blocks existed as subconsciously he knew there were issues; he just could not articulate where. Following the money is a sure way of resolving this problem.

This same difficulty constantly plays out on a large scale with my clients. As a consultant, I am frequently engaged to  prepare process models, maps and related material. The conversation generally  revolves around the relationship between people, process and technology and is often interlaced with the phrase “shared service.” 

What I battle to understand is this: why, despite engaging consultants to investigate the business, are managers so reluctant to engage with the detail? Businesses are complex, but managers just don’t seem to want to know.

To  further illustrate this point,  the next graphic is an example of a detailed process map. Call it “Process 1.” I do not expect managers to invest significant time at this level of detail. That is, managers other than the process owner.

process flow

Occasionally, an individual process map will include a reference to the next process in the sequence. More often than not, the process just ends with a box that says “post invoice” or “file letter” or “pay supplier.” That’s it. Process over.

This style of process mapping has little bearing on reality. Activity very seldom just stops in a business. Rather there is a handover to the next department or process. Everybody knows this and automatically accepts that this detail is just not included on individual process maps.

But, when that process map is placed in conjunction with other processes on the value chain, it offers limited insight. When the same process is shown inclusive of its relationships to other processes the value of the analysis goes up significantly. Consider the next two graphics.


The  first  graphic shows what processes sit where on  the  framework. The  second graphic  shows the relationships between them. The interconnecting lines represent the hand off between processes and the flow of information within the business.

The  top  row of each graphic represents the  functions and  processes that generate revenue. This row answers the question, “How do I make money?” The middle row comprises the processes that support revenue generation. These processes are not  customer facing and  exist only because revenue is flowing. The bottom row comprises the processes that must exist for the company to be in business, in other words, the true back office.

Rows 2 and 3 tend to be the areas where you spend money. In rough terms row 2 goes to gross contribution and row 3 to operating expenses.

The layout is a great way to “show me the money.” It tells you which processes result in revenue and how and where the invoice is generated. It also provides a foundation for determining which processes belong in the shared services group and the basic configuration of that group. By extension it supports the demarcation of service level agreements  and key performance indicators.

A simple critique of the graphic demonstrates that there is possibly a significant gap in the revenue flow.


Within the circle there is no output process for the third process. It is a revenue generating process but it is almost 100% independent of all other processes. This can’t be right. Equally getting to its trigger process seems somewhat convoluted.

This insight is enormously valuable, especially  if a company wants to implement or refine a shared services model.

If this reasonably simple diagram produces this type of value, why then are managers reluctant to engage in the detail? Without the detail the above issue would not be exposed. Yet it can easily be consulting suicide to put the graphic up for comment. There is a good chance you will hear, “It’s too complex, and I can’t understand it.” So you “dumb it down” to a point where it fits on a slide and uses large font.

I fully acknowledge there is a time and a place for getting into the detail and presentations should be tailored to the audience.

I  close with  the  comment  that  businesses are  complex places and managers should make the effort and take the time to understand them. At the very minimum they should understand the flow of money. Where is it generated? Where and when it is invoiced? And how is it spent? Not necessarily at the fine detail level, but most certainly at the building block level.