BUSINESS PROCESS REENGINEERING

Posted on June 1, 2014 by Garth Holloway

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:

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

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.

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.

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.

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:

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

Path 1

Path 2

Path 3

Path 4

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.

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.

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

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.

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.

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.

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.

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.

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.

STRATEGY DEVELOPMENT WORKSHOPS

Posted on March 29, 2014 by Garth Holloway

This article covers the basics of developing a business strategy. My favourite maxim on strategy management is “The bus that runs over the pedestrian is never the bus the pedestrian is watching.” This maxim reinforces the point that the value of a business strategy is directly related to the assumptions that underpin it.

When establishing a strategy, the first assumption is that the management team formulating the strategy all frame the conversation the same way.

Invariably this is not the case and the book “Reframing Organisations” by Boleman and Deal describes this phenomenon very well.

In their book, they describe four frames through which a manager can view the organisation and environment they work in.

The structural frame: a focus on how groups and teams are structured.
The human resource frame: a focus on human resource management and positive interpersonal dynamics.
The political frame: a focus on power and conflict, coalitions and dealing with internal and external politics.
The symbolic frame: a focus on organisational culture.

Recognising that managers may not be aware that they view the organisation differently as do their colleagues, it is important to agree the frame or frames the team will use through the strategy development process. It is acceptable that different managers explicitly adopt different frames to enrich the conversation and ensure groupthink is mitigated. It is only important that everyone knows which frame each person is using through the course of developing the strategy.

The strategy management process is depicted as follows:

Simplistically, the purpose of a strategy workshop or process is to answer five questions:

1. What business are we in?

a. What is the corporate culture?

b. What is the risk appetite?

2. What is the endgame or, in other words, what does success look like?

a. Asset sale

b. Public listing

c. Family business hand-down

d. Stop investment and take the money in annual dividends.

3. Why will we succeed?

a. Analysis of the operating environment

a. How is value created?

b. Who are the competitors?

4. How will we succeed?

a. S.W.O.T. analysis

b. What is the business model?

c. What is the style and structure of management?

d. What are the priorities?

5. How will we manage success?

a. Organisation structure

b. Compliance management

c. Performance management

The strategy workshop should open with confirmation of the nature of the business, the company culture, and the risk appetite. The nature of the business is to answer the question: “What business are we really in?” Often the answer will revolve around business models such as treasury or risk. These models are then placed in the context of the business they operate in. For example, supermarkets are generally in the treasury business and construction companies are in the risk business. Understanding the company culture will inform the strategy process as to the nature of the risk the company is willing to take on. For instance, a conservative company will not endorse a high risk strategy.

It is difficult to develop a strategy if there is no consensus on the nature of business, culture and risk profile.

The strategy workshop can now move to an analysis of the endgame. The purpose is to establish agreement on the exit strategy. The exit strategy is a statement of how the owners will turn their investment in the asset into cash. Options include: sell it, list it on the stock exchange, or take the cash in billings without actually building the asset. An equally acceptable option is to give it to the kids.

The endgame question informs the investment decision. For example, it is very difficult to sell a professional services business and if the principles wish to exit the business, then investing in the business may not be the best way for them to get value from it. Rather they should maximise their billing and take out the value in dividends over the next few years, then simply close the business and walk away.

The endgame question is equally valid for a public company, but the alternatives are different. There is only one objective for the directors of a public company and that is to maximise shareholder value. This reduces the directors’ endgame to the alternatives of selling the entire company or selling the shares they hold in the company. There are a few additional complex options that are not included in this article.

If the business is saleable, or it is a public company, then the exit strategy will always be to sell the shares for the highest value possible. The business strategy must therefore focus on activities that increase share value in a sustainable manner.

The longest practical time horizon for a strategic plan is three years and many would argue that this is too long, but this depends on the market the company operates in. Developing a three-year strategic plan does not imply that the owners will exit in three years. The time frame is only to provide context for the strategy workshop and if the strategy development process is conducted annually, then the three years becomes a rolling three years. For some markets such as infrastructure development, the investment period is well over ten years.

At the beginning of this article I mentioned the need to manage assumptions. Through the course of agreeing the endgame, a number of explicit or implicit assumptions will have been made and the next stage of the workshop is to expose and critically examine these assumptions and answer the question: “Why will we successfully achieve the endgame?”

The intent of the question is to force an examination of the assumptions made about the market the business operates in (external environment) and the business’s ability to operate in that market (internal capabilities).

There is no right or wrong order in which to approach these two mini workshops. My experience is that workshop participants need to discuss their internal environment before they can properly consider the external environment. The problem with this approach is that it can become very myopic and the thinking becomes constrained to considering what is known, rather than including what is unknown. If the workshop sequence does start with an analysis of the internal environment then it should include a reconfirmation of the results after the external analysis concludes. This will ensure the capabilities considered in the internal analysis adequately address the opportunities and threats identified through the analysis of the external environment.

For the internal analysis workshop to be successful it is important that there is agreement on the core business. That is agreement on the question: “What business are we in?”

Understanding what business you are in, tells you what you must be competent in and, by inference, what the business must be capable of.

Many capabilities create a competency.

Source MGSM

The internal analysis is therefore a review of the existing capabilities against the nature of the business. It is a review of what exists now and what capabilities need to be introduced or enhanced. To guide the identification and classification of capabilities I recommend the B.T.O.P.P. model. It is a simple but practical model for structuring the analysis.

It is important to keep the analysis at a high level to avoid getting mired in conversation on the nitty-gritty. The following table provides a good structure for collating the results.

Source MGSM

Column A can be renamed “business objective” or “core competencies” or similar. The last column is important. It captures the group’s opinion on what needs to be resolved to close the gap. I recommend using the B.T.O.P.P. model here again to check for completeness. This is in addition to using it for the capabilities analysis. For example, if the desired capability is to be able to establish a “multi-local” distribution chain or to be capable of transacting in multiple currencies, then the issues will be multi-faceted. Using the B.T.O.P.P. model creates a common vocabulary for recording the issues.

There are many models that assist with the analysis of the external environment such as Porters Five Forces (shown below), the P.E.S.T. (Political, Economic, Social and Technological), and P.E.S.T.E.L. (PEST + Environmental + Legal) frameworks.

Source: Porters 5 Forces

The results of the analysis can be captured in a table as shown.

Column A describes the nature of change anticipated in the market.

While the table is simplistic, care should be taken to include as much detail as possible when describing the anticipated change. This may require adding additional columns. Depending on the depth of the analysis, a different table may be used for each analysis topic, or one table for all. The table is intended only to collate the issues, not to solve them so there is no column for mitigation actions.

The internal and external analysis addressed questions 3 and 4 (referred to at the start of the chapter) and provided the raw data required to answer question 5. The workshop is now ready to consolidate the issues and prioritise the actions for the next 12 months, 3 years, 5 years etc. The critical issues framework can assist with this process.

Source MGSM

The methodology is to use the grid to “sift” the issues gathered through the two analyses to determine the critical issues. It is important to treat the grid as a “relative” analysis in the sense that all the issues are important, but some are more important than others. This means that you should be able to place an issue in all nine cells. Placing an issue in the low priority cell does not mean it is not important. It only means that, of the raised issues, it is of a lower priority. The critical issues are then further analysed as shown.

Source MGSM

The final step in order to conclude this stage of the workshop is to perform due diligence. The approach is to cross-reference the priority actions captured in the previous table to the business objectives discussed at the start of the workshop, or the required competencies highlighted through the capabilities workshop. Using a simple light/dark analysis provides an easily understood summary. Dark shading represents a closer match between the objective and priority.

Cross-references that are overly dark should be examined for completeness. Is the underlying issue fully described and understood? Is the priority correctly applied?

The priorities are then associated with a high-level timeline and the workshop is now ready to answer question 5: “How will we manage success?”

On the basis of “a journey of a thousand steps starts with the first step,” the purpose of question 5 is to ensure there is agreement on the tactical changes or projects required to execute the strategy. The timeline provides the priority.

I close with the observation that managers frequently do not allow enough time for everyone to fully consider the points being discussed.

The commonly heard statement is, “Let’s just get something down on paper and we can refine it over email.” This approach may improve efficiency but it destroys the debate. It is recommended that each activity in the workshop is addressed twice, if not three times. If it is a two-day strategy session, then repeat Day 1 on Day 2 to give people overnight to really think about the issues. Then hold a further review a week or two later.

PERCEPTION: IT’S NOT WHAT YOU THINK

Posted on November 16, 2013 by Garth Holloway

Maybe each human being lives in a unique world, a private world different from those inhabited and experienced by all other humans… If reality differs from person to person, can we speak of reality singular, or shouldn’t we really be talking about plural realities? And if there are plural realities, are some more true (more real) than others? What about the world of a schizophrenic? Maybe it’s as real as our world. Maybe we cannot say that we are in touch with reality and he is not, but should instead say, His reality is so different from ours that he can’t explain his to us, and we can’t explain ours to him. The problem, then, is that if subjective worlds are experienced too differently, there occurs a breakdown in communication … and there is the real illness.”

I read the above quote by Philip K. Dick and it reinforced how relevant perception is to change management and the importance of what we say and allow others to say.

This was first highlighted to me when I was working with IBM on the Mercedes-Benz South Africa business transformation project. In the early part of the project we spent considerable time collecting data, the bulk of which was qualitative. I asked the seasoned project manager on what basis we could rely on qualitative data to make far-reaching recommendations. His reply was: if enough people repeat something to be true, then it is true, irrespective of the facts. In other words, perception is reality.

The primary agenda of any change management program is to deliver a change in behaviour. This is equally true for very large programs such as national “Don’t Drink and Drive” campaigns to small localised programs, internal to a business, such as how to code an invoice properly. In all cases people only change when they perceive the need to change, and it is the change manager’s role to socialise a message that will create this perception at the individual level and within the crowd.

It is not difficult to determine the view of the crowd as people will readily repeat what they perceive to be a commonly held truth. It is considerably more difficult to reliably determine how an individual perceives the world as their views are coloured by an unlimited range of personal circumstances to which the change manager is not privy. Consequently, it is a waste of time to try and change an individual’s foundation perceptions.

Rather the change manager should focus on managing how individuals express their perception of the work environment and the changes within it.

The importance of managing perception is represented by the dip in the graphic.

Every business transformation project shakes up the organisation. People become uncertain and routines are disrupted. This will cause organisational performance to decline, as represented by the dip, before targeted improvements are realised. As people become disrupted they lash out in their language.

Statements such as “nothing works here” or “management are idiots” or “why bother, nobody cares” become increasingly common and indicate a low level of engagement. The less engaged a person is, the more they will resort to using sweeping statements instead of taking the time to consider what is truly bothering them before they speak. These types of statement only serve to widen and deepen the gap and make the change program appear more confronting than it actually is.

Without intervention, and without a message to the opposite, there is a real danger that the sweeping statements of an individual become the view of the crowd. It must be true if everybody is saying it. Consider a new hire stepping into that environment. What else could they realistically believe?

The change manager cannot change how a person feels. However, the change manager can change the way people express themselves.

Instead of condoning or ignoring sweeping statements such as “this software is useless” ask staff to be specific with their complaints. Persist until they come up with a specific concern like “I can’t print a copy invoice.” That is the real problem. Encouraging individuals to replace sweeping statements with specific statements will cause them to actively think about and engage with the issue. When people speak differently they allow themselves to think differently and they start to perceive the world differently. This tends to reduce emotion and exaggeration. In addition, when people know that they will be called out on a broad generalisation, they tend to become more circumspect in what they say. Eventually they may even behave differently.

From a change management point of view, it is far better for staff to know that they cannot print a copy invoice than to believe the software is completely useless. Then, when they are complaining to other staff, they will be accurate and specific, not vague and inaccurate. The crowd becomes infected with the truth, which is, in this case, that you can’t print a copy invoice, rather than by broad inaccuracies about perceived deficiencies in the software.

Only when a person changes the way they express themselves, will they really be able to change the way they perceive their work environment, and subsequently change the way they present themselves in the work environment. Occasionally you will hear that someone has had a real change of attitude. What this really means is that their language has changed, from negative to positive. When people say positive things their colleagues will respond positively.

The same can apply to the group, but to achieve it the change manager needs to introduce a common vocabulary, a company lexicon. It will promote an environment where individuals use the same words for the same things. That way everybody knows what is meant when statements are made. Conversations should get shorter and the disquiet caused by miscommunication should be reduced. Introducing a common vocabulary is exceptionally difficult. It requires that the change manager has the vocabulary to start with and a mindset that realises that change management is not just about training people in a technical skill.

I recognise, that despite the change manager’s best efforts, it is impossible to get everyone in an entire organisation to change the way they speak. The best mitigation is to introduce scorecards. Using a scorecard moves the conversation from subjective perceptions about what happened to factual data. It should cause the conversation to start with a discussion on actual business results rather than a particular person’s behaviour, or more importantly, the manager’s perception of the employee’s behaviour.

I close with the thought that trying to manage perception is similar to standing in a hall between two mirrors. Each mirror reflects the other and this continues until each mirror appears to have an infinite number of reflections in it. These reflections represent the perceptions two people could have of each other. To know which two “perceptions” are active in the conversation is impossible.

POLICY AND RULES – SIMILAR BUT DIFFERENT

Posted on September 11, 2013 by Garth Holloway

Recently I was asked what I considered to be the difference between rules and policy. I gave my stock answer – rules cannot be changed, policy can. There was a group of people listening and they almost unanimously said – “what, of course you can change a “Business rule”.

I went on to defend my position by stating – you can repeal a rule and issue a new one. The original rule has not changed; rather it is no longer in force. A new rule has been issued and it is separate from the previous rule. Conceivably the original rule can still be reissued and both rules will be in force at the same time.

Policies by contrast can be changed and the ‘edges’ of policy are not as defined as a rule.

Policy and rules are similar in that they both set out to guide behaviour. They differ to the extent that they allow the individual to make the final decision as to how they will behave.

The key attribute of a rule is that is must be precise. You are either complying with it or not. Consider the rule – you must stop at a red traffic light. There is nothing ambiguous about this rule. You either stopped or you didn’t. You are not allowed to interpret the rule. When the fire alarm sounds above your desk, you do not get to decide whether you leave or not; you get up and go. (I admit that when it comes to fire drills, I frequently break this rule).

Policy is often written up in an equally prescriptive manner. Most companies have a policy on bribes along the lines of; no employee will accept or offer a bribe. This statement is as prescriptive as a rule. In fact I would call it a rule that is frequently called policy.

Policy sets the parameters that define how you will behave in a given situation. An example; staff are permitted to dress in business casual on Fridays. This policy does not explicitly define what business casual is leaving it up to the individual to decide what is appropriate. A further example is – sales managers may spend $XX a month on business expenses. The policy does not define how the allowance should be spent, or on what.

In both examples, it is assumed that the individual will – do the right thing- and will behave in accordance with the values and objectives of the company. With rules, this freedom is removed and the individuals’ behaviour is prescribed.

This distinction is important when establishing organisational procedures. A procedure tells you how to do something. Typically a policy covers the entire procedure and provides the parameters of permissible decisions on what’s appropriate behaviour when executing the procedure. Rules generally apply to specific tasks within the procedure and cannot be interpreted.

Despite the implication of the oft used phrase – policies and procedures – both policy and rules exist separately from procedures and have a one to many relationship with procedures. This means that individual policies and rules can be associated with multiple procedures and procedural steps respectively.

Establishing rules is reasonably straightforward as the language of rules is ‘native’ to managers. We are all comfortable expressing constraints on behaviour in terms of single statements. “You will….”, “You must…”, “You cannot….”. Even when we intend to establish policy statements we typically express them as a rule.

There is no easy methodology for establishing policy. As a guideline, the role of policy is to:

translate values into operations
reinforce compliance with legal and statutory responsibilities
set standards, and
improve the management of risk.

A good place to start is with rules. Write down the rules that will apply to the area you wish to establish policy for. Then bundle similar rules into groups. These rules become the parameters of the policy statement. Read each rule in a group and write a business statement that covers all the rules in that group. This is your policy statement. Given that the statement is trying to cover all the rules in the group, it will by necessity, be appropriately vague.

Another method is to take a specific problem area in the business that you wish to manage with improved policy and establish a table that aligns policy with procedures and rules. Having these three items in one table quickly surfaces issues where policy is written as a rule and rules as policy.

By way of example.

The business issue is to reduce the risk of poor decision making on tender submissions.

The first policy statement uses the word ‘accurate’. This is a relative term. The rules define how accuracy should be interpreted.

The second policy statement uses the word ‘complete’. This is also a relative term. The rules define how completeness should be interpreted.

Completing the table should deliver relevant and useful policy statements.

In closing I will say; the real difficulty is managing the policies and rules once they are published. The last column in the table is ‘consequence’ … when it comes to rules and policy, if you are not prepared to manage them, do not bother establishing them.

MALICIOUS COMPLIANCE – THE SMILING SERPENT

Posted on August 22, 2013 by Garth Holloway

I was talking to a colleague last week over a beer. He was full of ‘disgruntle’ as he related the story of his day. Basically it went like this…

I have been working on this IT project for months, doing long days and occasional weekends. This morning I arrived at 10.15am. In front of everyone the project manager shouted at me that the project hours were 8.45am to 5pm and that I should make sure my timesheet reflected my late start. Not only was I embarrassed by the reprimand, but the project manager gave me no credit for the fact that I never left the project before 6pm – ever.

I asked him what he was going to do about it. He answer was simple – “I will work the project hours, no more, no less. Then when the project is not delivered on time, it is the PMs fault, not mine”.

At the time of writing, he has been true to his word. Working what he calls short days.

I reflected on his story and I recognised that at some point in our professional lives, we have all stood in front of a manager receiving a dressing down. Outwardly we maintained our professional demeanour, while inwardly we were seething. The situation for which we were reprimanded may have been our fault, but our motives were honourable. We were working in the best interests of the project and colleagues. In our mind the reprimand was just wrong.

After such a reprimand it is quite human to leave the manager’s office with a mindset of – stick it buddy, if you don’t want me to ‘X’, then I won’t. It’s ‘by the book’ from here on in.

For most of us the emotion subsides fairly quickly and we get on with our job recognising that we can’t please all of the people, all of the time.

The problem is that there is a minority group who do not forgive and forget quite so easily. For these people their chagrin runs deep and they cannot readily bounce back from a reprimand. These people take their ‘by the book’ vow to heart and they consciously set out to change their behaviour for the worse. Next time the manager asks them to do something they follow the instruction to the letter, entirely aware that what they were asked to do is not what the manager actually wants. They know full well that following the instruction to the letter will be counterproductive to the manager’s intent and for that reason alone, they do exactly that.

This dogmatic adherence to the exact instruction given, rather than to the intent of the instruction is termed – malicious compliance.

From a business or project point of view, malicious compliance is a treacherous form of corporate sabotage. It can be very difficult to identify and even more difficult to treat. It can manifest in many ways including; adhering strongly to shift start and stop times, not contributing to a discussion when you know the answer unless you are asked a direct question, exaggerated responses to instructions, working strictly to the agreed standard or preparing reports you know to be unnecessary or irrelevant.

Failure to identify malicious compliance can set a project back months or as I have seen in some cases, derail the project altogether. This is especially true if the ‘bad apple’ is a leader in the group. Example; If the leader starts to work to the standard hours then it won’t be long before the whole group is following suit. Equally if the leaders attitude goes unchecked, it won’t be long before the whole group is grumbling and questioning the authority and leadership of the (project) manager. This can force an unplanned change of management as that becomes the only option to bring the situation back to normal. This in turn could unfortunately reinforce the negative behaviour of the employee or group and it may be some time before management is able to get the balance of power back.

The trigger for resorting to malicious compliance will vary by individual and includes everything from an individuals need to implement a machiavel private political agenda of destabilisation to those who are suffering change fatigue and need to resort to doing the minimum just to get by.

I consider those who are machiavel to be a smiling serpent. They smile to your face while sabotaging your project. They have perfected the art of hiding in the open.

For an employee to be maliciously compliant requires the employee’s manager to know that the employee could do a better job if they wanted to. It is a case of ‘can but won’t’ as opposed to ‘can’t and won’t’. The difference between the two is motivation. The formers motivation will always be negative and the latters could be neutral or positive.

Most people cannot ‘maintain the rage’ for long and generally do not require remedial action beyond possibly having a chat with them after the emotion has passed. For this majority, bouts of malicious compliance should be seen as part of the process of building corporate experience and maturing as a professionals – Learning that you can get angry and then get over it.

For the few that do persevere with malicious compliance there are three remedies:

Discuss outcomes and show belief in the person.
Give short instructions.
Critically listen to the employee.

Moving the discussion to outcomes forces the staff member to answer the – so what – question.

“You fulfilled the instruction – so what. What did you achieve”?

Forcing the employee to confront their contribution, or lack thereof, is a powerful means of communicating that malicious compliance cannot produce satisfactory results and that obvious and continued mediocrity cannot be ignored by either party. Both need to take action.

By definition, malicious compliance is a conscious choice. The employee chooses to behave in this manner. Therefore, they can choose to relax their stance as well. In remedy 1 above, I mention that the manager should show belief in the person. This is especially important when the employee cannot see a way out of the situation they have created. By accepting their justifications at face value and showing belief in them as a person, the manager allows the person to ‘save face’. This gives the person room to move, to adjust their behaviour without having to fully admit fault. It should lead to the return of an acceptable level of output and behaviour.

As part of the addressing the issue, the manager should give the employee short and simple instructions where the deliverable is easily identifiable and within a short timeframe. This allows the employee to build success upon success and to receive positive feedback frequently. It will help to mitigate any self-esteem issues the person may have.

Equally, these two remedies will provide the manager with the sufficient case study material should it become necessary to begin a job transfer or termination procedure. Because – if you can’t change the people, then change the people.

The third remedy is to critically listen to the employee. If the employee is a person with obvious skills and talent who is in effect dumbing themselves down to conform to the instructions, then the manager must evaluate who is the dogmatic party. This is particularly true when a manager is dealing with a highly experienced technical person. In this case the manager may not fully understand the technical answers given to their questions and therefore they inappropriately instruct the technician into a course of action the technician knows to be wrong. The technician is unable to get the manager to understand the error in the instruction so they throw up their hands and say – “It’s not my problem, I will do what I am told”.

With thanks to Kailash Krishnan for his comments on the early draft.

Garth Holloway

New Words for Old Ideas

Tag Archives: Business

BUSINESS PROCESS REENGINEERING

STRATEGY DEVELOPMENT WORKSHOPS

PERCEPTION: IT’S NOT WHAT YOU THINK

POLICY AND RULES – SIMILAR BUT DIFFERENT

MALICIOUS COMPLIANCE – THE SMILING SERPENT

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this: