“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

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

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)

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!

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.

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.

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. 

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.

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

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

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

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

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