Tag Archives: organisational redesign

SAVING THE TEAM

Posted on by

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

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

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

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

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

Teaming

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PERCEPTION: IT’S NOT WHAT YOU THINK

Posted on by

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.

Change curve (2)

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 by

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.

Policies and Rules table (3)

 

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 by

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:

  1. Discuss outcomes and show belief in the person.
  2. Give short instructions.
  3. 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.

MANAGING RISK, A TRIGGER FOR CHANGE

Posted on by

Having spent considerable time on business transformation projects I can say with a high degree of confidence that the discipline of change management is becoming so watered down it is at risk of becoming more of a catch phrase than a serious discipline. The term is bandied about freely whenever a project is discussed without any real thought of what it will mean for the project. When project concerns are raised, the response is frequently along the lines of – that’s a change management issue or ‘we will ask the change manager to deal with that’.

The upshot is; for any given project, change management is treated as a ‘catch-all bucket’. Having said that, in many respects, this position is acceptable as the primary deliverable from almost every project is a change in behaviour at the individual and collective level.

The problem therefore becomes – for each project, how do you create a common understanding of what change management means for that specific project.

Recently I was asked to prepare a project initiation document (PID) for a client, working off their template. The template included all the standard headers such as objectives, scope, risk management, change management, budget and timeline.

This got me turning over an old chestnut of mine; what’s the difference between risk and change management.

My view is that the major reason to employ a change manager on any project is to mitigate risk and the biggest risks on any project are those represented by stakeholder behaviour. This includes scenarios where stakeholders:

  1. Do not embrace the need for the project
  2. Do not accept the deliverables of the project
  3. Cannot / will not work with the deliverables of the project.

Consider the last PID or Statement of Work (SOW) you prepared or read. It probably had a risk section with a structure and text similar to this one. The table (sanitised) is a mix of actual examples from various clients.

Risk table (4)

Column one describes the risk and column four details what can be done to avoid it becoming an issue. Columns 2 and 3 are used to rate the severity of the risk threat.

To mitigate these risks, change managers are engaged. Therefore by extension, change managers are risk managers.

Now compare the table to the following typical position description for a change manager:

This position reports to the xx manager or executive and will be instrumental in providing change management expertise in support of organisation-wide business transformation, process reengineering and resulting system developments. The primary focus will be creating and implementing change management plans to maximise employee engagement and proactively manage employee and client resistance. The change management specialist will act as a coach for senior leaders and executives in helping them fulfil the role of change sponsor and will support project teams in integrating change management activities into their project plans. The role will involve liaising at all levels across business units to analyse and effectively develop, deliver and embed change management solutions in line with commercial objectives.

Quite clearly, there are overlaps between the risk mitigation actions and the change management position description. This raises the following fundamental question:

Why do change managers not formally link their change management plans to the risk register.

By way of example here is a change management plan I chose at random from a Google search.

http://tiny.cc/n4nj1w

Change Management Plan

 

 

This is a typical example of a change management plan. At a concept level I immediately question why a change management plan needs to exist as a separate document from the PID. However, if it is to be a stand-alone document, then there is no heading I would delete.

At no stage in completing the template is the author expected to link the change management plan to project risks. In fact, the word ‘risk’ appears only once in the template where the author is expected to describe risks to the change management process.

Based on this template, how can the project sponsor build confidence that project risks are being mitigated or that the change management activities will have any relevance to the risks at all.

My observation is that a risk register is typically prepared at the start of a project and then is really only given lip service through the course of the project. If the project manager does happen to review the register, then it’s likely that the participants in the review meeting will readily explain how the risks are being managed and all is good. No panic required.

Equally and by contrast, my view is that change managers frequently start a project with a comparatively light definition of their project activities. Often with no more detail than the position description referred to above, supplemented with some reference to change activities such as weekly communications broadcasts, training plans, status reports, town hall meetings etc. Most likely they will have ‘copy & pasted’ the relevant parts of the PID into the change management plan, if one exists at all. Then when the projects gets going they generally make it up as they go, using best and last experience as a guide.

My recommendation is that change management plans are retired as a separate document, replaced by the PID or SOW and that the role of the risk register is redefined so that it becomes a change management plan.

Risk with change (4)

This will ensure that:

  1. Risk mitigation strategies are better thought through
  2. Change management is better aligned to the project
  3. Change managers understand their responsibilities more clearly
  4. Risks are continuously and actively managed, and
  5. Project managers will have a structured means of evaluating the effectiveness of the change management aspect of the project.

Let me have your thoughts.