Managment accountability

A significant challenge for any large business improvement program is how to enlist the senior stakeholder community into the change program and keep them engaged. Senior stakeholders can be relied on to show an interest in the change program when it starts, but their interest will often fade as “business as usual” issues dominate the day-to-day operations.

Then, as the business improvement program progresses, the change team becomes mired in the detail and withdraws into their own world. They spend their time looking at data, completing risk reviews, agreeing the way forward, mapping processes, and preparing papers that will describe the desired outcome. The longer this goes on, the more introspective the change program becomes and the less the senior stakeholders are engaged by the change program.

The seasoned change agent knows that change is not sustainable without tangible support from senior stakeholders, and that getting the senior managers to change their daily routines, habits, and behaviours is very difficult. And it becomes more impossible the longer their behaviour is left unchallenged. The reason it goes unchallenged is that the change team believes that until they have worked through the detail, they don’t have anything meaningful to say, and they don’t want to waste the senior managers’ time.

The problem is that the senior managers run the company, not the change program. It is important that they stay engaged. But if the change agent is going to engage the senior managers, then they need to be able to frame the conversation and have an agenda.

When it comes to change, there is no better agenda than talking to managers about what they are or aren’t accountable for. If you can’t get a manager to agree on their own accountability, then you can be sure that the outcomes of the business improvement program will be less than optimal.

There are many models that support a conversation on accountability. The most common is the R.A.C.I. (RACI) model. It is a simple model, but the practical application of this model is beset with problems, the biggest of which is the question of what the acronym actually stands for.

The generally accepted definition is that it refers to: Responsible, Accountable, Contributor (or Consulted), and Informed.

This definition is misleading. The “A” cannot stand for Accountable as all four dimensions have accountability. A manager is accountable for being informed or contributing. It is not the job of the change agent or process performer to inform management. It’s management’s job to ensure that they are informed. The business holds them accountable to be informed. How can you manage if you are uninformed?

In the same sense, managers are accountable for approving a process outcome. This means they need to know what the outcome should be, what control points they should have considered, and what delegations of authority might apply. If the manager plays an active role in the process, then they are accountable for being responsible for doing their part of the process properly.

In terms of a business improvement program, when the change team approaches a manager designated as a Contributor for comment, that manager is accountable for making time and providing a well-thought-out contribution to the discussion.

Apart from the confusion arising from the fact that all four variables have accountability, there is a second misunderstanding about the RACI model, namely that it only applies within a business process.

Consider the graphic below. When RACI is applied within a process then it can be argued that the Supervisor approves the process outcomes, Role 1 is responsible for Steps 1 and 2, Role 2 contributes to Step 1 and Role 3 is informed by Role 2.

Slide-3

While it is acceptable to use the RACI model within a business process, it is equally acceptable to apply it to, or on, a business process. The difference between the two applications is significant and it makes a material difference in how each term is defined.

When applied to a process, RACI is used to define the architectural elements of the process rather than the transactional accountability within a process.

Consider the following scenario.

The managing director walks out of his office after losing a major tender. He turns to the sales director and asks, “Who designed the tender process? Who in their right mind thought that process would be suitable for us to win a tender?”

What he has not asked is, “Who filled in the tender response form? Who participated in the tender process?” Doing that would be to question the transactional aspects of the process. Rather his focus is on determining who the architect of the process was. Who designed the process, who approved it, and who can he hold accountable to ensure the process weakness is resolved and that the next tender is more successful?

Applying RACI on the process changes the definition of the terms as follows.

Responsible – accountable for designing the process.

Contribute – accountable for working with the Responsible person to design a process that was fit for purpose.

Informed – accountable for understanding how the new process works and how it impacts the informed manager’s work environment.

Approve – accountable for signing off that the process is fit for purpose. That when it is followed, it will deliver optimal outcomes. This role owns that process.

In essence, the managing director is asking his team, “To what extent did you apply yourselves as senior managers to ensuring the process your staff were following, was fit for purpose?”

Using these definitions of RACI means that the supervisor (who was previously the Approver) now may become an informed party only and the manager’s manager will approve the process.

Slide-4

The supervisor’s manager is more likely to be Responsible as the architect of the process. While the manager is Responsible for designing the process, it does not mean that they will necessarily do the work. Possibly they will delegate it back to the supervisor, but in this case, delegating the task does not equal delegating the accountability.

The two scenarios, in the process versus on the process, illustrate that depending on how RACI is applied, it will deliver very different levels of management accountability and they could be at opposite ends of the management spectrum. Supervisor vs. manager’s manager. Using the single term “Approve” for both situations is going to confuse the organisation and it raises the question: does the organisation want its processes approved by supervisors? It is reasonable to expect that this would not be the case.

The complexity between the two applications of RACI is increased when you consider that it is common for process flows to be modelled against roles and not positions. One position can play many roles. So when RACI is used in a process, it does not necessarily give accountability to a specific position. Rather, any position that happens be performing that role in that instance of the process becomes accountable. The burden this places on the organisation is significant. Just consider the training needs. Then there is the problem of process flows with process steps straddling the line of responsibility or swim lanes and the issue of mixing roles and positions in process flows. These issues make defining accountability in the process level very confusing.

When RACI is applied on the process, it is applied to positions not roles thereby mitigating the above issue.

The difficulty of working with RACI is exponentially increased when applied to a matrix management organisation. Simplistically, matrix organisations can be broken down into service functions such as Human Resources, IT, Quality, Safety, Health, and Environment, Legal, and Finance, and the do work functions such as Operations, Work Winning, Logistics, Maintenance and Repair, and Customer Service. The service function will define the processes for the do work functions to use. A good example is the Quality, Safety, Health, and Environment function.

Slide-5

The processes defined by the Quality, Safety, Health, and Environment function are used on the shop floor by the do work teams. This means that the quality function is accountable for defining and approving quality management processes that will be used by a completely different function. The RACI model just doesn’t cater for this level of sophistication. When you try and use it across the multiple silos of a matrix organisation it quickly becomes apparent that it just does not have enough variables to account for the organisational complexity and what is required is a different model for defining management accountability.

The best alternate model I have seen is the Linear Responsibility Matrix (LRM) methodology by Anthony Walker.

It is not my intention to repeat Anthony Walker’s methodology here. What follows is my own interpretation of his methodology. I claim no rights to the methodology and I acknowledge Mr. Walker’s ownership of the underlying intellectual property.

My interpretation of the LRM recognises ten functions with accountability. The original methodology had eleven.

  • Responsible
    • Accountable for defining the process flow and associated artefacts.
  1. Approve
    • Accountable for signing off the process flow and associated artefacts.
  1. Contribute
    • Accountable for working with the Responsible person and helping design the process.
  1. Informed
    • Accountable for being informed on how the process works and the requirements of any artefacts associated with the process.
  1. General Oversight
    • Accountable for ensuring the process architecture is appropriate and fit for purpose.
  1. Direct Oversight
    • Accountable for guiding the Responsible person.
  1. Recommendation
    • Accountable for reviewing the process and ensuring it is fit for purpose. Once satisfied, this role endorses the process for final approval by the approver.
  1. Monitor
    • Accountable for ensuring each instance of the process works as designed in the day-to-day environment.
  1. Maintenance
    • Accountable for ensuring the process is being used as designed. It is quality control.
  1. Boundary
    • Accountable for addressing areas of overlap in scope.

The word “process” in these definitions refers to the process appropriate to the level of management. At the senior level, it is the various value chains: Budget to Report, Contract to Cash, Procure to Pay, Hire to Retire etc. At the lower levels, the process is the transactional flow of a specific sequence of work. For senior management, the word “process” in the definitions can be substituted with specific items such as Policy or broader concepts such as the Governance Model for the organisation or a function.

This methodology is particularly powerful when working with matrix management organisations and the single biggest point to embrace is that the LRM is always on the process. It is never in the process.

In a matrix model, when it comes to defining the operating model for the service functions, the ten accountabilities can be loosely split between the service functions and the do work functions. On a per instance basis, this allocation could change.

Slide-6

What this means is that the change program cannot work with each function in isolation of the other functions and importantly, the other functions do not have leeway to say, “Not my job.” Rather the change agent should be establishing cross-functional teams based on the above separation of accountability to drive the change program and ensure the organisation gets a result that is sustainable and agreed.

Having ten functions with accountability gives the change agent a much wider scope for discussing the accountability of each and why senior management have no option but to become further involved in the business improvement program. You will note the first four functions with accountability largely correspond to RACI when RACI is applied on the process.

A senior manager would readily admit that when it comes to their function, the buck stops with them, but when pushed, it is often the case that these managers cannot easily describe what they are actually accountable for.

The ambiguity is because the names of functional areas (e.g. Quality, Safety, Health, and Environment), do not include verbs. Without a verb, defining the deliverable becomes very difficult. And if you can’t describe the verb at the parent level, then defining the verb for the children and grandchildren levels becomes very difficult.

“Well, if you do that, then what do I do?”

I am not suggesting that the names of functional areas are rewritten to include verbs. Rather, for the purpose of defining management accountability, the verb is inferred. By agreeing the verb, you can agree the deliverable, and only then can you agree the management accountabilities.

For the function Quality, Safety, Health, and Environment consider the difference between the following two verb/deliverable combinations:

Slide-8

It is accepted that the verb/deliverable combinations are not necessarily mutually exclusive and there is natural overlap between them. The verb sets up the focus for the function and will directly impact the way the function sees its role in the organisation and the culture that is established within the function.

The table can now be extended to bring in management accountability. Note how the accountability changes depending on the deliverable being sought.

Slide-9

When the verb is to monitor the Quality, Safety, Health, and Environment function, then the Quality, Safety, Health, and Environment manager cannot approve the deliverable as this would be a conflict of interest. In this case, using the reporting lines in the organisation chart above, only the CEO can approve that the Quality, Safety, Health, and Environment governance model is working effectively. At the senior levels, the do work manager will be watching proceedings to ensure the Quality, Safety, Health, and Environment governance model does not become an unnecessarily large administrative burden on the day-to-day operations of the business.

But if the verb was to deliver Quality, Safety, Health, and Environment, then the Quality, Safety, Health, and Environment manager could approve that the function was working as designed. This is because the deliverable has an operational focus and the senior Quality, Safety, Health, and Environment manager is expected to be the approver. It’s part of the description of the position. The responsibility for delivering Quality, Safety, Health, and Environment on a day-to-day basis moves to the operations function as this is where the work actually happens.

If the verb was transform, then it is unlikely that the CEO would have the authority to approve the new operating model. This is where the LRM methodology really comes alive, as it brings in positions that sit outside the obvious reporting lines and the function accountability table needs to extend to allow for the additional accountabilities.

Slide-10

For transform, the Board is now accountable for approving the new operating model for Quality, Safety, Health, and Environment. The CEO can only recommend the new model up for approval, but they will not do so unless they know the senior team has been consulted on the design of the new model.

For deliver, the quality manager is accountable for maintaining the integrity of the Quality processes within the organisation. The senior do work manager is responsible for ensuring the do work function are using the Quality, Safety, Health, and Environment processes across the entire organisation and, in this example, the country manager is accountable for monitoring that the Quality, Safety, Health, and Environment processes are being followed on a daily basis.

For monitor, the CEO is unlikely to approve the governance model unless it is recommended to him for approval by the legal counsel and the country manager. Recommending it for approval implies that they have reviewed it in detail and consider it fit for purpose.

The LRM model is also useful for defining accountabilities within a function.

The following uses the Quality, Safety, Health, and Environment structure referred to above. It has four levels.

Slide-7

The table illustrates how the accountability for Approve and Responsible changes as you move to the lower levels in the organisation.

Slide-11

Each organisational level requires a verb and a deliverable and there should be a natural relationship of deliverables between the organisational levels. It is implied that the accountability of other relevant positions will be included as required.

It is important that Responsible is not delegated below manager level and accountability for Approval is held at the level of manager’s manager or higher.

Organisational level 4 is typically the transactional level in an organisation. This is the level where the business process is operationalised. This requires the supervisor to monitor the process to ensure it is working as defined and correct it as required when the process deviates from design. Maintenance by comparison would be carried out by a representative of the function that designed the process For example, Quality or Safety.

It is not necessary to recognise all ten accountabilities for each function or process as it will make the model overly complex and confusing. Rather, it is easier to work with the implied hierarchy between the accountabilities and use the dominant accountability. For example, there is no need to state that a manager who is recommending a process for approval is also informed. It stands to reason that they would not recommend something they were not informed on. The same applies for consulted and recommend. It is highly unlikely a manager would be asked to recommend a model they had not been consulted on, in the definition phase.

When defining which positions require to be informed, the “less is more” principle is relevant. Sure, everybody needs to know about changes, but these changes will be rolled out through the organisation structure. All that is required is to define which managers must be formally informed of the changes.

What these management accountability models achieve is to cause the business to change itself.

Without this level of accountability, the responsibility of the success of the change program will, in practice, fall back to the change team, allowing management to point fingers and attribute blame for failure. There is no doubt that change will take longer to achieve when management are correctly held to account, but equally, there is no doubt that the benefits will be sustainable and owned by management when they are forced to be actively involved throughout the change journey.

STAKEHOLDER IMPACT ANALYSIS

Consultants and other business advisors are frequently brought in by senior management to establish and lead a change program within the business. This brings to mind the old joke: How many consultants does it take to change a light bulb? Just one, but the light bulb has to want to change. An old joke for sure, but it reinforces the inescapable truth that a consultant cannot change a business. Only the business can change the business. If the business does not want to change, then there is nothing the consultant can do.

But who is the business? The business is a collection of people working together to achieve a common objective. For change to be successful, these same people need to band together to build a momentum for change that cannot be stopped. The organisation must push over the tipping point to make change inevitable.

The problem is that, in large organisations, whilst most staff support the overall business objectives, they don’t necessarily agree on the best way to achieve them. A characteristic of large organisations is the proliferation of subcultures throughout the business.  These subcultures are normally aligned to the different stakeholder communities or silos that make up the business. Depending on the specifics of each subculture, change will be met with a variety of mindsets ranging from “I have been here 15 years and seen it all before; it didn’t work then and it won’t work now” and “If it ain’t broke, don’t fix it,” to “We welcome the opportunity to change.”

For change to be successful, these individual communities need to be recognised, understood, and engaged as stakeholders in the change program. The trick is identifying each different stakeholder community and determining how change will individually and collectively impact each community and how each will respond to the proposed changes.

This paper will not discuss in detail how to identify individual stakeholder groups. Rather, it will examine how to evaluate the impact of a change program on stakeholder groups and how these same groups can impact the change program.

It is common practice to start an impact analysis with a stakeholder identification exercise, the rationale being that once you know who the stakeholders are, you can evaluate the impact change will have on them. My experience is that an effective stakeholder impact analysis must start with an analysis of the impact of change on the business. After all, how can you be confident that you have identified the complete and correct set of stakeholders, never mind the impact of change on these stakeholders, until you have fully understood the impact change will have on the business as a whole

I have found that while most change practitioners agree with the above, they also frequently attempt to complete both analyses at the same time. Inevitably, this will deliver a skewed and incomplete result. It is important to complete the studies sequentially.

To understand the business impact, it is easiest to use the traditional variables of people, process, and technology, with the addition of foundation items such as culture, strategy, policy, and rules. Collectively, these variables will provide the necessary width to complete a suitably comprehensive business impact analysis.

The objective of the study is to agree what will be different in the business as a result of the change. The following framework can assist.

Business impact table

The table is a summary of the impact of change on the business.

You will note that the framework breaks the headers of people, process, technology into their component parts. It is the component parts that are analysed, not the header itself.

A key part of any change program is effective communication in order to  ensure senior managers understand the need for change.  To be successful, it is vital that a senior stakeholder is able to quickly assimilate and understand the issues. It is not uncommon for an overly detailed analysis to be put in the “too hard basket,” causing the findings to be partially ignored or even lost entirely.

If the table is detailed, it can be supplemented with Harvey Balls to provide a quick summary of the extent of the change.

Dark (red) indicates a high degree of change.

Business impact table withHB

Using the Harvey Balls as a guide, it can be seen that the proposed changes will have a moderate impact on the business processes and a high impact on people, management practice, structure, and culture. There will be limited impact on strategy, policy, and business rules.

This summary is highly significant, as the common practice in business improvement programs is to map the business processes. In this case, understanding the business processes may be important, but it is not where the real game is. Rather, a strong focus on people and culture is more likely to deliver the desired business benefits. The detail in each cell describes the nature of the change.

Depending on its size, a change program will comprise multiple projects or work streams, each focusing on a different aspect of change such as Quality, HR, IT, or operational improvements.

The framework can be used for each project within the program. As before, Harvey Balls can be used to indicate the magnitude of the change within each project.

consolidated business impact table withHB

This type of analysis will provide a manager with a ready snapshot of the impact of each project’s specific changes on the business. While this view is valuable, it is incomplete.

What is required is a consolidated picture of change across all projects.

Project summary unclassified

The table provides a consolidated and immediate insight into how the projects will individually and collectively impact the business. You will note that the subcategories of “people” have been removed. This is to support the principle of “easy to understand.” Senior stakeholders will want to know how much change will impact their people. The fine detail is unlikely to be important at this time.

In the example, project 3 is anticipated to have the biggest impact across the entire business, and management practice, access to information, and culture will be most heavily impacted across all projects.

Project summary

This table now becomes the basis for determining the real stakeholder groups. Given that process flows are not a top three priority, it is unlikely that the process operators are going to be a primary stakeholder. Conversely, their managers are identified as a primary stakeholder. This is reinforced when you consider management’s impact on culture and access to information.

With this insight, that change program can set its priorities and tailor the messaging appropriately.

To understand how the change program will impact a specific stakeholder group requires the application of a consistent numerical scale. Such a scale could be:

  1. No impact
  2. Low impact
  3. Moderate impact
  4. High impact
  5. Maximum impact

Each stakeholder group is then evaluated according to this scale and the results are tabulated as follows. The stakeholders are listed down the page. The types of change the stakeholders will go through are listed across the top of the table. Once again the variables of people, process, and Technology are used to guide the analysis. It is unlikely that the detail will be a mirror of the business impact table, but is expected that the business impact table will inform the variables used in this study.

Stakeholder summary table

The table is completed once the totals column is complete. To really make sense of the table, graph it and rank it from highest impact to lowest.  It is clear that the first six stakeholder groups will be most impacted by the program and the last four stakeholder groups will be least impacted.

The primary difference between the stakeholders on the left hand side of the graph and those on the right is that those on the left will typically be operational staff and those on the right will be senior managers and executives. The seniority of these managers means that they are unlikely to be substantially impacted by the technical aspects of the change program.

stakeholder graph with circles

This type of stakeholder analysis is common practice and in the normal course of events, the change program would target the top six with specific interventions and deal with the bottom four with general interventions. The stakeholders in between would gradually move from specific to general.

By general activity, I refer to interventions aimed at groups, rather than individuals. It would be brilliant if a company had the time and resources to work with each person in the company individually. This luxury is seldom, if ever, open to large companies and so change is addressed with general activities.

My critique is that this is a one-way study, in that it only evaluates how the change program impacts the stakeholders.

In my opinion, a far more critical analysis is an evaluation of how the same set of stakeholders could impact the success of the change program through their actions, be they positive or negative, or simply through inaction.

The point of this second study is to determine which individual stakeholder groups could substantially impact the success of the project if they wanted to. Consider: if the executive team chose to, they could terminate a specific project or even the entire program, a particularly substantial impact. If the service desk became disenchanted, they could reduce the quality of the customer service they provide. This would dilute all the good work done on the rest of the project. It would not stop the project, but it would have a detrimental effect on customer satisfaction.

To complete this study, the scoring can again be on a simple low to high scale, as the evaluation is more subjective than objective.

  1. No impact
  2. Low impact
  3. Medium impact
  4. High impact

 

When completing the analysis to determine how stakeholders could impact the change program, it is important to use the same stakeholders that were evaluated in the first study.

Stakeholder impact on project

As before, the scores are graphed. It is important that the stakeholder sequence is kept constant as per the first graph.

reverse stakeholder graph

It can be seen that, unlike the initial study that produced a smooth graph, this study produces a saw-toothed result, indicating that there are stakeholders across the full spectrum that can significantly impact the project.

Of particular interest are the stakeholders on the right. In the first graph these stakeholders were scored very low as they were deemed to be senior or executive managers and therefore largely unaffected by the technical aspects of change. But in this second graph, they have a very high score as they have the positon and power to substantially impact the project.

The full strength of the analysis is evident when the two graphs are compared.

stakeholder graph comparison

As expected, there is a strong two-way impact across the first four stakeholder groups. These are the primary stakeholders impacted by the project and, if the change program does not fully enlist them in the change program, then it will be almost impossible to achieve sustainable business improvements.

Equally, when looking only at the first graph, it is unlikely that stakeholder groups 8 and 9 would have been considered particularly important stakeholder groups. But when combined with the second graph, they become high priority stakeholders.

The first graph is an analysis of the technical aspects of the change program. It evaluates which stakeholders will be impacted by the change and the data behind the graph will tell you why they are impacted. In many respects, change will happen to these stakeholders whether they want it or not. This does not diminish the responsibility of the change manager to minimize their resistance to change as much as possible.

By comparison, the second graph reflects the political aspects of the change. While these stakeholders may or may not be directly impacted by the technical changes, they will be acutely aware of how the change program could impact the business financially and their own reputations within the business and the market place. These two considerations make them a particularly important set of stakeholders. This is particularly true as you move towards the right. The change manager needs to work very closely with these stakeholders as they are not directly impacted by the change program, “whether they want it or not” and can choose their own level of involvement.

This dual analysis is of critical importance when it comes to communicating with each stakeholder group. The primary stakeholders in the first analysis will need to be sold on how important the change program is to the business and how important they are to its success. At the other extreme are the priority stakeholders identified in the second analysis. As per the first group, these stakeholders will also need to be convinced that the change program is strategically important to the business. But they will also need to be convinced that the business improvement program is being well managed and that it is unlikely to have a detrimental impact on the reputation, operations or finances of the business. If any of these tests fail, then the program runs into the very real risk of being cancelled.

There is a further relationship between the two graphs. The senior stakeholders on the right will frequently have the organisational position and authority to instruct the stakeholders on the left. This makes these senior stakeholders even more important when it comes to designing the initial communications and prioritizing which stakeholders need to be engaged with first.

There is one other stakeholder group that needs to be considered as part of the impact analysis, namely the business improvement team. This is the group of people who are working full-time or close to it on delivering the business improvement project. They may or may not be part of the program office and frequently this team will be a blend of full-time employees and contractor staff.

For me, this is one of the most important stakeholder groups on the project. This team is a catalyst for change in the sense that they create change, but are not themselves changed. They are also a temporary group, constituted for the life of the program. For these reasons, they are seldom, if ever, evaluated as part of the impact study.

A key responsibility of this team is executing an effective communications strategy. They will decide on what messaging is communicated to which stakeholder group, on what frequency and format. The importance of getting this strategy right cannot be underestimated as it will directly influence how the business perceives the change program.

It is therefore vital that the health and competence of the team is measured and managed. If this team becomes disillusioned or suffers from poor morale, the consequences for the success of the program would be significant. Equally if this team does not have a common understanding of the objectives of the program or how the various projects fit together, then they will be prone to delivering mixed messages to the business and undermining the very change they are trying to create.

BUSINESS PROCESS REENGINEERING

I  have  addressed many  of  the  principles around  business process reengineering (BPR) in the previous articles. What will make this article different is that it will describe how to prepare for, and run, a BPR workshop and program of improvement. It will repeat a few of the points covered in previous articles, as the concepts are inherently intertwined.

To run a successful BPR project requires context. The easiest way to build context is to establish a table that disaggregates  the business from the macro to the micro. Industry language describes this as going from level 1 to level 4. Level 4 is the generic term for the detailed process map, but in practice the disaggregation may drill down to level 5, 6, or 7.

There is no right or wrong, but it is worth considering that if you need to drill down to levels 6 or 7, then you may be narrowing the definition of process too much. This will make it very difficult to keep the process in context.

The disaggregation is represented  as follows:

Process stack and decomposition

To operationalise this picture prepare a table with the following or similar headers.

10

The description fields are important as they force the author to think critically about the separation between the processes they are intending to map. It may not be possible to complete all the fields in the first instance. It is recommended that you do not start mapping processes  until the data for that process is agreed. Ideally the table will be included in the statement of work.

For the process mapping workshop, you will need a decent size white board, a data projector, and a laptop. The workshop participants should be staff who are very familiar with the process. This may mean that you need more than one “subject matter expert” in the room to adequately cover all aspects of the process.

The following guidelines will add rigour to your process mapping.

1.   Model the process using roles not positions.

2.   Only one role can be responsible for an activity. Another role can contribute to the activity, but they are not responsible.

3.   The input from all trigger processes should be sufficiently consistent with the unit of measure being used in the process. A trigger process is a process that precedes the process you are working on. The output from that process is the input to the next process.

At the very least, the following data should be collected in the workshop, or as a result of the workshop:

•     Unit of measure—what is “processed.” It provides a means for calculating the annual volume.

•    Annual volume—can be broken down to weekly or monthly.

•    Process owner.

•    Process deliverables/product.

•    Distribution list for reports.

•    Trigger processes.

•    Hand-off processes.

•    Roles.

•    Indicative role costs.

•    Process activities.

•    Process sequence.

•    Decision points.

•    Percentage splits on each decision.

•    Work time for each process activity.

•    Cycle time for the process.

•    Technology used for each activity. Extended data requirements can include:

•    Information gathered at each step.

•    Status changes in the item being processed.

•    Descriptions of each activity. This may include work instructions.

It is important to establish early on whether you want to draw or model the process. It is almost impossible to adequately collect and evaluate the level of information described above if you do not use process-modelling software. If you use software that only captures the process as a flow sequence, such as Ms Visio, and different software applications such as Ms Word and Excel to capture the additional detail, then you are drawing. In this case you will not be able to complete the analysis described below.

Modelling  software allows you to capture the details of the process in the third dimension. That is, you can capture all supporting information in the application at the time of mapping the process. The concept is: write once, use many. There are a range of applications on the market that support this type of process modelling.

To start the workshop, ask the participants to confirm the data collected in the process definition worksheet. Then ask one of the participants to talk you through the process. It is best to have a high-level schema of the process in your head before you start.

Using standard interview techniques, capture the flow sequence on screen in front of everyone. Pay special attention to the words the participants use. Take time to explore inconsistencies or the subtle differences between branches in the flow.

Process map

Once you have documented the process, go back through it and capture the required details for each activity. The most important data are the work time for each step, the percentage splits for each decision, and the role costs. With these three data points you can complete the primary process analysis. An additional data point to collect for each activity is the underlying technology and whether it is manual, batch manual or integrated processing.

Please note the following techniques are only possible if you are using modelling software.

For  the  first round  of analysis, use the  traditional R.A.C.I. (RACI) (Responsible, Accountable, Contributor, Informed) table.

•    The process owner is Accountable.

•    The roles are Responsible.

•     The distribution list for reports and process outputs helps define who are the Informed stakeholders.

•    You may or may not have a Contributor.

The following is an example of a RACI table.

50

The RACI table allows you to confirm you have gathered all the required information and applied it in the correct manner.

The next level of analysis is to confirm how the process fits into the wider business. That is, do the trigger and hand-off processes make sense? In the graphic below the downward arrows represent trigger processes and the upward arrows are hand-offs. Obviously a hand-off process is also a trigger for the next process. In this way process 1 is the trigger process for process 2 and process 2 is the trigger process for process 3 etc. Each process is measured with KPIs  and the relationship between them is measured by SLAs.

Shared Services 3

The third level of due diligence is to understand the process data itself. This is done through understanding the sequencing paths within the process. 

Consider the following process:

22 (2)

It is an amalgamation of four paths or processing sequences. The paths are shown as follows:

Path 1

12

Path 2

Process sequence3 (2)

Path 3

Sales Clerk1

Path 4

Process sequence1 (2)

This analysis will produce two key tables:

1.   The cost to serve.

2.   Full-time equivalents (FTE).

The cost to serve table is shown and provides the weighted average cost for one iteration of the process. This number can be multiplied by the annual volume to get the annual cost.

Cost to Serve

Column 1 references  each way the process can be transacted. In this example there are four paths.

Column 2 is a result of the percentages applied to each decision in the process. (These are not shown in the diagram.)

Column 3 is the activity-based cost of the sum of the activities within each path. The figure is based on the costs associated  with each role multiplied by the time associated with each process step in the path.

Column 4 is the product of columns 2 and 3 and represents the cost to serve of one iteration of the process.

The second table is a staffing analysis. It is a similar analysis as is the cost to serve, but is completed on staffing needs-based FTE requirements. The following is an example. It shows FTEs by path and total FTEs for the process for one iteration.

FTE numbers

The analysis is completed by applying the annual volume to the FTE table. In this case, the annualised staff requirement becomes 1.8 FTEs.

FTE numbers2

Due diligence is to ask: “Does the annualised FTE number make sense? Can the annual volume be completed with 1.8 FTEs?” If you add a productivity factor of 10% or 20% the FTE figure rises to 2 (rounded). If the answer is yes, then you know you have captured the process correctly. If not, then the process data needs to be revisited. The answer does not need to  be precise; rather a “substantially  correct” answer is accurate enough for decision-making.

Once  the  individual processes are agreed, they can be aggregated to provide a holistic view. It is the same table as shown in previous blogs.

 Path analyis table (2)

With this table, process improvement can be prioritised. Assuming the intent is to reduce costs, you read the right-hand column. It shows the relative contribution of the individual process costs to the sum of costs for all processes. It can be seen that the “purchasing” and “new user setup” are the two processes that contribute most to total costs.

To reduce the costs associated with a business process refer to the cost to serve table.

Cost to Serve

Path 1 is the most cost-effective  processing  sequence. The best outcome is to reengineer the process to maximise the volume flowing through this path. This will deliver a savings of $49 per process iteration. If the process is transacted 10000 times a year, then this is a savings of $490,000. If you cannot improve the process to get 100% through path 1, then the next best option is to maximise volume through path 1 and use path 2 for the overflow.

 Moving 100%  of  the  volume to  path  1  can  be  achieved through controlling the decision.

Typically this can be achieved through a change to the:

1.   Staff profile through skills improvement  or behavioural change.

2.   Processing sequence through policy or procedural changes.

3.   Underlying technology through workflows  and configuring the existing system.

A change in skills will require further analysis to be able to answer the questions illustrated below.

training

 

The approach is to complete this analysis for each step in the process and then aggregate  them into a consolidated table. This table can be cross-referenced to the RACI table to check for completeness. Once this data is collected, it can be cross-referenced to the skill profile of the staff working in the process and improvement strategies developed.

Option  3  is the  best option  as the  application of  technology or  a workflow removes the  option  for  the  process performer to  make a decision in the process. This concept is explored further in the chapter on Judgement Support and Decision-Making.

Recognising that   this  type  of  process change  is  frequently  quite substantial in  its nature, it  is better to  complete the  analysis for all processes as shown in the following table and then develop a business improvement program to meet the change requirements of all processes at once.

100 (3)

Before implementation commences it is important that the business case for change is validated. The above table identifies the entire program of required improvements and  these improvements are then  used to recalculate all tables described throughout  this chapter. The  expected benefits are then compared to the existing process metrics.

 image005 (2)

In  this example, a total benefit of more than  one million has been identified with an associated saving of 21 FTEs. The nature of these 21 FTEs can be identified through a comparison of the staff profile tables.

I  close with the  following comments. Business process reengineering is reasonably straightforward to do at the “surface” level, and somewhat more difficult to do at the detailed level. A schematic of a process is just that—a schematic. It is a representation of the routines staff follow on  a daily basis and  to  reengineer the  process requires a change in these routines. To gain the trust of the affected staff requires a rigorous analysis of the processes  combined with a focused program of change management. It is equally important to remember that processes do not exist in isolation and to change a process without understanding how the process interfaces with the rest of the business is likely to reduce the overall benefits received.

STAKEHOLDER MOTIVATION

I am frequently asked to write on the mechanics of change management, a level of detail I have tried hard to avoid until now. The reason is simple—change management is complex, it is difficult, and it should not be reduced to a series of “cookie cutter” activities. I will never understand why large business improvement programs frequently refuse to pay a decent wage for the change manager’s role. On less than successful programs, it is common to hear statements to the effect of “the change management work stream failed” or “we would have delivered a better program if we had started the change piece earlier” or other words similar in nature. These statements assume that the business improvement program had any change management at all. Frequently, this is not the case.

No doubt, each unsuccessful program would have involved the completion of a stakeholder analysis, the delivery of training, and the publishing of communications. But I doubt all of this was delivered in a cohesive, integrated broadside to the organisation. I use the word “broadside” deliberately. Treating them as activities is why business improvement programs fail to deliver the required changes in organisational behaviour. Activities tend to get completed sequentially and then signed off as complete when delivered. In this case, the business improvement program has at best, a change coordinator. “We have done the stakeholder analysis.”—tick.

When it comes to change, the most fundamental question to ask is: so what? What has been learnt from a change activity? What is the business going to do with the information?

Note that the question does not ask what the program team is going to do with the information. That is of lesser importance than what the business is going to do with it. This distinction is vital, as the program team cannot change the business. Only the business (line management) can change the business. The program team will do all the heavy lifting required to meet the agreed deliverables. It just won’t change the business. If the business does not want to change, then the program office, despite its best efforts, will deliver a sub-optimal result and the senior management team will once again wonder what went wrong. By the time they realise that they had abdicated their responsibility for achieving a successful outcome, it will be too late to make corrections without the need to invest significantly more money into the program than what was budgeted for. Effective stakeholder management substantially reduces this risk.

Effective stakeholder management starts with the program sponsor. The sponsor is accountable for achieving the business benefits and this, by necessity, must include accountability for the change management work stream. Consider: if the business was serious about improvement, then it would hardly make sense to make a support function (change manager) accountable for achieving the structural and cultural change necessary to deliver the desired business benefits. The change manager’s role then becomes one of a subject matter expert designated to guide the sponsor through the difficulties associated with change. This would not exempt the change manager from their responsibility to prepare traditional deliverables such as impact studies, training packs, communications, etc.

A primary variable in any change program is people’s behaviour, as individuals and as groups, and the key objective of the change program is to establish predictability of behaviour. Predictability cuts both ways. The change program must provide predictability to those staff impacted by the change so they know what to expect, and equally the change manager, working through the sponsor, must provide management with predictability of how those staff will respond to the change and what is required from them as a senior leadership group. When people know what to expect, then they will be more accepting of the change when it happens, even if the change has a negative impact on them.

In practice, predictability and stakeholder management are synonymous terms and this means stakeholder management moves from being a discrete task in a change management plan to being the backbone of all the change management activities. To further illustrate this point, consider the following typical change management plan.

Change plan

To actively manage stakeholders requires agreement on who the stakeholders are. A stakeholder impact analysis workshop will help to identify the extended set of stakeholders. Stakeholders can be individuals or groups. For example, the CFO is part of the executive team, a key stakeholder group, and yet the CFO is important enough for the role to be identified as its own stakeholder group. In this way the CFO is referenced twice in the stakeholder management plan.

The impact analysis is a determination of how widely the “ripples” of the business improvement program will be felt. Ripples are typically operational, financial, or reputational. I define these terms in the broadest possible way.

The above methodology table indicates that the impact analysis is completed prior to the stakeholder management workshop. In practice, the two activities are iterative as each informs the other.

Once the stakeholder groups are identified, then the next step is to determine the best means to engage with each group, to bring them into the change program and cause them to actively participate. Basic psychology says that this is best achieved by engaging them on topics that interest them, in a manner that interests them. To this end a simple 2×2 matrix that cross references Power (the capability to influence the direction or outcome of the program) to Interest (the desire to influence the direction or outcome of the program) is a frequently used methodology.

Power interest matrix

This type of analysis is only valuable if the terms Power and Interest are understood.

In her article posted on the American Express OPEN forum, (https://www.americanexpress.com/us/small-business/openforum/s/?query=Nicole%20Lipkin%20) psychologist Nicole Lipkin discusses seven types of power, namely:

Legitimate Power is where a person in a higher position has control over people in a lower position in an organisation.

“If you have this power, it’s essential that you understand that this power was given to you (and can be taken away), so don’t abuse it,” Lipkin says. ”If Diane rises to the position of CEO and her employees believe she deserves this position, they will respond favourably when she exercises her legitimate power. On the other hand, if Diane rises to the position of CEO, but people don’t believe that she deserves this power, it will be a bad move for the company as a whole.”

Coercive Power is where a person leads by threats and force. It is unlikely to win respect and loyalty from employees for long.

“There is not a time of day when you should use it,” Lipkin tells us. “Ultimately, you can’t build credibility with coercive influence—you can think of it like bullying in the workplace.”

Expert Power is the result of the perception that one possesses superior skills or knowledge.

“If Diane holds an MBA and a PhD in statistical analysis, her colleagues and reports are more inclined to accede to her expertise,” Lipkin says.

In order to keep their status and influence, however, experts need to continue learning and improving.

Informational Power is where a person possesses needed or wanted information. This is a short-term power that doesn’t necessarily influence or build credibility.

For example, a program manager may have all the information for a specific program, and that will give her “informational power.” But it’s hard for a person to keep this power for long, and eventually this information will be released. This should not be a long-term strategy.

Reward Power is where a person motivates others by offering raises, promotions, and awards.

“When you start talking financial livelihood, power takes on a whole new meaning,” Lipkin says. For example, “both Diane and Bob hold a certain amount of reward power if they administer performance reviews that determine raises and bonuses for their people.”

Connection Power is where a person attains influence by gaining favour or simply acquaintance with a powerful person. This power is all about networking.

“If I have a connection with someone that you want to get to, that’s going to give me power. That’s politics in a way,” Lipkin says. “People employing this power build important coalitions with others … Diane’s natural ability to forge such connections with individuals and assemble them into coalitions gives her strong connection power.”

Referent Power is the ability to convey a sense of personal acceptance or approval. It is held by people with charisma, integrity, and other positive qualities. It is the most valuable type of power.

The most frequently used definition of power is legitimate power and using this definition alone is short-sighted. Staff who have relatively low legitimate power can have very high power when it comes to influencing the success of the program. This is especially true for subject matter experts who have expert power.

Once you consider all seven types of power, then it is likely that the set of identified stakeholder groups will be refined and expanded.

Equally, Interest can have multiple variables. I recommend using the same as those used to determine the “ripples” in the impact analysis, namely:

Operational Interest is a primary focus on structure, strategy, environment, and implementation; a desire to improve the operational effectiveness and efficiency of the business.

Financial Interest is a primary focus on the ROI and the impact on the balance sheet.

Reputational Interest is a primary focus on the company’s reputation in the market or the individual stakeholder’s own brand value.

Typically, all three variables will apply to each stakeholder group, but each group will have a leaning to one or another of them. For example, a middle manager will have a high interest in the operational benefits of the program and a lower interest in the financial aspects. They get their salary no matter what, so financially the program may not change their situation much, but operationally, the program could materially impact their work environment.

Then there is a forth variable to interest—self-interest.

Self-Interest is a primary focus on oneself. The WIIFM question or “what’s in it for me?” How will the program impact an individual’s personal circumstances?

This analysis gets interesting when it is used to evaluate how the nature of a stakeholder group’s interest will change depending on the health of the program.

To fully consider the relationship between the power and interest variables, it makes more sense to use a table rather than a simple 2×2 grid.

Slide-21-A

In this example, “Executive Management” has legitimate power with a primary interest in the financial results of the program. They are focused on ensuring the program is on budget and is delivering the promised ROI. They will also want to be sure that the change program is enhancing or has a neutral impact on the reputation of the company. As they are senior managers, they are less interested in the day-to-day operations and should be least worried about their “Self-Interest.” Obviously, depending on the specific circumstances of any given change program, the priority between the four interest types will change.

The above prioritisation should remain true while the business improvement program is going well. It will change if the health of the program declines and starts to have an adverse impact on business operations. When this happens, executive management will want to ensure that the business can still run and consequently, they will become less worried about delivering the program on budget. Their primary interest will switch from “Financial” to “Operational” and they will start to release additional funds. “Financial Interest” is reprioritised to second place and “Reputation” moves to third.

If the program health declines further, they may switch their primary interest to “Reputation” and start to take action to ensure reputational damage is minimised and operations are stabilised. “Financial Interest” moves to third priority.

In these examples, I have left “Self-Interest” at priority four, assuming that the executives are all professionals. It is realistic, however, to believe that individual executives will start to reprioritise self-interest higher up the scale depending on their exposure to the consequences of a failed program.

By comparison, the stakeholder group “Subject Matter Expert” is characterised by technically competent staff who are experts in their field. This group will typically have a high “Operational Interest” in the program, especially if it relies on their expertise and enhances their reputation (“Reputational Interest”). They will also want the business reputation to grow as it helps their CV. These staff may never rise to the senior levels of management and are less interested in “Financials.” Stereotypically, as long as the company keeps funding their budget they are happy. With a healthy program, interest in their “Self-Interest” is the lowest priority.

If the program health declines, then their Self-Interest will very quickly get reprioritised to the top of the list, as a subject matter expert typically does not want to be associated with a failed program, particularly in their area of speciality.

As the program health changes, so should the mode of the interaction the program has with each stakeholder group.

The 2×2 matrix can now be used as a guide to determine the best means of interacting with a specific stakeholder group with the caveat that Power is changed to Power type and Interest is changed to Interest type and the message is tailored to suit.

The quadrant into which a stakeholder falls, dictates the suite of preferred interaction styles that could be used to engage with that stakeholder. Interaction types include:

  • One-to-one interactions
  • One-to-few
  • One-to-many
  • Email
  • Town-hall meetings
  • Theatre
  • Website updates
  • Intranet forums (chat rooms)
  • Awareness education
  • Workshops
  • Delegations of authority*
  • Technical training
  • Posters, brochures, and other marketing collateral.

* Delegations of authority refers to the degree to which a position or role can make a decision that will bind the company. Pushing delegation levels lower into the company should result in higher levels of involvement in the program as the applicable manager responds to the fact that they can make a meaningful and sustainable difference to the change program.

It should be noted that all types of interaction are relevant. What changes is the importance and reliance that should be placed on a specific type as a means to effectively engage a specific stakeholder group, with a realisation that the most effective mode will change with the health of the program.

Subject matter experts will probably respond to detailed website updates and awareness education sessions far better than to face-to-face meetings. Executives, on the other hand, will most likely respond better to succinct emails and face-to-face briefings. Tied to this, is the content of the interaction. As a stakeholder’s interest changes with the health of the program, so should the content covered in each interaction.

The matrix now looks as follows:

Power interest matrix with comm type

I close with a reinforcement of the principle that only the business can change itself and that the change manager must ensure that their activities do not absolve the sponsor and other key stakeholders from their accountability to make the program successful.

DRAW THE PICTURE

Two of the biggest difficulties in the work environment are a) being able to quickly understand and contextualise difficult concepts and then b) being able to convey these complex concepts to colleagues or managers. These skills are almost mandatory for uninterrupted career advancement.

There have been many studies on the way people assimilate knowledge and no one shoe fits all. Depending on who you are you will prefer written text, audio, or graphics. My view is that if you can’t  draw it, you don’t  fully understand it. A graphic forces you to summarise your thinking, to organize it tightly into a visual object. Both written and spoken words allow you to describe the same concept from a few different angles and to really elaborate on the idea. A picture is static. Everything you want to say has to be summarised in the graphic and you are limited by the size of the page.

To  get a picture right means that  you really have to understand the concept you are drawing and the interrelationships within it.

There is no right or wrong way to draw a picture. You can use blocks and lines, symbols or a mind map. Once you get the picture right, you will be able to talk to it for an extended period of time.

Sometime back I  was wrestling with  how strategy was related to  a business. I drew the following picture.

diagrame editia 2

I look at the picture today and while I still agree with it, there are parts of it I would change. But at the time I drew it, that was how I understood the world. It summarised a few hundred pages of text. Once I had the picture clear in my head I was confident that I could take any question on the topic and be able to answer it in detail and in the context of how it worked with the rest of the business.

There is no formal methodology for drawing a picture and you need to be patient with yourself. It may take a few days to get the picture to a point where you are comfortable with it.

The underlying assumption of this approach is that any message  you receive, be it a written text, a verbal instruction or lecture, or even a visual event will only contain a half dozen important points. It is these points that you must include in your picture. The trick is identifying the points in the first place. My recommendation is: don’t try too hard. Use an A4 size piece of paper and draw your understanding of what you have just read or heard or seen. Make the picture rich in detail. The more detail, the better. Once you believe you have all the concepts on the page and you have related them to each other, take a new A4 and fold it in half. Now draw the same picture in half the space. It will force you to summarise your first picture. If you can, repeat the exercise with a one-quarter  size piece of paper.

Then reverse the process. When you can draw the summarised picture from memory, then draw the next level of expanded picture and when you have that right, draw the very detailed picture again. When you can do that, then you will find you really have internalised the concepts and you will be able to talk about them fluently. Then, depending on who your audience is, you can produce the appropriately summarised picture on the white board without notes and speak to it with confidence.

The following is another example of a picture I have used for years to describe the business architecture.

9 Point Model (2)

This picture conveys a significant amount of detail without being overly busy. It  describes the  elements of the  business architecture and  the context in which they exist. I now know this picture so well I can speak to it for over an hour if needed. I have also prepared pictures for each of the nine points (shown as blocks). This allows me to drill down into additional detail if necessary.

I have mentored a number of entrepreneurs who have come to me with an idea and the passion to start a business. They will all have prepared detailed business plans, but  when asked to  describe their  idea they invariably battle. My recommendation is always: write up a brochure of one page only with a picture. The potential client must be able to look at the picture and understand your business. The text is supporting detail only. When you can do that, you understand what you are selling.

It is said, a picture speaks a thousand words. This is true and when you have your picture, you will have a thousand words at your fingertips.

BUSINESS OUTCOME MANAGEMENT

One of the greatest challenges for any company is the execution of strategy or the realisation of benefits from the implementation of large change programs. Frequently, the reason isn’t organisational resistance to change, a difficulty that is commonly referred to. Rather it is for a more serious reason: managers and management teams focusing dogmatically on what they are doing rather than what they want to achieve. This causes managers to narrow their thinking and, in effect, operate at a more junior level. They “can’t see the wood for the trees” and the return on investment from their time is diminished.

The more senior a manager, the more they  need  to  work  within  a team to achieve the business objectives. Irrespective of how siloed the organisation is, the silos have to come together eventually. The lower in the organisation that this cross-departmental engagement occurs, the better.

A major inhibitor to  cross-departmental  engagement  is  the  absence of common purpose. Frequently managers believe they are working cooperatively but when pushed they have difficulty explaining the interdependencies between the initiatives they are all working on. This is because they are working towards completing initiatives, rather than delivering outcomes.

1

Initiatives are the activities managers and staff are engaged in. Outcomes are the result of one or more initiatives.

Consider the technology salesperson. Their role is to approach prospective customers and convince them that their technology solution will improve the prospects’ business operations.

For example, a CRM (customer relationship management) salesperson will state, “Buy my CRM software and you will have happier customers and improved revenues.”

BOM 4

Anyone who has implemented a major piece  of  software  will  know how flawed this scenario is. The truth is that once you implement a technology solution, all you have is a database of names and files.

BOM 2

To achieve the benefits promised by the CRM salesperson, the company must implement a range of complementary initiatives. The collective output of these initiatives will deliver the desired outcome.

BOM 44

The approach of interlinking initiatives and outcomes is known as Business Outcome Management. It is fundamentally different from traditional approaches to project planning in that the emphasis is almost entirely on the outcomes required.

The principle is the same as it is for ball sport players in the sense that it is better to be where the ball is going to be rather than where it is.

Business outcome management is a methodology that assists management teams to establish a common purpose. It  produces  two  deliverables. The first is a two-dimensional mind map that graphically displays the outcomes and initiatives and the second is a document that transposes the map into a business plan.

The importance of having a two-dimensional mind map cannot be overestimated. When discussing the importance of business outcome management with my clients they generally point to a range of documents or a single thick document and say they have it covered. At this time I ask them what the relationship is between their various documents, or how page x relates to  page  y  in  a  single  document. The point is that documents are “three-dimensional,” making it exceptionally difficult to know or visualise the multiple many-to-many interrelationships that exist in a single document, and between documents.

A two-dimensional mind map surfaces the interrelationships  and explicitly reveals how a single business outcome is dependent on multiple initiatives. It highlights relationships that are not immediately obvious in a document. The following is a simple example of the concept. Initiatives are represented as a square and outcomes as a circle. Risks can be included as a different shape.

300 (3) small 4

The graphic details the basics of implementing a change program. The entire “island” is labelled change management.

For larger projects and programs of work, the map will comprise of multiple “islands,” each representing initiatives and outcomes of similar intent and strategic focus. They provide  an  additional  dimension  to the map and assist the process of aggregating the relationships found in traditional documents into an easier-to-read format. Each “island” is labelled to provide context for the outcomes within the island, and collectively these labels are the executive summary of the program of work. Each island will have its own owner, a manager who is responsible for ensuring all the outcomes in the island are achieved.

800 (3)

Initiatives are written in the format: verb/noun. For example: “document the business process” or “administer  a  customer  survey.”  Outcomes are written in the past tense. “Staff morale has improved” or “customer requirements are understood” or “shareholder value has increased.” Using the past tense is important as it assists managers to clearly articulate the desired outcome.

Focusing on achieving the outcome encourages the manager to avoid tackling a project with a checklist mentality, as it is almost impossible to document all the initiatives required to achieve an outcome.

If you were focusing on initiatives you would work on “review and agree upon the business plan” and once completed you would consider that the business plan was reviewed and agreed.

3 copy

However, if you take a broader view, then you could only consider the business plan to be “reviewed and agreed upon” once all the indirect contributing initiatives were taken into account.

The indirect initiatives that contribute to “business plan reviewed and agreed” are:

  • Induct work package resources in project approach
  • Agree activities in scope and document approach to each
  • Establish change management program to mitigate risk
  • Review and agree risks to project
  • Agree approach to business planning
  • Socialise business planning approach
  • Prepare business plan
  • Review and agree business plan

These initiatives are part of two different strategic groupings (islands) but they all still contribute to the outcome and the manager who is signing off the business plan will expect to see contribution from all of those initiatives.

700 (3)

An important insight is that if a decision is made to delete or not complete an initiative, the impact of its absence can now be traced to those outcomes that relied on the initiative being successfully completed.

To prepare a business outcomes roadmap requires a workshop of four parts.

Part one is to agree the “endgame”—the flag on the hill. This is the medium-to-long term objective for the company or, if it is for a major project, then it is a statement of what the project will achieve. It should be a “big statement” but equally one that is achievable.

Example: “A culture of delivering excellence is implemented and a collaborative unified management team that is the envy of the industry is established.”

The second part of the workshop is to discuss the current issues facing the business. This is because managers and staff frequently cannot discuss the future without first explaining the problems they face in doing their job. You have to give them the chance to “put their baggage down.”

Part three of the workshop is to capture intermediate outcomes, those outcomes that must be realised in order to achieve the end game.

Part four is to capture the initiatives collectively required to deliver the sub-outcomes.

The methodology for collecting the data is important and it starts with the room selected for the workshop. The room should be set up without a table and the chairs should be arranged in a semicircle or similar. This assists people to “open up” in the workshop.

Each person is given a felt-tip pen with a broad point and a pack of post-it notes. Part one of the workshop can be completed on a white board through normal facilitation techniques.

Parts two to four will follow the same approach. The facilitator requests that the participants write one issue, outcome, or initiative (depending on the session) on a post-it note and to keep producing post-it notes until they have exhausted everything they have to say on the topic.

While the participants are writing down their thoughts, the facilitator should walk between them collecting the completed post-it notes and placing them randomly on a wall or window. As the notes are placed, the facilitator should read aloud a selection of the notes. This will stimulate the thinking of the participants.

When everyone has written down everything they have to say, and the facilitator has stuck all the notes on the wall, then the participants will be asked to sort the notes into groups. The rule for this part of the workshop is that the participants must work in silence. They cannot discuss their thoughts on the grouping. Once everyone is happy, the participants take their seats. At this time the facilitator will review each group and agree on a title for the group. These groups will later influence the “islands” in the mind map.

When all three mini workshops are complete, the workshop is over.The facilitator types up the workshop and prepares the business outcomes mind map. This will include de-duping the lists. The issues list does not make the map. Rather it is used to validate that everything that is included in the map will address the issues. Microsoft Visio is a good application for preparing the mindmap.

An important feature of this approach is that the outcomes are collected independently of the initiatives. This means there is no direct link between the outcomes and initiatives. When the map is prepared, the author must draw their own conclusions on which initiatives are related to which outcomes.

Once the map is prepared, it is critiqued by all or a subset of the participants from the original workshop. It may take two or three iterations until the map is agreed upon by all.

Viewing the map for the first time can be quite confronting for the participants. The best personal example of this was when I presented a map to a group of executives in the aviation industry. When they first saw the map, the room descended into chaos as each manager tried to find their department or function in the  map.  When  they  couldn’t, they turned on me. I explained that each of their functions was spread out through the map and that they had to work as a team to deliver the endgame. It was a significant moment and once the emotion died down, they really embraced the concept. Later the managing director wrote to me to say that they were 27% up on the budget as a direct result of the workshop. He was ecstatic.

Once the map is agreed upon, it needs to be turned into a document. This document has two parts.

Part 1 focuses on outcomes and part 2 on initiatives. The layout is as follows.

For outcomes:

BOM 7

 

The idea is to list all the initiatives that contribute directly or indirectly to each outcome. The “person accountable” refers to the outcome, not the initiatives.

For initiatives:

600 (2)

This table relates all outcomes to a single initiative. This is important as it informs the owner of the initiative about which outcomes are dependent on their activity being successfully completed. The R.A.C.I. table describes who will own the initiative (accountable), who will deliver the initiative (responsible), who will contribute to the delivery, and who should be informed of progress.

This is a powerful methodology and the results will improve with practice.

SAVING THE TEAM

One of the great projects I had the opportunity to work on was the IBM consultancy to Mercedes-Benz South Africa. The project managers did everything right. At the start of the project they took the time to properly establish a  project team  comprising of  MBSA and  IBM  staff. This included classroom training for the team to ensure a common approach, team-building activities and engaging with the client. This foundation ensured that the project was enjoyable and rewarding. The hours were long as is normal on a consultancy but nobody seemed to mind.

The  end of my involvement on  the project correlated well with my move to Australia. I made the final recommendations presentation to the MBSA executive team and two days later I moved to Australia. The presentation had gone very well and I was on a high.

Once I found my feet in Australia, I reapplied to IBM to join the local consulting practice. My application was accepted and I was soon on the projects. The problem was that the projects were not MBSA. The teams were new, the  objectives were different, and  the  project culture was different. In short I was unhappy and I quit. On the MBSA project I had been part of a high-performing team, established over months of focused project work. I mourned for what I had left behind.

As a consultant you are expected to move from project to project without difficulty, and I do it today without thought. What made the MBSA experience different is that I left it at the high point. I had delivered a successful final presentation and walked out of the boardroom, out of IBM and out of the country. I took no time to celebrate success with my colleagues. No time to debrief from the project and no time to bring closure to my role.

 My experience provided me with firsthand practical insight into  Dr. Bruce Tuckman’s model on teaming. Dr. Bruce  Tuckman   published  his  “Forming  Storming  Norming Performing” model in 1965. He added a fifth stage, “Adjourning,” in the 1970s. Tuckman’s model explains that as a team develops maturity and ability, relationships establish, and the leader changes leadership style to further the team’s evolution. He or she begins with a directing style, moves through  coaching, then  participating, then  finishes delegating and ends with a style that is almost detached. At this point the team may produce a successor leader and the previous leader can move on to develop a new team.

Teaming

The adjourning stage is also referred to as the mourning stage, when team members mourn for the high performance  “hellfire” days of the project and the camaraderie of the project team.

This final phase is frequently not recognised as important or, at best, is poorly managed. As professionals, managers are expected to “just deal with it” and keep their problems to themselves. As I found, this is not that easy.

Once I had lived the experience, I began to see it all around me. I met many senior executives who were put in charge of large business improvement projects within  their  company,  and  who  resigned after  the  project completed. Not immediately after the project, but within a reasonably short time of the project end. For the company, this is a problem, as frequently these projects are part of the manager’s succession plan.

The more I saw it, the more I took an active interest in the problem and, through discussion and observation, concluded that the primary cause was one of exposure.

Prior to commencing the project, a manager will have been working in their normal role, dealing with the daily routine expected from that role. They would have known where the role started and ended and what the limits of their authority were. They would be diplomatic with their colleagues, preferring to worry about their own role and allowing others to do the same in theirs. 

When  the  manager is  taken  out  of  their  routine  and  placed in  a senior project role, the rules change. No  longer are they confined to the boundaries of their position. No  longer do the rules of business diplomacy prevent them from enquiring about why their colleagues are doing what they are doing; in fact, they are now expected to investigate the way their colleagues work.

Driving a large business improvement project gives them licence to ask questions of the company and to review material they would not typically see in their daily role. Through the project they are exposed to the “soul” of the company. They are exposed to  the inadequacies of the senior managers. When you look into the soul of a company, you cannot forget, you cannot “un-see” what you have seen. You cannot go back. The firm assumption that  senior managers know what they are doing becomes less firm.

As a project lead, they are expected to think strategically and consider the big picture. This can be vastly different from their previous role as a silo manager.

When the project is over, it is almost impossible for the manager to return to their old position. They have just spent six months or more working harder, longer, and  with more freedom than  they ever had before. They have had almost unlimited access to the executive team.

In short, they are no longer the same employee as they were when they started the project and it is foolhardy to expect them to forget and return to the comparatively bland existence of their previous routine. If they are asked to, they quit.

There is an equally dark flip side to this issue. As the manager grows in confidence through the project and develops their insights into the company, they become a threat to more senior management who don’t want their “dirty washing” exposed and don’t want the manager getting ahead of themselves. The end result is that the manager is forced out of the company.

To address the issue and to save the skills within the company, senior executives  need to create a new role for the manager coming off the project. Invariably this requires that the company find or create a suitably senior role that allows the manager to come “back into” the company whilst respecting the journey of discovery  the manager went through over the course of the project. It  is important  to  recognise that  the manager who led the project is not a professional project manager and frequently they wish to keep their line management career intact.

The same issues exist for more junior staff members seconded to projects to work with consultants, either as subject matter experts or as a general project resource. These employees are also exposed to company details they would not normally see and witness or participate in conversations with the consultants that discuss the failings of the company. Under the influence of this often negative messaging, they start to see their managers in a different light. They will also start to work longer hours than their colleagues. As an individual, they will grow in confidence and as part of a team, they start to “perform.”

Project staff do not expect to get promoted when a project ends, but they do expect to be recognised for their contribution and to this end it is important to hold structured celebratory events to recognise the project and individual efforts. Failure to recognise an individual’s  contribution will almost certainly cause the staff member to  become disillusioned with the company. They will feel as if they have become an expendable commodity and not a valuable contributor to the company.

It is unlikely that they will resign, but it reasonable to expect that they will be less engaged with the company. This feeling of isolation can be amplified if the project has caused them to drift apart from their colleagues. Before they could gossip and share information. Now that they have had  access to  confidential information, they cannot  share information and invariably this creates distance between themselves and their colleagues.

There is no easy remedy for this problem. The most successful mitigation strategy is to agree the post-project role description for the employee before the  project starts. The  new role should stretch the  employee more than the project did. In this way they will rely on skills they learnt through the project and will not have time to mourn the end of the project. Done well, the employee will hardly notice the change.

An equally viable strategy and similar to  the above, is to  ensure the employee has a structured succession or  career development plan in place. This plan should supersede the project enabling the employee to contextualise the project as part of their greater development program. In this case, it is expected that the employee will come off the project requiring  less structured  support  for  their  re-assimilation into  the business-as-usual routine. Their period of mourning should be reduced but it is unlikely to be removed altogether.

Both of these strategies will be of immense benefit if the company works with the consultancy from the beginning to agree how the consultants should  develop the employee. This  will includes activities such  as allowing the employee to deliver important presentations through the course of the project.

In closing, I note that the above observations and strategies are general in their nature and will assist executives  and managers to retain staff, but when it comes to human nature, each person is different and has different needs. Those staff who are in “deep mourning” will require a re-assimilation strategy personalised to their specific needs.