The Search for Role Clarity Ends with Strategic and Operating Model Clarity! (Part 1)

Role-ClarityI come across a whole heap (yes, that’s a technical term!) of “role confusion” in my consulting and training work. And it’s an insidious issue. Lack of role clarity leads to errors, miscommunication, redundancy, noise and wasted effort. It creates frustration, confusion, and, for a provider such as an IT organization, it leads to a poor customer experience and to the familiar refrain, “IT costs too much, delivers too little and is hard to do business with. They want to help us improve business processes, while their own processes are badly broken!”

It’s interesting to note that external providers generally don’t have this problem. They demonstrate high maturity and a level of precision in how processes, roles and rules of engagement are defined. They have to–it is crucial to how they make money and how they attract and retain clients–and talent! Internal IT organizations often like to say, “We run IT like a business!” But they rarely do. If they did, they would ensure role and operating model clarity–or they’d have a failing business!

You Can’t Transform a Silo’d Organization Silo by Silo!

Too often I see an IT transformation initiative being managed silo by silo:

  • Service Management is on a path to a better future–often on a great path, but it’s their own path!
  • Enterprise Architecture is on a path to a better future–often on a great path, but it’s their own path!
  • Solutions Delivery is on a path to a better future–often on a great path, but it’s their own path!
  • Business Relationship Management is on a path to a better future–often on a great path, but it’s their own path!
  • Project/Program/Portfolio Management is on a path to a better future–often on a great path, but it’s their own path!

The good news is that most of the ‘moving parts’ that comprise an IT capability are moving to a better, more disciplined and more intelligently designed future. The bad news is that:

  1. They are starting from different points on a maturity curve.
  2. Their destinations are usually roughly the same–unless you drill into the details (where the devil lies!)
  3. They are each following their own trajectories.
  4. Nobody is driving this holistically–it’s a set of relatively independent transformations.

The result?  Role confusion.

Pre-transformation Things Seemed to Work

Before each of the silos began transforming, work got done through a combination of:

  • “I know who to go to because she and I have worked here for years.”
  • Heroic efforts. Processes are either broken or undefined, but that’s fine because I can fix things and be the hero. And heroic behavior is rewarded.

So, before the transformation, things kind of muddled along–error prone, inefficient and frustrating to the business customer. But they worked. Now, in the heat of transformation, people are:

  • Positioning for power and influence.
  • Protecting turf.
  • Unable to see (or believe!) the “big picture” of the end state.
  • Afraid of loosing control. (“The old ways were not very efficient, but at least I understood them!”
  • So focused on their own silo, they don’t have the time, energy, or structural paths to clarify how all the moving parts engage.

I will pick up on Part 2 in the next week or so. Meanwhile, as ever, comments welcome!

Scrum: Twice the Work in Half the Time–Really? Part 2

scrum-daily-scrums-axisagile-scrumtroopersThis is Part 2 of a 2-part post.

In Part 1 I provided some context for my post inspired by the book “Scrum: The Art of Doing Twice the Work in Half the Time” by Jeff Sutherland, including a disclaimer on why you might not like this book. If you are experienced in Scrum methods, please look at Part 1 before reading this post. If you don’t have any Scrum experience, please look at Part 1 before reading this post!

Why I Loved This Book!

With my career focus on realizing business value from IT investments I’ve seen so much “business value leakage” and even many outright project disasters. As such, I’m inherently a believer in agile approaches, and wonder why they are so slow to penetrate enterprise IT organizations.

Scrum draws heavily on the principles of Lean, with aspects of Iterative Development, Rapid Application Development (RAD) popularized by James Martin, and is one dimension of the Agile movement. The book is very much a history of Scrum–and a compelling history it is! If we are to believe the author (and his credentials are stellar!) many major projects that were waaaaaay off track were brought back on track using Scrum.

I’ve always believed in the mantra, “Deliver value early. Deliver value often” and this is inherent in the Scrum approach. What surprised me most about the book is that Scrum can be and apparently is being used in a wide variety of projects and businesses, well beyond the world of software projects. In retrospect, this makes sense. With the pace of change we all live under, the ways social media and Web 2.0 technologies enable rapid experimentation and the rise of ‘customer experience’ as the key perspective, the notion of rapid delivery of value in a series of short “sprints” makes sense.

Dr. Sutherland has an impressive background–from Top Gun fighter pilot with over one hundred missions over North Vietnam, to receiving a Doctoral degree from the University of Colorado Medical School to systems development and the co-father of Scrum. He is a great story teller–his many anecdotes and experiences are highly relevant and compelling. The book is well-organized, with each chapter ending in “The Takeaway.” Apart from the anecdotal evidence in favor of Scrum and the sheer logic of his arguments, Sutherland presents mathematical evidence of the cost of ‘context switching’ so prevalent in the way IT organizations run today, and in the prevalence of misguided multitasking that is robbing us not only of quality, but of lives, as people try to drive and text or conduct phone conversations at the same time.

Jeff gets into a topic I feel quite passionate about because I see it very frequently in my clients–we are all working harder than ever and generally getting less done! This is an insidious behavior–creating the delusion that we are getting things done, while the reality is that we are simply busy–trying to get so much done that nothing of value is really getting done–or that we are unable to distinguish between the valuable and the urgent.

The book reminds us of what we are all acutely aware–detailed ‘waterfall style’ project planning creates a lot of work and delivers an illusion of reality that almost never pans out.

The Trouble With Scrum

Other than the inevitable learning curve, there are some very real problems with Scrum–or more to the point, with the context in which Scrum is applied.  These include:

  • The IT project funding model. There’s an age old aphorism about crime, “If you want to understand a crime, follow the money.”  My corollary to this is, “If you want to understand dysfunctional behaviors around IT, follow the money!”  Most funding models drive dysfunctional behaviors. With regard to Scrum, funding models are often not set up to fund in increments, and business sponsors feel that if they don’t sponsor the whole project up front, they may be left ‘hanging’ with additional needs and no resources to support them. Sponsoring the whole project up front typically means building the project plan and securing project resources–with the implication that you know exactly what you are going to deliver and how you are going to deliver it–which flies in the face of Scrum. I believe there is merit in adopting a Real Options approach to funding business initiatives, and that this might align quite nicely to Scrum and other agile methods.
  • The shortage of skilled Scrum Masters and Product Owners–roles crucial to Scrum success.
  • Resistance to organizational change. It is ironical that even though we know that waterfall approaches don’t work very well, we at least we are familiar with those methods and feel like we have control (even if that is largely fantasy!) we are reluctant to try new methods, no matter how compelling the evidence might be about the value of those methods.
  • Clarity of what types of solutions best lend themselves to Scrum, and what to stay away from.  I hear this quite a lot, and have to say I’m actually rather skeptical that Scrum can’t be applied to most, if not all, business problems and IT solutions. However, I don’t have the experience base to support my skepticism–reader feedback welcome!

Implications for Business Relationship Management

Regular readers of my blog will know that since co-founding Business Relationship Management Institute in early 2013, many of my posts have a Business Relationship Management (BRM) spin, so I want to explore the implications of Scrum on the BRM role. Having teed that up, I have to admit that I have many more questions that answers. I’ve had many discussions with BRMs about Scrum, and this is what I’ve learned so far:

  1. Some BRMs have no idea what I’m talking about when I raise questions about Scrum.
  2. Those that do are generally enthusiastic about the concept but are having a hard time nudging their Project Management and Solution Delivery groups into adopting Scrum methods.
  3. A few actually have Scrum ‘experiments’ going on, with generally positive results.

I’ve recently kicked off some research among the BRM community and will share my findings through this blog and other channels.  If you have some experience and would like to participate in the research, please let me know directly, or via comments on this post.


Graphic courtesy of Axis Agile

Business Relationship Manager Titles–Does Size Matter?


Once again, I received an interesting question from a reader that prompted a post. Here’s the question:

My BRM organization is going through leveling and restructuring. I have several BRM’s reporting to me and am working with very senior business executives with billion dollar business units. My peers in the IT organization have Vice President titles because they have larger organizations than mine. My BRMs sometimes feel that their titles put them at a disadvantage when engaging with their business partners. Is this a common issue?  Any suggestions for approaching this issue?

Organization Size Does Not Equate to Importance of the Leader!

This reader was caught in an interesting and relatively common dilemma! CIOs have faced issues about salary levels for years–often seen as having too many specialists, too many salary bands, and being ‘out of step’ with the rest of the company they support. Exacerbating this, IT organizations often continue to equate the importance of a leadership position (and therefore ‘level’ of that position) with the number of people in a given leader’s organization. This is, of course, a false premise–importance should have more to do with the nature of the leadership position rather than the number of folk reporting to that position (which is not only an invalid indicator of importance, but also drives dysfunctional behavior, i.e., organization size = power!)

Contemporary management thinking and leading HR practice has worked hard to flatten organizations and to break the “organization size = power” paradigm. Some roles carry more ‘weight’ than others, regardless of the number of people working for that role.

Access and Influence Are Key BRM Requirements

Of course, access and influence are earned by a BRM through their skills and behaviors–not because of their title. I’ve worked with very young and relatively low-level BRMs who wield enormous influence and gain access to the highest levels of business executive by dint of their skills and abilities.

However, some enterprises are very hierarchical in nature, and titles carry significant meaning. A BRM with the title ‘Manager’ for example might find it impossible to get on a Vice President’s calendar, while a Director or another Vice President would have no problem gaining access.

BRMs–Leverage Thy Influence and Persuasion Skills!

So, what did I advise the reader that prompted this post to do? Leverage their influence and persuasion skills and their knowledge of Business Transition Management (also known as Organizational Change Management) principles:

  1. Identify the key stakeholders in effecting a change to BRM titles/levels.  And don’t forget Human Resources as a key stakeholder!
  2. Identify What’s In It For Them (the WIFM’s) for each stakeholder by determining:
    • Problems resulting and/or opportunities missed due to the current state approach to BRM titles/levels.
    • Benefits anticipated from the future state with better-aligned BRM titles/levels.
  3. Consider moving the BRMs into the business units they represent.
  4. Identify the optimal first steps in effecting such a change to BRM titles/levels.


IT-Enabled Business Innovation: A Missing Link?

Power Information technology is enabling business innovation through new types of product and service, transformed business models and improved lives for customers, consumers, shareholders, employees and citizens.

For example, when Sam Walton famously recognized the competitive advantage Walmart could gain by ‘turning inventory to information’ he was experiencing (and then acting upon) an insight that would innovate supply chain management for big box retailers and, ultimately, for retailing in general. When Max Hopper‘s team at American Airlines recognized (and then acted upon) the power of yield management as a means of dynamically pricing airline seats based upon supply and demand, he created a competitive advantage that put promising low-cost airlines such as People Express out of business. When Jeff Bezos recognized (and then acted upon) the opportunities in reinventing online retailing for an exceptional customer experience, he created a new buiness that today captures $75 Billion per year of retail business and continues to innovate products and services.

These are examples of “big” IT-enabled innovation, but smaller examples appear all the time. Domino’s Pizza reversed its slumping performance in large part by making online ordering a cornerstone of its business through its web-based tools such as voice ordering, Pizza Tracker, 3-D Pizza Builder, and Pizza Hero tools.

Stories such as this appear frequently — though not as frequently as one might hope!

What Limits IT-Enabled Innovation?

With the emergence of all sorts of innovation enablers, such as the “Internet of Things“, inexpensive ways to identify and locate objects, people and places, powerful analytical capabilities, wearable technology, agile methods, smart phone apps, and so on, why does it seem that most businesses, government agencies and organizations of all sorts are stuck in the last century? Why does IT-enabled innovation always seem to refer to “over there?”

I’ve been fortunate in my career to be involved in IT Management research and learn from many talented academics and practitioners. One multi-company research study into IT-enabled innovation about ten years ago highlighted three key success factors:

  1. A clear and compelling ‘innovation intent.’
  2. An effective channel and structures that bring together business need/opportunities with IT capability/possibilities.
  3. An effective process for filtering, refining, testing and deploying innovation opportunities.

Business Relationship Management — A Missing Link for IT-Enabled Innovation?

The skilled and properly positioned Business Relationship Manager (BRM) can help inject the success factors identified above.  For example:

  1. As ‘demand shapers’ the BRM helps stimulate the business appetite for innovation. The skilled BRM uses techniques such as Value Network Analysis, Scenario Planning, Appreciative Inquiry, Competitive Intelligence, Bibliometric Analysis, and Capability Gap Analysis to help establish innovation intent.
  2. As ‘demand surfacers’ the BRM discovers innovation opportunities using techniques such as Design Thinking, Brainstorming, Knowledge Café, Synectics, Why-Why Diagrams, Behavioral Prototyping, Mind Mapping and Storyboarding.
  3. With their focus on business transition and value realization, the BRM helps deploy innovation opportunities using techniques such as Design Structure Matrix, Force Field Analysis, How-How Diagrams, Stakeholder Mapping and Analysis, Organizational Change Management, Business Experiments, Rapid Prototyping and Agile Development.

So, if you are in a BRM role, become knowledgeable in Design Thinking (see my 3-part post on Design Thinking here, here and here) and the disciplines and techniques of business innovation. Understand how innovation can create business value in your context. Of course, this means truly understanding your business partner’s business model, business processes, marketplace, competitive strategies, and market forces. It also means knowing the key stakeholders and influence leaders — where is innovation thinking taking place in your organization? How well connected are you with the innovation thought leaders? How are you learning about innovation in your industry? How are you keeping up with IT-enabled innovation?

So much to do — so little time — no time to waste!


Image courtesy of Business 2 Community

How Do You Optimize IT Capabilities for Business Value?

Value Disciplines

In their groundbreaking book, The Discipline of Market Leaders, published in 1997, co-authors Michael Treacy and Fred Wiersema argued that companies that have taken leadership positions in their industries have typically done so by focusing their strategy on one of three value disciplines, and optimizing their business operating models accordingly. They don’t ignore the other two value disciplines — they must meet industry standards in all three disciplines. But they lead in, and optimize for one value discipline, be it operational excellence, customer intimacy, or product leadership.

If we think of an internal IT organization in business terms, it becomes clear that IT infrastructure and operations are optimized for Operational Excellence, and that enterprise architecture and solutions delivery should be optimized for Product Leadership. This begs the question, what of Customer Intimacy?

How Can an IT Organization Achieve Customer Intimacy?

Many years ago (and even today in some companies) business leaders achieved Customer Intimacy with their IT capabilities by establishing their own, dedicated IT organizations. Over the years, as IT became an increasingly large chunk of business budgets, IT organizations transformed to gain advantages of scale by consolidating their IT capabilities into centralized shared service organizations. These tended to be optimized for Operational Excellence, consistent with the “lowest price and hassle-free service” promise associated with the business case for centralization.

For many such centralized, shared service IT capabilities, however, the Customer Intimacy value discipline was subsumed under the pressure to take out cost and be operationally excellent. The business customer of the IT organization could have anything they wanted, as long as it was consistent with the enterprise IT infrastructure and drew from the portfolio of standard enterprise solutions. In other words, as long as one size fits all! As business leaders stepped up to the competitive plate, trying to get ever closer to their customers, their IT organizations, in the name of defensible cost structures, were moving further away from their customers!

Enter the Business Relationship Manager!

In today’s leading IT organizations, the Customer Intimacy value discipline is being restored through the emerging role of Business Relationship Manager (BRM) — charged with driving business value from information and IT by getting close to their internal (and external) customers and, to paraphrase Treacy and Wiersema, by “delivering what specific customers want” and by “anticipating needs.”

All well and good — as long as IT infrastructure and operations live up to the Operational Excellence value discipline. When Operational Excellence is lacking, internal customers are typically reluctant to engage their BRMs in strategic exploration while basic operational issues (metaphorically, “lights on and training running on time”) are disrupting business operations. So, what is the BRM to do?

Plug the Holes, or Call for Improvement?

With many BRMs transitioning into their role from other IT disciplines, including Service Management and Project Management, there is often a strong temptation to step up to the plate and compensate for the deficiencies in Operational Excellence. There are several traps inherent in this strategy:

  1. When the BRM steps into an Operational Excellence role, they are taking time and energy away from their Customer Intimacy role — they tend to become part of the problem their role was established to address.
  2. When the business partner sees their BRM in an Operational Excellence role, the BRM may have a hard time either establishing or sustaining a relationship based upon strategic insight.
  3. By ‘masking’ the operational issues, the BRM is essentially ‘colluding with dysfunctional behavior’, potentially weakening the forces for operational improvement.

A Better BRM Approach for Addressing Operational Issues

Rather than falling into the ‘collusion’ trap, an effective BRM leverages their influence and persuasion skills and their competencies in organizational change management by stepping to the role of Change Agent for improved IT operations and infrastructure. They fearlessly call out process issues by:

  1. Gathering and presenting data that highlights process issues and their implications — always focused on the process, rather than the people.
  2. Offering to help fix the process issues — volunteering their business customer perspective, facilitation, process management, organizational change management, or whatever competencies they can bring to the table.
  3. Creating synergistic “foxholes” with their IT colleagues by establishing (or reinforcing) shared goals, common enemies (such as poor process, rework, dissatisfied business customers) and mutual dependencies.

Know and Lead With Your Customer Intimacy Value Discipline

When you get sucked into operational issues, you may find yourself in a role that is inconsistent with your main mission — it might feel good, heroic even — but it’s not what the BRM role is really about. Operational issues should be solved in those organizational entities that are optimized for Operational Excellence — IT infrastructure and operations.


Note: You can learn more about the techniques discussed here — and much more in my next on-line BRMP Certification course. This is being held across 3 Tuesdays—November 4, 11 and 18 . For details, please click here.


Driving Business-IT Convergence – The Evolving Role of the Business Relationship Manager (Part 2 of 2)

cloudIn Part 1 of this 2-part series I defined the BRM role – with the caveat that it is by no means standardized.  In fact, as far as IT Service Management standards such as ITIL® and ISO/IEC 20000 are formalizing the existence of the Business Relationship Manager (BRM) role and corresponding process as a new best practice, they are selling the role short in terms of its potential strategic impact to business.  I went on to describe the typical BRM in terms of their purposes, goals, responsibilities and accountabilities.  To the title of this post, I introduced the shift from business-IT Alignment to Convergence and why this is so important as every aspect of business strategy and operations is increasingly dependent upon information and IT.   Today, the BRM operates at the leading edge of the convergence movement – a movement being accelerated by the ‘consumerization of IT‘, digitization of everything, and by the “Internet of Things.”

In part 2 of this 2-part series, I’d like to discuss needed BRM competencies, how the BRM role changes over time with increasing maturity (of both the BRM and her business partner) and how the way that the BRM engages with the business partner shifts the nature of the relationship from one of order taker to that of strategic partner.

Typical Competencies Required of the BRM

Drives Value Realization

This might be the most important competency for a BRM.  It includes knowing how to surface, clarify and promote the best value-delivering opportunities for IT investments and assets, and how to ensure that these actually deliver on their promised value – delivered in ways that are felt and seen.  This requires skills in Program Management (with implied Project Management skills), Portfolio Management, influence, persuasion, communication, finance and organizational change.

Understands Business Environment

Driving value realization also requires a great understanding of the business, its ecosystem and its competitive landscape.  Successful BRMs have a keen sense of the top strategic business and IT issues – both short and long term, and how these issues relate to initiatives in their industry.  In short, they understand the “business of the business.”  They are viewed by business leaders as a proactive partner in finding the right solutions to business needs and not as a mere “order takers” for IT services.

Aligns IT with the Business

First, let me say that some readers will fume at the subheading.  “IT and the Business are one and the same!” they shout.  While this may reflect a laudable perspective (and one that will gradually materialize as IT-business convergence takes place) it is rarely, if ever, the case today.  Unless your business is information technology, then “business” is where profits are generated, and IT organizations work in support of that.

With that digression out of the way, alignment can be a tricky concept, and in some respects sounds inconsistent with my argument for business-IT convergence.  But alignment represents the necessary table stakes – business leaders and IT leaders need to be ‘on the same page’ in terms of mission, vision, values and goals for both IT and the business – and how these relate to each other.  Mismatches in any of these can spell disaster to the ability to build and sustain value-producing business-IT relationships, let alone converge business and IT capabilities.

Successful BRMs work closely with business leaders to predict demand for IT services and to manage that demand.  They take the lead in highlighting competing objectives.  They are effective at managing the flow of demand through negotiations and seek to iron out demand/supply disconnects between IT and business leaders.  Most important, they constantly seek ways to foster convergence – empowering business leaders – teaching them to fish, as it were, rather than always fish for them!

Manages Relationships

Any role with the word “relationship” in the title has to imply a high level of competence at creating, sustaining and developing strong relationships among stakeholders – especially between business units and the IT groups that support them.  Relationship skills do not come naturally, and are not easily developed in some people.  Effective BRMs are able to build and maintain relationships with senior IT and business leaders.  They are seen as a value-added participant in strategic business-level discussions (i.e., worthy of a “seat at the table”).  Successful BRMs are not shy in speaking up when the demand for IT services outpaces supply ability or capacity.

Manages Organizational Change

Another tough set of skills and behaviors to master!  This requires deep understanding of the organizational levers for making change (people, process, and technology) and how IT and business strategies translate into practical plans of action for change.

The successful facilitator of change engages in discussion with IT and business leaders on the intended and unintended consequences of change, and is willing to confront senior executive sponsors if they are not “walking the talk” and proactively leading the change themselves.  They understand the total cost – both technical and human – of end-to-end implementation.  They can surface the hidden costs and potential obstacles that could derail the change.

They have the ability to identify key stakeholders at the outset of a project, to assign decision-making roles, and ultimately hold leaders accountable for results.  They think and act in terms of outcomes, not deliverables.

Manages Projects and Programs

Successful BRMs typically have several years of project and, ideally, program management experience under their belts.  They have demonstrated competency in project management fundamentals and in the complexities of program management. They demonstrate the ability to get things done through others, even though they may lack ultimate authority.

Effective Communication

Successful BRMs are recognized for their ability to listen, speak, write and communicate clearly and effectively. They demonstrate the ability to negotiate win-win, or at least buy-in, in situations where there are opposing viewpoints.  They are effective at influencing those that they hold no real power over.  They have the ability to recognize and surface disconnects between IT and business leaders and are able to resolve problems through difficult confrontations.

Financial Savvy

Successful BRMs have good knowledge of finance and accounting – they know their ROIs from their NPVs and know how to build a business case that is compelling.  They understand Portfolio Management and have at least basic knowledge of Options theory.  They understand the financial drivers of the business and the drivers of the industry within which the company operates.

The BRM Maturity Journey

BRM Maturity - The Merlyn Group

The graphic above shows how the quality of the Business Partner experience grows and the BRMs maturity increases.

Ad Hoc Relationship

At the lowest maturity level, the BRM role has typically not been formalized.  As such it is being handled in an ad hoc way – the ‘squeaky wheel’ Business Partner gets the most attention.  Or, in some cases, the least demanding Business Partner, regardless of their potential to use IT for high value purposes get the most attention.

Order Taker Relationship

I see this most frequently. Typically, IT supply has been badly broken and the business-IT relationship is hostile, so the BRM role is introduced to “patch things up!”  The BRM, in her ignorance, believes the best way to improve the relationship is to say “yes” to any and all business demands.  This is nearly always a losing proposition.  IT can’t meet the demand, and if they did, there’s little to no business value to be gained.


This is a more constructive and productive relationship, where the Business Partner sees the BRM as an advisor.  By this time, there has usually been some formalization of the BRM role and its rules of engagement.  There’s also been some level of training for the BRM – or at least some thought put into the selection of people for the role.

Strategic Partner

The ‘Holy Grail’ of BRM implementations.  This should be the clear ambition – one that is understood and shared by the BRM and her Business Partner – with the recognition that you aren’t a Strategic Partner because you say you are, or because you want to be.  You reach that elevated position because you’ve earned it – and because your Business Partner sees you that way.

IT Matures as the BRM Role Matures

At the risk of pointing out the obvious, the BRM role does not act in isolation.  It is inextricably linked to IT supply.  If IT supply is broken, the BRM role will be limited, and might not even make it to Order Taker.  This, from my experience, is a common situation.  Things are bad, so the BRM role is introduced.  Unless supply improves, the BRM is doomed to failure – and may actually make things worse.  Promises are made and expectations set that cannot be kept.  On top of lousy supply, the BRM is seen by the business partner as ‘overhead’ – yet more evidence that the IT team is clueless, always adding cost without demonstrating value!

To reach the Holy Grail of Strategic Partner, IT supply has to be excellent – both with steady state services (networks, email, help desk, etc.) and with solution delivery (projects and programs).  The “strategic” BRM needs IT supply to work flawlessly.  IT supply needs the BRM to suppress low value demand while stimulating demand that delivers real business value.  That way, everyone is happy and a virtuous cycle is sustained.

Image courtesy of TradeArabia

Enhanced by Zemanta

Is IT Organizational Confusion Exacerbated by the Role of Business Relationship Manager?

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:

  1. 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?
  2. 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?”)
  3. 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:

  1. We have bright, hard-working people who work at ‘smoothing out the bumps’ caused by lack of Operating Model clarity.
  2. 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:

  1. 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.
  2. 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.
  3. 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 courtesy of Awakening Business Solutions

Enhanced by Zemanta