Tag Archives: IT funding

Why It’s Time to Re-Think IT Funding Models! – Part 1 of 3


The Live 3rd Rail!

Recently, a colleague said to me about a client, “It’s time to raise the subject of their IT funding model.  The current model is causing all sorts of dysfunctional behaviors!”  My response was, “You are right – but I really don’t want to go there just yet.  I don’t think they’re ready to hear that message, or, more importantly to tackle the ‘live third rail’ and do anything about it!”

I’m not particularly proud of my response – in some respects, it was ‘wimping out’ on an important client conversation.  On the other hand, I’ve had mixed results over the years in getting clients to tackle this issue.  Let me be clear – getting agreement that the funding model is broken and is driving dysfunctional behaviors is always an easy sell.  In just about every client I’ve ever worked with, the funding model is clearly broken!  In some cases, it’s slightly broken.  In most cases, it’s badly broken, with all sorts of bad behaviors as a result, including inefficient consumption, underspending on IT infrastructure, lack of value realization, an overly conservative IT portfolio, and so on.  But few CIO’s have the courage to tackle funding models – with so many battles to wage in the name of realizing business value from IT, the funding battle just seems too big, hairy, complicated and politically charged to take on.

Where I have had success, it has usually been thanks to one of a couple of conditions for success:

  1. There was a strong partnership in place between the CIO and the CFO, or…
  2. The CEO (or Chairman, or Board) recognized that the IT funding model was broken and wanted to change it to drive the right behaviors

What’s Wrong With IT Funding Models Today?

Actually, most of today’s IT funding models are riddled with problems, but the biggest issue is that they DON’T DRIVE RESPONSIBLE CONSUMPTION BEHAVIORS!

  • Many IT services are essentially “free” (recovered as overhead costs and corporate ‘taxes’) leading to irresponsible behaviors.
  • Other services that could increase the business value of IT (e.g., consulting services to identify and leverage high value opportunities for IT activities and investments) are dis-incented  (i.e., too scarce, too expensive, or, in many cases, not even available).
  • Most pricing models lack transparency.  The ways that services are packaged and priced hide the cost drivers from the business consumer.  As a result, the consumer has no idea how to manage these costs, and wonders why IT bills fluctuate so widely.
  • Most pricing models don’t reflect business value – often the bulk of the IT bill is for services seen as low value (e.g., basic desktop support).
  • Some pricing models are just too complex!  If the clients don’t understand what they are paying for, why, and what they can do to control costs, the model is broken.  If clerical effort is being expended around the company to check on, decipher and challenge every IT bill, then the model is broken!

Decomposing the Funding Model

So, before we talk about how to change funding models, let’s take apart the underlying components and issues.

Pricing vs. Recovery

The first and most obvious distinction is between pricing – how we price IT services – and recovery – how we recover IT costs.  These are completely separate and distinct – and yet, sometimes get commingled unnecessarily.  Just because a services costs you $x per unit to deliver does not mean you have to charge some function of $x, or charge by the same units as the costs are incurred.  You may chose to ‘give away’ some services, or to charge different clients at different levels, or charge based upon units different from those you pay by.  Recognizing this separation between pricing and recovery gives you tremendous pricing flexibility – and the ability to think about consumption behaviors you’d like to drive, and price accordingly.  Then you can tackle the recovery side of the equation separately – and adjust pricing levels and recovery strategies to balance the budget, as it were.

IT Savvy vs. IT Literacy

The “IT Savvyness” of business managers and executives is a crucial factor in any and all IT value discussions.  This term was first coined by Professor Peter Weill at the MIT CISR.  It is quite distinct from the more common concept of IT literacy.  I can say that Fred is IT literate – he knows his way around Windows and the main Microsoft Office products and successfully installed his own WiFi local area network in his home.  This does not necessarily mean that Fred is an astute steward of IT resources – understanding how IT can really differentiate his business area.  Nor does it meant that Fred can appreciate the distinction between one-time and full life cycle costs.  Bill, on the other hand, struggles with his PC.  But he does appreciate the need for ongoing investment in IT infrastructure.  He does realize that the business owns the accountability for extracting value from IT investments.  Bill might not be very IT literate, but he’s quite IT savvy!

Business-IT Funding Principles

I’ve mentioned Principles in many other posts – they can be a great tool for surfacing some of the tough strategic choices, and then making those choices explicit.  Business-IT Funding Principles do this for the strategic choices around IT funding.  For example, one of my favorite IT Funding Principles is;

We optimize IT investments for the enterprise – not for individual business units.

Or, if you prefer:

We optimize IT investments for the individual business units rather than for the enterprise.

I don’t care in the abstract case which one of these you pick, but pick one and stick to it!  Hopefully, the one you pick will be consistent with your agreed business model, and the degree to which that model calls for common processes and/or shared information.

A less contentious example of an IT Funding Principle is:

Business units directly fund both business-specific IT projects and the steady-state IT expenses associated with the outputs of these projects, rather than funding common activities via corporate contribution or standard allocations.

The rationale for this Principle (all Principles should state the rationales behind them!) would be that IT capital and expenses should be funded by the party best able to manage the demand for the IT services and thereby the cost.  An implication of this Principle (all Principles should articulate their implications!) would be that services that are specific to a business unit, such as third-party maintenance fees, other maintenance support, desktop costs, and IT labor for service requests, should be borne by those business areas that consume the services and are best able to justify the cost relative to business value.

We will pick up on the underlying IT Funding components and issues in the next post.

Enhanced by Zemanta
About these ads

Do You Have IT Organizational Clarity – Part 3


This picks up on Part 1 and Part 2 in this series on IT Organizational Clarity.

In Part 1, I discussed the importance of IT Organizational Clarity, the symptoms when clarity is compromised, and the challenges of trying to address those symptoms rather than the root causes that lead to compromised clarity.  Part 1 closed with a discussion of the two key dimensions along which IT Organizational Clarity can be tackled – scope (units of IT Capability) and meaningful and assessable characteristics for evaluating and improving IT Capabilities.

In Part 2, I discussed ways to define IT Capabilities and provided guidelines on the manageable number of IT Capabilities and appropriate depth of decomposition.  In this post, I will describe three different types of IT Capability.

Not All IT Capabilities Are Born Equal

It is helpful to classify IT Capabilities into one of three different types, as illustrated in the graphic above.

Value Chain Capabilities

At the core are those capabilities that take inputs, add value, and deliver outputs to a customer or end consumer (in the world of IT, these tend to be services and products).  Think of these Value Chain Capabilities as those that the end customer appreciates (hopefully!) and is willing to pay money for.

For example, as a business user, I may have a business problem I’d like IT help to solve.  That problem (or opportunity) is the input to a Value Chain.  The first Capability that will approach that problem adds value by analyzing the problem, identifying and proposing a solution.  As the business user, I appreciate that value has been added – drilling into my stated problem and offering (and perhaps demonstrating via a prototype) one or more proposed solutions.  The next Capability in the Value Chain might take the chosen solution and develop and deploy that solution.  Again, as the business user, value has been clearly added – taking a proposed solution and delivering it.  The final Capability where value can be added is supporting and maintaining that solution – again, a recognizable way of adding value for me, the customer.

Ultimately, as the business user or consumer, these are the only Capabilities I care about and am willing to pay for (directly or indirectly) because of the value they add for me.  Unfortunately, while these Value Chain Capabilities are necessary, they are not sufficient.

Enabling Capabilities

Value Chain Capabilities typically draw upon other Capabilities that enable them.  Think of these as Shared Services that are common to other Capabilities, or to other instances of problems/solutions working their way through the Value Chain.  Examples of IT Services that might enable the Value Chain Capabilities include Project Management, IT Operations, and IT Supply.

Alignment and Governance Capabilities

Value Chain Capabilities also typically depend upon other Capabilities that ensure that the work they are doing is aligned and governed to ensure they are operating effectively and in the interests of the enterprise.  For example, determining which business problems will be addressed, which solutions will be selected, how staff and resources will be allocated are all important control that Value Chain Capabilities will be subject to.

Why These Distinctions Matter to IT Organizational Clarity

The distinctions between Value Chain, Enabling and Alignment/Governance Capabilities are significant:

  1. Different types of IT Capability tend to be optimized towards different value propositions, with implications for how they are organized.  For example, Enabling Capabilities tend to be optimized for Operational Excellence (as shared services, they need to deliver predictable, consistent, quality services at the lowest possible cost).  Value Chain Capabilities tend to be organized for Customer Intimacy, delivering what specific customers want; anticipating customer needs.  Alignment and Governance Capabilities tend to be more about decision-making – rather than delivering services, they make decisions or provide decision-making frameworks – think Enterprise Architecture and the mechanisms and structures that support it as Alignment and Governance Capabilities.  As such, these tend to be networked, linking stakeholders and decision makers, and optimized to maximize the business value delivered or enabled by IT Investments..
  2. Some types of IT Capability lend themselves to alternate sourcing more than others.  For example, Aligning and Governance Capabilities lend themselves the least to straight outsourcing approaches (do you want to pass decision rights to an external vendor?)
  3. Different types of IT Capability lend themselves to different funding models.  For example, Value Chain Capabilities lend themselves to direct business funding, whereas Enabling Capabilities lend themselves better to indirect funding models (e.g., overhead charge).

IT Capability Model Example

As an illustration, below is a ‘normative’ IT Capability Model.

The Fractal Nature of IT Capabilities

Note, that as you decompose any IT Capability, you will generally find that the decompositions will have a similar structure – a primary Value Chain, drawing upon underlying Enabling Capabilities and influenced by Alignment and Governance Capabilities.

For example, Manage Business-IT Portfolio & Programs might decompose into the following sub-Capabilities:

In the following post, we will look at the assessable characteristics of any IT Capability as a means of determining Capability Maturity and determining how to increase maturity and thereby improve performance.

Enhanced by Zemanta

The Challenge of Sustainable Software


Just about everyone has become attuned over the last few years to the concept of sustainability.  Except, it seems, when it comes to software practices.  In most IT environments, by far the largest chunk of costs associated with a given piece of software, surface after it is initially delivered.  That is true of purchased packages, as well as for custom code.  And yet most organizations don’t properly budget for the total lifecycle costs for a piece of software.  More importantly, neither do they plan and build software for sustainability.  And very few actually plan and budget for the costs of decommissioning a system that is no longer sustainable (either technically or economically) or is no longer needed – until that decommissioning is long overdue!

“We Support the Future!”

This is not a new problem.  Many years ago I was involved with an organization known as the Software Maintenance Association (SMA).  Prior to the so-called Y2k thing a decade ago, the SMA struggled to garner the respect it deserved.  As Y2k loomed, the SMA became a valuable focal point for software remediation practices and tools.  Post Y2k, I have not kept up with the fortunes of the SMA, but I will always remember their slogan – “We Support the Future!” That always struck me as a fresh and compelling way to think about the disciplines and activities associated with keeping software doing what it needs to do.  It also reminds me that much of today’s software practices are focused on the here and now, with relatively little regard for future sustainability.

How to Make Software Sustainable?

Given the complexity behind the issue and in an attempt to increase the value of this blog to its readers, I’m going to approach the topic of software sustainability as an experiment in collaboration.  I will create a series of posts over the next month or so, incorporating as much dialog and discussion as I can surface.  I welcome, as ever, any and all commentary on this blog.  But I will also leverage other means (e.g., social media, personal network) to discover the state of the art and surface leading or promising practices.

I am hopeful that we can generate useful commentary, experiences and shed some helpful light on the topic.  As a starting point, I propose three major categories or ‘lenses’ through which to explore sustainable software practices:

  1. Technical
  2. People
  3. Financial

To help get things kicked off, here’s my initial thinking on these issues.

Sustainable Technical Practices

There is no doubt in my mind that Enterprise Architecture is key here.   My colleague and friend Roy Youngman describes this appropriately as “a means to reduce the cost of change.”

There’s been some very good news here over the last few years.  Standards have emerged that while not being panaceas, can help in bringing a more ‘architected’ approach to software – more ‘plug and play’ as it were.  Service Oriented Architecture (SOA) and derivatives such as Web Oriented Architecture (WOA) have shown significant benefits.  Unfortunately, much of the evidence is anecdotal due to a lack of good software management practices – in particular, good metrics, uniform terminology, enlightened costing models (e.g., activity based costing) and good baseline data.

Ironically, the lack of good  data exacerbates the challenge of building a business case sufficiently robust to drive real change in software practices.  As such, in spite of their promise, these standards are still not commonplace, their adoption impeded by forces such as organizational inertia, lack of an architecture infrastructure with sufficient ‘teeth’ to shape behaviors, and by all the packaged software that organizations increasingly rely on.  These bring their own architectural idiosyncrasies (or lack of architecture!), leading many organizations to have effectively outsourced their architecture – often unwittingly, and almost always, unwisely!

There is other good news in contemporary development methods such as Agile and its Scrum derivative.  Being based on iterative refinement, these inherently create and, to a degree, enforce sustainability into their products – each iteration must, in some respects, ‘anticipate the next iteration.’  Furthermore, Scrum roles such as Product Owner, if well implemented and connected with broader Product Management roles (responsible for total lifecycle costs and value) can bring a great deal to sustainability.

Sustainable People Practices

The challenge here, especially with agile development models, is that the teams run at a relentless pace.  The question is, can people sustain this pace day in, day out?  Does Scrum become a euphemism for ‘heroic efforts’ that leave people sick or with broken families?

I believe the last couple of recessionary years have left IT staff’s depleted, less than fully engaged and with deteriorated organizational talent management practices.  While the pace of technological change continues to increase, most organizations have actually decreased their investment in training and competency development over the last couple of years.

Sustainable Funding

I’ve joked before that a consultant can often score a cheap point by telling a CIO, “Your IT funding model is broken!”  It always is!  Funding models typically evolve over many years, without sufficient consideration as to the desired behaviors they should lead towards.  On top of this built-in dysfunctionality, IT project teams, by way of either reducing “sticker shock” or simply because they’ve not done the analysis, don’t plan and manage in terms of full lifecycle costs.

Let the Sustainable Software Discussion Begin!

So, with those few initial thoughts:

  • How do you see the issues of sustainable software at your organization?
  • What priority does software sustainability have in your organization today?
  • What priority should it have?
  • What successes have you had addressing sustainability of software?

Please comment here, or Tweet me, email me, or whatever!  Let’s figure this out!

Image courtesy of BLDG Blog

Reblog this post [with Zemanta]

How “IT-Savvy” Is Your Company? Why Does That Matter?


weillross_300dpiRegular readers will know that from time to time I refer to research by Peter Weill, Chairman & Senior Research Scientist, Center for Information Systems Research (CISR) at the MIT Sloan School of Management.  I’ve had the privilege of knowing Dr. Weill for many years, and having collaborated with him on several multi-company research initiatives.

Peter and his colleague and co-author Jeanne Ross recently published their latest book called IT Savvy: What Top Executives Must Know to Go from Pain to Gain.

This is an excellent and important book.  It is notably the first book by this duo written for the top executive community, rather than for IT professionals – the target readership for prior Weill/Ross books.  I’m well known for repeating the mantra, “Organizations get the IT they deserve!” This book really reinforces the leadership roles and practices that help converge business and IT.  The ideas are beautifully organized, clearly presented and convincingly illustrated by interesting case studies.

I don’t want to pretend that one book can, by itself, move you along the road to “premium return on IT.”  But it sure is a great resource and, most importantly, a way to educate your key stakeholders what it takes to get on the right road!

Practices that Earn a Premium Return on IT

The authors, building on 15 years of research, describe what they refer to as the “Three Obsessions of the IT-Savvy Firm.”  These are:

  1. Fixing What’s Broken About IT.
  2. Building a Digitized Platform.
  3. Exploiting the Platform for Profitable Growth

Citing several case studies to illustrate their points and help make the practices real, they work through issues of business operating model and the IT implications of operating model choices: IT funding model, digitized platforms, governance, driving value, and leadership.

Read, Share and Discuss!

Read this book with the idea of sharing it with your business partners and stakeholders.  Set up or take advantage of current opportunities to drive dialog around the implications of IT Savvy to your organization.

I believe you will recognize in the IT Savvy book many of the practices, recommendations, and “vignette’s” that surface in this blog from time.  In fact, Peter and Jeanne’s work over the years, and my research experiences with Peter, has greatly influenced my belief system, and with it, my approach to IT management consulting, at least over the last 15 years!

Book Cover Image Courtesy of Harvard Business Press

Reblog this post [with Zemanta]

Don’t Look for ROI on Enterprise 2.0 – Look for Value!


roi

Dion Hinchcliffe had a superb post on Determining the ROI of Enterprise 2.0.  The post cites several authoritative and useful sources on the subject.  It also hypothesizes several reasons for the mostly “wait and see” attitude currently taken by most IT leaders and business managers.

But I mainly want to focus on the business case for Enterprise 2.0 – specifically, the pursuit of Return on Investment – ROI.

The Problem with ROI

Much has been said in the past about the limitations and challenges with ROI as a tool to evaluate many types of IT investments.  Dion’s post links back to an old post, The Case Against the Business Case by the father of the term Enterprise 2.0, Andrew McAfee.  McAfee in turn references the work of Kaplan and Norton and their Strategy Mapping book which points out that the value of intangible assets (human, organizational, and information capital such as databases, information systems, networks, and technology infrastructure):

…derives from their ability to help the organization implement its strategy… Intangible assets such as knowledge and technology seldom have a direct impact on financial outcomes such as increased revenues, lowered costs, and higher profits. Improvements in intangible assets affect financial outcomes through chains of cause-and-effect relationships.”

This is a really important point, but it sets up a very slippery slope. “We can’t attribute any direct financial impact to our Enterprise 2.0 investments…  so we won’t try.”  It’s the “not trying” here that drives me nuts!  It leads to:

  1. Lazy thinking… which leads to…
  2. Lack of clarity about what outcomes we are trying to drive to with our Enterprise 2.0 initiative… which leads to…
  3. Lack of rigor in thinking through what behaviors we are hoping will change in order to realize the targeted outcomes…  which leads to…
  4. A “if we build it, they will come” approach to Enterprise 2.0…  which leads to…
  5. Failure of the Enterprise 2.0 initiative, “proving” there is no business case!

Value from Enterprise 2.0 can be a Self-Fulfilling Prophecy

Last August I wrote a post titled Measuring the Business Value of IT – Where You Can Win By Simply Trying! My point here was that the discipline of thinking through what we’d like to achieve, and how we might achieve it, dramatically increases our probability of achieving it.  As a trivial case, imagine the following conversation:

Let’s invest $1 Million to increase collaboration across our company.”

“Why?”

“Because we’ll be more innovative and productive.”

“How?”

“Hmmm – good question!  Well, we’ll tap into people’s ideas about how to improve our products and services.  And even how to improve our processes.  We could even tap our customers’ ideas!”

“How will we do that?  What will we need to enable that?  What will we need to shift to those kinds of behaviors?  Are there any aspects of our culture that might inhibit those things happening?”

“Hmmm!  More good questions.  Perhaps we need a bit more definition around what we are trying to do?  Perhaps we need to drive to some clarity on the outcomes we hope to achieve?  Perhaps we need to assess our ability to achieve those outcomes and clarify what will need to change for them to materialize?”

And so on.  Note, we aren’t building a business case in the financial sense.  This is not an ROI exercise – its a business value and outcomes exercise.  And this is the type of analysis that needs to be done to shift from the laissez faire “if we build it” to a more thoughtful, targeted approach.

(Image courtesy of SponsorMap)

Supposing You Funded IT Like a Charitable Donation?


charity_box1I’ve had this IT funding fantasy for years (I know, it’s really sad that my more exciting fantasies are to do with IT funding scenarios!) Supposing the CIO had to do a fund drive every year or every six months the way our local National Public Radio stations had to operate in order to fund certain IT activities?

I actually hate the NPR fund drives, but I love what privately funded radio brings compared to all other forms of news and quality radio programming  in the USA, and I realize that the funding model is necessary and ultimately important to the NPR mission.

Listening to my local radio station’s NPR funding appeal for a couple of weeks twice a year always gets me thinking about IT funding and my “IT Charitable Donation Fantasy.”  I’m not suggesting this is the way to fund all IT activities – far from it.  I believe that funding, for good or bad, drives behavior, so if we want responsible business behavior around IT assets and activities, we need to think through the desired behaviors and how funding models promote or detract from those behaviors.

Three Distinct IT Funding Pools

It is useful to carve IT spending into 3 broad categories:

  1. IT infrastructure.  This should be defined very broadly to include all shared IT capability.  To borrow from Prof. Peter Weill’s definition, IT infrastructure is the base foundation of IT capability budgeted for, centrally coordinated and shared across the enterprise.  I don’t see this being funded through a charity-like, voluntary basis.  Like all infrastructures, nobody really wants to fund it, and few understand the technology details, risk management, capacity planning and other implications that render IT infrastructure either reliable and supportive of the business mission on the one hand,  or unstable and get in the way of the business mission on the other.  I think IT infrastructure is best funded as a kind of tax – in a way that fairly represents the proportional value to the organization that uses it.  Depending upon the nature of the business, this might be a function of headcount, divisional revenue, or some other factor.  And, as an aside, the CIO should be looking to continuously improve the cost per unit of infrastructure over time.
  2. Business Solutions.  These should essentially be funded by the business units that require them and will benefit  from them.  If more than one business unit, then the combination of business units will fund the solution in proportion to the degree of benefit or value each derives.  This will never be pure science and will typically involve some kind of negotiation between the parties.  By the way, this type of activity should have a robust value realization approach to go along with the funding.  (I’ve posted on value realization quite a bit in the past – if you are not familiar with this material, please either search my blog for “value realization” or drop me a line, and I’ll send you the links.)
  3. Innovation/Research and Development.  This is the part of the IT budget that I think lends itself best to a voluntary funding model.  The most common funding practice I come across for this category of activity is “stealth funding” – i.e., the CIO squirrels away funds from other activities, and runs them below the radar – some unspent training dollars here; some savings from a renegotiated vendor contract there; some money left over from a project that came in under budgets, and so on.  The problem with stealth funding is that it is unpredictable, and it hides from the customer base the fact that money for innovation and R&D is actually necessary, and a sign of a healthy IT organization.

Fund Raising for IT R&D

So, how might this work?  First, the CIO needs to decide a funding target for IT Innovation and R&D.  This might be something between 1% and 5%.  Then build a business case – how will the funds be used?  Why should the business care – how might they benefit?  Typically, these funds will be invested in a mini-portfolio of activities, from low-risk to high-risk, and from short-term to long-term.  Will there be an expected payback on the whole portfolio?

For those business heads that chose to participate, will they get any special treatment compared with those who chose not to participate?  (This is a thorny question!  NPR does not threaten to cut me off listening to the wonderful Morning Edition or All Things Considered, or any of their great weekend shows should I not ante up each year for “membership.”)  For the CIO, I’m not sure how best to play this out.  I think some special treatment might be the ability to participate in business experiments that are associated with the R&D activities, but there may be other quid pro quos for those who pony up to the R&D fund.

Comments?  Questions?

So, what do you think?  How “fantastic” is my IT funding fantasy?  Are any of you doing anything like this?  How is it working?  Could it work?  Answers on a postcard, please!

IT Infrastructure, Options, and Cost-Benefit Analysis


There was a piece on National Public Radio this morning that got me thinking about IT infrastructure funding.  I think this is especially relevant as companies consider Web 2.0 technologies and ask the inevitable question – “What’s the value proposition?”  It’s a great question, unless that question gets morphed (as it so often does) into “What’s the return on investment?”

The NPR article was about the levees along the Mississippi River.  Apparently, after the huge floods in 1993, a few Midwestern states got together with the Army Corps of Engineers to draw up a plan to build higher levee walls.  Unfortunately, the plan, which could have helped limit the amount of flooding the region is now seeing, ranked the project low on the Army Corps of Engineers’ priority list, because a cost/benefit analysis showed an economic benefit to cost ratio of less than 10%.  This was due to the combination of high cost (over 1,000 miles of river bank) and the fact that the land was already protected by existing levees, so the new plan would have only added protection when the water got really high (which, of course, has just happened, and in retrospect, the levee work would have been well justified!)

As someone on the news piece pointed out, this is a classic error of trying to use cost/benefit analysis for projects that are infrastructural in nature.  This has been exactly my experience with IT infrastructure.  When IT infrastructure (or any type of infrastructure) works well, it is invisible, so nobody wants to fund improvements to it.  This is exacerbated by the fact that the economic benefits for a given IT infrastructure investment, while potentially significant, are often indirect and/or intangible.  There is extensive research on this phenomena, and a literature review shows that traditional financial evaluation techniques, such as NPV, undervalue IT infrastructure.

There are a variety of preferable techniques such as Real Options that include the effect of project inter-dependencies and recognize that an IT infrastructure project may have a negative NPV when evaluated on stand-alone basis, but the project nonetheless can provide an option to launch future value-added capabilities. Unless the option value of this flexibility is taken into consideration, it is impossible to accurately represent the strategic business value, or justify, strategic investments in IT.  A related technique is the Value Net approach to estimate project benefits based on interactions between stakeholders. A Value Net is a map that links a firm to various player segments: customers, competitors, suppliers and partners.

For all of the research on this topic (see, for example, the Journal of Information Technology Management’s “Justifying Investments in IT” by Sasha Dekleva at DePaul University for an excellent treatment of this topic) I find IT management surprisingly lackadaisical on their approach to IT infrastructure funding, with the result that infrastructure is misunderstood, undervalued, and therefore underfunded.

All this, of course, course, depends upon your definition of IT infrastructure.  I still find that Professor Peter Weill’s definition works most effectively:

“The base foundation of budgeted-for IT capability (both technical and human), shared throughout the firm as reliable services, and centrally coordinated.” 

This gets at the key distinctions of “foundational”, “budgeted-for”, “technical and human”, “shared throughout the firm”, “services”, and “centrally coordinated” (note, not necessarily centrally-managed.  This definition, together with appropriate justification techniques such as Real Options and Value Net approaches, together with a strong partnership between the CIO and CFO, can lead to a more robust understanding of the role of IT infrastructure, and a more valuable IT capability for the firm.  By the way, these techniques help not only in that they might get an investment approved (and/or appropriately prioritized), but that they ultimately improve value realization by clarifying the cause and effect chains between IT infrastructure investments and the value they enable.

Managing IT Infrastructure vs. Platforms


platform-4-626.jpg

I was in an interesting discussion with one of my consulting clients recently.  I was with a group of IT managers responsible for their firm’s shared IT assets.  This is a large, global enterprise that has been on an aggressive journey over the last 5 years to transform business-IT maturity.  By any measure, they have been successful – rationalizing and consolidating a patchwork of data centers, networks, systems and dispersed IT groups – some “official parts of an IT organization”, others “shadow IT organizations” operating outside of IT budgets and controls.

In essence, this group is responsible for the firm’s “infrastructure.”  We talked about the definition and meaning of “infrastructure” in order to get a handle on their scope of responsibilities, and how these might change over the next 3-5 years.  A typical dictionary definition of infrastructure is: “the basic facilities, services, and installations needed for the functioning of a community or society.”  For IT infrastructure, I find Professor Peter Weill’s definition especially useful:  “The base foundation of budgeted-for IT capability (both technical and human), shared throughout the firm as reliable services, and centrally coordinated.”

Let’s examine the keys to this definition.

  • Budgeted-for implies conscious analysis, planning and funding.  This is critical for IT infrastructure given its characteristic that it tends to be invisible until it breaks.  Therefore, an effective IT infrastructure management group has a hard time getting funding for improvements – “If its working fine, why do you need more money?” is the typical refrain.  (Public infrastructures suffer the same fate – hence our bridges are falling down, and, as an Atlanta resident, I have to suffer continuous drought conditions while 20% of the water traveling from reservoirs to homes is wasted through leaky water pipes!)
  • Both technical and human helps correct the common misunderstanding that IT infrastructure is all cables, computers and disc drives.
  • Shared throughout the firm as reliable services introduces the notion of ‘firmwide sharing’ which sets scope, and ‘services’ which takes us to the disciplines of Service Management, and frameworks such as ITIL.
  • Centrally coordinated tells us something about how IT infrastructure is managed – note here, its not necessarily centralized management, but central coordination, implying Enterprise Architecture and Governance.

The big question for this group is how should they evolve over the next 3-5 years, given all the changes in the business ecosystem (Next Generation Enterprise, anyone?)  One of the key elements of IT’s contribution to business success and growth in the next few years is through the notion of “platforms.”  A platform is a set of assets whose roles and connections are defined so that they can be configured in a variety of useful ways.  My company, BSG Alliance, recently kicked off a new multi-company research project, Platforms for Business Growth, so the research team has been giving a great deal of thought to IT-enabled business platforms for some time.

“Platform thinking” originated with manufacturers who wanted to build a variety of products using standard designs and interchangeable parts. It then migrated to the software industry.  For example, as Microsoft Windows operating system became popular, partners began developing products to work with the Windows platform.  Today, companies such as Amazon offer their ecommerce systems as a business platform, YouTube provides a platform for embedding video clips, and Apple’s iTunes/iPod has become a successful entertainment platform.

A key element of platform thinking is easy and open connection and collaboration with customers and suppliers.  Customers want to collaborate in the creation of customized products and services.  Business partners offer an ever-growing variety of services to leverage. A flexible platform is an engine for growth – because the business is more nimble and responsive, because it is better able to connect and collaborate, and because it maintains a larger portfolio of “options” for innovation and future action.

So, what are the differences between IT infrastructure  and IT-enabled business platforms?   Building a business platform certainly depends upon a sound infrastructure.  But platforms also depend upon clearly defined and published specifications and ground rules for what assets do and how they connect.   As IT infrastructure requires the mastery of IT Service Management,  IT-enabled business platforms, on top of IT Service Management requires the discipline of Product Management.   For many IT organizations, this is a new and unfamiliar discipline – one rooted in the disciplines of marketing, and therefore quite foreign to the world of IT.  I will get more into the distinctions between Service Management and Product Management in a subsequent post.

New Year’s Resolutions for Reaching Level 3


 resolutions.jpg

Some suggestions for IT leaders who are determined to drive up the business value and impact of Information Technology during 2008:

  1. I resolve to be more effective in raising awareness of the potential for information technology to drive business growth.  I will bring ‘marketing thinking’ to my IT organization, and focus on improving our business communications.  I will leverage Web 2.0 technologies to this end, we will start several blogs authored by the IT leadership team, and be more deliberate in seeding experiments in IT-enabled business innovation.  These efforts will help me implement my 2nd resolution.
  2. I resolve to innovate IT funding so as to drive higher business value and more innovative behaviors throughout my enterprise.  Among the outcomes I will strive for through my new IT funding approaches are:
    • Shift at least 10% of my spending in 2008 from ‘steady state’ activities to ‘innovation-focused’ activities by aggressively retiring and decommissioning systems and technologies that are no longer essential to running the business.
    • Shift costs for business unit specific activities from the IT budget to business unit budgets – and shift the accountability for ROI on those costs to the respective business unit.  This will allow increased investment in IT infrastructure.
    • Add a new, voluntary ‘IT Innovation Fund’ – business are free to contribute to this fund out of their top-line income.  The IT organization will partner with business units on business innovation activity in proportion to that business unit’s voluntary contribution to the IT Innovation Fund.
  3. I resolve to experiment aggressively with Software as a Service (SaaS) during 2008 with a goal of shifting at least 15% of my IT spend to SaaS by the end of 2009.
  4. I resolve to establish the IT organization as the model of collaboration for our enterprise – we will lead our enterprise into becoming a ’Next Generation Enterprise’ by establishing a ‘Next Generation Enterprise’ IT capability during 2008.
  5. I resolve to establish a strong, compelling and valued ‘brand’ for IT at my enterprise during 2008 – a brand known for creating an exceptional customer experience for both our internal and external customers and partners.
  6. I resolve to significantly strengthen our IT talent during 2008 by looking beyond the traditional recruiting sources, and hiring people from entrepreneurial, high tech environments – I will care less about industry experience and more about attitude and potential.
  7. I resolve to shift more of my time and attention from inward-focused activities to looking outside – outside my IT organization to our business units; outside my business units to their clients and customers; outside our industry to other industries where innovation intensity is significantly higher than our own.
  8. I resolve to learn more about ‘design thinking’ and bring more design thinking competence to bear on everything we do as an IT organization.
  9. In conjunction with Resolution #1, I resolve to increase the transparency of everything we do in IT.  This will mean communicating from an ‘outside-in’ perspective – in business rather than technology terms.
  10. In conjunction with Resolution #4, I resolve to make the IT organization a more fun place to work – a place of innovation, experiments and excitement.  The heroes we will celebrate will be those that try innovative things, whether or not they are successful. 

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.