I warmed to this guy from the start. He was a technical linchpin in the organisation, and everyone knew it. He had a wicked sense of humour, his knowledge and work ethic were first class and perhaps more importantly, he was the glue on the floor. If things went bad, there was a gravitational force that centred on his desk. More than once, he would be working away while a half dozen middle managers stood behind him. Most of us know someone like him.
But he had a problem. He was tagged as one of the staff that ‘didn’t get it’.
The organisation was going through a significant initiative that would fundamentally change the way his team delivered their service. But, lets just say not all of the team were fans of the change. And naturally, some were tagged as problem children trying to hold the company to ransom. Interestingly, management knew that if they could turn this guy, the rest of the team would probably follow.
The suspicion was that the team perceived the change as a threat to their power base. And sure, there were elements of this, but it wasn’t that simple.
What looked like a solid and sensible strategy to senior management looking ‘down’ from their vantage point, looked nothing like that from within the team that were sitting In the bowels of the operation looking ‘up’ through the prism of poorly-executed strategies, budget cuts and incongruous decision making. Remember, perception is reality.
Let’s be clear though. The change initiative was sound and absolutely necessary, in fact many other organisations had gone through the same change successfully. The senior management team were experienced and competent. They communicated the need for change well, they understood the financial, process and structural implications and put the necessary actions in place. So what was going wrong?
It’s all about perspective.
It can be very difficult to become enthusiastic about the ‘plan going forward’ when you’ve got a bucket in your hand and all you can do is bail.
Human nature being what it is, we all tend to gloss over the elements of a plan that are difficult to resolve; head in the sand style. We may use phrases like “we’ll work through that”, or “it’s not going to be derailed by special interest groups”, but what we’re really saying is, “I don’t know what to do about that, but I’m not stopping”. Fair enough, those who wait for every single detail to be resolved will probably never get started.
However, many change plans deal with the mechanics of the change (influencers and blocker type heat maps, communication plan, process change, roles and responsibilities etc.) without actually attacking the operational issues that can derail the whole initiative. And there’s no-one better to understand those operational issues than the people on the ground.
Legacy systems are notorious for having a very few specialists within the organisation that actually understand how these things tick. How do you move systems like that to the cloud? If we assume there’s a reasonable case that says it belongs in the cloud (many don’t), then one activity that is often undertaken is automating the build process that is probably in the heads of those same specialists. Ok, so we sit our faithful engineers and developers down and automate, right? Well, we already know they’re a bottleneck as their day is consumed with just keeping the lights on.
And that is the elephant in the room. They don’t have time and no-one else can do it.
There is a way to avoid all of this without overburdening your change program.
Identifying risks and issues early is key. All project management methods include risk, issues and change management as a staple. But we’re often ineffective in the way we mitigate.
How often are we aware that a skills shortage or a concentration of knowledge is going to rear its head and cause the project real issues? Typically, management are fully aware there is a problem, but nothing is done about it until the issue bites. It’s confounding.
In my experience, project budgets do not allow for skills transfer or backfill resources because budgets are drawn up before underlying operational issues are fully explored and appreciated.
And now we’re down to what I believe is often the crux of the problem. Asking the right people the right questions at the right time.
Our hero in this story, could have saved the project quite a bit of pain had his opinion been sought while the project was being scoped. He would have told the project leads (probably quite bluntly), that they’re going to fall into a pothole and before they embark on this project they need to up-skill. He could have set them on the right path. But no-one asked him.
Identifying the people in the organisation that understand the task you’re embarking on, or at least understand the dangers involved is absolutely key to the projects success. And it has a double benefit.
We get deep insight into aspects of the change we may be glossing over, and we turn sceptics into supporters.
This article represents an amalgamation of experiences and observations during numerous engagements. If you would like to discuss your experiences and challenges with The Advisory Hub please call or email for a confidential chat.