The Business and IT Love Requires Lubrication

This article was contributed by Peter Lijnse, Managing Partner and IT Management Consultant at Service Management Art Inc.

For years we have been talking about Business-IT alignment and to be honest limited organizations have successfully accomplished that. In most organizations the relationship is “dry”, which causes friction. We are getting to the point where we need to realize that the love between the Business and IT requires more than just alignment… we need to make sure that the fusion between business and IT is well lubricated to avoid friction.

(Note: any weird images in your head are yours and yours alone).

Focusing on the Business Relationship Management capability in the enterprise will help the Business-IT Love, but just focusing on the capability is not enough. We see relationship management in different levels in the organization:

Peter Lijnse
Peter Lijnse
  • Service Desk
  • Technical Analysts
  • Project Managers
  • Program Managers
  • Business Analysts
  • IT Executive Team
  • Enterprise Architects
  • User Acceptance Testing
  • etc.

Most of these roles are focused on the IT organization. The problem is there are pockets of IT in the whole enterprise, examples are:

  • Shadow IT groups (to use a new buzz word)
  • Technology that supports the primary business process
  • Super Users that represent a department
  • etc.

On an operational (and tactical) level in the IT Service Provider we often have roles in place that talk to the business, but is it often unclear how this is done on a strategic level.

The consumerization of IT and the business becoming increasingly technology savvy and self sufficient, drives the need to the convergence of the Business and IT. When we talk about Business IT alignment, we need to align all these groups… to make the overall enterprise successful.

The BRM Role

The role of the strategic Business Relationship Manager (BRM) role is a connector, facilitator, and orchestrator. I like to translate that to “lubricator” to make the connection between the Business and IT working smoothly. This role needs to be assigned in organizations. Not assigning the role in the organization leaves the relationship with the business mainly focused on a tactical/operational level. Or the activities are executed with other roles (like for instance the enterprise architect), which often means they are not able to focus on what they should be doing.

This role is accountable for the ensuring that the strategy of the business and IT are aligned and work smoothly. The BRM represents the business to the IT service provider, and the IT service provider to the business.

The purpose of the Strategic BRM Role is to stimulate, surface and shape business demand for a provider’s products and services, and facilitate the capturing, optimization, and communication to maximize business value captured from the provider’s products and services (as defined by the BRM Institute).

The activities for the BRM can be categorized in four main groups (processes).

Demand Shaping

Aligning the business expectations for demand with the service provider offerings and portfolio. The stakeholders in both the Business and the IT Service provider are defined, these stakeholders will help shape demand and influence the supply capabilities. The BRM plays the role of facilitator.

Example questions to focus on:

  • How does demand enter the value chain?
  • How are decisions made when demand exceeds supply?
  • How do we handle demand changes?
  • How is the backlog of demand tracked?

Exploring

These activities focus on identifying and rationalizing demand. The BRM role helps apply business and technology trends to facilitate discovery and demand management.

Example questions to focus on:

  • What demand is not on the radar and should be?
  • How much can we invest in exploring?
  • How do we break down demand in workable initiatives?
  • How can we innovate while operating the current services?

Servicing

As orchestrator, the BRM ensures engagements that shape business demands and then translates them into effective supply requirements. During the servicing process, the BRM facilitates business strategy and road mapping with the business as well as facilitating portfolio and program management for the provider organization.

Example questions to focus on:

  • How do we ensure that through use of the services the value is realized?
  • How do we ensure the service provider understands the value of the services they deliver?
  • How do we maximize business value, while taking into account risk and cost?

Value Harvesting

The value harvesting process also includes activities to track, review performance, identify areas that increase value of business outcomes and initiate feedback that triggers continuous improvement cycles. This process provides stakeholders insights to results of business change and initiatives.

Example questions to focus on:

  • Where do we see waste in the value chain? How do we reduce waste?
  • How do the stakeholders participate in realizing value?
  • How is value measured and monitored?

NOTE: As seen in these activities, there is a requirement to have Portfolio Management in place. This is where we see the requirement for making sure all parties work well together. In the Program and Project part of the IT Service Provider we often see a Portfolio – a list of opportunities that clarifies the demand. In the Service Provisioning side of IT Service Provider we start seeing Service Portfolios. Capturing what is in the pipeline (link to the project portfolio) and what is currently in production. It is key for a BRM to have access to both Portfolios… and hopefully have a consolidated view. 

Introducing the BRM role in your organization will help with shaping the opportunities for the business and aligning it to the IT’s ability to deliver.

This article was contributed by Peter Lijnse, an IT Management Consultant with over 20 years of IT Management and Leadership Experience. He has in-depth knowledge of IT Service Management and IT Governance in different industries. Peter is also a accredited ITIL, COBIT, BRM trainer. You can read his personal blog here.

Everything is improvement

Traditionally Continual Service Improvement (CSI) is too often thought of as the last bit we put in place when formalising ITSM.  In fact, we need to start with CSI, and we need to plan a whole portfolio of improvements encompassing formal projects, planned changes, and improvements done as part of business-as-usual (BAU) operations.  And the ITIL ‘process’ is the wrong unit of work for those improvements, despite what The Books tell you. Work with me here as I take you through a series of premises to reach these conclusions and see where it takes us.

In my last article, I said service portfolio management is a superset of organisational change management.  Service portfolio decisions are decisions about what new services go ahead and what changes are allowed to update existing services, often balancing them off against each other and against the demands of keeping the production services running.  Everything we change is service improvement. Why else would we do it?  If we define improvement as increasing value or reducing risk, then everything we change should be to improve the services to our customers, either directly or indirectly.
Therefore our improvement programme should manage and prioritise all change.  Change management and service improvement planning are one and the same.

Everything is improvement

First premise: Everything we change is service improvement

Look at a recent Union Pacific Railroad quarterly earnings report.  (The other US mega-railroad, BNSF, is now the personal train-set of Warren Buffett – that’s a real man’s toy – but luckily UP is still publicly listed and tell us what they are up to).

I don’t think UP management let one group decide to get into the fracking materials business and allowed another to decide to double track the Sunset Route.  Governors and executive management have an overall figure in mind for capital spend.   They allocate that money across both new services and infrastructure upgrades.

They manage the new and existing services as a portfolio.  If the new fracking sand traffic requires purchase of a thousand new covered hoppers then the El Paso Intermodal Yard expansion may have to wait.  Or maybe they borrow the money for the hoppers against the expected revenues because the rail-yard expansion can’t wait.  Or they squeeze operational budgets.  Either way the decisions are taken holistically: offsetting new services against BAU and balancing each change against the others.

Our improvement programme should manage and prioritise all change, including changes to introduce or upgrade (or retire) services, and changes to improve BAU operations.  Change management and service portfolio management are both aspects of the same improvement planning activity.  Service portfolio management makes the decisions; change management works out the details and puts them into effect.

It is all one portfolio

Second premise: Improvement planning comes first

Our CSI plan is the FIRST thing we put together, not some afterthought we put in place after an ‘improvement’ project or – shudder – ‘ITIL Implementation’ project.
UP don’t rush off and do $3.6 billion in capital improvements then start planning the minor improvements later.  Nor do they allow their regular track maintenance teams to spend any more than essential on the parts of the Sunset Route that are going to be torn up and double tracked in the next few years.  They run down infrastructure that they know is going to be replaced.  So the BAU improvements have to be planned in conjunction with major improvement projects.  It is all one portfolio, even if separate teams manage the sub-portfolios.  Sure miscommunications happen in the real world, but the intent is to prevent waste, duplication, shortages and conflicts.

Welcome to the real world

Third premise: we don’t have enough resource to execute all desired improvements

In the perfect world all trains would be controlled by automated systems that flawlessly controlled them, eliminating human error, running trains so close they were within sight of each other for maximum track utilisation, and never ever crashing or derailing a train.  Every few years governments legislate towards this, because political correctness says it is not enough to be one of the safest modes of transport around: not even one person may be allowed to die, ever.  The airlines can tell a similar story.   This irrational decision-making forces railroads to spend billions that otherwise would be allocated to better trackwork, new lines, or upgraded rolling stock and locos.  The analogy with – say – CMDB is a strong one: never mind all the other clearly more important projects, IT people can’t bear the idea of imperfect data or uncertain answers.
Even if our portfolio decision-making were rational, we can’t do everything we’d like to, in any organisation.  Look at a picture of all the practices involved in running IT

You can’t do everything

The meaning of most of these labels should be self-evident.  You can find out more here.  Ask yourself which of those activities (practices, functions, processes…  whatever you want to call them) which of them could use some improvement in your organisation.  I’m betting most of them.
So even without available funds being gobbled up by projects inspired by political correctness, a barmy new boss, or a genuine need in the business, what would be the probability of you getting approval and money for projects to improve all of them?  Even if you work at Google and money is no problem, assuming a mad boss signed off on all of them what chance would you have of actually getting them all done?  Hellooooo!!!

What are we doing wrong?

Fourth premise: there is something very wrong with the way we approach ITSM improvement projects, which causes them to become overly big and complex and disruptive.  This is because we choose the wrong unit of work for improvements.

How to cover everything that needs to be looked at?  The key word there is ‘needs’.  We should understand what are our business goals for service, and derive from those goals what are the required outcomes from service delivery, then focus on improvements that deliver those required outcomes … and nothing else.

One way to improve focus is to work on smaller units than a whole practice.  A major shortcoming of many IT service management projects is that they take the ITIL ‘processes’ as the building blocks of the programme.  ‘We will do Incident first’.  ‘We can’t do Change until we have done Configuration’.  Even some of the official ITIL books promote this thinking.

Put another way, you don’t eat an elephant one leg at a time: you eat it one steak at a time… and one mouthful at a time within the meal.  Especially when the elephant has about 80 legs.

Don’t eat the whole elephant

We must decompose the service management practices into smaller, more achievable units of work, which we assemble Lego-style into a solution to the current need.  The objective is not to eat the elephant, it is to get some good meals out of it.
Or to get back to railroads: the Sunset Route is identified as a critical bottleneck that needs to be improved, so they look at trackwork, yards, dispatching practices, traffic flows, alternate routes, partner and customer agreements…. Every practice of that one part of the business is considered.  Then a programme of improvements is put in place that includes a big capital project like double-tracking as much of it as is essential; but also includes lots of local minor improvements across all practices – not improvements for their own sake, not improvements to every aspect of every practice, just a collection of improvements assembled to relieve the congestion on Sunset.

Make improvement real

So take these four premises and consider the conclusions we can draw from them:

  1. Everything we change is service improvement.
  2. Improvement planning comes first.
  3. We don’t have enough resource to execute all desired improvements.
  4. We choose the wrong unit of work for improvements.

We should begin our strategic planning of operations by putting in place a service improvement programme.  That programme should encompass all change and BAU: i.e. it manages the service portfolio.

The task of “eating 80-plus elephant’s legs” is overwhelming. We can’t improve everything about every aspect of doing IT.   Some sort of expediency and pragmatism is required to make it manageable.  A first step down that road is to stop trying to fix things practice-by-practice, one ITIL “process” at a time.

Focus on needs

We must focus on what is needed.  To understand the word ‘needed’ we go back to the desired business outcomes.  Then we can make a list of the improvement outputs that will deliver those outcomes, and hence the pieces of work we need to do.

Even then we will find that the list can be daunting, and some sort of ruthless expediency will have to be applied to choose what does and doesn’t get done.

The other challenge will be resourcing the improvements, no matter how ruthlessly we cut down the list.  Almost all of us work in an environment of shrinking budgets and desperate shortages of every resource:  time , people and money.  One way to address this– as I’ve already hinted – is to do some of the work as part of BAU.

These are all aspects of my public-domain improvement planning method, Tipu:

  • Alignment to business outcomes
  • Ruthless decision making
  • Doing much of the work as part of our day jobs

More of this in my next article when we look closer at the Tipu approach.