Who’s On First? Playing Together With the Provider Organization – Part 2

This article is the second in a series about clarifying the interactions of the BRM with other roles in the provider organization. In the previous post I provided an example of the way in which one company reached role clarity across intersecting roles.  Here, I explore areas where there is typically contention or confusion about specific roles.

Part 2: BRM Interactions with Specific Roles in the Provider Organization

Meeting the challenge of role clarity is about digging deep to understand where boundaries are and where the most likely failure points exist in the workflow of the provider organization. That said, I have found that we can take this to the extreme where everything is absolute black and white and the boundaries are so hard and fast that the give and take we sometimes need in organizations goes missing.  Don’t be tempted to drive the role clarity models to the extreme!  The client I mentioned in part 1 was very careful to lay out ground rules for the role clarity exercise, including the following:

• We’re not seeking a “pure” model, but a practical one.
• We’re not changing our direction—we’re just clarifying the details.
• Our role clarity work focuses on the future – how we want it to be, not necessarily how it works today.

So what areas of interactions are most contentious when introducing the BRM role? Here are a few where deep dialogue is required.

1.       During Project Mobilization, the BRM interaction with the Architects, BAs, and Project/Program managers gets tricky.

• A healthcare company worked through specifically how architects, BRMs, and Solution Delivery play together based on whether the concept was emerging technology, existing technology or simplifying technology.
• Other questions arise as to who typically creates the Project Request & Capital Expenditure Request (the BRM) and who oversees creation of the Project Charter (often the Solution Delivery Manager or Project Manager) while the BRM contributes to it.
• And don’t forget about Solution Assessment: the BRM often drives it, especially from a business needs perspective, but Solution Delivery and Architecture also have key duties.

2.       Differentiating the Strategic BRM Role when there are Tactical roles of a similar nature.

• A consumer products company implemented both a BRM role and a BIM (Business Integration Manager) role. The former focused on strategic, new value to the business. The latter focused on tactical use to ensure that every last drop of value was being extracted from current systems. As you can imagine, confusion reigned!

3.       BRM and the Strategy & Planning Group

• It is important to differentiate between these two groups. The Strategy & Planning Group often owns the process for strategic planning & portfolio management, but the BRMs are accountable for the strategy and portfolio for their business areas.

4.       Service Issues and Infrastructure & Support

• Who is often the first to hear about a senior executive’s issues with service interruptions or major issues with operations? Yes, the BRM!
• If the BRM role didn’t exist before in your organization, then the Infrastructure & Support folks don’t always realize what they should be doing to keep the BRM in the loop on service interruptions, escalated issues, and meeting SLAs.

Though there are leading practices in how these roles should generally interact, every organization is unique. Some form of role clarity exercise helps people discover and internalize the key interactions that will make or break the BRM role.

So let’s get back to that ‘single point of contact’ phrase.  Maybe we should call it a ‘single point of focus,’ as has been described in the BRM Institute webinars, or ‘primary point of contact,’ as some other organization have used. Or—ponder this—we could recognize, by moving away from those phrases, that the BRM role works in concert with many others to deliver the full value chain of IT to create business value!