It seemed like any other partner event focused on ITIL 4. There was the usual buzz of anticipation as more than 70 delegates filled the conference hall, eager to hear how ITIL 4 would help solve a growing demand to “make IT service management (ITSM) more agile.” At the same time, delegates recognized the need to “demonstrate the relevance of ITSM,” and more particularly ITIL, which is seen as getting in the way of agility! However, it wasn’t just ITIL 4 on the agenda, DevOps was also one of the key event themes.
It all started well. Little did I realize the shock that was to follow…
But it’s not just the shock that I felt at the event that’s important to understand. It’s the shock that many will feel if they fail to recognize and address some of the attitude, behavior, and cultural issues identified during the event.
It’s as simple as ABC!
So, what caused the shock wave? For more than 15 years we have been promoting the ABC of ICT (Attitude, Behavior, Culture) as the number one success or fail factor in IT, giving presentations and workshops around the world.
Now here we are 15 years later. Where ABC is now sometimes perceived as old hat. It’s not shiny or new anymore.
Whereas we in IT like shiny and new. Especially shiny and new stuff we can install or implement.
Does ABC have a sell-by date?
Often at conferences, when I submit a speaking proposal on ABC I’m asked “Haven’t you got something new you can present on, like DevOps? ITIL4? Or artificial intelligence (AI)? We’ve done ABC before… ABC is more than 15 years old!?”
“Hmm,” I think. Einstein was once attributed with saying “Two things are infinite: the universe and human stupidity; and I'm not sure about the universe.” We don’t ignore Einstein just because his ideas were last century thinking. But hey “ABC was 15 years ago… it’s out of date!”
Einstein was once attributed with saying “Two things are infinite: the universe and human stupidity; and I'm not sure about the universe.” We don’t ignore Einstein just because his ideas were last century thinking - @GamingPaul #ITSM Click To Tweet
This was obviously said by somebody who is sure about the universe, or…
Or perhaps ABC is no longer relevant because we’ve solved all the ABC issues? Simple! Right?
Not according to a McKinsey article Mindsets matter in Transformations which states that 70% of transformations fail, adding that “Transformational change requires individuals to behave differently, which means that leaders must address how people think and act in their day-to-day work.”
Let’s put our cards on the table!
Whatever the reason for ABC being perceived as old hat, I blew the dust off the old ABC cards and put a number of them on the table. I used them to provoke and challenge delegates visiting my stand by saying “ITIL 4? DevOps? It doesn’t matter what you adopt you’ll fail because of these.” Pointing to the cards on the table.
I intended it as a joke to stimulate a dialogue.
I was shocked.
The ground fell away from under my feet.
I felt an earthquake.
Why? Because nearly all of the delegates I spoke with at my stand said, “Oh my gosh this is so accurate, so recognizable… where can we get the cards?”!
This is serious!
How come we still have these issues?
For more than 10 years ABC has actually been referenced in ITIL. In “Planning to implement Service Management” and in the toolkit of ITIL Practitioner. (But it seems nobody reads these books because they’re not needed to gain ITIL Expert level certificates!) Both of these books also strongly reference organizational change management (OCM) which is a sorely needed skill to address these ABC issues and a sorely needed skill in these times of rapid and continual change. It seems like too little has been, and is being done, to address ABC or OCM. And this doesn’t just apply to ITIL! Yet, like an earthquake, the damage that ABC can do to the structures and frameworks you’re putting in place to support your organization’s digital transformation can be significant.
But how serious an earthquake? I decided to look up the Richter Scale of earthquake severity and equate this to the magnitude of the potential impact. I decided to score it as a 6.
Effects: Damage to a moderate number of well-built structures… Poorly designed structures receive moderate to severe damage.
What does this mean in ITSM terms? What will be the impact of these ABC issues?
“Damage to a moderate number of well-built structures…”
Even well built (framework centric organizations) will be damaged by the impact of ABC with their digital transformation, such as the challenges of collaboration skills, and customer and value focus which can impact trust and credibility.
Earthquake proof measures won’t take too much effort but are needed. Investments will need to be made!
“Poorly designed structures receive moderate to severe damage…”
Organizations that say things like “We have an ITIL compliant tool, we don’t need processes!” or “We have implemented ITIL” or “My framework is better than your framework” or “We have installed DevOps.” Or those thinking that a certificate equates to behavior change may face resistance, frustration, lack of goal realization, and severe damage. Putting your organization’s digital transformation aims at risk.
Even well built (framework centric orgs) will be damaged by the impact of ABC with their #digitaltransformation, such as the challenges of collaboration skills, & customer & value focus which can impact trust and credibility -… Click To Tweet
Earthquake proof measures are a must and will be expensive and effort-intensive!
Ignore the warnings at your peril… or your business peril!
But ABC is old hat!?
Really? See how many of the issues below YOU still recognize in YOUR organization.
The cards tell a story…
A picture paints a thousand words. These were the ABC cards I showed that caused my shock, and the story I’ve painted…
First, I laid out the cards:
- ITIL (or DevOps) is the objective – not what it is hoped to achieve and
- IT thinks it doesn’t need to understand the business to make a business case.
I related this to my presentation in which zero hands went up when I asked who knew the definition of a service. (VOCR – please see this blog, “ITIL 4 dummies,” to see if that is relevant).
...So, we don’t know what value we’re HOPING ITIL will deliver
We then assign a team of “ITIL experts,” who don’t know what value we’re hoping to achieve, and who have never read “Planning to implement Service Management” or the “ITIL Practitioner” books, to design some ITIL solutions. Often resulting in books of bureaucratic processes and procedures, ending up with the behavior cards:
- Throwing solutions over the wall and hoping people will use them. The behavior card this stimulates is that people are then
- Saying “Yes,” but thinking “No” as they were not engaged in designing the new ways of working.
…Our implementation project is deemed a success – people have said “yes” to the new ways of working
The implementation project is disbanded. Well done everyone!
But within a certain amount of time we see the behavior card:
- Never mind about following procedures, just do what we normally do. The pressure from the project organization has gone. Procedures seem to be slowing things down, getting in the way, taking too much time. It’s unclear what benefits they deliver, procedures are not seen as fit-for-use. People either circumvent them or go back to the old ways of doing things.
...But, no need to worry as we’ve designed RACI models and have a process manager role to ensure that people follow the processes
However, we then see the card:
- Process managers without any authority to correct these behaviors. They’re often not empowered with authority, behavioral skills, or leadership backing.
...By now we see the business – who were also not engaged in defining the business case and not involved in agreeing to a change to their behaviors – are getting frustrated with the bureaucracy of the processes and procedure which are not fit-for-purpose
So, we now see the cards:
- Everything has the highest priority according to the business, to get around the issue of everything taking too long and getting stuck in queues. This is coupled with…
- Too little business involvement in requirements specification and testing. With more and more features being rolled out even quicker as organizations start “implementing DevOps,” this behavior can cause technical debt to accumulate equally as quickly.
…The process manager then escalates to senior management, who are convinced they are committed to process-based working and the framework initiative as they were at the kick-off explaining how important the processes are
However, they often display the cards:
- No management commitment because they’re unsure of what’s expected from them, or managers who themselves circumvent the processes displaying the behavior on the card
- Don’t do as I do, do as I say because they’re being put under senior business pressure by business leaders displaying the behavior on the card
- Demand and give, I demand and you give in because the business is frustrated by not getting the value that wasn’t defined or agreed in the beginning to support the strategy that wasn’t defined or communicated.
Because, (as I tested in my presentation – less than 5% were doing formal continual improvement top-down and end-to-end) most organizations display the behavior on the card”:
- Plan, do, stop… no real continual improvement culture.
...This “behavioral debt” mounts causing end-to-end frustration
The business blames IT, IT blames the business, Dev blames Ops, Ops blames Dev. What we see is the card:
- Blame culture, then they all rally forces and blame ITIL (or framework X) and wait for the latest updated version of the framework or a promised automation tool that will solve all the issues.
We then repeat these behaviors. And have done for the last 15 years!
Only now with all this digital transformation and the importance of digital capabilities is the impact of this ABC earthquake being felt more.
Very little seems to have changed in 15 years. Obviously, your ABC doesn’t work?
You’re right, let’s blame ABC and the cards… or let us explore why ABC isn’t changing, and what we as an industry can do to make ourselves more ABC earthquake resistant, or resilient. Here are some thoughts.
But also, please send me your ideas, or share approaches (to tackling these issues) that you tried that worked!
Because the principal theme of the event was “ITIL 4: Crossroads” I’ve limited my comments to ITIL. We are at a crossroads. We can either simply carry on along the road we currently follow with regard to ABC or we can take a new road:
- Perhaps we need to reference ‘Planning to Implement Service Management’ and “ITIL Practitioner” in every ITIL course. Neither of these publications have been widely read. (As mentioned earlier, at this event nobody had read them apart from trainers and consultants).
- Perhaps dealing with the ABC issues above needs to be included as exercises in higher-level ITIL courses? Let people share practical insights and experiences of what they tried and what worked.
- Perhaps further develop the Organizational Behavior Management (OBM) concepts into the guidance, courseware, and examinations.
- Perhaps some sort of ABC or OCM (or OBM) training needs to be mandatory to become an ITIL Expert? (Or whatever the next equivalent level in ITIL 4 is). Preferably linked to some sort of case or practical assignment (and these cases could be bundled into new guidance).
- Perhaps we need to explore how coaching, mentoring, and the transfer of these ABC or OCM/OBM skills can be facilitated following ITIL training? Very often, just like the ITIL theory itself, people are left to translate theory into practice by themselves and then struggle.
- Perhaps we can just ignore it and hope it will go away.
I don’t have the answer, but it’s shocking to still see that many, perhaps even the majority of, organizations continue to struggle with ABC and that we as an industry struggle to change this.
At the event, it was proudly declared that Belgium is famous for chocolates, beer, waffles, Hercule Poirot (and for me Tin-Tin), and DevOps (a reference to the original DevOps Days from 2009 in Ghent). Perhaps now, as an extension to exporting DevOps, the Belgian experience can stimulate the renaissance of ABC.
But then again, a top-scoring ABC card chosen globally is Not my responsibility!
Please leave me your thoughts, opinions, experiences, and advice in the comments. Thank you.