BRM: Is there a role in project delivery?
Question: What should the BRM’s role be after an IT project has been initiated and during the lifecycle of that project?
Like many questions, the answer to the role that a BRM takes in the delivery of a project does depend.
Without an understanding of the purpose of the role within the wider organisation then it will be almost impossible to come to a satisfactory answer. I’ve never been a fan of a RACI (Responsible, Accountable, Consulted and Informed) model for showing who should do what for the simple reason that it seems to create blame rather than ownership culture.
One of my rules for life is to keep small toes, that way no-one can stand on them. I think this is helpful for the BRM in working through what role they are going to play. Being clear about what it is you do, the purpose of the role and the benefits of this is a great starting point. Sometimes it is better to leave others to have the fight about who is doing what.
Another thing that I think it is important to be clear about is that the BRM role is not a delivery one.
If you’re finding yourself picking up delivery tasks then ask is that because of a failing on behalf of the provider domain, or is it because you secretly like being the hero and fixing the crisis? Both are bad places but the way you deal with them will be different.
Something else that I’d raise before moving to look at what the role might be is that you should also be questioning if it is right to be delivering projects or should the organisation move to delivering products. Depending on the nature of the business it may be easier to spot what those products are, but in my experience, you can go a long way to changing the silo culture by recognising that you deliver products (services and capabilities may be easier terms) and the focus should be on the lifecycle of those.
There is a lot to be said for funding product teams rather than specific products. That is another topic in its own right.
The BRM and Projects
Working on the basis that the BRM sits between the provider (IT/technology/Digital function) and the business partner (customer/”the business”) then the BRM can be focused on enabling a successful outcome.
Ultimately the sponsor is accountable for realising the value of the investment that they may in a project. The role of the BRM along the way is “helping it to happen.”
That begins by spotting the right opportunities to invest in at the outset and shaping that request both with other areas of the business but also with the provider domain so that it is set up with the best possible chance of success. If you have a choice between two projects and one needs capabilities that you don’t have access to then it should be a factor in the choice you make. It isn’t that you don’t pursue it but you do so in a different way.
The next area that the BRM plays a role in is in the specification and expression of what needs to be achieved.
Being able to specify what the outcome is rather than what people want to be done is a key skill for the BRM. Interestingly, the UK Government’s Digital Marketplace has a procurement route called the “Digital Outcomes Specialist” (DOS) framework. If you take a look or ask any supplier bidding for work through that how often they see a customer specify an outcome you’ll understand the point I’m making.
As you develop the definition of the outcome then the BRM plays a role in translating the business perspective to the provider domain. We should be moving beyond the point where we’re talking too different languages between IT and “the business” but there is often a misalignment around understanding why something is important or how it underpins the organisation's strategy.
That insight can be a huge help to the provider in managing the portfolio of delivery they commit to.
If that is the work leading up to the project being started then the BRM is often playing the role of the defender for the provider domain. They don’t speak on their behalf or have to make excuses but they are ensuring that the project is set up for success, that it is clear what is needed and that it is the best investment for the organisation.
Beyond this point, as the project moves to delivery then the BRM switches sides and starts to become the defender of the business partner. They are still facilitating and ensuring that the right things happen but they do it with a bias towards the business partners interest. The BRM has the insight and understanding to ensure that the provider (especially if it is an external supplier) isn’t pulling the wool over the eyes of the business partner and to be able to ask the insightful and intelligent questions.
Finally, the project should only be considered a success if the transition from project to use takes place and that the outcome is achieved. The BRM Institute refers to transition management and this is a broad area, but specifically, it is the people change management that you need to be looking at.
The BRM should be looking to partner with the sponsor to make sure that this activity is planned and takes places. By bringing the extensive experience of multiple projects to the discussion then the sponsor should benefit not only from the BRM’s experience but specifically how other projects have landed a change in this organisation. The context of the organisation as a whole is critical to understanding the barriers that you may face to adoption, and the approaches that will be most successful.
In summary, I believe that the BRM role is to act as a consultant to the business partner and to do so in an advisory capacity. Ensuring that the right opportunities are selected, defined as outcomes and that the provider focuses on the key delivery is the job of the sponsor. Your job is to partner with them to achieve that successful outcome.
By working with sponsors of change to be successful then the BRM starts to demonstrate the value of engaging early and opens up the door to further conversations. In time you can begin to move those conversations earlier and earlier so you’re no longer responding to projects but starting to introduce the ideas that should be explored in the strategic business planning stages.