X
X
Share
Back to news

Technology makes it possible, but people make it happen. It’s a behaviour thing…. by Will van Zyl

Duh, but we know that!

In keeping with the rest of this piece, I am going to start with the end in mind and then communicate.

To sum up, it seems the often-neglected activities of future state definition (detailed blueprinting or user scenarios) and structured, two-way communication are exactly the tools that help prepare the business and make it ready for data and data management related change.

This is not unique to data related programmes, but for some or other reason these essentials seem to take even more of a back seat here than on other types of programme.

Objectives and deliverables aside, it is about getting people to think and work differently

Most projects focus on technical deliverables. In fact, in most organizations I have recently worked in, programmes seem more focused on pace of technical delivery as well. There seems to be a decreasing focus on clearly defining and preparing for the change these deliverables will bring.

Data is the spoor of all companies. The trail of where they come from, an indicator of who and how they are and pointer to their journey forward. Making sure the data is accurate and fit to use is an increasingly demanding task. It follows fairly logically, then, that if you work with data and a data management change programme comes along, you may get a little excited…or anxious.
A fundamental change in how we deal with data brings significant behavioural and process change along with it. The sizeable portion of resistance to this change is a bonus we get. Something of a “…buy this project and get the resistance for free…”

Focusing project efforts early and appropriately on motivating the required behavioursand then designing the process and technical solution with these in mind, may be the difference between a series of successful project deliveries and a successful transformation!

Why the resistance?

Cliché alert!!

For true change to be affected, it needs to come from within.

It is a cliché for a reason though.

On an individual level, you have to want to do it or, at least, find it important enough to do as part of what you are at work to achieve.

Alongside this importance you need to feel that you (or your team) are able to make the shift. The type of change we are talking about on these projects often involves changes to role, team or expectations of individuals in their roles or teams. Generally asking more of them!!!

As a result, the underlying confidence in achieving the outcomes / making the change could be low.

Ironically, a common result of this low confidence is that certain user groups or stakeholders start to adamantly claim the required change is, actually, not that important. There is a word for that…DENIAL. I am not going to get all “psycho analytical”, however.

What to do…exploring and raising the readiness to change

To recap…change is possible if it is important enough and we are confident in achieving it. I.e. IF we are ready to change, we will. So it stands to reason that a project that focuses on Readiness for Change as well as technical deliverable would stand a good chance of being successful.

“But that is what all projects should do anyway…” You may say. You would be right. They should, but this is my “callback” to the opening line, if you will: Not all of them do.

There seems to be a neglect of the basics of preparing businesses for change. We then seem surprised when pockets of resistance, often strong, to the planned change pop up!!

You have probably guessed where this is heading, but I’ll go there anyway.

To avoid or reduce resistance to change, we need to go back to basics and work with user groups, change blockers or not, to get them ready for the change.

The most useful starting point for this that I have used is to start with two fairly simple questions:

1. Do they know what is in it for them? AKA is it important enough?

There is always (at least one) discrepancy between how things are done and how they should or could be done. The programme would not exist otherwise.

The greater this discrepancy, the bigger the reward and greater the importance of the change could be.

The objective is to build this discrepancy in a way relevant to each user / user group.

Example

Capital modeling actuaries on a quarterly reporting cycle. These noble folk work unbelievable hours to get the numbers turned around and available for the rest of the finance team, to incredible timelines, using fairly clunky excel based processes (liberal use of the word). A possible benefit of greater control and efficiencies in their processes (I.e. Data Quality changes…) is the ability to get more done in a workday. Looked at another way…they could leave earlier!! In addition, with advances in self serve and agile BI technologies, controlled does not necessarily equate to constrained!! A key goal with Actuarial change should always be to retain the value of the actuaries, despite increasing the controls. Making these seemingly obvious facts explicit in a recent project got us the buy in of the entire Capital Modeling team!! Well…almost the entire team.

Make sure you have articulated the target state in clear and simple terms that are relevant to this group of users. If they cannot see a reason to go along for the ride, they generally will not go along for the ride, let alone take the driver’s seat…

2. The opposite of confidence is fear. All else being as it should, what are they afraid of?

This is a tricky one…

The organization culture may make someone afraid to voice their opinions in requirement workshops on the way things have been done

More complexity could arise from the team having built all their current tools and, as a result, having a bit of a personal investment in them

One of the more difficult scenarios in which to motivate the change is where the project includes an element of organization redesign that may see some of your key stakeholders redundant or, at least, fighting to retain their roles

The list goes on, but you get the picture and I am sure these are not new to you.

The trick is to pro-actively work to understand the fears and build the findings into your overall transformation approach.

Example

A third party technology supplier had been inappropriately appointed to a piece of process transformation work and predictably could not articulate their scope of work or approach to the delivery. After bouncing around the business for a few weeks it started to become apparent that the key stakeholders were losing interest and hope in the programme. Workshops yielded little and rumours of possible technology operations outsource started to surface. Operations staff started sniping projects and prioritizing their time on other activities. The business was uncertain of scope, future solution plans and the job futures of people and entire teams. Discovering this helped us to get handle on where to look to get things back on track.

A series of client led scoping and approach planning sessions, followed up with focused communications, started to get the groups “back online”. In fact, the business users started driving the direction of the work and raised the bar for the supplier through sheer desire and urgency to get it right. We had removed the uncertainty and fear…and raised the confidence.

There are all sorts of techniques for figuring out what the confidence problems may be, but it always comes down to fear of some sort.

This is not easily overcome. It is generally hard work. If left too late, the task may become mammoth.

Knowing the cause of the fear should influence the shape of your work and allow people to build confidence in the project. You cannot make them confident.

Almost there…

As you have read through this you may have connected with what I am trying to say.

i.e. Data programmes are not (just) about the data. People make the change happen…or not.

To be successful, use clear direction setting and communication to get the people on board by changing APATHY to IMPORTANCE and FEAR into CONFIDENCE

Note: The Change Rulers concept (Confidence and Importance) for determining Readiness to Change is from the theory of Motivational Interviewing. Rollnick and Miller. Contact me for more detail on how to apply this method on a daily basis.

Biography

Will van Zyl is a senior Transformation Manager with over 17 years of experience in designing or leading IT and Business change initiatives. An Architect and peoples person at heart. Will has spent a large portion of his recent career working on process, systems and data related change in the regulatory space. Having studied various technical frameworks and behavioural change models, he applies this learning to drive the right solutions thinking and motivate all team members in the chosen direction.

Will is fascinated by what makes people behave as they do and how this influences the delivered impact of change initiatives.

KDR Recruitment is the home of the best data, technology and analytics jobs. For more tech news and views follow KDR on LinkedIn.

You might also like: