If People by nature are change adverse, how do you change an Organisation? In this post we are going to discuss the 5 essential underrated and misused capabilities needed for change.
In a recent blog post we covered how 30% of leaders who have executed business and digital transformation initiatives, said that the problem with the transformation was technology, while 70% said technology wasn’t the problem, but stated that people and process was the problem and the hardest part of implementing the transformation.
So, in this post we will talk about the 5 essential capabilities of the people aspect needed for successful transformation, and why they are under-rated and misused:
- Culture,
- Stakeholder Management,
- Communication
- Leadership, and
- Teamwork
Culture
Every organization has a culture. It is an important feature of an Organisation, and something that provides an identity and its distinction, but it can also be hard to see.
Culture can be a powerful foe in change, and business transformation, if used correctly. The problem with culture is it is often mistaken for structure. Structures are generally classified into three (3) types – hierarchical, flat, or matrix.
Structure often refers to rank-and-order, or command and control i.e. how people give and take orders, and who reports to who.
This is not the right thinking for change or business transformation, however. You have to approach culture from the perspective of ‘what is the attitude or adversity to change’.
The more or higher attitude or adversity to change, the higher the resistance to change, and the harder it will be to implement your transformation.
The more or higher attitude or adversity to change, the higher the resistance to change, and the harder it will be to implement your transformation.
To key to making culture work for you in your change or business transformation, is understanding that attitude. One of those ways is surveying the staff’s attitude, either formally via a poll or survey or informally with conversations with staff.
In a business transformation you are either changing the people, process and/or technology, but in terms of culture, it’s not about changing the organisational culture, it’s about understanding the culture, and with that knowledge of the culture, and attitude to change, using that knowledge to inform the people-change activities.
Stakeholder Management
- (R)esponsible – for doing the work
- (A)ccountable – the work is completed to a satisfactory quality
- (C)onsulted – for their input, or
- (I)nformed – of the development or outcome.
In terms of change and business transformation however, this is not the way to be looking at stakeholders, but to the degree they are impacted by the change, and how much influence they have to support it (key players), or to potentially oppose it, as shown in the following example:
It is from this point, knowing the degree of their impact/influence, you prioritise and develop strategies and communications with the different stakeholders to keep them on-side with the change.
For example, for Key Players (high impact/high influence) these stakeholders can act as promoters of the change, versus the Monitor quadrant (low impact/low influence) who you need less frequent communication than the others, but enough that they don’t negatively influence the rest of the organisation.
Communication
Traditional change management looks at communication in terms of the communication needs of the different stakeholders on the RACI, and depending on their needs, and communication preferences determine the means or method of communication e.g. email, face to face meeting etc), and frequency (e.g. daily, bi-weekly, weekly etc).
But there is a step that happens before engaging with the stakeholders in the business, and that is the engagement and communication with the stakeholders in and on the change programme itself.
These stakeholders are those that shape the direction of the Programme, leading (and driving) the change from a Business perspective i.e. Business Architecture.
To make your change and transformation successful, you need to be proactive with your Business Architecture and engage early, as opposed to a ‘Reactive’ (or ‘Inactive’), once the change or business transformation programme is underway.
Where communication (and engagement) with Business Architecture is reactive and bought late into the Programme, often as an ‘after-thought’ to justify (not validate) the proposed technology solution in a compliance-like ‘box-ticking’ exercise.
The problem bringing Business Architecture in late in the programme is (in our experience in these situations) they unearth the misalignment between the proposed solution the business transformation is planning on delivering, and the Business’ Vision, Strategy(ies), Objectives and Measures, leading to (necessary) replanning, and reprioritising planned changes and design and implementation activities. Time, money and effort that could have been saved, had Business Architecture been bought in early instead.
Leadership
- Impact – how their roles will change from what it is today, to what it will be in the future;
- Skills – how the programme (and Organisation) is going to assess the training required to get them to where they need to be in the future;
- Training – what training will be provided and what it will look like to bring their skills to fulfil their role(s) in the future; and
- Support – what support will be provided up to, during and post implementation – so they know where they need to go, and what they can go to the different sources of support for.
Teamwork
The last essential but underrated and misused change capability is teamwork.
In enterprise wide change or transformation programmes, it requires both business stakeholders and technology stakeholders to transform the business.
In enterprise wide change or transformation programmes, it requires both business stakeholders and technology stakeholders to transform the business.
Unfortunately, in our technology dominated world, technology has overtaken the conversation and drowned out the voice of the business.
What projects are starting to do well though, is through the use of the Product (or Service) Owner, represent the Voice of the Customer (VoC) on the programme as the conduit between the programme (Core Team) and the Business (via the stakeholder map), as show in the example below:
What is missing is that although the VoC is captured, it is not represented on programme decisions, and therefore lost in implementation.
In our experience being called into rescue failing business transformation programmes, the reason why the VoC is lost is because boards or design authorities that make these decisions are either technical or technology design authorities which don’t include business stakeholders who represent the VoC.
To address this, the simplest way is to look into the room of the programme board and design authorities, and if the VoC is not represented by a person or body in the room, you need to get one.
The following example shows where the VoC would be represented as part of the Business Design Authority (BDA), that takes and ratifies business design (and Business Architecture) requirements to the technology (and Technology Architecture) counterparts in the Technical Design Authority (TDA) as part of the overall Solution Design Authority (SDA), ensuring the VoC requirements are carried through to implementation.
Do you agree with our list? Join the discussion and let us know in the comments what you think…
Thank you for reading this!
Sincerely,
Heath Gascoigne
