I was with a client last week. Well not the actual client, but one of the client’s management team. He didn’t see the point of Relationship Management, didn’t understand the function and how it could enable him and his team, and was quite vocal about it to boot. Read Rude.
‘Good God Man’, I thought, ‘don’t you know you are from the dark ages?’ Those halcyon days where SaaS and pay-per-byte style infrastructures were a just a Gartner hype curve are long gone. Meow!
His ears must have been burning at about 7pm every night, which is when I would bore my husband rigid with anecdotes of him just not getting what I did.
Then the penny dropped. And ker-klanged very loudly.
Poor lamb was getting it large from one of his senior business stakeholders. She had been particularly difficult, and had a reputation for being so with his team. My client just couldn’t understand it, and launched into every single unfair moment throughout their entire working history.
The reason for her disruptive behaviour was simple. He had been calling her Caroline when her name was Carolyn. She hated it, and although lovely, she was very clear about her dislike. Each time he got it wrong, she made him wrong about something he was doing. After much urging, he finally picked up the phone and apologised for it. It worked a treat.
My client did have the grace to reveal he finally got the merits of relationship building and generally engaging with people. But he isn’t alone in his opinion of Business Relationship Management. Or in ITIL land the BRM.
The concept of Relationship Management is much like the traditional account manager. Account management in other walks of business life is a fully accepted discipline and requirement for business continuity and growth. So why do some technologists have such a hard time accepting the function as a beneficial one to them and their organisation?
I suspect because Relationship Managers have a hard time really articulating what it is they do, and just what they are accountable for. Because the plain truth is that what they do changes with every situation, and they are really accountable for a great big fat zero of the technology service delivery piece. Which is really where it’s at for a technology department.
Simply the Relationship Manager is the translating department for the technologists. They are the ones who are singing the praises of the techies, explaining why they said ‘No’ and that they really mean ‘Yes…However…’. And generally retaining a good working relationship with the business from top level strategy to day-to-day operations. So that when the inevitable mis-communication happens there is an established route to triage the incident.
The best Relationship Managers are the ones that know the inner machinations of their business clients and are probably not specialist technologists. Rather, they are generalists. The primary goal for any BRM is not to do the do, but to make the technologists job easier and deliver value back to the business. Most often by helping both be heard, understood and have a voice at each others table.
Many times the business just don’t know that they need to invite the technology department to their new project meeting. In my experience they fall into four categories.
1. Why would I need to invite Technology to my project kick off.
2. I know I need to invite Technology but I can’t articulate why.
3. Doh! I can articulate why, I just forgot to invite Technology this time.
4. And the best one, It’s got a plug on it, we need to invite someone from Technology!
Sadly in my experience there are very few business folk who are in that last category.
The BRM will make sure the technologists have a seat at the table, because they know what’s coming up. What the priority is for the business, and where it should be prioritised in the wider Tech portfolio. Not only that, they will have made sure that any governance issues, like fiscal, SOX, or sustainability concerns etc have already been worked through.
A good BRM will also have already canvassed the wider market, or the existing service catalogue, to see if there is an existing solution that can meet most of the requirements. Or as an interim solution to take the heat away from the heads down, hard at work, budget thin, Techs.
Further, they anticipate road-blocks, tango around issues so the technologists don’t have to hit them, and triage incidents, so everyone feels loved, understood and prioritised. Additionally, and this is where any technology department can really demonstrate the return on investment in the BRM function, they guide the business to deliver back to the technology department at key decision gateways what is expected of them during a project lifecycle. This is the bit that ensures there are no costly change requests, and the technologists continue to meet business expectation.
As technology continues to drive to the front and centre of enabling most businesses and compounded by technologists speaking in their own tongue, it is now more confusing than ever for the business to understand what they need and who to go to for it.
That would be the BRM in the first instance. And it’s this piece that the Technologists often don’t like. Citing interference and not being service savvy enough.
It’s an understandable response. And too many cooks can spoil the broth. However having a chef who coordinates the kitchen ensures the customer gets the meal they ordered, and don’t have to send it back because it wasn’t what they expected. Costing the kitchen dearly.
So despite the above account of the BRM, the value they really deliver is not measurable or easily defined in a job description. Just like our chef analogy, perhaps because they are dealing with different ingredients everyday, what they bring to the secret sauce, might be remain indefinable.
But…you’ll sure as hell notice a difference if that secret ingredient wasn’t included in the mix.