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 accountabilities 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 versus 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 lines 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.

  1. 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 account abilities.

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 deliverable 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 for 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 an 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 range of mindsets. Some will say, “I have been here fifteen years and I’ve seen it all before. It didn’t work then and it won’t work now.” Others will say, “If it isn’t broke, don’t fix it.” And still others will say, “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 position 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 behavior, as individuals and as groups, and the key objective of the change program is to establish predictability of behavior. 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 aseach 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 sameas 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 isa 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, 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.