I think of business relationship management, agile product management, and service management as a three-legged stool. You know what happens when a stool is not well balanced. It’s not pretty!
In this article, I take a look at each of these viewpoints—BRM, ITSM, and product management—and how they relate to and support the other perspectives.
First, let’s start with how we arrived at this comparison.
How we got here…
In the 20 or so years I have been working in or around IT service management (ITSM), there have been many changes, lots of new ideas and philosophies. We have seen multiple frameworks come and go and many new flavours of the month pass in and out of fashion.
Service management as a discipline has outlived them all.
What’s different now, in 2021? Agile has been part of the landscape for many years, and business relationship management (BRM) became part of our vocabulary more than a decade ago. So, why should they now start being of interest, or concern, to the service management practitioner? If we ignore them for long enough, surely they will, like all the others, just fade into oblivion…
We are living in a complex world. Our business partners expect things to work. When they want new features or solutions, they want them now, not in two years’ time after an expensive waterfall project has come to fruition.
Success in today’s world looks very different, as I’ve previously written. ITSM is no longer the only pathway into the IT function, and the service desk as the “single point of contact” for all things IT has ended.
We need to find a better way of providing the level of care that our business partners expect.
This is a balancing act. We need to take care that each leg is the right length and gives the appropriate level of support in what can be a confusing landscape of competing interests, where we have:
- Service management saying, “We are the single point of contact.”
- The product owners and managers saying, “We are the voice of the customer.”
- Business relationship management claiming they’re the “single point of focus” for business partners.
Surely, they can’t all be right? Or can they?
The role of IT service management
Everyone reading this knows how important effective service management is. But is it still the single point of contact for the entire IT arm of the organisation? I am going to put my hand up and say “No, it is not.”
ITSM is where you turn when…
- Existing services are not functioning correctly.
- Changes are needed to something that is already in production.
- You need access to a service that is in use in the organisation.
Service management keeps the lights on and ensures that business as usual (BAU) keeps happening. If things break, service management is responsible for:
- Getting services back up and running.
- Stopping services from breaking in the first place.
ITSM is the single point of contact for anything to do with existing capabilities.=
The role of business relationship management
In my opinion, the business relationship manager has the perfect job. (I might be biased here as that is now the role I have.) BRMs are not actually responsible for doing anything! That’s not quite true, of course—the BRM practice has many roles:
- Getting out and talking to business partners.
- Discovering the outcomes partners need (or want) to achieve.
- Pulling the right people together to have technology help the organisation meet these outcomes.
The BRM enables the IT organisation to converge with the rest of the organisation, building a productive strategic partnership between these functions. They are the orchestrator, the connector, the facilitator. They help to define the “what”—what do we need to achieve to be successful?
They then connect to the teams that can articulate and build the “how”.
The role of product management
So now we come to our product managers and product owners. This is where we find the “how”. This is where the creative solutions are uncovered to provide the answer to the “what” statements the BRM team have presented. The product teams are the magic in the middle. They:
- Take the ideas and value plans from the BRM team.
- Build a solution around those plans.
- Deliver the end product to ITSM, where it is introduced to the business and the value is realised.
(Learn more about product managers & product owners.)
A well-balanced act, hopefully
Back to our three-legged stool. When the stool’s legs are well balanced, life is good, and nobody topples over.
BRM uncovers ideas, bringing them to the product teams to devise and build solutions, who in turn deliver new capability to the service management team, who supports the organisation to use and extract the value from the IT investment.
But what happens when the stool’s legs are not well balanced? Let’s play it out.
When service management is sub-optimal…
If we have less than optimal service management practices, many areas will not function as they should.
BRMs, who have the ear of your business partners, will inevitably find themselves plugging gaps and making up for processes that are lacking. This dilutes the value of a strategic BRM practice and forces the BRM to work at a tactical level, limiting their ability to seek out opportunities for innovation that can make a difference to the business on a much deeper level.
The BRMs will find themselves becoming a VIP service desk, expected to fix broken tech systems for the senior business partners they are engaging with. This not only limits the strategic impact BRM can have, it also impacts their ability to be a trusted advisor and strategic partner: the BRM has unwittingly come to be viewed as the person who can get IT problems fixed.
Your product teams will also suffer when IT service management is less than optimal. Product owners need service management to feed items into their backlog for service improvement:
- If the ITSM continual improvement practice is broken or inefficient, backlogged items will either not reach the product teams or not be appropriately prioritised or documented.
- Poor incident, problem, and change processes will cause product teams to work on the wrong things, spending too much or too little effort on BAU tasks.
I am sure I am not the only one who has heard comments along the lines of “We are going agile, so we don’t need service management anymore.” WRONG. Instead, what you need is:
- The right sort of service management, with practices and processes that have been adopted and adapted to fit with your new ways of working.
- Strong relationships and trust between product teams and service management practices.
In an agile environment, service management will not look like it did 20 years ago. Life has moved on.
To be honest, the most important part of service management has not changed, and it never will—communicate! Talk to people, inside out outside of your team or function. The more you understand about your business and the other teams that help to deliver the IT capability that makes it tick, the better off you will be.
Service management remains a critical enabler for any business, but it is not the only player. Ensure that your practices are supporting both the business and the other business enablers within the IT function—ensure you are an effective cog in the wheel.
When project management isn’t ideal…
Now let’s look at our product teams. What happens to the other legs of our stool when this part of the IT function is less than optimal?
Firstly, let’s get one misconception out of the way: Agile does not mean unplanned or undisciplined.
Life happens. Unplanned work will need to be done. But this must be kept to a minimum. A good product team will know just what it can achieve in a program increment. The planning around this will give business partners a level of comfort, understanding two things:
- What they will get
- When they will get it
That’s the picture I want to see. But what impacts are we going to see if our product construct is not working the way it should?
Your business relationship managers love certainty. They like to be able to go out to their business partners and say, “The feature you are waiting for will be completed in PI 8, so we can expect to see it in production on this date.” What they don’t like is letting people down! Trust is too easily broken.
In many organisations, the IT function has a legacy of…
- Letting the business down
- Not delivering on time
- Not providing a robust IT infrastructure that enables the organisation to succeed
The BRM is tasked with converging the IT function with the business. Every time a delivery is delayed or does not perform as expected, that convergence becomes harder and harder to achieve. Why should the business trust us with their strategy if we can’t deliver on our promises? The BRM is the holder of those broken promises. It is not a nice message to have to deliver, and harder still if you have to deliver it multiple times.
Again, the key here is communication. We know that dates slip, things happen, and sometimes you need to delay delivery. If this is clearly communicated—as soon as a problem is seen—the message is easier (and less painful) to convey.
That’s all about getting stuff out, though. What about getting ideas into the product owner’s pipeline? Do you have a clear process for accepting items into your backlog? If a BRM gives a product team an idea, do they know what will happen next?
The best ideas for capability uplift or new capabilities are pointless if nobody knows what to do with them once they are defined.
An effective, strategic BRM will be uncovering opportunities to provide business value all the time. The product teams need to ensure that they have a gateway and a clearly defined process for bringing these in to their queues. If that does not exist, we are left with a culture of shoulder tapping to get work done, causing more issues for product teams who are being asked to deal with increasing levels of unplanned work.
Don’t let this happen. Instead, you must:
- Define your processes.
- Articulate them.
- Make sure the rest of the organisation understands and follows them!
Now, how does the ITSM function suffer when product teams falter?
Where BRM needs improved or new capabilities, ITSM needs the product teams to devote adequate time to:
- Keeping the lights on
- Maintaining BAU functionality
When incidents and problems are escalated to product teams, we need to be certain that the needs of our business partners are understood and that their expectations are being met. It is a matter of trust.
Product teams need to:
- Respect the prioritised tasks that have been assigned to them and deal with them appropriately.
- Have planned for an adequate amount of time to deal with BAU work. If they have not, then either current or new functionality is going to suffer as a result.
Understand your own IT environment and how fragile your systems are. One size does not fit all. Different organisations will need to devote different percentages of time to keeping the lights on, so we need to plan for our own unique business environments—no industry average formulas will work!
What about new products coming into production? Do we deal well with those, do we communicate clearly with our service desk teams, change teams, and other ITSM functions? Or do we just throw things over the fence and hope for the best?
To provide the appropriate level of support to business partners who will be using new services, the product team must include service management. A good product team will ensure the ITSM practices that support new products have a clear understanding of:
- What is going to be delivered
- Who it will be delivered to
- What they need to know about the new product or feature
The best IT services in the world will not provide the expected business value if we do not know how to support them. (Did somebody say communicate?)
When BRMs isn’t strategic…
The last leg of the stool we will look at today is our business relationship managers.
Now, in my part of the world, we are only just starting to understand the value that a BRM team can deliver to the organisation. So, for some of you, the full value of the BRM practice is well understood. For others, you may not fully understand the concept of the BRM as a strategic partner.
What happens to our product teams when BRM is not functioning at the strategic partnership level?
BRM is a conduit into the IT function that:
- Brings in value-producing ideas from the organisation
- Looks at these ideas at a strategic level
If the BRM function is not working at the right level, the full value of new ideas will not be realised.
For example, let’s say one business partner identifies a potential business improvement from automating a part of their daily work. A strategic-thinking BRM will look at the idea at an organisational level to see if other parts of the business could benefit from the same or similar capability. Then, the BRM can create a value plan that fully articulates the potential value of a new idea.
When a BRM does not think this way, ideas that are not fully explored at the organisational level will come to the product team. This will cause one of two things to happen:
- The ideas will be discarded as not providing sufficient business value.
- The product teams working in a piecemeal manner. When one part of the organisation sees a new feature delivered to another, they will seek to have the same capability developed for their own business unit, causing additional work, waste, and a decrease in the value of the work being done by product teams.
A well-developed and strategic BRM practice ensures that ideas that reach the product teams have been fully explored and the total business value has been defined.
What about service management—how does the BRM leg of the stool support the work of the ITSM practices?
As the glue that brings the business and technology together cohesively, the BRM will be meeting with senior business partners throughout the organisation. Without a BRM function, many opportunities for improvement may be missed. That’s because BRM has conversations that ITSM doesn’t get to have. Business partners talk to ITSM only when:
- Things are broken.
- They need something.
Compare that to the BRM, who is out there all the time, hearing ideas that can help to improve the way ITSM supports its business units.
The BRM function aims to converge the strategies of the IT function with the strategy of the wider organisation. There should not be an IT strategy that supports the business strategy—there should simply be an organisational strategy. The BRM aims to build a web of trusted relationships, connecting the dots between the business and IT functions.
Communication is the #1 tool
I am hoping that you can see what the main tool that will help us to level the legs of the stool is—communication!
We all need to talk to each other and to understand that we are part of the same team. We are all here to enable to organisation we are supporting to succeed. We all share the same goals:
- To provide business value
- To enable outcomes
- To delight our business partners
We need to be forward thinking. We must understand the goals and strategies of our business and remember that we are not here to play with technology: we are here to meet the outcomes of the business we support, whatever that may be.
Of course, this stool has many more legs that support it. But, when we get these three legs in balance, good things will happen!
