Increasing Maturity by Reducing Complexity


There are characteristics of Level 1 and low Level 2 Business-IT Maturity that allow (cause?) the IT environment to become overly complex, and with that complexity comes high cost and low agility.  This complexity is a killer sticking point for getting to higher maturity. 

Let’s first try to understand what it is about the lower maturity levels and why they foster complexity.  Below is a simple form of the Business-IT Maturity model introduced in my second post.

Business-IT Maturity Model

Note that Level 1 demand tends to come from individual business units and functions, rather than by end-to-end business processes.  Recall that this is a business as well as ITmaturity model, at Level 1 the business tends not to be very process-oriented (there are, of course, some notable exceptions, but even then only for “signature” processes that are core and differentiating to the firm).  So, this siloed demand, and IT’s Level 1 “order taking” behavior is met with siloed supply.  (Remember the point in an earlier post that the more mature consultative and business partnership oriented behaviors tend only to become commonplace at mid-Level 2 and beyond).  Also note, that Enterprise Architecture does not really take hold until mid-Level 2, so all this siloed demand has no overarching business process architecture against which to bounce off and react to.

Consider a situation where division/business unit “a” needs a manufacturing planning system (MRP), as does division/business unit “b”, as does “c”, and so on.  The next thing you know, you have many MRP systems, all configured differently, often from different vendors, running on different hardware platforms.  I had one client who even had trouble producing an accurate count of their MRP systems – they got to about 47 different systems around the world, and gave up trying to count.  (They are now in mid-Level 2 maturity, and aggressively moving to global common processes and systems).

We can imagine the complexity of just maintaining that many different systems, and the resource inefficiencies in doing so.  Now imagine you want to add a data warehousing layer – think about the data feeds and interfaces that must be built and maintained.  Suppose that in Level 2, the business, perhaps forced by market conditions, quality problems, or simply by the need to take out cost, decides to implement lean manufacturing approaches.  The underlying systems and platform complexity becomes a daunting barrier – typically perceived as “an IT problem.”  Of course, it is, in many respects, an IT problem – unfortunately created by IT’s natural response to business demand.

There are zillions of other aspects of this complexity, and the reasons for it.  Early Level 1, COBOL or RPGII might have been the programming language of choice.   Later in Level 1, this was supplemented by a Fourth Generation Language such as FOCUS, RAMIS, or MANTIS.  Early in Level 2, C++ was the new language of choice, then Java.  Each of these “flavors of the month” languages left behind them legacy systems, legacy programming and testing tools, and all the other trappings of a development environment to be maintained.

Below mid Level 2, the notion of Programs as opposed to Projects is not well formed, so there is little sophistication in finding and managing the inter-relationships and dependencies between projects, adding to the complexity in the legacy environment.  Make a simple change to one system, and there may be hundreds (thousands?) of “knock on” effects to other systems and interfaces.

Then there is the complexity of change upon change of technology infrastructure – DOS to Windows to NT to XP Professional; Novell to Microsoft; Microsoft to Open Source; TCAM to VTAM to TCP/IP.  The changes go on an on – each leaving a layer of technology and the baggage it implies.  Oh, and then there’s the many acquisitions that are never fully integrated.

So, how do you break out of this complex environment, leave the boat anchors behind, and move nimbly into Level 3?  The answer is in some respects deceptively simple.  I’ll get to it with a story.  About 15 years ago, I was running a multi-client research project on IT transformation.  One of the big success stories back then (with several Harvard Business Review case studies) was BP oil.  They had grown through acquisition and all the other inevitable sins of Level 1 to the point where their IT infrastructure was exceedingly complex, costly and a constraint on business agility.  I was moderating a panel at one of our research workshops.  One of the panelists was a senior BR IT executive – a rather dour Scot with a heavy Scottish brogue.  Someone asked him, “How did you deal with all the legacy systems?”  He said firmly, in his heaviest Scottish accent, “Och, aye – ya just have to kick it in tha teeth!”  And with this one line, he really captured the key truth here – you have to have absolute, take no prisoners, executive determination – a “just do it!” approach to change.  He even told us about a giant CDC mainframe dedicated to scientific computing (for analyzing seismic data).  The IT leadership team had a strong suspicion that most of the scientific computing had migrated to desktop supercomputers.  To prove the point, after several attempts to get people to respond to inquiries about who still needed the CDC machine went nowhere, they simply shut it down, and waited to see who screamed.  One month later, nobody had whimpered, let alone screamed and several million pounds worth of hardware and annual operating costs were decommissioned.

How to you deal with the overly complex IT infrastructures facing many IT shops today?  You just have to kick it in tha teeth!

About these ads

The Business Case as a Value Realization Tool


I want to pick up on the previous post about shifting from a supply constrained to a value constrained business IT model.  I think this shift in paradigm about the IT resource is one of the most critical for getting out of Level 2 and into Level 3 Business-IT Maturity.

In the lower stages of Business-IT maturity, initiatives get approved without much formality around business justification in the form of a business case.  IT acts as order takers – “if the business wants it, we will build it,” up to the point (quickly reached!) where demand exceeds supply.  At that point, we might set up steering committees and prioritization mechanisms, but in the end, it’s the project sponsors with the most clout who get their projects approved.

To get out of Level 1, most IT shops typically implement some kind of business case mechanism to put some formality around the proposing of IT investments, and to enable a more rational approach to prioritization.  At first, the business case is all about helping to make the go/no go investment decision.  This is better than the order-taking, or “squeaky wheel” model, but, frankly, not much!

At some point in mid to upper Level 2, the business case shifts from an approval/prioritization tool to a value realization tool.  Formerly, you put stuff in the business case that you hoped would help get it approved, but you knew nobody would ever look at the case once approval was gained.  There really was little to no accountability for the case, or consequence, or even learning that takes place about hte quality of the estimates and assumptions that went into the case.  As a value realization tool, on the other hand, the estimates are taken very seriously, and accountability is now placed around achieving the forecast benefits.  Of course, the ability to tightly link business benefits to a given project is very tricky in all but the simplest cases.  It becomes somewhat more reasonable to link business benefits to programs, rather than to projects, as programs are, by definition, oriented towards business outcomes.  (See earlier post on Projects, Programs, and Portfolios.)

Even then, the linkage of any given program to specific business benefits is tough.  At low Level 2 Business-IT maturity, the challenge of benefit estimating and linking seems really difficult, so people shy away from trying.  At higher Level 2, there is somehow an acknowledgement that it is tough, and that really we need to think in terms of cause and effect value chains, and “trails of evidence.”  Moreover, the act of thinking this through (at business case development) and engaging the appropriate stakeholders in figuring out the cause-effect chains and trails of evidence is the real key – an act that in of itself brings better clarity, buy-in, ownership for the results (i.e., the value to be realized) and with all that, a better likelihood that the value will be realized.  We will get more into this notion of cause-effect chains, and trails of evidence in a subsequent post.

From ‘Supply Constrained’ to ‘Value Constrained’ Business-IT Model


One of the difficult paradigm shifts that tends to trap IT organizations in Level 2 Business-IT Maturity is the notion that business demand must be constrained by IT supply.  Demand always exceeds supply for IT capacity, so the idea (part of the Level 1 experience) is to set a limit on IT supply, then figure out some way of prioritizing demand against that supply capacity.  Sometimes the the constraining mechanism is IT budget, other times it is IT headcount – either way, the net effect is the same – a bunch of work that the business wants won’t get done, and we hope the prioritization mechanism works sufficiently well that the “right” demand is flowing through and getting address, and the “wrong” demand (low business value) is not.  I’ve rarely seen this work well.

If there is a single line of business, at least demand can be prioritized across the business line, and the mechanisms to achieve this are not too hard to implement.  Typically, however, there are multiple lines of business, and while the mechanisms in each business line may work ok, there are rarely effective mechanisms across lines of business.  This leads to all sorts of dysfunctionality, especially as the enterprise matures and shifts towards more of an integrated business, with common and shared process, compared with the more functional and stove-piped model typical at Level 1.

For example, IT resources get “walled off” against business units – sometimes actually being embedded in the unit.  There’s nothing inherently wrong with the embedding – certainly some IT capabilities (such as Relationship Management) work most effectively when they are really close to the business).  However, when analysts, designers, developers, testers, etc. get “walled off” for given business units, they are no longer available to be shared across the enterprise – they creates all sorts of inefficiencies.  And, from my experience, with the best will in the world, and with competent, well meaning people both in IT and the business, demand will fill that available “walled off” supply no matter what.  A result is that lots of relatively low value and non-essential demand gets filled, while high value demand, both within the business unit with the walled off resources, and in the other business units sits in a backlog (at best) or, more typically, just does not get surfaced because people know there is no hope of getting it filled.  A symptom of this is an IT organization with literally thousands of active projects, mostly small, and with a general sense that IT costs a lot of money and delivers little value.  Such an environment presents all sorts of challenges to real business-IT strategic alignment.

The big breakthrough comes somewhere in Level 2 where there is a shift from this supply constrained model to one that is value constrained.  Let me first describe the theoretical end state of the value constrained model – we will explore the practical realities of moving to this model later on.  At the theoretical end point, IT supply is treated as an infinite resource that can flex its capacity on demand – ramp up to meet high value demand, ramp down when that demand goes away.

The key enablers to move to this model (once the paradigm shift is understood and desired) are to:

  • Prioritize demand based upon business value (which has all sorts of implications for business cases, cost and value accountability, value measurement, portfolio management, etc.)
  • Create an agile and flexible supply capability (which typically means there is a robust global sourcing strategy and management model, key partnerships with global sourcing entities are in place, and the IT organization has become focused exclusively on “core” IT capabilities – usually encompassing relationship management, demand management, value realization, business process improvement, innovation, program management, portfolio management and global talent sourcing.)
  • Add an IT Program Management layer over IT Project Management
  • Add an IT Enterprise Portfolio Management layer over IT Program Management
  • Elevate IT Architecture to Enterprise Architecture
  • Implement an effective business-IT governance model to facilitate cross enterprise and cross business-IT decision making.

I will explore each of these enablers in subsequent posts.

IT Funding and the “Stealth Infrastructure” Trap


Another common sticking point that shows up in IT funding approaches in Level 2is the “stealth infrastructure” trap.  The logic (or illogic!) behind this is, “The business does not understand all this infrastructure stuff (or plug in your enterprise-wide IT improvement initiative du jour – e.g., SOA, Enterprise Architecture) so we will squirrel away funds through other sources to pay for it (e.g., underspend our training budget, add a bit of “slop” to project budgets, add a small margin to steady state service charges, IT research and development activity).

The paradox here is that below high-Level 2 maturity, it is true that the business does not understand many of the IT infrastructure components.  And yet, sheltering them from these arcane issues is to deny them the education they need to become more IT literate, and therefore, more effective in leveraging IT for business value.  Now I’m not saying that you have to expose them to the technical minutiae – but you do have to be able to translate this stuff into business implications.  As a consumer of electric power at home, I don’t need to understand how electrons flow through wire, or how 3 phase electric transmission works, but I do need to understand the risks of ice causing low hanging tree branches to snag transmission lines, and potentially cut the power supply when I least need an interruption!  An educated consumer is a smart, effective consumer, whether that is a home consumer of electricity, or a corporate consumer of Enterprise Architecture.

Another important trick here is to ensure that individual components are packaged together into “bundles” that are meaningful to the business client/customer.  Contemporary IT practice is to use Service Management as the underlying discipline.  We will expand on this important concept in a later post, but for now suffice it to say that the service “bundles” must make sense to the service consumer, and be aggregated at a high enough level to have meaningful business value impact, but be sufficiently granular to enable meaningful “cost-to-serve/value-of-service” trade-offs.  For example, when I onboard a new employee, as a business manager I don’t want to negotiate for and pay for separate services to equip the employee with a PC, a cell phone, an Internet account, passwords, a help desk account, etc.  I want an “on-board new employee” service that might well draw from IT, HR, facilities, and other enterprise-wide services.

If there is any place for stealth infrastructure, it is in an emerging service that I’m trying, as a service manager, to refine – for example, and early experiment or pilot with SOA.  But even in that case, I think it is better for all if the business understands there is a need to, and price for advanced IT R&D, and keeping an eye to the future.  They don’t need to understand all the components of this R&D at a granular level, but they do need to understand, and buy into the fact that we have chosen, for example, to spend 1% of the IT budget on advanced R&D as an investment in our future.

IT Funding and the Level 2 Sticking Point


One of the more intractable sticking points on the journey to Level 3 Business-IT Maturity is in the IT funding model – the ways that IT prices its products and services, and recovers its costs (and, it a profit center, covers its margin).

Life as a consultant is tough.  I’m not complaining, but we have to find small ways to introduce humour and keep our sanity.  I wrote recently about how a consultant can use language clues to quickly assess both business and IT maturity.  Sometimes, you don’t even need the clues!  One of the ways I can put a sparkle into my day, when I meet a CIO I’ve never met before, at an organization I know nothing about, after a few minutes conversation, I pronounce, “I think your IT funding model is broken!”  In every case, they look surprised, then reveal, “How did you know so quickly?”  Of course, the answer is, funding models are nearly always broken.

However, IT funding is one of the dominant causes for sticking at mid-Level 2 Business-IT Maturity.  Below that point, much IT spend is funded by the project.  To a degree, business clients understand the idea of projects, and, again to a degree, are prepared to fund them if they believe there is a direct benefit to them, usually in terms of cost savings, cost avoidance, or increased revenues.  They don’t understand the idea of IT infrastructure, and what it takes to keep it running and positioned for the future.  One of the characteristics of infrastructure is that you only notice it when it fails.  If infrastructure is working fine (any infrastructure), it is invisible except to those who are involved in keeping it working.  So, IT infrastructure investments requests are typically met by, “Why do we need to spend $x million moving to Windows Vista?”

Typically, at Level 1 maturity, IT infrastructure is funded by some form of allocation or tax.  The business leaders don’t like – it always seems to deliver  too little and cost too much, and keeps needing additional spending on mysterious things that should have been anticipated and planned for.

At Level 2, IT infrastructure becomes an even more significant portion of IT costs.  Recall, Level 2 is often about cross-functional systems (ERP, CRM) and support for collaboration and inter-enterprise communications.  During Level 2, IT is laying down a foundation for shared computing – in effect, procuring “options” for future capability that has not yet been implemented (perhaps not even defined).  Business executives at Level 2 maturity don’t yet have the IT literacy to appreciate the concepts of infrastructure and options.  Costs associated with these things are not easily tied to projects (which they understand they have to fund), and yet stuffing them under the covers as an allocation or tax does nothing to contribute to their understanding – it just makes them more suspicious and skeptical that the IT resource is being properly managed. 

So we get  into the Level 2 trap – IT does not adequately “sell” the benefits of infrastructure.  The business does not adequately understand the value of infrastructure.  Ergo, IT infrastructure places a drag against progress and increasing business-IT maturity.  We will come back to this point, and ways to address it in a future post.

Language and Business-IT Maturity


Language has some interesting relationships to Business-IT Maturity.  As a management consultant, one of the things I have to do is quickly calibrate a client’s situation – sometimes, in just minutes (e.g., with a new, or potential client).  I’ve had some version of the Business-IT Maturity model in the back of my head for many years – it’s become a lens I use to calibrate where a given company is in terms of business maturity with IT, the maturity of the IT organization, how progressive the appetite is for business demand, how progressive the ambition is for IT supply, and so on.

Often, clues about these characteristics are found in the language people use to talk about thier situation.  Many years ago, there was a quiet move afoot to stop calling business clients “end users.”  As one wag said to me, “The term ‘user’ has a narcotic connotation – they become dependent upon IT, and we act as if we are drug dealers, fostering that dependency, then abusing the relationship!”

More recently, I find clients struggling to distinguish between internal business customers, and the external “consumer.”  These terms never quite work right – there is the age old debate between client and customer.  Generally, client is used where services are being delivered, and customerwhere products are the object of delivery.  Unfortunately, IT organizations, in some senses, deliver both services and products, so the distinction is somewhat limited.  I have clients who have banned the term clientas connoting a service provider model, and therefore implying “order taking” behavior.  I’m not sure I agree with this connotation, but if your CIO has a passion about terms she hates, or terms she’s trying to inject, logic does not do much good.

Anyway, with the Business-IT Maturity model in mind, I listen for these audible clues in the client’s use of language.  If I hear a lot of “us” (IT) and “them” (the business), chances are they are Level 1 or low Level 2.  If I hear the customers/clients referred to as “users”, chances are they are low Level 1.

If the conversations seem to be mostly about costs, they are Level 1 or low-to-mid Level 2.  If the conversations are mostly about value, they are high Level 2 or Level 3.  If I hear lots of discussion about Project Management, but none about Program of Portfolio Management, the client is likely low Level 2.  If I hear the terms Project, Program and Portflio being used in ways that consistently differentiate between them, and imply the relationships among them, they are probably high Level 2 or Level 3.

If the dialog is mostly about ERP, and major transactional systems, they are probably Level 2.  If the discussion is more about innovation, growth and IT as a source of new revenues, they are high Level 2 or Level 3.  Increasingly, if the conversation has a heavy dose of “collaboration,”  “social networking,” “Next Generation Enterprise,” or “Web 2.0,” at least I know there are some ambitions for Level 3 – though possible a long row to hoe to get there!

Of course, these points about listening to the language is simplistic – I have 30+ years of experience that helps me calibrate Business-IT maturity.  Sometimes, the earliest impressions prove to be wrong – but rarely.  Usually, my early instincts are correct – the things I learn subsequently are more “fine tuning.”

By the way, there are also visual clues, if you are physically with the client – books on people’s shelves, scratchings on whiteboards.  Increasingly, I’m finding office layout to be a clue (amount and quality of team rooms, coffee break areas for social networking, etc.) is a clue to maturity.

So, what does the language and terminology in your company tell you about Business-IT maturity?  How would you expect the language to change as a reflection of increasing maturity?

IT Maturity and the Role of Relationship Management


I’ve noted before that Level 1 in the Business-IT Maturity Model is mostly about Supply Management (managing the provisioning of IT products and services for consumption by the business or its customers/consumers), and that Level 3 is mostly about Demand Management (shaping and surfacing the demand for IT products and services from the business and or its customers/consumers).  Reminding us that, as a maturity model, the Supply Management emphasis of Level 1 does not go away – rather it becomes institutionalized, highly efficient, and optimized such that the management focus for improvement/transformation can shift to the Demand Management capabilities ot get through Level 2 to Level 3.

In our much discussed Level 2 (where I see IT organizations getting “bogged down” or stuck) a key role becomes that of the Relationsip Manager.  Note, I am describing a role, not a job or a title – rarely, if ever, do I see this role thus named.  More typically it is “IT Acount Manager” or something innocuous.  (I’d be delighted to hear creative titles for this role that you have in your organization, or that you’ve come across!)  The role is critical as it truly is an important “bridge” between the IT organization and the business(es) it serves.  While the CIO is typically the “uber-relationsip manager,” much of the daily work of influencing, shaping, identifying and gathering demand takes place a level or two down below the CIO.

Relationship Managers sometimes exist at Level 1, but typically execute their role as “order takers” – the simple “account rep” role.  They are typically seen as adding little value, and the role at Level 1 maturity is often not sustainable – it is seen as an added cost and overhead.

In Level 2 the role begins to add value as it shifts from pure order-taking to a more consultative role – advising the business on potential opportunities for IT enablement.  As maturity progresses, the role shifts again from consultative to more of a true business-IT partnership – for example, partnering with the business in process and product innovation.

There is much, much more to this shift that I’m covering here (I will drill down on the other dimensions and subtleties of the shifting Relationship Manager role), but the key point I want to make today is that the shift in Relationship Manager role, and its implied shifts in competencies, is yet another common “sticking point” that traps IT organizations in mid-Level 2 maturity.  The people that interface with the business and that help get you out of Level 1, are not the people that are likely to get you to Level 3.  The skillsets are very different, and even if a Relationship Manager is able to develop the needed competencies, if she has acted as an order taker for several years, it will be very difficult for her to be perceived as a valued business consultant, let alone a business partner.

One complexity is how the Relationship Manager faces of with the business it serves.  Again, as a reminder, we are referring to a business-IT maturity model – the business is maturing with its ability to drive value from IT assets and capabilities, just as the IT organization is maturing.  At Level 1, the business is typically stove-piped and functionally oriented.  In Level 2, a strong process perspective develops (e.g, order to cash, procure to pay, hire to retire) cutting across business units and functions.   So, at Level 1, Relationship Mangers typically face off with business unit leaders.  At Level 2, they also have to face off against business process owners, raising interesting questions of “who’s on first” and how priorities get set.