Category Archives: Demand Maturity

Maturity of business demand (appetite) for IT capability

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.

Advisor

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

Related articles
Enhanced by Zemanta
About these ads

ITIL and the Business Relationship Manager: Avoiding the Performance Trap!


order-taker

I have good news, and I have bad news!

The Good News…

The IT Infrastructure Library (ITIL) 2011 edition and the ISO/IEC 20000 standard for IT Service Management formalized the existence of the Business Relationship Manager (BRM) role and corresponding Business Relationship Management process as a new best practice and international IT Service Management standard requirement.  This is good – for professional BRMs around the world, for the IT profession in general, and for improving the business return on IT investments, as technology becomes ever more deeply embedded in business processes.

The Bad News…

(And I know I will get hate mail and lose readership for saying this, but…) As defined by ITIL, the BRM role comes off as somewhat tactical – not something to get business leaders salivating over their new partnership with IT, nor hungry to innovate business products and services!  Let me be clear – the ITIL vision of BRM is necessary – but from my experience, it is insufficient to drive real business value beyond a certain point.  It will help an IT organization with poor service quality get better.  But it will not help an IT organization with good service quality to excite and delight their customers with the new business capabilities that are enabled by information and information technology!

Business Relationship Manager Role

I’ve posted extensively on this role in the past – the BRM is a bridge between the IT organization and its business clients (just as a good CIO is a bridge between the IT organization and corporate leadership).  As such, it both represents the business clients to IT, and IT to the business clients.  This role has surfaced over the last 10 years or so and Gartner predicts that the fraction of IT personnel dedicated to Relationship Management and Change Leadership functions will reach as much as 15% by the end of 2013 and grow up to 20% by 2016.  LinkedIn hosts two groups dedicated to the BRM role.  One group – IT Business Relationship Management - currently boasts over 1,800 members.  The other group, Professional Business Relationship Managers currently has over 2,600 members!  (In the interests of full disclosure, I co-manage the latter group.)

I’ve conducted a significant amount of consulting, assessment and training in the BRM space, including designing and leading BRM training and development programs for global companies with over 100 BRMs (as well as for those with fewer than 5 BRMs).  From that experience, and from my ongoing activity on the LinkedIn groups, I’ve seen two distinct ‘flavors’ of BRM – “Tactical” and “Strategic.”

BRM and Business-IT Maturity

To help understand “tactical” and “strategic” BRMs and how they’ve come to be, I’ll use my Business-IT Maturity Model (BITMM).  I’ve posted at length about the BITMM.  In its simplest form (see graphic below) the model represents both business demand maturity (highlighted in red to the left of the learning curve) and IT supply maturity (highlighted in blue to the right of the curve. These never move completely in tandem – sometimes demand is slightly ahead of supply, other times it is slightly behind.  If demand and supply get too far out of whack, there’s usually a change of CIO (or a turnover of the IT organization to an outsourcer!)

Slide1

The number of maturity levels is arbritary, but for simplicity let’s use three – business efficiency, business effectiveness and business transformation.  Where a company is at any point in time is a function of factors such as:

  • the industry it’s in
  • current business leadership
  • competitive and regulatory forces
  • quality of IT leadership
  • quality of service delivery

For example, the financial services industry tends to be highly information-intense, so is generally demonstrated higher business demand and IT supply maturity than say, manufacturing companies, which have traditionally been less dependent on information.  All that is changing, of course, as businesses and governments everywhere become increasingly digitized.

The ITIL Connection

Improving service delivery quality is where ITIL focuses.  According to its current owners (The APM Group Limited) ITIL is “the most widely accepted approach to IT service management in the world.”  Originally developed under the auspices of the UK Office of Government Commerce (OGC), ITIL is becoming a popular approach to service management.  Often loosely, and occasionally rigorously followed, ITIL documents processes and practices for service management.  This focus on service management is crucially important in moving IT supply maturity up from low Level 1 to mid-Level 2.

The Tactical BRM

The graphic below crudely cuts the BITMM in half.  The lower half is what I refer to as the “tactical” BRM space – focused on business efficiency and effectiveness.  The conceptual dividing line between these spaces is important.  Around the mid-point of Level 2 maturity, the learning curve changes direction.  This is also a common “sticking point” (see my earlier posts on “sticking points”) where IT organizations often become trapped and their efforts at performance improvement taper off.  In some cases, they actually fall back in performance.

Slide2

So, in the pursuit of service management quality, the BRM has an important role, establishing a strong business relationship with the customer by understanding their business and customer outcomes.   But the focus is service management, as opposed to the strategic possibilities for IT capability to enable new or improved business products and services.  Service management applies most to ‘steady state’ IT services – not to transformational projects and programs on behalf of business units.

The Strategic BRM

The upper half of the BITMM is the “strategic” BRM space – focused on business effectiveness and transformation.  While an IT organization must be careful not to slip back on IT service quality and customer satisfaction, simply delivering ever-improving services will not transform IT into a respected, value-producing business partner. Sooner or later, IT service management efforts reach a point of diminishing returns. Something quite different is then needed to further improve the business return on IT assets and investments.  While the “Tactial BRM” tends to focus on IT supply management processes and activities, the “Strategic BRM” focuses on business demand management – stimulating, surfacing and shaping demand for services, activities and initiatives with the highest potential business value.  The “Strategic BRM” works closely with her business partner to ensure that IT investments and capabilities yield real business value.

Leverage the Standard Frameworks – But Don’t Get Stuck

The message here is that it’s ok to leverage standards and frameworks such as ITIL, COBIT and TOGAF – but essential to do so with intelligence!  They have their place – and a context for which they were intended – that often being UK government entities.  Nothing wrong with that, but it tends to be a context of control – not innovation.  Control can help you get from low Level 1 to mid-Level 2 – but not to Level 3.  What kind of IT capability does your business need – controlling or innovating?

Thoughts on a postcard, please!

Graphic courtesy of giffconstable.com

Related articles
Enhanced by Zemanta

What’s Really Meant By Business-IT Engagement and How Do You Achieve It?


This is another post triggered by a reader’s question emailed to me.  Here’s his question (some details have been omitted to preserve anonymity).

I was searching for information around Business-IT engagement but have yet to really come across anything with substance.  I’m looking to better connect with the business unit managers to formulate an IT strategy. The unit managers have a track record of operating in their own silos, often making IT decisions without talking to IT which has ultimately cost the company money.  I was thinking about putting a plan together to engage. Structured via, face-to-face, email, social media, newsletter and even survey. Ultimately, from start to finish, I build the picture and connect and portray the message that IT is an enabler and there is benefit in engaging.  I wondered if you knew of anything which may help me?”

This is an interesting question and a common challenge.

What Do We Mean by Business-IT Engagement?

A little research into the term “Business-IT engagement” found a reference to “Employee Engagement“, which Wikipedia defines as:

An ‘engaged employee’ is one who is fully involved in, and enthusiastic about their work, and thus will act in a way that furthers their organization’s interests. According to Scarlett Surveys, ‘Employee Engagement is a measurable degree of an employee’s positive or negative emotional attachment to their job, colleagues and organization that profoundly influences their willingness to learn and perform at work’. Thus engagement is distinctively different from employee satisfaction, motivation and organisational culture.”

I don’t think it’s an unreasonable stretch to derive from this a definition of business-IT engagement:

Business-IT Engagement exists when business unit leaders are fully involved in, and enthusiastic about their IT capabilities, and thus will act in a way that furthers the business value of those capabilities.  Business-IT Engagement is a measurable degree of a business executive’s positive or negative emotional attachment to their IT capabilities, IT colleagues and IT organization that profoundly influences their willingness to participate in the use of IT for business value.”

IT Engagement Model

I also found an IT Engagement Model from our friends at the Center for Information Systems Research:

The IT engagement model is defined as the system of governance mechanisms that brings together key stakeholders to ensure that projects achieve both local and company-wide objectives. The model consists of three general components:

  • Company-wide IT Governance – decision rights and accountability of company level and business unit level stakeholders to define company-wide objectives and encourage desirable behavior in the use of IT
  • Project management – a formalized project management process, with clear deliverables and regular well-defined checkpoints, that encourages disciplined, predicatable behaviour for project teams.
  • Linking mechanisms – processes and decision-making bodies that connect project-level activities to the overall IT governance.

The Linking Mechanisms are further explained in the following graphic:

I find this to be a pretty comprehensive and easily understood way to define some of the major aspects of Business-IT engagement.

Key Business-IT Engagement Factors

The other key factors I pointed my reader to include:

  • The experience your unit managers have with IT – do they trust IT? Has IT served them reliably? Is there transparency into how IT charges?  Is the business value of IT recognized and celebrated?
  • How engaged are business and IT leadership with each other? Does the CIO sit on the Management Committee? Is there an effective business-IT governance board and related processes and structures?
  • The skills of those in the business-IT interface role (Business Relationship Managers, or BRM’s) – how well do they understand the business? Do they have good relationship skills? Are they co-located with the business unit leaders and sit in on business management meetings? Do they perform a business management role, or are they simply seen as technical people taking care of IT?  Are they primarily responsible for Demand Management?

To the balance of his question, I asked:

  • Are you really trying to formulate an IT strategy? Or is it going to be a business-IT strategy. (If I’m a business unit leader, why should I care about or want to be involved in an IT strategy – it sounds rather internal to IT to me, so I’d probably want to stay out of it – I’m busy enough as it is!)
  • Do you really understand the business problems and how IT can contribute to solving them? If you do, what’s the best way to “market” those ideas, and to whom should you be marketing them?
  • What are the cultural norms in the business – do ideas drift down from the top, or do they percolate up from the edges – the ‘front lines’?

Outside-in Versus Inside-out Thinking and Acting

Finally, I was troubled by an aspect of the language my reader used in his question:

I build the picture and connect and portray the message that IT is an enabler and there is benefit in engaging”

This is what I call Inside-out thinking – “We (IT) are good and can help you so you should engage with us!”  I think my reader might be on a better path to engagement if he can identify the specific business issues and needs and communicate how IT might contribute to addressing those issues and needs.

Don’t Engage – Empower!

Just as I was finalizing this post, Zemanta did its usual thing of suggesting links and related articles.  (I really like Zemanta – it’s been one of my little blogging secrets for a while!)  Among its suggestions for articles was Don’t Engage Employees, Empower Them!  I think that is an important dimension to Business-IT engagement – especially in this age of IT consumerization.   Too many IT leaders see there role as ‘protecting the business from the perils of IT.’  Empowering them – for example, Bring Your Own Device (BYOD) can be a powerful way of bringing the business into the business-IT dialog and engaging them in strategic and tactical dialog and decision making.

Graphic courtesy of The Social Workplace

Related articles
Enhanced by Zemanta

To Whom Should Business Relationship Managers Report?


I recently received this question from a reader:

We are evaluating a strategy to centralize IT and implement Business Relationship Management (BRM) roles as part of the centralization. Where do you typically see the BRM’s reporting into in a centralized IT organization? Should they report directly in to the CIO, or can they be effective a level or two below the CIO?”

Rule #1 – Reporting Lines Are Weak Determinants of Success for the BRM Role

I have found reporting relationships to be a very weak determinant of success for the Business Relationship Manager (BRM) role. Far more important are the competencies (especially business knowledge and relationship skills) of the BRM and the maturity of the business executives they partner with.

Rule #2 – Heft Matters!

Notwithstanding Rule #1, the “heft” of the BRM role – the weight and implied authority it carries does matter.  There’s a couple of reasons for this:

  1. BRM’s are often on a CIO succession path (either explicitly or implicitly) – i.e., have the skills and wherewithal to be a CIO down the road, and the BRM role may be seen as a developmental step.  This has implications for who you chose to fill BRM roles, and for their career paths.
  2. The story a CIO tells the business executives when establishing the BRM role is along the lines of, “I am giving you one of my senior staff members to help surface, shape and manage IT demand so that you get the highest possible value from IT investments and assets. In return for this ‘gift’ I expect you to treat this BRM as a member of your management team.”

As a result, the most common reporting relationship for successful BRM’s is directly to the CIO.  In some cases, the BRM has a dotted line relationship to the senior business executive for the unit they represent.  In other cases, the BRM role is solid line to the senior business executive and dotted line to the CIO.

Rule #3 – Context Matters!

There are many other contextual factors to consider here, including:

  • What is the scope of the BRM role – is it primarily demand management (shaping, surfacing and managing business demand for IT)?  Or does the role include supply management, service management or other responsibilities?
  • Do the BRM’s act as Project or Program Managers for major initiatives?
  • Do the BRM’s sit on any governance bodies, such as Portfolio Management or Service Management?
  • How do BRM’s engage with the supply side?  How do they engage with Enterprise Architects?
  • How mature is IT supply?
  • Howe mature is business demand?

BRM’s Can Be ‘Game Changers’!

The BRM role is a tough one to get right, but from my experience, well worth the effort!  An effective BRM can:

  1. Elevate business maturity
  2. Ensure that IT resources are being focused on the highest potential value activities and initiatives
  3. Ensure that those initiatives capture the highest possible value

 

Graphic courtesy of Linda Galindo

Related articles
Enhanced by Zemanta

How Good are your IT Capabilities and How Good do they Need to Be? – Part 2


This is the 2nd in a multi-part post on assessing IT Capabilities.  (See Part 1)

A Quick Recap

Part 1 introduced some assessment principles I’ve found to be important.

  1. The Process is more important than the results.  I’ve found facilitated self-assessments to be the most effective.
  2. The results must be actionable. An assessment must give you insight into what needs to be improved, with what urgency and in what sequence.
  3. The results must be multi-dimensional. For example, address performance, value delivered and health of a given capability.
  4. Process-based assessments only go so far – and may in fact be misleading! Not all IT Capabilities are process-based.  Some depend more on standardization of deliverables or the outputs produced by a capability, and some depend more on special skills and training. Concluding that a given Capability might be highly mature or highly immature might have nothing to do with its ability to deliver excellent results!

Capability Defined

There are several aspects to defining Capabilities:

  1. What is meant by “IT Capability”?
  2. What is the potential landscape of IT Capabilities?
  3. How do you know what IT Capabilities you need?

Let’s examine these in turn.

What is Meant by “Capability”?

Wikipedia defines Capability as:

The ability to perform actions. As it applies to human capital, capability is the sum of expertise and capacity.”

A couple of things to note about IT Capabilities:

  1. While Capability Maturity Models such as CMMI put processes as the central construct of a capability (and the key to capability maturity assessment), in practice not all IT Capabilities are inherently process-centric.  Some depend more on people’s skills and competencies (think Business Relationship Manager, for example) while others depend more on deliverables than they do on specific processes.  (For a more detailed treatment of this distinction, see Part 1 in this series or my earlier posts on Henry Mintzberg‘s seminal work on organizational constructs.)
  2. You don’t need to “own” any given IT Capability – you can “rent” it as in outsourcing or contracting, for example.
  3. Not all IT Capabilities exist in an IT (or IS) organization.  Some are embedded in business units or other organizations.  For example, the capability to chose, procure and maintain personal computing devices may belong to the business – think “Bring Your Own Device” or “BYOD” as this rapidly growing movement is often referred to.

What is the Potential Landscape of IT Capabilities?

I’ve covered this topic in some depth previously in my posts on IT Organizational Clarity, but as a quick recap, below is a normative, high-level IT Capability Model.

Normative IT Capability Model

One can debate the specific labels for each of these capabilities, but essentially, any enterprise that depends upon Information Technology to any degree needs each of these IT Capabilities.  Of course, the devil, as they say, is in the detail, and the detail exists in the drill-down decompositions for each of these high-level IT Capabilities.  We will get more into this in Part 3 of this series.

How do You Know What IT Capabilities You Need?

There must be a clear and explicit linkage from Business Strategy to needed IT Capabilities.  There are many methods for achieving and expressing this linkage, and this is the realm of strategy formulation.  At its simplest, a given Business Strategy will require a set of Business Capabilities.  In turn, most, if not all Business Capabilities will depend upon one or more IT Capabilities.  Common techniques for achieving this linkage include:

But, IT Must Not Only Satisfy Business Demand – It Must Stimulate and Shape Demand!

The big danger with most strategic alignment methods are that they are inherently reactive.  i.e., To enable “x” business capability or strategy, we need “y” IT capability.  But how do you know that the business strategy is properly informed by IT possibilities?  This is where the first in the Value Chain Capabilities (see graphic above) comes into play – Discovering Business-IT Potential – and where the role of the Business Relationship Manager is so key.  So, you don’t just need the IT Capabilities the business thinks it needs – you also need IT Capabilities that create IT “savvy” and equip the business to understand and fully exploit IT potential.

Coming Up Next…

In Part 3 of this series we will examine assessment dimensions and methods.

Graphic courtesy of LipheLongLurnERrdok

Related articles
Enhanced by Zemanta

How Good are your IT Capabilities and How Good do they Need to Be?


This will be the first in a series of posts about assessing the “goodness” of IT capabilities, both in terms of your current state (how good your IT capabilities are) and ‘desired’ state (how good they need to be).  We will get into the dimensions of ‘goodness’ as well as assessment methods.

I’ve been designing and facilitating IT capability assessments for over 20 years, and have conducted hundreds of them – both as part of multi-company research projects that generated a substantial base of assessment data, and through individual assessments as part of consulting engagements. Over that time, I’ve developed a number of assessment principles I’ve found to be important.

The Process Is More Important Than The Results

There are several aspects to this.

  1. People don’t like being assessed, but they love being part of an assessment process!  By and large, people like to know how they are doing, especially from an organizational perspective.  But they are mistrustful (rightly so!) of consultants or other ‘agencies’ that come in and assess them or their organizations.  So, I’ve always taken an approach where I am a facilitator of a self-assessment process.  I bring the process (which the client and I may agree to modify to accommodate specific contingencies), experience to help them through the process, and act as an impartial ‘judge‘ to resolve differences of perspective, opinion or interpretation.
  2. The process must be transparent.  If people don’t understand or buy into the process, they will never buy into the results!
  3. The process should be repeatable.  Like a meaningful scientific experiment, the process should lend itself to repetition with consistent results.  In fact, repetition over time may well be important to sustained investment in capability improvement activities.  Too many assessments are conducted, discussed and then swept under the table.  This is a travesty!  Not only is the assessment wasted effort, but it may also be that much harder, or even impossible, to get people to participate in future assessments.  “Why should I bother – the last time we did this it went nowhere!” is a fairly common refrain.

The Results Must Be Actionable

The results should let you know:

  1. What needs to be done to improve capability performance.
  2. Where the greatest urgency lies for capability improvement.
  3. What it will take for a given IT capability to be improved, and to what benefit.

The Results Must Be Multi-Dimensional

This actually gets to the question of “goodness.”  I believe there are three important aspects of “goodness” as it relates to IT capability:

  1. Performance – this gets to efficiency – what resources it takes to achieve a given result.
  2. Value – this gets to the effectiveness of an IT capability – what benefits are being derived from the capability.
  3. Health – the ability to perform and deliver value over time.  We’ve all seen heroics, where, for example, a project team moves mountains in the final weeks of a project by working 20 hour days, 7 days a week.  It’s a wonderful thing to behold, and sometimes is necessary and may even promote ‘good health’ for the organization as people pull together and participate in a ‘miracle’.  But it’s not sustainable.  Expecting people to perform at a sprint when the course is a marathon is both dangerous and demotivating.

Process-based Assessments Only Go So Far!

We are all familiar with the SEI CMMI type maturity assessment.  These typically assess a capability’s maturity as somewhere along 5 levels:

  1. Initial
  2. Managed
  3. Defined
  4. Quantitatively Managed
  5. Optimizing

I believe maturity assessments such as this are appropriate for capabilities that are heavily process-dependent.  These include IT operational processes – highly predictable, repeatable processes.  But, drawing from Henry Mintzberg‘s discussion of standardization many years back, (see Mintzberg’s “Structure in Fives: Designing Effective Organizations”) not everything demands standardization of work processes.  If the goal is to make work consistent, repeatable, predictable and of high quality, there are three approaches:

  1. Standardize the work processes
  2. Standardize the outputs – i.e., the deliverables from the process
  3. Standardize the skills – i.e., focus on the people and their training

Typically, all three types of standardization apply to varying degrees – the mix being a function of the nature and complexity of the work you are doing.  For highly complex work (think brain surgery) the emphasis is on the people, which is why surgeons go through years of training, board certification, residencies, and so forth.  It’s no use handing them a detailed process to follow and expecting an untrained person to achieve a quality result.  For work such as bridge building, the emphasis will be on the deliverables – various types of blueprint, work breakdown structures and so on.  For routine, sequential work, the emphasis will be on defining the tasks to be followed and the sequence in which to follow them.  Ideally, the work can be so ‘routinized’ that it can be automated.  (Think data center operations and the shift over the years to ‘lights out’ data centers.)

The graphic below illustrates this concept.  Detailed processes are great at helping manage work that is routine and sequential in nature (which is one of the reasons why ITIL has gained so much traction in the last few years.)  For work that is inherently collaborative, and may require more visual enablement, standardizing on deliverables may be more apparent (think discovery and solution delivery).  For work that is more complex and exploratory, training and performance support systems are more appropriate.

For more on the different approaches to standardization, see my post, “Are Your Processes Setting You Free?  Or Holding You Back?“

Please join me for the next post in this series where we will drill further into assessment dimensions and processes.

 

Graphic courtesy of Take On Torah

Enhanced by Zemanta

Questioning the Role of the Business Relationship Manager


I’ve been deeply into understanding and developing the role of Business Relationship Manager (BRM) since the early 1990′s when, as a Partner at Ernst & Young’s Center for Business Innovation, I began researching what was then an emerging role.  Since then, I’ve continued research into this important role, led many consulting engagements helping companies implement or improve the performance of the BRM role, and have been on the faculty for several global BRM development programs.

More recently, I’ve been a co-moderator of the Professional Business Relationship Manager Group on LinkedIn.  This has been a fascinating experience for me – some very interesting dialogs surface from time to time, and the diverse opinions and approaches to the BRM role become ever more evident each day.  Also, the sheer growth of this group over the last couple of years is remarkable, and speaks to the growing importance of the BRM role.

What is a Business Relationship Manager?

First, it is important to understand that this is a role, not a job title.  In fact the job titles for people who fill this role vary enormously.  Adding to the confusion around titles, “Relationship Manager” is a common title in banking, and we get a lot of applications to join the LinkedIn group from banking officers – not the intended audience!  Also, a number of pure “sales” jobs call themselves “relationship managers.”  I don’t have a problem with that, but it’s not the focus of the BRM group.

Second, the ways that the BRM role is implemented varies significantly.  Sometimes it is a sole practitioner – other times, the BRM leads a small team (anything from 1 or 2 business analysts to a larger team, including architects and even developers.)  Sometimes the BRM reports to the IT organization – typically as a direct report to the CIO.  Other times, it reports to a business leader – perhaps with a dotted line relationship to the CIO.

No matter what the variations in organization and structure, the common thread across BRM implementations is an interface between business and IT.  The common goal (though expressed and measured in myriad ways!) is to increase the value realized from IT investments (typically, new initiatives), assets (usually current systems and infrastructure) and capabilities (the services and products offered by the IT organization.)

This “interface” responsibility implies two ‘faces’ of the BRM role:

Representing the Business to IT

This is one of the BRM ‘faces’ – representing a given business unit (or units, or business process, or geography) to IT.  In this regard, the BRM’s primary role is in shaping and surfacing business demand – always with an eye to maximizing the business value of IT investments, assets and capabilities.

Representing IT to the Business

This is the other BRM ‘face’ – representing IT to the given business unit(s).  In this regard, the BRM’s primary role is in supply management – ensuring that the IT organization understands business needs and expectations, and is delivering against those expectations.

But, What is the Real Rationale for the BRM Role?

Implicit in the many debates I see in the BRM community (and behind some of the failures I see in making the BRM role successful) is the question:

What is the most important aspect for the BRM to focus on – demand management or supply management?”

There is no easy answer to this – it really is a function of both supply and demand maturity.  But, I will make some assertions based on a great deal of experience:

  1. If supply maturity is low (i.e., basic IT services are unreliable, unpredictable, unstable, unclear) the BRM role will almost certainly fail.  It cannot add real value, spends it’s time apologizing for IT and making excuses, and is quickly seen by the business partner as “overhead.”
  2. If supply maturity is moderate (i.e., basic IT services work well, but capacity is highly constrained, projects take too long to deliver and are prone to delays) the BRM role has to play a careful balancing act – stimulating and shaping demand while living within the constraints of supply.
  3. If supply maturity is high (i.e., a well regarded IT organization that delivers basic services and project work; that has ‘elastic’ supply that can flex with demand and can deliver with ‘agility’) the BRM role can and should focus almost exclusively on demand shaping and surfacing.

Of these three situations, scenario 1 is the most treacherous for the BRM.  It’s essentially a losing proposition.  My advice to clients is, “Don’t put BRM’s in place – fix the basic services first!”

Scenario 2 takes a great deal of finesse.  The temptation for the BRM is to either try to fix the problems of supply, or shield the business partner from those problems.  Fixing supply is best done with those on the supply side who are responsible and accountable for IT supply.  If you put the BRM in that role, they can’t be effective in their demand management role.  Once their business partners see them as part of the supply side, the BRM loses their credibility as valuable demand shapers.

Why would I invite you to my leadership team strategy retreat – you’re the person who’s fixing IT services!” might be the reaction of a business leader to a BRM who has asked to join the business unit’s strategy formulation retreat.

On the other hand, shielding the business partner from supply side woes is also a trap – what I refer to as “colluding with dysfunctional behavior” which is never a good idea!

Scenario 2 also takes great skill with the discipline of ‘value management’ – understanding how IT investments, assets and capabilities lead to business value – making sure that the constrained supply is working on the highest value possibilities, ensuring that low value requests do not get through the intake process and that value is actually ‘realized’ – felt and seen by the business.

Scenario 3 is the ‘holy grail’ for the BRM.  Unfortunately, by the time IT supply has reached that level of maturity, so has business demand, and the BRM role may be redundant.  But that’s a story for another post…

Enhanced by Zemanta

Why Some Projects Should Be “Led,” Not “Managed”


I’ve posted before (many times!) about Business-IT Maturity, and the common “sticking points” that most IT organizations run into around the mid-point between low and high maturity.  (See, for example, here, here, and here, or enter “Sticking Point” into the search box.)

Walking Ever Faster Will Not Get You Running!

If, arbitrarily, you pick 3 levels of Business-IT Maturity – say Level 1 = low, Level 2 = medium and Level 3 = high, you will typically find that the things you have to do to get from Level 1 to Level 2 not only won’t get you from Level 2 to Level 3 – they will actually prevent you from reaching Level 3!  The trick is to recognize what these things are, and that you are entering a very different learning curve.  For example, if your solutions delivery process is broken, you need a great deal of rigor and discipline – in the form of Project Management and a Systems Development Life Cycle.  That will get you from “chaotic” (Level 1 in my hypothetical 3-Level scale) to “managed” (mid-Level 2).  But over time you will find the limitations of a “managed” approach to solutions delivery – especially when you need to implement “fuzzier” solutions, such as social media, or business analytics.

One Size Does Not Fit All

With solutions delivery, one-size does not fit all, and the methodology that works well for a relatively easily pre-specified transaction processing system (order-to-cash, for example) will not work well for something that is less predictable and more emergent.  Hanging in there with the “official” methodology (for fear of reverting to the chaotic situation that persuaded you to implement the methodology in the first place!) will frustrate the developers, annoy the business client, and will probably lead to a poor or unworkable solution – which will upset everybody!  What is needed is a finer-grained way of categorizing types of business solutions, and flexibility with methodologies to fit the best approach for a given solution type.

What Worked for Transactional Systems Won’t Work for Innovation Solutions

Collaboration and Knowledge Management initiatives are not readily planned using traditional project management methods – they tend to follow an ‘emergent’ pattern that is typically non-linear and somewhat unpredictable.   A traditional planning style, with detailed deliverables, work steps, activities and due-by dates must give way to a more iterative and organic approach.

Social Media Projects Should be Led

You cannot mandate participation in a community – you can invite participation and create reasons to do so. You cannot schedule a date by which a given percentage of a community will be collaborating on a wiki, for example – you can only set expectations, model desired behaviors, and create good reasons for people to become active users of the wiki.  Then you must reevaluate the results and adjust the approach in the light of experience.

Recognizing the Hard-Won Battle – and the Need to Fight New Battles

It seems that sometimes the battle of getting from Level 1 to Level 2 Business-IT Maturity is so hard won, and the win so apparently fragile, that leaders hang on to the methods that got them to Level 2.  This is about being really good at solving yesterday’s problems.  It’s a different world today, and the ways that technology and information can be exploited for business advantage demand different approaches.  Don’t let the trappings of Level 2 restrict your ability to get to the next level!

Enhanced by Zemanta

 

COBIT – Good News… Bad News!


COBIT is described by its creators, ISACA, as a “Framework for IT Governance and Control.”  Celebrating it’s 15-year anniversary, COBIT provides an excellent framework for helping bring IT under control.  In ISACA’s own words:

COBIT is an IT governance framework and supporting toolset that allows managers to bridge the gap between control requirements, technical issues and business risks. COBIT enables clear policy development and good practice for IT control throughout organizations. COBIT emphasizes regulatory compliance, helps organizations to increase the value attained from IT, enables alignment and simplifies implementation of the COBIT framework.”

With Version 5 being released this year, COBIT 5 will consolidate and integrate IT value delivery and IT risk management into the COBIT 4.1 framework.

So, You Want to Increase IT Maturity?

For IT shops of relatively low maturity, COBIT provides an effective framework and body of intellectual capital for implementing or improving IT processes and controls.  It can help avoid a great deal of ‘reinventing the wheel’ that so many IT shops get into, developing IT processes from scratch, or living with processes that do not integrate properly and propagate IT organizational silos.  The danger here, though, is that simply licensing a set of process descriptions is by no means equivalent to adopting them.  If people don’t really understand the processes they are supposed to be following, or if they aren’t completely bought into the need for and value of those processes, then having scads of process descriptions and related documents is not going to ensure a controlled IT environment.

Oh, You Want to Reach High IT Maturity?

I have blogged at length about Business-IT Maturity and have described a simple 3-stage model of both Business Demand Maturity – the business ‘appetite’ for IT, if you will, and IT Supply Maturity – the necessary IT capabilities to satisfy business demand (at lower maturity) and to shape and stimulate business demand (to reach higher maturity).  I’ve also written several posts on what I refer to as ‘sticking points‘ or traps that IT organizations fall into when they are in the middle levels of business-IT maturity. (I’m reminded of the proverbial ‘gumption traps‘ that Robert Pirsig so eloquently describes in his exploration of the metaphysics of quality, Zen and the Art of Motorcycle Maintenance.)

Unfortunately, I’ve found that COBIT can easily create one such trap.  While it can be an effective way to get from Level 1 to Level 2 maturity (on the 3-stage model), it will not take you from Level 2 to Level 3, and can, in fact, inhibit movement towards high business-IT maturity.

Let me try an analogy.  Imagine a car driver who is taught how to drive around a city and diligently follow all the rules and regulations of the road, including speed limits.  Then put that driver into a racing car and expect them to keep up with other racing car drivers on a race track.  Not only will they be unable to keep up, they will likely wreck the car and hurt themselves, unaccustomed as they are to the finer points of fast driving, and unskilled in high speed steering techniques.  Note, the racing car driver is still perfectly able to drive in the city and be compliant with the rules of the road, she has learned additional skills to win races and avoid high speed crashes.  Our novice, city-trained driver has not learned these skills.

This is the COBIT trap – it will take you so far, but, absent further skills and enhanced processes, will not take you further.

I’m expecting this post to be controversial, and the COBIT bigots to attack my heresy, so please, bring it on!

Enhanced by Zemanta

Account Teams and Business-IT Relationship Management


I’ve posted quite frequently on this blog about the role of the Business-IT Relationship Manager. It’s a key role – crucial, in fact, at mid-levels of Business-IT maturity.  It’s a role that typically does not work well at lower maturity, yet is essential to reaching higher maturity. It’s also a role that is hard to get right!  But went you get it right, it can contribute significantly to business value realization from IT assets and investments.

An Account Teaming Approach to Relationship Management

I’ve found myself re-immersed in the Relationship Management (RM) domain lately.  I’m working on a significant RM development program with one current client, and helping another client fine tune their IT Operating Model.

With the first client, I got involved in a benchmarking exercise, going back to two former clients where I had led extensive RM training a few years back.  The purpose of the benchmarking was to find out how their RM approach had evolved, what was working well, and where they still had challenges.  In both cases, the clients had converged on an Account Management Teaming approach – essentially, a set of business unit-facing account teams comprising a very senior Relationship Manager (rarely called that, by the way), a Solutions Manager and an Enterprise Architect.

In the client where we are fine tuning the IT Operating Model, one such account team had formed fairly naturally.  Nobody told them to organize that way.  One of the RM’s met with a business architect and a solution manager and decided they needed to set time aside to meet and talk and strategize in order to present a cleaner, simpler face to the business client.  They wanted to be more deliberate and proactive in shaping business demand rather than simply respond to it.  They saw the formation of the account team as a sort of experiment.  They did not ask permission – just went ahead and tried it.  (I’d describe this as a fairly sophisticated client in an information intensive industry, with an exceptional quality of IT leadership and management.)

This Seems to be Working – Let’s Generalize It!

I met recently with the account team and other architects, RM’s and solution managers to talk about how to generalize the model and duplicate it for the other business units and their RM’s.  We analyzed what had changed as a result of the account team approach – both from the perspective of the individual IT roles, and from the business client’s perspective.  It was an impressive story with impressive results.

So, how to ‘codify’ the approach and generalize it?  The responses from the account team members were surprising and distressing on the one hand, yet obvious and comforting on the other.  Their counsel was, “Don’t try to codify this too much.  It won’t work!”  and, “Remember, we formed into a team because we wanted to, not because we were told to!”

Not So Fast, Tonto!

The business-IT interface is an extremely complex space.  The Account Teaming approach works because it is organic, and was emergent.  It works because the team members have mutual trust and respect.  It is the role of the team that is important and brings the magic, not the roles of the team members.  They talk about “having each others backs covered.”  About the fact that the client executives know that they can talk to any of the team and reach the whole team at the same time.  About the fact that any business-IT conversation quickly and automatically gains the perspectives of enterprise architecture, solution delivery and relationship management.  The business executives don’t need to be concerned about who to call for what.  Nor do they have to sit down with five IT folk to get anything done!

The Power of Self-Organization

Ralph D. Stacey, in his great book, “The Chaos Frontier” defines Self-Organization as:

A process in which the components of a system in effect spontaneously communicate with each other and abruptly cooperate in coordinated and concerted common behavior.”

I believe that viewing organizational spaces such as the business-IT interface as a complex system, operating at the ‘edge of chaos’ (scientifically speaking) reveals the insights that:

  1. Variety, randomness, paradox, information, and interconnection are sources of creativity.
  2. Organization is a natural, spontaneous act – to force otherwise is not sustainable or effective.
  3. Systems have a capacity to self-organize to great effect – given the opportunity to do so.

The danger feared by the Account Team was that as an organizational consultant, I would take the model and create organizational charters, role descriptions, competency models, and so on, and in so doing squeeze the life out of the account team concept.  And I use the word “life” deliberately.  Everything we know about complex emergent behavior tells us that for life forms such as this type of account team to really work, they have to behave like living organisms – with porous boundaries, guided by a common sense of mission and purpose, a ‘genetic code’ if you will, not sealed off from their world by hard boundaries and deterministic rules.

Image courtesy of The Savvy CIO

Enhanced by Zemanta