Tag Archives: Project management

Managment accountability

Posted on by

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.

THE RISK OF RISK MANAGEMENT

Posted on by

Last year I published an article on Governance and a number of people wrote to me, critiquing the article over its failure to adequately include risk as a separate item in the frameworks I was using. Their point was that while risk management is an integral and mandatory discipline for executive management and company directors, it is sufficiently important for it to be addressed as an item in its own right.

I agree with this point of view but am not convinced that risk management is something separate from the day to day running of the business. To be fair I don’t think the people critiquing my article intended that risk be separated from the business; rather their view was that it is a specific discipline and it requires special emphasis in the business. This is particularly true as the operational time horizon shifts from tactical to strategic for the more senior levels of management in the organisation. This includes directors.

At the senior levels, the strength of the focus on risk is so strong that risk is frequently governed through a stand-alone committee (risk or risk and audit committee) or through a specialised role such as chief/senior/global risk manager.

The problem is that best practice (of any sort) embraced at senior levels, frequently does not filter down to the operational level. And when it comes to risk management this schism remains unchecked by the advisory community (consultants etc) and tactical risk plans seldom, if ever, adequately reference the strategic risk frameworks that are used at the senior levels in the organisation.

The majority of the tactical risk management plans comprise of the same elements; Identify and Assess, Evaluate, Manage and Measure.

Risk methodology

While the verbs may change from model to model and author to author, the intent remains consistent between the various models.

The standard approach at the tactical level is to hold workshops to identify and assess and evaluate the risks facing the business or project. Comprehensive lists of risks are produced.

My view is that these workshops fall foul of the principle that – you don’t know what you don’t know – and it should be expected that important risks will be missed. This is the risk of risk management.

It is impossible to remove the problem of, you don’t know what you don’t know, but it is possible to mitigate it if you change where you start, and you don’t start with Identify.

My recommendation is that the preparation of a tactical risk management plan should start with an articulation of company culture and a reaffirmation of the risk appetite of the business. Risk appetite can be defined, as the nature and extent of risk a company is willing to take in order to meet its medium to long-term strategic objectives. To have clarity on risk appetite, demands that the business understand exactly what business it is in and whether the business strategy is aligned to the business itself. For example, the major food retailers are not really in the business of selling food. Rather they are in the treasury business. Every day they collect millions in cash deposits and therefore have no problems with accounts receivable. On the other ‘side’ they pay suppliers slowly. Their true business is to invest and grow the funds in between.

Confirming there is a common understanding of the company culture is important. The simple definition of culture is – the way we do things around here and the risk appetite should be aligned to the culture. Obviously a high risk appetite will not fit a company with a highly conservative culture.

Risk appetite is different to risk tolerance in that risk tolerance defines how much of each risk type the business will accept. It is the risk parameter for each risk type. Risk tolerance allows the risk appetite to be broken down into measurable components.

Risk appetite

I am not suggesting that the team preparing a tactical risk management plan should start with redefining the culture in the company. Rather they should make sure that everyone agrees what the culture is and make sure they fully understand the risk appetite and associated tolerances for the business.

At the tactical level, the ‘Identify’ activity then becomes an exercise in aligning identified tactical risks to the short-term tolerance levels. This will ensure the tactical risk management plan is aligned to types and areas of risk the company is willing to embrace as risk tolerance is informed by risk appetite. It also encourages the completeness of thought around tactical risks. A quick review for ‘widows and orphans’, between the tolerances and the tactical risk plan, should quickly identify missed or non-aligned risks.

Using risk tolerance means that you already have the parameters for your risk model. This does not mean that the parameters at the tactical mirror those of the strategic level, but there should be some obvious alignment.

From a risk management point of view you are now in a strong position to identify and assess, evaluate and manage risks.

The manage step can be complex and the title is misleading. A more fitting title would be ‘Protect’ as in how does the company protect itself against risk. There are three primary defences:

  1. Self-insure
  2. Transfer risk – external insurance
  3. Reduce it. Operational response

Risk

These three choices should be used concurrently. The weighting between each ‘protection’ option is determined by the risk appetite, the specific risk under consideration and the time horizon associated with that risk.

By way of example, consider reputational risk. There is little point taking internal or external insurance against reputational risk as once it manifests you can’t undo it. You can’t un-sink a cruise liner or un-crash a crashed IT server. Insurance money will help pay for the PR campaign required to rebuild the reputation and other associated costs such as liability payouts or consequential legal fees. But these are different risks, not reputational risk. When it comes to reputational risk, prevention is the preferred option. The same applies for employee safety.

The concept of risk prevention is also a misnomer. You do not want to prevent risk as to achieve anything in business requires a certain amount of risk. To prevent a cruise liner sinking you would not go to sea. Rather the intent of risk management is to reduce risk in terms of frequency, likelihood, and consequence. That is, reduce the frequency of having to face the risk, the likelihood of the risk materialising and the impact to the business should it materialise.

Self-insure and risk transfer are predominately financial decisions and will not discussed further.

Effective risk reduction comes from using an appropriate risk framework and relating it to the business processes and to the control points within the processes.

Linking risk to process

This model extends to reference the process manager and the process owner should these roles be different.

The importance of relating risk to process cannot be overstated. The definition of risk appetite is ‘the nature and extent of risk a company is willing to take in order to meet its medium to long-term strategic objectives’. You have to take risks to be in business and the products and services of the business are delivered through the business processes. Therefore risk and business process can never be separated.

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.

GETTING THE MEASURE OF KPI’s

Posted on by

I was talking to a client about KPIs and they passed me a large bound booklet. It must have been 200 pages. The booklet was their operations report; a compendium of KPIs. I was asked if I could assist to determine new KPIs to address performance issues within the business. I flicked through the booklet. It was filled with red and green status indicators. Mostly red. I handed the booklet back to the client and apologised – I could not help him. I pointed out that the book already held more KPIs than I could possibly think of, and that the problem was not the absence of a specific KPI, but rather the absence of response to the existing KPIs.

To elaborate this point I turned to a page at random. The three monthly trend showed three months of ‘red’. This was largely the same for all the indicators on the page. The KPI’s had been indicating an out of tolerance position for months and nothing had been done about it.

The conversation then moved to discussing the purpose of KPIs and how to make them effective in the business.

Frequently when first implementing KPI’s, the mindset is to measure everything that moves; if it doesn’t move, kick it until it does and then measure it. Unfortunately, within a couple of months, many KPIs will be found to offer so little value that they are ignored. This sends a message to managers – that it’s all talk and no action – and the slide to indifference starts.

There is only one reason to implement KPIs and that is to manage behaviour. Equally there is only one type of behaviour in an organisation and that is human behaviour. Companies don’t behave, technology does not behave, plant and equipment does not behave. People behave. But what do KPIs measure. They measure customer satisfaction, mileage on trucks, lost sales, revenues, costs, throughput, quality and productivity. The list is endless.

The underlying principle of a KPI is – if you are going to manage it, then measure it, otherwise ignore it. There is no point in measuring something you are not going to manage. To address an indicator that is out of tolerance somebody somewhere in the organisation has to do something differently. Different to what they did last time because last time they created an out of tolerance result.

The difficulty arises when the KPIs are too broad in their definition. For example; sales are down so salespeople are told to ‘get out there’ and work harder. But does the salesperson know what to do differently to improve their sales figures. Clearly their current approach is not working. They need to ask themselves – what must I do differently to ensure I get a different result – or in other words how must I change my behaviour.

The astute sales manager will know exactly what behaviours are required to make even an inept salesperson successful and they will implement KPIs that evaluate this behaviour at the micro level. The focus will be on things that the manager can actually change. This could be number of calls made, length of calls, number of times the salesperson gets through to the decision maker, appointments set and the number of times a salespersons telephone rings.

The misconception is that sales managers are in sales, or more broadly, that managers of a function are in that function. Truth is they are not. They are in a separate function called management and managers behave differently to workers (staff). Therefore the KPIs that measure a managers’ behaviour must be different to those that measure staff behaviour – even if they appear to be in the same function.

The seniority between managers introduces additional complexities.

Consider the following four relationships.

The first relationship is between first line management and staff. A key feature of this relationship is that the two roles are different. Broadly, staff deliver technical output while managers deliver an administrative output. This requires that the manager use KPIs that measure ‘technical behaviour‘.

Mgt to Staff

The second relationship is between a manager who manages workers and his/her manager. 

Mgt to Senior Mgt

 The next level is the relationship between two levels of management where neither level is managing workers.

Senior Mgt to Exec Mgt

The key feature of the previous two levels is that management is managing management. This requires the use of KPI’s that measure ‘management behaviour‘. The KPIs for each level can largely be the same, separated by the degree of aggregation applied to the more senior of the roles.

The fourth level is the relationship between directors and managers. In many respects this relationship is similar to the first level of management. From a directors point of view, business management is ‘technical delivery’ whilst directors take more of a deterministic/directive role in the organisation in that they determine strategy, the governance model, the organisational risk appetite etc.

Exec Mgt to Directors

For each relationship set, what is the role of the senior manager. This is a complex question and not easily answered in a short paragraph. But in the spirit of this article I will say; it is to ensure that direct reports are behaving in a manner that maximises the likelihood of them achieving their KPIs.

Based on this definition, for each relationship, it is mandatory that the senior of the two managers knows what behaviour is required to maximise the business benefit possible from the subordinate management function, and what behavioural changes are required when the expected business benefit is not realised.

If the relationship between the KPI and behaviour is not understood or if a KPI cannot be manipulated through changes in a managers behaviour then it is likely that the wrong KPI is been used.

IT’S ONLY KINKY THE FIRST TIME

Posted on by

Everybody on this planet knows that cutlery goes in the top draw. You can walk into any kitchen anywhere and know that if you need cutlery, then one of the top draws will have it. But not in my house. My wife looked at the dust, crumbs etc that kept falling off the counter into the cutlery draw and watched the family behaviour. She noticed that a person would open the draw, take out an item and frequently not fully close the draw. This meant that anything falling off the counter got caught in the draw.

Her solution was to move the cutlery to the second draw down so it could be closed with the upper leg or hip. The action would be unconscious. Your mind is focussed on what is happening on the counter and with unconscious multitasking you also close the draw. If for no other reason an open draw is in the way.

The solution works brilliantly. The draw is substantially cleaner. The problem is that I have over 40 years of training behind me that says cutlery goes in the top draw. It took me a week to accept that cutlery could live in the second draw. I also realise that despite all my consulting in and experience in change management I was resistant to change. My wife implemented the change, not through consultation and facilitated workshops but through active execution of strategy. On my part while I was not happy for a few days, I soon realised that the roof of my house had not fallen down and the quality of my days did not diminish. If anything my life span has probably extended through having cleaner cutlery.

If you can’t cope with change at home how do you cope with it at work. A quick scan of the job boards indicates multiple vacancies for change managers with job descriptions that variously include everything from process mapping and training to communications and stakeholder management depending on the definition being used. This got me thinking.

What needs to change for things to be different in an organisation?

I now take my cutlery out of the second draw at home, but I remain convinced that if I ever find myself living on my own, my cutlery will be in the top draw.

So my behaviour has changed but my mind hasn’t. My ‘boss’ told me to do things differently so I did. But given I am never the one to actually clean the cutlery draw I have not actively enjoyed the benefit.

To truly effect change in a business it is mandatory to engage the hearts and minds of the ‘changees’. Training staff to use a tool such as a newly implemented ERP solution gives them new skills, but does that not make them embrace change.

Popular literature often refers to the WIIFM – “what’s in it for me”. This is an important question. People change for two reasons; 1. The pain of maintaining the status quo is too high and 2. The pleasure foregone by not changing is too irresistible to forego. Any other point in this spectrum is unlikely to cause a person to want to change. The key word is ‘want’. They may have to change to keep their job, but that does not mean they want to. For change to be sustainable, people have to want to change. The old joke of – ‘how many consultants does it take to change a light bulb; Just one, but the light bulb has to want to change’ – is particularly relevant.

For most projects the pain and pleasure points are understood by the project sponsor and the senior managers. They have commissioned the project and understand the ROI. In the majority of cases, these managers are not directly impacted by the project. They receive the benefits but do not actively work in the business functions and processes that produce the benefits. Obviously it is not black and white, but in broad terms they consume benefit and do not generate benefit. For these managers it is very easy to embrace change. Quite possibly they don’t even have to change their behaviour at all.

For the staff who work in the business, it is a completely different story. They have to change and change means learning a brand new routine – learning a brand new set of habits. But the benefit of change to these staff is diluted. They sit towards the middle of the pleasure/pain spectrum and are unlikely to receive any tangible benefit from change so why bother changing. This brings us to the WIIFM question. An answer frequently heard is that you get to keep your job. Sure this is a nice outcome, but it is not one that is going to capture the hearts and minds of the staff.

To capture the hearts and minds you need to enlist the staff. Enlisting staff means creating an environment where they are willing to proactively break their comfort zone, to challenge their entrenched views and truly believe that things will be better as a result of the change. This may mean pushing them kicking and screaming over the edge so they realise that change was safe. Show them that it is only kinky the first time. The next time it is familiar – I have done it before and survived. Once you have done something once, you are more willing to do it again.

How do you enlist staff. The most important thing is to realise there is no such thing as ‘staff’ in the sense that ‘staff’ is a collective noun. There are people, individuals. Each person is different, with different agendas, hopes and fears and personal pressures. To treat them as a collective is to short cut the enlistment process. There really is no substitute for open communication, consultation and active engagement of the individuals.

I readily accept that it is frequently impossible to engage each person in a one on one environment. This does not defeat the point. Rather treat one on one as the benchmark and the process of getting there as a process of continuous improvement. Where you have a choice, err on the side of engaging with small groups.

I also readily accept that there will always be individuals who will not accept change under any circumstances. In this case, acknowledge it, move on and let the normal course of events for employee lifecycle management play out. As my mentor used to say; if you can’t change the people, change the people.