Monthly Archives: March 2012

IT Leaders – Get ‘With it’ or Get Out of the Way!


This short post was inspired by Dion Hinchcliffe‘s recent post on the Consumerization of tech: The new enterprise disruptor.

Dion notes:

One trend has emerged with clarity from the discussions this year about the tidal wave of consumer tech moving into the enterprise: It’s profoundly reshaping the IT landscape in most organizations. Just a year ago, Bring-Your-Own-Device (BYOD) was barely on the strategic radar, yet a recent CDW survey of the federal government shows that as of last month, nearly half (44%) of federal employees now use a personal device for work purposes and that 62% of agencies now permit the use of worker provided devices.”

I’m not totally sure I believe the numbers – they seem somewhat aggressive to me given the typically conservative nature of federal government.  But Dion goes on to note:

Though data are still emerging about the trend in all industries, the early numbers in the private sector are even more dramatic, with a new report from Harris Interactive claiming that 81% of firms have already adopted some form of BYOD policy.”

Again, the numbers seem way aggressive per my conversations with IT leaders in the US, but the direction is clear.  And the movement now has its own acronym – BYOD (Bring Your Own Devices)!

A Compelling Argument…

This was the paragraph that most caught my eye:

This new mindset around IT is one where users tend to lead the IT charge. Not always, but increasingly so. They have frequently occurring technology needs on the ground. They also have the resources, time, and urgency to find the technology, or least more than the IT department does. So part of the consumerization story is a pull model of easy-to-access IT. Most of the time, it’s what they find in their browsers or app stores and on the shelf at their local mobile store or online electronics retailer.”

Bingo! The need is with the users. The funding is with the users. The resources are with the users. The urgency is felt by the users! So where is IT in all of this?

IT – The Protectors!

In spite of the rosy data Dion cites, I’m mostly seeing IT leadership either in denial (“This too shall pass!”) or anxiously assessing all possible risks and how to mitigate them.  Clearly, there are all sorts of risks – some of which we have yet to fully understand.  Infoworld’s recent BYOD: A world of pain awaits IT (subtitled: “Seasoned IT pros discuss the slings and arrows IT must endure to embrace bring-your-own-device policies”) lays out a litany of risks facing those who adopt BYOD policies.

The Real IT Choice

I believe the Consumerization of IT should be seen for what it is – a game changer for the world of corporate IT organizations.  One that will shape the future role of corporate IT and the future roles of IT professionals.  One that will unleash the creative power of IT in ways not previously seen, and that will have significant upside economic implications. This blog is titled “IT Organization Circa 2017″. That is 5 years away. I think those 5 years will see a massive shift in the center of mass of enterprise computing. Corporate IT can lead that shift – and stay relevant. Or they can study every nuance of every risk and put up barriers to change.  The change will happen anyway, and they will become all but irrelevant.

 

Related articles
Enhanced by Zemanta
About these ads

Who “Owns” the Business-IT Relationship?


My recent post on Questioning the Role of the Business Relationship Manager (BRM) has sparked some interesting discussions. One revolves around the question of “owning” the business-IT relationship. It’s a tricky question for several reasons:

  1. “Ownership” is a tricky term in this context – just what does it mean to “own” a relationship?
  2. There are at least two sides to any relationship – do all parties to the relationship see it in the same way?  If you “own” the relationship with me, do I recognize that and behave accordingly? Do I need to?
  3. Context is everything – what works well for one company/one situation might not work at all for another!

Business-IT Relationship Issues

First, a small anecdote to frame the relationship ownership question. I recall interviewing a business executive about his needs and expectations from his IT organization. He said:

The last time I needed to talk about a possible new IT solution, I set up a meeting with my new Business Relationship Manager. Seven people from IT came to that meeting!  We had to find a conference room and move the meeting!  By the end of the meeting, most of those present had said nothing, but they had all furiously taken notes – presumably each capturing the same things.  No wonder IT costs too much and delivers too little!”

Too Many Cooks…

It’s a familiar situation – understandable but not acceptable! I imagine the seven IT folk included the BRM, a couple of Business Analysts, an Enterprise Architect, Project Manager and a couple of ‘subject matter experts‘.  They all wanted to be there so nobody would miss anything.  Perhaps they thought a “show of force” would impress the business client.  (In fact, it had the opposite effect!)

Too Many Specialists…

Yes – IT is complicated stuff, and ultimately, you have to get it right – 80% availability is not adequate for most IT solutions! This has led to an IT world that is full of specialties.  That is fine – but do all the specialties need to be represented in an initial meeting with the client?  How are the client’s needs best handled in terms of IT relationships?  How can we create an exceptional experience for our client?

The Need for a Single ‘Focus’ of Contact

The needs of both the business group and the IT organization are best served when there is a single ‘focus’ of contact – an individual who shepherds all contacts between business and IT.  This is one of the roles of the BRM.  Note, they are not a “Single Point of Contact” (SPOC), but they do “own” the business-IT relationship.  This means:

  1. They are accountable for the success of the business-IT relationship.
  2. As such, they need to be aware of all contacts between business and IT.  So, if I’m an Enterprise Architect, and I run into a business executive in a corridor and he mentions some specific need or IT issue, it is my responsibility to let the BRM know.
  3. Similarly, as BRM, if I hear something through my business relationship that the Enterprise Architect should be aware of, it is my responsibility to let them know.

A good model to consider is the one followed by most consulting firms. They typically operate to a ‘rule of engagement’ whereby each client or prospect is ‘owned’ by a specific partner. If someone other than that partner has contact with the client or prospect (which was absolutely fine!) then they must ensure that the partner is aware of that contact.  This is seen as a common courtesy, both to the partner that owned the relationship and to the client – and a means to ensure an efficient, transparent client relationship. More importantly, it fosters strong relationships and a deep client knowledge.

Enabling the Business-IT Relationship

Business executives are not served by specific individuals – they are served by teams representing many facets of IT – operations, solutions delivery, support, training, architecture, and so on.  On the business side, there is typically not just one executive that represents a given business unit or function – there are many.

Taking the friction and noise out of these types of many-to-many business-IT relationships is crucial.  Clarity of the BRM role, their ownership of a given business-IT relationship, and an effective means of capturing and managing the myriad needs and activities are essential mechanisms for a healthy, productive business-IT relationship.

Tools such as Semantic Wikis and Customer Relationship Management solutions such as Salesforce.com can be effective enablers of many-to-many relationships such as those between business and IT, capturing all interactions and facts about the relationship.  Considering the size of IT investments and the business value that is on the line, investments in better managing business-IT relationships seem well-placed!

How clear is business-IT relationship ownership in your organization?  How well does it work?  Could better clarity around relationship ownership and rules of engagement improve the business-IT relationship?

 

Graphic courtesy of SmallBusinessFriends

Related articles
Enhanced by Zemanta

Do You Really Need an IT Transformation?


I’ve been part of many organizational transformations over 30 years of management consulting.  Most were with IT organizations, many were with HR organizations and some were transformations to global shared services.

I used to be excited by the idea of an organizational transformation.  When a client or prospective client used the word “transformation” I would salivate!  “Them’s fighting words!”

But nowadays, I generally shy away from the “t” word. Here’s why.

The Trouble With Transformation

There are several reasons why I don’t like the word “transformation”:

  • For most of the organization, it can feel demeaning, effectively sending the message, “You aren’t any good and you have to transform!”  That can be a bitter pill to swallow (and is almost always untrue – at least in part.)  Not the best way to enroll people in change!
  • From the perspective of 2012, most people have been part of at least one organizational “transformation,” – it was painful and ultimately failed to deliver on its promises.  Announcing yet another transformation typically elicits the response, “Here we go again!” Organizational transformations tend to promise too much and deliver too little.
  • Transformation implies a journey from current state to a future state by going through some kind of radical (transformational?) change.  Increasingly, organizations that are healthy, effective and growing in capability are in a state of constant change and adaption.  The current state → transformation → future state model no longer applies, so why delude ourselves and confuse everybody about having a transformation?
  • Transformations are highly disruptive. They are disruptive because they assume that someone (or group) knows what the future state will look like – “all we have to do is to transform into that future state from our current state!”

To this last point, the reality is that organizational behavior is way too complex for anyone to “know” what the future state will look like.  Perhaps, way back when, in the days of hierarchical, authoritarian organizations in the early industrial revolution, a determinist approach to operating model design was feasible – especially if you thought you were transforming into a future state that would then be ‘frozen.’  We may well know the characteristics we would like to see in the future state, and the kinds of behaviors we’d like to experience, but exactly how we will get there, and what our Operating Model (processes, roles, rules of engagement, governance, services, metrics, etc.) will look like is far less certain.

I think organizational and operating model design nowadays is more about emergence – point people in the right direction, then get out of their way!  To that end, we need to define that direction:

  1. Outcomes we’d like to see
  2. Capabilities we need to achieve those outcomes
  3. Processes, roles, competencies (i.e., knowledge, skills and behaviors) we need for those capabilities
  4. Management and governance systems

Then we need to:

  1. Over-communicate items 1 through 4 above – engage people in really understanding, co-developing and creating organizational clarity.
  2. Empower them to do what is necessary, make sure they have the right tools and infrastructure and get out of their way.
  3. Enable them with a meaningful way to participate in shaping their future – we have found that a semantic wiki can be a great vehicle to achieve this (see this post and the earlier posts (here and here) in the series).

Image courtesy of Wikipedia

Related articles
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