Far too often the first question when changes go bad is “did it go to CAB”. The question is not only the wrong one, but reveals some poor thinking behind the question.
Did it go to CAB?
In a healthy organization, proposed changes are reviewed prior to implementation, often by a CAB. But when something goes wrong, how is that even relevant? What difference does it make if the change was reviewed by CAB or not?
On the surface, it’s an innocent question – trying to determine if the change in question is authorized or not. But in reality, it’s most likely a blame-oriented question. Do i really care if the plumbing was approved by the foreman when there’s water pouring through the ceiling from the bathroom remodel upstairs?
Look, no matter how you slice it, the impact to the business is the same either way. And that’s just it – the question isn’t intended to accelerate restoration or drive improvement. it’s intended to place blame.
CAB approved it!
The first cousin to ‘did it go to CAB’ is ‘it was approved by CAB’. This is a subtle transference of blame. It wasn’t my fault, I’m just the change requestor or change implementer, what do I know? CAB – they’re the smart, responsible ones, right?
Such is the undercurrent in the typical CAB. A bit of a cat-and-mouse game – the kind of coaching your lawyer gives when you are called to testify in court – answer only what’s asked. Don’t offer additional information. If they don’t ask exactly the right questions, then it’s their fault when something was missed.
It’s organizational politics at it’s worst. RFCs are filled out with bare minimum of information (following ‘legal council’ advice), so they can’t be held accountable for much. CABs ask a lot of probing questions that border of hostile cross examination.
Why?
Well, to defend against the inevitable blame storming, of course.
Little wonder, then, that staff would rather have an elective root canal than follow the Change Management process or heaven forbid attend CAB!
Blame Management
Let’s talk about Blame Management – the well known, but seldom documented other ITSM process?
Sadly, it’s not some April Fools joke, either. Blame Management is alive and well in many organizations, and traditional IT Change Management is prime target for it.
No one wants to look bad. That’s career limiting, to say the least. Predictable, I suppose, but the problem is that as a service provider, our customers suffer when we’re not unified in our effort to provide excellent service.
If IT were an automobile, then Blame Management is driving down the freeway riding the brake. A (literal) drag that kills speed, fuel economy, creates heat and needless wear and tear. It’s the kind of thing that will eventually cause us to be traded in for a newer, leaner, higher-performing model. (DevOps, anyone?)
Of course, I realize it’s not that simple. But, while attitudes and actions are individual, culture is the behaviors that are accepted within a group. If the IT culture in your organization is steeped in Blame Management, then those who would change it are at risk. Blame thrives in low trust cultures, so it stands to reason that killing it requires building trust, ownership and accountability. It’s bit of a cold war. Those who would put the customer in front of self preservation (politics) become vulnerable. With very real consequences. Who’s willing to put down their arms first?
Enter leadership.
Leadership has the opportunity and responsibility to influence the behaviors that are accepted. By being strategic and intentional about acceptable behaviors, leadership can have a huge impact on overcoming Blame Management culture.
Overcoming Blame Management
In How Good Change Management can Still Sink Ships I talked about how, literally, IT and the business are in the same ship. (The article talked about the Titanic crew’s response to the iceberg, and how, in the end, they all ended up on a sinking ship.) IT must rise above its legacy of silos and tribalism and focus on The Goal – achieving results for the business.
Overcoming blame:
- Develop metrics that measure achievement of business outcomes. For instance, avoid metrics that compare numbers of failed changes from team to team (i.e. network vs. applications). This is simply applying the old saying ‘what gets measured gets done’. If you’re measuring who has the least failed changes, teams will naturally try to minimize what’s counted against them, and maximize what counts against their competitors.
- Develop a blameless culture. Umer Manseer talks about the long-term value of Examining Failure Without Blame. Without fear, “a mistake can be a great opportunity to learn…”, which serves to improve overall quality over time. Blame will do just the opposite. If people are afraid they will be blamed when things go wrong, you can be sure they won’t be forthcoming with information that’s crucial to improvement.
- De-escalate Change Management, especially CAB meetings. Set standards for RFC documentation, and recognize good examples. Engage senior staff and unit managers to anticipate questions Change Management will want to know, and ensure RFCs include the information. Encourage CAB members to review RFCs before meetings, and raise issues directly with the requestor and change manager outside CAB. Avoid ‘witness stand’ cross examinations at all costs.
- Kill the CAB. Reduce the number of changes coming to CAB. You’ll find some practical suggestions in my Killing CAB series. Long story short – if you can effectively facilitate business-required changes while managing risk and minimizing negative business impact without taking each change to CAB – do it.
- Get staff engaged in shaping your Change Management capability, especially through incremental, continual improvement. Rather than dictating what ‘they’ must do from on high, trust that staff, when empowered and engaged, will come up with great ideas for improving Change Management. It requires a lot of trust and vulnerability, but the change in culture is well worth the risk.
Change Management is about facilitating customer-required outcomes while managing risk and minimizing negative impact. Surprisingly, Blame Management cares very little about these things, and instead focuses primarily on making sure ‘someone else’ can be blamed if and when anything goes wrong.
To be clear: organizations concerned with ‘blame’ are internally focused, and their customers suffer. Trade in immanent. Organizations who are focused on achieving customer outcomes are valued by their customers and become trusted partners.
What’s it going to be – change or blame?
One comment on „IT Change Management or Blame Management”