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 People Insight and licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

 

Enhanced by Zemanta
About these ads

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

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

Four Common Mistakes in IT Portfolio Management


Among my most popular topics, week after week, is Portfolio Management.  It’s a key discipline, especially crucial in driving Business-IT Maturity past the tricky mid-point where many IT organizations tend to get stuck.

IT Business Edge has just published a short slideshow on “Four Common Mistakes in IT Portfolio Management“, re-purposing a post of mine from January 2008.  I think they did a great job simplifying and bringing to life some of the key points in the original post.  Enjoy!

Enhanced by Zemanta

Increasing Business Value Through Demand Shaping


walk-past-no-coffeeA key role for IT leaders, especially during recessionary times, is Demand Shaping.   A perennial reality in the business-IT world is that demand seems to exceed supply.

Of Backlogs and Early Cloud Computing

When I entered the field of IT back in the 1960′s, the term “backlog” was pervasive – that huge list of requests we could not get to until supply resources freed up.  Around the same time, and partially as a result of these huge backlogs (often measured in months or even years!) time-sharing and service bureau’s were the rage.  Often they would install terminals for you for free, provide access to so-called Fourth Generation Languages, data analytics, simulation and modeling tools, and let you “pay by the drink.”

Long term, this may not have been the most cost effective approach, but it let “end users” (as we called them back then) get access to the tools and computing power they may not have otherwise had access too.   I remember doing some work for a large enterprise that ran movie theaters.  I needed to model the economics of dividing up cinemas from single screen (which was the only model in the UK back then) into mutli-screen theaters – an approach called ‘multiplexing’ today.  I used a financial modeling tool called PROSPER through a service bureau.  I was learning the tool while I was building the model, so it took me a while to get it all working.  I remember getting to my 30th iteration of the model before I saw the first service bureau invoice, and on seeing all the zeroes following the pound sign, realizing that, “I had some splainin’ to do” as Ricky Ricardo would have said at the time!

But the results were important to the company, and they were happy to pay the invoice without complaint as it validated a major strategic shift for them, and they became one of the pioneers of the new movie theater model in the UK, capturing significant market share from competitors, and driving great profits for many years.  Had I responded to their request for the analysis with, “IT does not have the capacity just now, we’ll get to it in 18 months,” at best, I’d have had an unhappy customer.  At worst, we’d have watched a competitor beat them to the punch!  On-demand, cloud computing (in its earliest form) provided me the flexibility to satisfy demand without capital investment or undue delays.

Shaping Demand Rather Than Accepting It

Perhaps the more interesting story behind the cinema multiplexing modeling story above is how it came about.  I was at the time a Systems Engineer for ICL – then the leading British computer company.  I was working with a Sales Engineer.  The movie theater enterprise (actually, this was just one business in a broad range of consumer businesses) was his key account, and he was working hard to convince them to buy a larger computer.  He came up with the strategy of multiplexing (I think he’d been to the US and had first seen it there) and took the idea to his customer with the offer to find a free resource (yours truly!) and do the necessary modeling to analyze the financial implications.  (Note the irony here that we both worked for Britain’s largest computer company and that I had to go to a service bureau to get access to the computer cycles!)

The point is, that sales executive was shaping demand for his customer – bringing ideas to create demand.

Two Ways to Drive Business Value Through Demand Shaping

In the example above, demand shaping was through the relationship manager bringing ideas to his customer.  This is a technique familiar to all of us (at least, in the US) used by pharmaceutical companies to let us know about medical conditions we may not even be aware of and for which they have a potential remedy – even if we can’t go out any by those remedies.  We have to ask our doctors whether the treatment is appropriate for us.

The second method those in relationship management roles use demand shaping is when the customer tells us their ‘demand’ and we deflect it by suggesting a solution that might be of higher value, or, at least, pointing out that the requested ‘demand’ may not deliver value sufficient to justify the need.  This is the more common opportunity for demand shaping, and typically the trickier role to successfully pull off.  If we are not careful, it can be seen as being unresponsive or uncooperative.  It might mean elevating a one-off and/or siloed need to a more enterprise-wide solution.

Anne, that’s an interesting request, but perhaps we can kill several birds with one stone if we provide a solution that addresses more than the needs of your department?”

To the customer, that might mean delays as we work through enterprise-wide governance processes, or work the politics to enroll other departments in the solution.  In these cases, pushing back by the relationship manager requires intestinal fortitude, skills in the art of persuasion, and political savvy.  But such is the lot of relationship manager – shifting from ‘order taker’ to ‘valued business partner’, from ‘account executive’ to ‘agent of enterprise solutions and business value.’

How often are you simply in the role of order taker?  What could you do differently to position IT capability for value realization?

Getting Control Over Business Demand – How to “Just Say No!”


just-say-noDid you ever feel that some of the things you are asked to do by your business partners just don’t make sense?  That they won’t deliver value that truly justifies their cost?  I find this to be a common issue.  And it’s not just the questionable value associated with some of these requests.

Low value demand:

  • Carries with it an opportunity cost – resources working on clarifying and satisfying low value demand are not available to stimulate and satisfy higher value activities.
  • Fosters a ‘master-servant’ and ‘order-taker’ relationship between business and IT which in turn limits that relationship’s ability to grow into a more strategic and value-creating partnership.
  • Order-taking behavior misses out on important opportunities to raise business-IT savvy – to raise business awareness of information and IT possibilities for value creation, or to raise IT awareness of where and how the business can leverage information and technology in important or significant ways.
  • Typically backfires on IT by creating an undercurrent sense that ‘IT costs too much and delivers too little’.
  • Creates the feeling that the person taking the order adds only cost, not value, to the business-IT relationship, often leading to a vicious cycle of weak relationship managers not receiving the training and development they need to be more effective.

I think there are all sorts of historical reasons why we get into this bind, mostly associated with low business-IT maturity on which I’ve commented substantially over the last 15 months or so.  But I believe the economic downturn presents a wonderful opportunity for the IT professional to get back in front of, and in control of business demand.

Saying ‘No’ by Saying ‘Yes’

As nonsensical as this sounds, there are ways of saying ‘no’ that don’t sound like ‘no’ and can lead to a far more constructive conversation and a more productive outcome.  I’ve worked with The Second City improvisation group in client workshops, where they taught us the simple skill of re-framing a  ‘No” into a “Yes, and…”  With a little practice and the right mindset, you can take a low value request (e.g., please produce a report that shows sales trends by sales person by region over the last 6 months) and turn it into something with a lower cost-to-serve, higher business value, and an improved customer experience.  “That sounds like a useful report, and my guess is that in the current economic climate, you’re going to be needing all sorts of analyses to help drive sales performance improvement.  Given that, perhaps it would be more useful to you if we created a data warehouse with all the current and historical sales data, and showed you how to use the report-writing tools to create just about any report you are going to need.  Let me show you an example of how easy that is, and how empowering it can be – you’ll be a company hero for your understanding of the sales data, and your insight into what it means!”

Now, my example is, of course, trivial, but hopefully provides a sense of what can be done.  Saying ‘no’ is typically seen as non-constructive, lacking service orientation, obstructionist and generally annoying.  Rejecting a bad idea by smoothly and collaboratively turning it into a good idea is seen as constructive, service oriented, and satisfying.

Think back over times when you’ve had to say ‘no.”  Think about those times when you finessed the situation, using your best zen instincts that led to a positive outcome?  Compare those examples to the times where you were less elegant in how you handled the situation.  Could you have offered a better alternative?  Could you have better explained your rationale?  Could you have made the requester feel better about the outcome?  Finally, look for opportunities to practice and use this skill.  To quote Standford Professor Paul Romer, “A crisis is a terrible thing to waste!”

Why IT Might be Slow to the Web 2.0 Collaboration/Innovation Party


partyLately I’ve been spending time with several IT teams from global Fortune 500 enterprises who are charged with fostering collaboration, innovation and the other hoped-for outcomes of Web 2.0.  It’s been a fascinating experience – plenty of good news, but some aspects I find frustrating.  More importantly, I believe these are things that are slowing progress in exploiting Web 2.0 et al in the enterprise context.

For most companies, the necessary infrastructure, while mostly in place, is not fully there.  Desktop software may not be at the right level.  Videoconferencing capabilities are first or second generation, and need to be upgraded to tap the full potential of today’s telepresence and high definition video.  Instant messaging, previously banned as a perceived “renegade, redundant and dangerous technology is now seen as a useful tool, but the IT infrastructure must now be tweaked to embrace it.  Early implementations of SharePoint that served as interesting experiments, must be updated and redeployed to take advantage of the latest release and goodies.  More complex initiatives such as virtualization, unified communications, shifts from perimeter-based to asset-based security take time, energy and investment to sort through.  Collaboration strategies tend to be emergent rather than holistic,
IT- more than business-centric, push rather than pull, infrastructure rather than application focused.

The good news is that for the more forward-thinking companies, these infrastructure initiatives are funded, resourced and underway.  The people leading them are the best and brightest from the IT infrastructure ranks – they know what they are doing, and move assuredly through this complex space, checking off important milestones, and celebrating successes along the way.

The more frustrating, and ultimately limiting aspects are around the demand management (especially, stimulation/seeding) and application (especially value capture) of Web 2.0 – how to ensure that the emerging collaboration infrastructure is actually used, and used productively and creatively.

A couple of points.  Without the right infrastructure, Web 2.0 doesn’t work, or doesn’t work well enough to sustain itself – it is the table stakes.  But, a shyness in addressing the broader landscape of collaboration and innovation across the enterprise and its ecosystem ultimately limits the value of the infrastructure.

I use the word “shyness” with some thought – there is literally a shyness about getting into things that are thought of as “really needs to be in the business.”   The Catch-22, however, is that without IT leadership in demand shaping/management, you might not have the exact infrastructure you need to really tap the power of the emerging collaboration capabilities.  And I’m taking “infrastructure” quite broadly to include all the shared components and services that support Web 2.0 and its inevitable implications (e.g., Cloud Computing).

So, my recommendations to these teams typically include:

  1. Keep going with the infrastructure plans and deployments!  Celebrate the infrastructure, market its capabilities, keep up the great work!
  2. Step back and look at your broader collaboration strategy.  What other projects or programs are underway that impact or are impacted by this initiative?  What other projects or programs are needed to ensure success?   What does success look like?  How would we measure it?
  3. Add a demand shaping/demand management perspective to the collaboration initiative.  Wrap it into the overall collaboration strategy and plan.
  4. Expand the collaboration initiative team and brief/charter to bring in the business and customer/user perspective, and some “Net Gen” people or really understand how the Web 2.0 world works in the social/consumer space.
  5. Foster adoption from the grass roots up.  Think “chaos theory” and “emergence” – but don’t lose sight of the fact that we are human and ultimately, political and social animals.

IT Pros – What Will Become of Them?


Ben Worthen had a great post last week in the WSJ Business Technology blog entitled “Tech Pros: The Next Dinosaurs?”  Ben cites Nucleus Research’s Rebecca Wettemann:

It’s the logical consequence of two interrelated trends: the average worker becoming more tech savvy, and tech companies realizing that appealing directly to workers is as – if not more – important than appealing to IT management… There was a time when IT departments could get away with forcing employees to use complicated and hard-to-use software. The average worker didn’t know that better alternatives were out there. But as workers gain experience with consumer-focused software – either in their personal lives or at the office – they’re starting to realize that software can be easy to use and quick to get started on. It started with productivity boosters like instant messaging and collaboration software, but it’s crept into the realm of software that’s traditionally the realm of IT departments, such as sales automation.

In the language of Business-IT maturity often cited on this blog, I find that business demand in general is maturing quickly, and IT supply, as defined in terms of the collective supply (hardware, software, services) is maturing alongside demand (perhaps just slightly ahead of demand).  However, if we consider IT supply through the lens of any particular IT organization as opposed to collectively, then to Ben Worthen’s and Rebecca Wettermann’s point, progress is not so rapid or so obvious at many IT organizations.  I’ve referenced before that some IT shops seem to be stuck in time warp – in an age of mainframe programming and big ERP application packages, of taking orders from business partners and delivering against those orders, no matter what the potential business value.  Innovation and collaboration are not seriously visible on their agendas, and notions of measuring business value of IT investments are as foreign as notions of flying saucers and apparitions.

It is the IT pros in these low maturity shops – especially those without a real ambition to drive up both business demand and IT supply maturity that I fear for.  They are becoming the dinosaurs.  They evolved in a time when you could get by with a fairly weak set of IT capabilities, and lay the blame on the business for “not getting it!”  I come across many such IT pros who are cruising along with an ‘entitlement’ mentality.  I have never been more convinced that their time is limited.  They will be the ones that will be outsourced, off-shored and ultimately, will have a hard time staying actively employed.

So, What Comes After Level 3 Business-IT Maturity?


I had a question from a colleague recently that I’d like to address in this post.  She asked, “I’m going to ask a possibly ‘dumb’ question, but since I believe that there are no dumb questions I’m asking it anyway…  Since level 3 is constantly evolving i.e., today’s Level 3 will be tomorrow’s Level 2 etc., isn’t it always going to be a moving target?  If I was a company at Level 3 Business-IT Maturity, where IT and business act as one in strategy, planning and execution, and so on,  won’t you eventually fall to Level 2 if you don’t keep changing? How do leading edge companies do that?”

As she noted, there are no dumb questions, and this is actually a very smart question.  First, a reminder.  We recently updated the 3-level Business-IT Maturity Model to more clearly show that it is really made up of 3 separate ‘S’ shape, or ‘learning’ curves.

new-bus-it-no-detail.jpg

The significance here is the discontinuities that occur between levels.  To simplify, Level 1 was about learning to leverage (business demand) and manage (IT supply) the universe of mainframe computing.  The big discontinuity that threw everyone was the entry of the Personal Computer, and the seismic shift to client-server computing.  So, Level 2 was the same as Level 1, but for client-server computing.  The seismic shift today is ultimately caused by the Internet as a computing platform, with all its consequences, including Service Oriented Architecture, Software (and Hardware) as a Service, Cloud Computing, Web 2.0, and so on.  Level 3, then, is about learning to leverage (business demand) and manage (IT supply) the universe of Internet computing. 

The fact that this is a discontinuity gives us choices about how, when and why we jump from the Level 2 curve to the Level 3 curve.  Some are jumping early, and for everything (e.g., Google, Amazon.com).  Some are jumping early for some things (e.g., ING Direct, but not ING), and most are not jumping at all at this time.

Back to my colleague’s question.  The way we are using the Business-IT Maturity Model, from the perspective of today, high Level 3 means we have mastered the new computing paradigm, both from a business demand and IT supply perspective.  There will have been such a confluence between what we today know as “business” and as “IT” that these things will be inextricably interwoven.  Some will say we are already at this point, but I beg to differ.  These things are deeply interdependent, but still most organizations have IT specialists (internal or external) who are responsible for “doing” most IT development and support work.  On the other hand, most “business” people are ‘users’ of IT but not ‘producers.’  I believe that by 2017, the focus of this blog, that situation will have changed dramatically, and most organizations will be well into the Level 3 space.  As she noted in her question, they will have to work at staying at at high Level 3 – entropy, anarchy and other forces are always working to undo the good work of management.

Note, the ‘S’ curves become asymptotic to the horizontal – but never become horizontal, so I could answer my colleague by saying, “There is no ‘after Level 3′ – just a long, slow, journey through it.”  Or, I could say, “There will be some other seismic shift, as yet unanticipated (at least by me!) and we will transition through another discontinuity.”

What I actually said was, “Level 3 does change over time – when everyone has reached Level 3, the model will no longer be valuable.  As an analogy, once you are an adult and stop growing, you tend not to obsess the way kids do about how many inches you’ve grown over a year.  The Business-IT Maturity Model will have outlived its usefulness, I will be retired and living on a Caribbean Island, and some other blogger will be all in a lather about some new maturity model!”  See, it was not a dumb question after all!