Tag Archives: IT infrastructure

Does Cloud+Consumerization Doom the Federated IT Operating Model?


The Federated IT Operating Model is Under Threat!

Today, most organizations employ some sort of Federated IT Operating Model.  Wikipedia defines a federation as:

…characterized by a union of partially self-governing states or regions united by a central (federal) government. In a federation, the self-governing status of the component states, as well as the division of power between them and the central government, are typically constitutionally entrenched and may not be altered by a unilateral decision of the latter.”

Typically, enterprise-wide or common applications, initiatives and infrastructure are a centralized (federal) responsibility, while local applications and activities are under the control of business units or functions.  This “federal rights/states rights” model has infinite variations.  Definitions of “common,” “enterprise-wide” or “infrastructure” are subject to interpretation, and these tend to change over time, with changing business conditions, leadership, technology and other forces.  There’s also inevitably a “shadow IT” phenomenon – sometimes quite large – where much IT activity happens outside the realm of IT governance.

Just as in countries with a federal governance model, the competing forces between state and federal rights pull and push over time, leading to an ebb and flow of centralization and decentralization.  This can be healthy – like an accordion, making sweet music as the parts are squeezed together or pulled apart.  It’s never static, but constantly responding to the forces of change – just as all living systems “breathe” in some way or another, and have their seasonal variations.

But every now and again, new forces surface and combine together to disrupt the gentle ebb and flow – the so-called Arab Spring comes to mind.

The New Forces of Change

IT governance is undergoing such a confluence of new forces.  These include:

  • Cloud computing – it is easier, faster and cheaper (on the face of it) to leverage the cloud to host applications and provide IT services (e.g., storage, transaction processing, data analytics) rather than have your federal IT group provide these services.  Much of this activity takes place in the “Shadow IT” realm.
  • Mobile computing – more of us are doing more via smart phones and tablets.  This exposes us to mobile applications and the many “app stores” including Apple’s and Google.  Getting an app is as simple as clicking a button – and many apps are free, or cheap enough to add to your mobile phone bill without feeling any pain.
  • The shift in the personal computing operating system – from Windows, et al, which can be controlled by the central (federal) IT department, to technologies such as Apple’s iOS and Google’s Android which are much harder (perhaps impossible?) to control centrally.  The genie is already out of the bottle, and it’s not going back any time soon!
  • Economic climate – the economic climate facing most businesses, whether in the US or just about anywhere else is in the doldrums.  This keeps people scrutinizing costs, prepared to make short term economic moves, even if at the expense of the longer term, and trying just about anything to get “unstuck”!  Such a climate tends not to favor centralization and federal power (just ask President Obama’s campaign advisers!) but empowers local forces and factions.

Beware the Unintended Consequences

So, what to do about it?  Here’s three options:

  1. Take a laissez-faire approach – a path of least resistance.
  2. Push back, hunker down and reinforce the federal model with more controls and stronger sanctions for “shadow” behavior.
  3. Adopt a “mutual adjustment” approach that navigates the stormy waters to constantly find the optimal balance.

From my perspective and experience, Option 1 has potential (likely?) unintended consequences.  We saw this when many central IT groups were slow to respond to the emergence of the Personal Computer.  When they did respond, it was generally via Option 2 – they tried to constrain them.  That drove a lot of rogue and shadow behavior and set many companies IT efforts back several years.

For most of us, Option 3 is the practical and pragmatic solution.  Let’s face it, there are all sorts of unknowns in terms of how these forces will play out over time.  We need some form of centralized coordination of infrastructure. However, the terms “coordination” and “infrastructure” must be defined clearly and re-defined from time to time as we gain experience with cloud computing and consumerization of IT.  There is not a right and wrong here – but a critical need for organizational clarity so that you are setting the bounds of infrastructure clearly and in a way that is appropriate to the times and to your business context.

Seven Steps to a Mutually Adjusting IT Operating Model

I believe IT leaders must approach this in the same way they would approach any needed change:

  1. Create and “market” a compelling end state vision.
  2. Surface and “sell” the cost of status quo or of going down the wrong path.
  3. Define a credible and palatable path to the future.
  4. Enroll key stakeholders in joining together on that path.
  5. Engage selected key stakeholders in the governance model.
  6. Surface and celebrate successes along the way.
  7. Take action to discourage deviations from the path.

Image courtesy of Charles Ayoub

Related articles
Enhanced by Zemanta
About these ads

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

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

IT Organizational Implications of Cloud Computing


First off, let me make myself clear.  I firmly believe that Cloud Computing, in its various forms, is real, absolutely inevitable and will completely revolutionize the form and role of the IT Organization.  Some readers will look at that sentence and laugh – it’s like saying “day will pass into night.”  Obvious, beyond dispute, devoid of insight.  Others will also laugh at my opening proclamation – only in their case, because my assertion is completely ridiculous to them – beyond belief.  Of course, to many businesses, especially smaller and medium sized, Cloud Computing is already real, and has been for some time.  So, feel free to debate me (comments and opposing views highly welcome!) but I will stick with my beliefs on this.

For IT Leaders, the Cloud Changes Everything!

For me, the big question is, what does the migration to Cloud Computing mean for today’s IT organization?  What structural changes are necessary to successfully leverage Cloud Computing capabilities?  How quickly should you be moving IT services to the Cloud?  How does the Cloud impact the IT Service Portfolio and the capabilities needed to deliver those services?  What are the implications for IT competencies?  How does business-IT governance change in a Cloud Computing world?

I think these are important questions whose answers are not yet totally clear.  As I reflect back on the shift from mainframe to client-server computing, many IT organizations were less than stellar at anticipating needed changes.  As a result, they experienced more bumps and potholes in that journey than was necessary.  For example, for all that had been learned about back-up and recovery in a mainframe world, the onset of client-server computing created gaping holes in the IT organization’s ability to cope with data protection and loss at the Personal Computer level.  The same was true for the evolution from client-server to the web – many of the controls put in place for client-server computing were ineffective (and some even counter-productive) as more work moved to the Internet.

Which Aspects of Cloud Computing Could Bite Your IT Organization?

In the next few posts I will explore some of IT organizational implications of Cloud Computing.  Aspects we will examine will include:

  • Mobility implications – both for the business user and the IT professional charged with enabling that user.
  • The distinctions between Infrastructure as a Service, Applications as a Service, Platform as a Service, Development as a Service and Business Process Services and how these impact IT organizations.
  • The distinctions between Public, Private and Community Clouds and their implications for IT.
  • Accounting implications, including funding and budgeting.
  • Implications for Business-IT Governance.
  • Security and Privacy.
  • Implications for the work teams and flow of work involved in requirements analysis to solutioning.
  • Impact on Enterprise Architecture.
  • Implications for IT Services and Service Management.

Please weigh in – let us know your experiences, issues and concerns about the shift to the Cloud.  Do you agree with my assessment that this shift is inevitable?  How fast do you see it happening?  What does it mean for you personally, and for your career?

Enhanced by Zemanta

Exploring an IT Operating Model for Enterprise 2.0 – Part 4: IT Governance


In Part 1 of this series, I suggested that the implications of Enterprise 2.0 for the IT organization are dramatic.  I also suggested that the ways of designing and executing an IT Operating Model in a Web 2.0 context are quite different from traditional approaches.  In Part 2, I outlined the major elements of an IT Operating Model as being:

  • Processes – how we perform activities that deliver predictable and repeatable business results through competent people using the right tools.
  • Governance – how we make and sustain important decisions about IT.
  • Sourcing – how we select and manage the sourcing of our IT products and services.
  • Services – our portfolio of IT products and services.
  • Measurement – how we measure and monitor our performance.
  • Organization – how we structure and organize our IT capabilities.

In Part 3 we looked at how Web 2.0 approaches could transform the way IT processes are defined and managed.  I now want to look at IT governance, and the implications of Web 2.0 for this ever important aspect of IT operating models.  Due to the depth of this topic, I will discuss the facets and domains of IT governance in this post, then deal with the Web 2.0 implications in a subsequent post.

Facets of IT Governance

There are many definitions and descriptions of IT Governance, and frameworks such as COBIT that attempt to bring ‘best practices and processes’ to the domain.   The two definitions I have landed on in my years of research and consulting in this space, are:

  1. A framework of decision rights and accountabilities to encourage desired behavior to realize maximum value from information technology.
  2. Aligning IT decision-making with enterprise governance and business unit objectives through an interrelated set of processes, policies and decision-making structures with clear goals, roles and functions, sponsored by the CEO, with clear consequences for compliance or lack thereof.

I like the first definition for its simplicity, getting to the heart of both ‘decision rights’ and ‘accountabilities’ through the lens of ‘behaviors’ all focused on maximizing the value realized through IT.  This is pragmatic – you can define the types of behaviors you would like to see (e.g., business takes ownership for the business outcomes to be enabled by IT initiatives), or behaviors you are seeing but would like to eliminate (e.g., people see IT as a ‘free’ resource, and therefore use it with little or no regard as to its cost or value.)

I like the second definition in contrast for its recognition that IT governance is an extension of enterprise governance, and for its reference to ‘processes’, ‘policies’, and ‘decision-making structures.’  I also like the emphasis on CEO sponsorship and consequence management – i.e., governance with ‘teeth’.

I’ve come to view IT governance as a means to achieve balance between the competing forces of innovation versus standardization and business unit autonomy versus collaboration.  I also see IT governance as a way to manage IT investments and assets as a  resource that is shared by the enterprise.  Finally, good IT governance provides a “transmission chain” for the highest level enterprise strategy, from senior executives on down through the organization. As such, IT governance is a critical alignment mechanism.

IT Governance Domains

Peter Weill and Jeanne W. Ross, in their excellent book, IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, call out five decision domains of IT governance:

  • IT Principles (strategic choices between competing perspectives.  For example, ‘We will optimize IT investments for the enterprise rather than for individual business units.’)
  • IT Architecture (“the organizing logic for data, applications, and infrastructure captured in a set of policies, relationships and technical choices.”)
  • IT Infrastructure (“Centrally coordinated, shared IT services that provide the foundation for the enterprise’s IT capability.”)
  • IT Investments and Prioritization (“How much and where to invest in IT, including project approvals and justification techniques.”)
  • Business Application Needs (“Specifying the business need for purchased or internally developed IT applications.”)

While these domains may each be handled by different processes, policies and decision-making structures, all of these domains must be covered in ways that support a coherent strategy and set of beliefs about IT.

IT Governance, In Other Words…

IT governance deals with how the business makes decisions about the deployment and delivery of IT.  When sound IT Governance is in place, senior executives not only know their organization’s IT plans and policies, they also know how they are made.  IT governance is about the specification of decision rights and responsibilities required to ensure effective and efficient use of IT.  As such, it deals with organizational power and influence, and therefore  must be approached with care!

IT Governance 2.0

The implications of Web 2.0 on IT Governance are dramatic and far reaching!  On the one hand, with ‘transparency’ a watchword of good governance, 2.0 capabilities offer several important mechanisms to bring transparency both to the design of effective IT governance processes and structures, and to their ongoing execution and management.  On the other hand, dealing with decision rights and accountabilities in the types of highly diverse, distributed and fluid information environment enabled by social networking tools can become quite complex.  We will dig deeper into the implications of Web 2.0 for IT governance in a subsequent post.

Image courtesy of The ERM Current

Reblog this post [with Zemanta]

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!

Portfolio Management: So Much More Than a Collection of Projects!


collectionI’ve posted recently about Program Management – mainly in response to a reader’s question about how to group projects into programs.  Her question, in turn, was in response to one of my most popular posts on the distinctions between Project, Program and Portfolio Management.

IT Portfolio Management Matters!

I’m delighted that my old post on this topic (about 16 months ago) keeps attracting readers – portfolio management is one of the most important keys to business value realization from IT.  It is also often poorly implemented.  In fact, quite often, the term “portfolio management” is used without any justification in reality.

Modern Portfolio Theory

IT portfolio management is rooted in Modern Portfolio Theory.  Defined by Wikipedia, Modern Portfolio Theory:

proposes how rational investors will use diversification to optimize their portfolios…

When applied to IT, Portfolio Management proposes how the organization (assuming it is acting in a rational way towards its investments) uses diversification to optimize its IT investments.  In this case, optimization may include balancing:

  • Short term and long term investments.
  • Low risk, low return against high risk, potentially higher return initiatives.
  • Common and shared (i.e., IT infrastructure) against business unit specific investments.
  • Investments by major business process.
  • Creating new capability versus maintaining existing capability.
  • Investing in IT process and capabilities (i.e., improving the “business of IT”) versus investing in IT capability for the business.

IT portfolio management is the primary means to elevate IT decision making and investment prioritization to a business issue.

In this context, IT portfolio management implies a top down decision making framework.  It implies that:

  • Senior executives have debated, considered and reached consensus about their IT investment portfolio strategy.
  • This, in turn, implies that senior executives have considered and agreed to a business-IT strategy.
  • They have wrestled with the thorny questions about “level of optimization” of IT investments – whether this should be a business unit or function (implying a conglomerate or holding company model) or the enterprise (implying a more integrated business model.
  • If they balance by business process, that the major business processes have been defined, and their importance to business strategy execution determined.
  • They are able to monitor the gaps between their actual IT investments by portfolio category, against their target, or “model” portfolio, and can make adjustments as necessary.

Not a Collection of Projects

From time to time, I see consulting clients attempting to implement portfolio management from a collection of projects.  Sometimes, this activity includes taking a huge list of several hundred (in one recent case, nearly a thousand!) to the business so they can “prioritize the portfolio.”  This bottom-up approach is always doomed to failure.  It is often the result of several years of “order taking” behavior by the IT organization, and is, in fact, the order taking equivalent,  elevated to a different level.  It effectively says:

We’ve taken orders from you for years, and now we have this huge list of projects.  So, please take a look at them, and help us prioritize them, because we can’t do them all!”

This cannot work, and ultimately, reinforces order taking behavior, and the sense that IT does know know what it’s doing, and does not deserve the trust of its business partners.

A Question of Business-IT Maturity

I’ve written extensively about Business-IT Maturity and its relationship to business value. (For a more comprehensive treatment, use this search.)  At very low maturity, by definition, the business executives will not have the wherewithal to engage in and answer the questions exemplified in the bullet points above, so implementing portfolio management is going to be virtually impossible.  But, to get to higher maturity, these questions have to be understood, discussed and decided upon, so the IT leadership is best served educating the business till it is ready to engage meaningfully in these questions.  At that point, they will be ready for IT portfolio management.  Until then, be careful not to call bottom up collections of projects, “portfolios.”  If you do, when you are finally ready to introduce portfolio management, the language, and the business discipline it connotes, will have been polluted.

An the Link Back To Programs?

Finally, linking back to the start of this post, and the readers question, “Programs” become the most meaningful intermediary between “projects” and the “enterprise IT portfolio” – a manageable and meaningful “unit of value-producing work” that business executives can get their heads around.

Photo courtesy of the Building and Fire Research Laboratory.

The IT Infrastructure Investment Deficit Disorder


man-andHow should you treat IT infrastructure investments in a recession?  I was listening to an interesting piece that got me thinking about this question on NPR this morning titled “Obama’s ‘Big Fix,’ And Investment Deficit Disorder.” Renee Montagne interviewed New York Times columnist David Leonhardt about his January 27 article, “The Big Fix.“

Determining IT Infrastructure Investments

Arguing that the US economy has been “far too dependent on consumption over the past couple decades and not dependent enough on investment,” Leonhardt points out that in the 1950s, the government spent the equivalent of about 7 percent of GDP investing in highways, buildings and other infrastructure.  But that amount has declined to 4 percent in recent years.

This got me thinking about IT infrastructure, and how investment levels are determined, and how these levels are typically impacted in an economic downturn.  I think there is an analogy between “government and infrastructure investment” with “business-IT governance and IT infrastructure investment.”  I further believe that the role of business-IT governance in IT infrastructure investment takes on an especially crucial role in an economic downturn.  When “the tide is rising,” as the aphorism goes, it is relatively easier to fund infrastructure, but in the current recession, the temptation will be to starve IT infrastructure.

One of the key roles of business-IT governance is setting the level of IT infrastructure investment.  I use the term “business-IT governance” to describe the highest level of business-IT decision-making, typically the Executive Committee and CIO, who is hopefully a member of that body, or if not, is a member of a special Business-IT Governance body, along with the CEO, CFO and business unit leaders.

The Tragedy of the IT Commons

Extrapolating from Garrett Hardin’s “Tragedy of the Commons” article written first published in 1968 in the journal Science, it is in each business unit’s self-interest to leverage and load the IT infrastructure as much as possible (i.e., put as many cows as possible onto the land)  even if that infrastructure suffers as a result (i.e., even if the commons is damaged.)   The business unit receives all of the benefits from over-leveraging the IT infrastructure (i.e., the herder receives all of the benefits from the additional cows) while the damage to the infrastructure is shared by the entire enterprise (i.e., the damage to the commons is shared by the entire group.)  If all business units make this individually rational decision, the IT infrastructure is degraded and all its users suffer.

Three Key Disciplines for IT Infrastructure Investment

Discipline #1. Business-IT Governance

The metaphor of the commons is a good one, and points out why a robust, intelligent, and forward-looking business-IT governance capability is crucial for planning and guiding the level of IT infrastructure investment and the relative portion of the overall IT spend that goes to common capabilities – i.e., IT infrastructure.  Another reason that increasing IT infrastructure investments may make sense in recessionary times is that business agility becomes increasingly important.  The ability to try new things, to be able to rapidly scale up, scale down and seize market opportunities often requires a more agile IT infrastructure than is typically in place at most companies today.   The good news is that the types of IT infrastructure change that increase agility, such as server virtualization, infrastructure consolidation and rationalization, and the shift to cloud computing, all show promise for actually lowering ongoing IT infrastructure operating costs.

Discipline #2. IT Portfolio Management

Closely related to Business-IT governance is the discipline of IT Portfolio Management – and here I’m really referring to the top down strategic aspects of this important discipline.  (Some organizations practice IT portfolio management more as a bottom up aggregation and rationalization of projects – a practice that I find does not typically work well, and actually masks the fact that top down portfolio decisions are not being made.)

Just as in any market, personal investors have to decide their investment goals (funding college, building wealth for retirement, creating income in retirement, etc.) then formulate an investment strategy that meets those goals, businesses have to determine their IT investment goals, then formulate an IT investment strategy, including:

  • What should the level of IT investment be?
  • How much of this should go into common and shared IT infrastructure?
  • How much, and in what proportion, should go into individual business units and functions?
  • How much should go into “risky” but potentially high return “strategic” investments?
  • How much should go into pure IT research and development?
  • How should smaller business units or opportunities be subsidized by larger, cash-generating investments or business capabilities?

Discipline #3. Enterprise Architecture

Professor Peter Weill at the MIT Center for Information Systems Research) defines Enterprise Architecture as:

The organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model.”

Enterprise Architecture offers the grand blueprint for IT investments – including technology roadmaps, standards and models that help simplify,  unify and rationalize information and technology decisions.   Just as the personal investor will determine their investment goals, then the investment strategy to reach those goals, they will then create (or work with some type of agent or specialist) the roadmap that helps determine when and what investments to buy, what to hold, and when to sell.   Perhaps a better analogy for Enterprise Architecture is the grand design for a city, including forms and designs for transportation (streets, highways, rail lines, bus routes), for energy distribution, for sewers and waterlines, for public facilities such as schools, town halls, libraries, and so on.  One of the most important issues that Enterprise Architecture should address is the question as to what IT capabilities are common and shared – i.e., IT infrastructure, versus business unit specific?

This turned out to be a much longer post than I envisioned as I was shaving this morning while enjoying NPR’s Morning Edition, but my key point is – do you have an IT Infrastructure Investment Deficit Disorder?  Is this exascerbated due to the economic climate?  Is now a good time to be increasing your IT infrastructure investment strategy?  Would your firm be better positioned for the current economy if the IT infrastructre were more agile and responsive to change and opportunity?

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 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.