I received a question from a reader about the role of a Business Relationship Manager (BRM). I decided to bring the question and my response to this blog.
His question, and the context for it was:
When the BRM role was introduced at our organization, the Head of IT did not convey a clear vision or direction for how the new role would fit into the existing IT organization structure. We did not have clarity on how to deal with the issues that are brought to surface by the BRM, or how the BRM should work with Business Analysts, Project Managers and other key roles. Please share practical examples of how a typical BRM should operate on a day-to-day basis. What impact should a BRM expect to have made in 3, 6, 12 months and who should see/feel the impact- is it for the IT department and its behavior or how business begins to engage with BRM?”
His email went on to say:
I feel that a lack of clarity and appropriate structure and governance of how a BRM is to operate within an existing IT organizational structure will result in a muddle and confusion for IT colleagues and ultimately fractured relations with the business/customers.”
New Organizational Roles Disrupt the Status Quo
My first observation is that you could substitute any major new role for the specific BRM issue above and have the same potential for organizational confusion. I’ve seen this with the introduction of Business and IT architects, Program Managers, Service Managers, Product Managers, and so on. Sometimes the new role gets introduced with limited clarity as to its purpose – rather it feels like “the thing to do”. Often, the catalyst for the new role is something like:
- Someone in an influential position has read about or came from an organization where this role reputedly worked miracles – “We should try this here!”
- There are recurring pain points (e.g., a ‘noisy’ or dissatisfied business customer) – “Let’s put Jill into a role to face off with this customer and see if she can reduce the noise!”
- Something doesn’t feel right about the current organization structure – “Let’s introduce a new role and see if that improves things!” This is akin to the proverbial moving of deck chairs aboard the Titanic!
Implications of New Roles
Whatever the catalyst, there are a couple of important contextual characteristics to note here:
- Lack of clarity about the rationale for the new role – what problem(s) are we trying to solve and how will the new role solve them?
- Unclear expectations about what the outcomes of the new role should be (for example, picking up my readers question, “impact to have made in 3, 6, 12 months and who should see/feel the impact?”)
- Failure to fully consider changes that must be made to the IT operating model. Presumably, the new role is taking over some Responsibility and/or Accountability from other roles, and that other roles need to be Consulted or Informed by the new role. Note, the initials I’ve capitalized – RACI – the (hopefully) familiar tool for clarifying and assigning roles and responsibilities.
Unclear New Role + Unclear IT Operating Model = Total Confusion!
So, what we have here is a new role being introduced with a lack of clarity as to why, or how, into an organization that already has an unclear Operating Model. In the past, we somehow managed to ‘get by’ with the unclear Operating Model because:
- We have bright, hard-working people who work at ‘smoothing out the bumps’ caused by lack of Operating Model clarity.
- They’ve been at this for a while, so unless there’s an unusual disruption to the status quo (such as a new role being introduced), we manage to limp along ok.
Answering the Tough Questions
My reader asked for “practical examples of how a typical BRM should operate on a day-to-day basis.” With due respect to my reader, it’s the wrong question. You can’t solve the problem by defining how a BRM operates. The real question is, “How should the IT organization operate on a day-to-day basis with the introduction of this new role (the BRM)?” i.e., “What is our next-state IT Operating Model?” I’ve posted many times on the components of an IT operating model, how to define one, how to implement one, and so on. Enter IT Operating Model in the search box at the top – you’ll get about 40 posts on this topic representing 30 years of IT management consulting wisdom shared over 5 years of blogging!
My reader also asked, “What impact should a BRM expect to have made in 3, 6, 12 months and who should see/feel the impact- is it for the IT department and its behavior or how business begins to engage with BRM?” The first part of this is totally dependent upon the organizational context – and especially on business and IT maturity. But it is the right question, and the BRM should be working with the IT leadership team defining the hoped-for impact and how to track it.
It is also important to consider possible unintended consequences of a new role’s introduction. For example, I worked with a global multi-billion dollar company who carefully introduced the BRM role. They picked their “best and brightest” to fill the BRM position, and we developed a robust training program and toolkit for the BRMs. Unfortunately, they were so effective at surfacing, stimulating and shaping business demand for IT, that they quickly exceeded supply capacity. The BRM’s found themselves saying “no” to the same business executives they’d worked with to surface that demand. If the expression “getting egg on your face” has any meaning, this was getting an entire chicken farm all over yourself, with lashings of excreted waste!
To the second part – who should see/feel the impact – I’d say that if there’s no positive impact to the business customer, then why bother with the BRM (or any new) role? And inevitably, the IT department will feel impact – disruption initially, but over time, greater efficiency (“doing things right”) and effectiveness (“doing the right things”).
So, What To Do?
Again, this is a topic I’ve visited many times over the years on this blog – click on Organizational Change Management on the tag cloud to the right of this post for a collection of posts that more or less deal with this issue.
There’s no easy formula here – it’s about motivating change. This is highly contingent on organizational context, relationships, and other factors specific to a given environment, but there are some common elements:
- Find ways to surface the pain of the status quo to those with the organizational power and authority to initiate the change – what the quality movement calls “the cost of quality”. Use the process of surfacing this pain to build a guiding coalition of stakeholders who want and will benefit from the change.
- Find ways to clarify and sharpen the vision of the future state – the remedy to the pain of the status quo. How will the introduction of a BRM role improve things? What will this look like – after 3, 6, 12 months? What will the implications be for our IT operating model? Again, leverage the coalition – get their input and ensure their buy-in to the future state. Help them understand what they must do to help the change happen and the future state become real.
- Find ways to clarify the transition from the status quo to the future state – what’s the transition plan? Should we start with one BRM and conduct a pilot? Should we pull together an “IT Operating Model Improvement Team” to do a fast cycle (no more than 60 days) analysis and provide recommendations to the IT leadership team?
Image “One In One” is used with permission, courtesy of its artist, Nad Wolinska.