Increasing Maturity by Reducing Complexity

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

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

Business-IT Maturity Model

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

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

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

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

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

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

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

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

About these ads

The Business Case as a Value Realization Tool

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

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

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

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

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

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

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

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

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

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

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

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

I will explore each of these enablers in subsequent posts.

IT Funding and the “Stealth Infrastructure” Trap

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

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

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

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

IT Funding and the Level 2 Sticking Point

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

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

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

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

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

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

Language and Business-IT Maturity

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

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

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

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

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

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

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

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

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

IT Maturity and the Role of Relationship Management

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

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

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

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

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

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

IT Leadership and the Level 2 Sticking Point

I want to address a controversial aspect of IT Leadership, and why I see it being a relatively common contributor to why IT organizations get stuck in the middle of Level 2 Business-IT Maturity.

Many years ago, while leading a multi-year longitudinal study of IT organizational transformations, the research team hypothesized that the leadership style and approach needed to transform from Level 1 to Level 2 was quite different from that required to get from Level 2 to Level 3.  In my last post, I referred to Joseph Juran’s Managerial Breakthrough book of 1964, where he distinguishes between “control” and “breakthrough.”  I believe that the Level 1 to Level 2 journey is largely about controlwhile the Level 2 to Level 3 journey is largely about breakthrough.   I have seen CIO’s that are much better at leading a control-oriented IT organization, and other CIO’s that are better at leading one that is breakthrough-oriented.  I have rarely seen CIO’s that are equally adept at both, and that are therefore capable of leading their IT organizations on the entire journey from Level 1 to Level 3.

IT leadership, of course, is about much more than the CIO.  The CIO’s leadership team, IT managers, and ultimately, everyone in the IT organization has a leadership role.  However, if the CIO is not bringing the right leadership style and focus (e.g, breakthroughto get from Level 2 to Level 3) to organizational transformation, her leadership team is unlikely to do so.  If the IT leadership team is not bringing the right style and focus, it is highly unlikely that IT managers will, and so on.  While I don’t believe that change always begins at the top (though it often does), transformational change is ultimately led from the top.

As an example, I recently worked with a systems development organization to help them redesign their IT Operating Model for increased speed and agility.  In trying to model the desired end-state behaviors, we have moved quickly through a series of highly participative workshops and reached agreement on the design of the new Operating Model that everyone agrees is just what is needed.  The organization’s members were (mostly) excited about the changes, and eager to get on with it, but quickly lost momentum as the CIO insisted on more and more detail, financial business cases and so on.  He put the leadership team through a lengthy series of monthly reviews.  Nine months later, little change has happened, the enthusiasm is waning, the momentum that had been established is gone, and the organizational has been “hoist by it’s own petard” as the saying goes – the strong control mindset (prevention of bad change) squeezing out the ambitions for breakthrough (creating good change).

I think one lesson here is reflected in Einstein’s quote, “We can’t solve problems by using the same kind of thinking we used when we created them.”   If you are trying to get from Level 2 to Level 3, look carefully at the leadership and management practices that got you to Level 2.

IT Improvement vs. Breakthrough

I want to explore another aspect of the Business-IT Maturity mid-Level 2 sticking point.  As a client said to me last week in a variation on an old chestnut, “You can’t improve yourself into Level 3.”  I think it was Joseph Juran in the early 1960’s who really had this figured out.  In his groundbreaking book, Managerial Breakthrough, Juran distinguishes between improvement and breakthrough.  This is the essence of a debate that has raged for years between the quality improvement fans and the business process reengineering aficionados – “Should you improve it, or blow it up?”  I’ve always believed that debate was bogus – you need both strategies, and need to understand the differences between continuous improvement (Juran, as a statistical process control authority refers to this as “control”) and innovation (which Juran refers to as “breakthrough.”)  He discusses the different management systems and structural approaches to each.  Both are valid and are appropriate under different circumstances, typically alternating in one long cycle.

My point here is that the journey from Level 1 to Level 2 is essentially one of continuous improvement – putting the controls in place for predictable, stable and reliable services.  The journey from Level 2 to Level 3, at the mid-point of Level 2 requires a shift to breakthrough management.  You can’t get there with a control mindset.

Now the real challenge is, remembering that this is all about a maturity model – the Level 1 and low Level 2 stuff never goes away, so you can’t simply throw out all the good process and quality improvement work you did to get to Level 2.  But you have to shift focus from the IT supply side to the business demand side, and this is where the breakthrough disciplines can be applied.  So, as a broad generalization and over-simplification, you first master continuous quality improvement management (control) on the supply capabilities to get out of Level 1, and then apply innovation management (breakthrough) to get towards Level 3.

Project vs. Program vs. Portfolio Management

I mentioned in the last post the shift from project management to program management as one of the many important shifts in business-IT maturity that typically take place around the middle of Level 2 (in a simplified 3-level model).  I want to explore that in greater detail in this post, and connect it to Portfolio Management which I see as a key discipline in getting to Level 3, and to extracting high, visible business value from IT investments.

A recent post, Programs are More than Just Big Projects, by colleague and friend Roy Yougman in his blog inspried me to discuss Program Management as a critical link between Project and Portfolio Management.  In a simplified sense, project management deals with a single project (be it small or large) with a focus on producing agreed deliverables, to an agreed schedule and budget.  Program management deals with multiple projects that collectively produce an agreed business outcome – i.e., they have inter-dependencies (e.g., impact the same group of stakeholders, each contribute to achieving a business outcome, and depend upon each other to do so).  It is the management of these inter-dependencies against the delivery of the agreed outcomes that distinguishes program from project management.  I have to acknowledge that the terminology here, though well defined in the project management literature and sources such as Wikipedia, is not universal or used consistently.  In the aerospace/defense industry, for example, programs have a different connotation more related to funding.

If projects can be thought of as the bottom of a hierarchy, programs sit above them in the middle of the hierarchy and address a related set of projects, then things get to be most interesting at the top of the hierarchy – the portfolio management level.

My favorite source on IT Portfolio Management are Prof. Peter Weill and his co-author, Marianne Broadbent.  Their first book that addressed this topic was Leveraging the New Infrastructure: How Market Leaders Capitalize on Information Technology.  There are various IT portfolio models around – the reasons I like Weill’s are:

1. It differentiates the IT investment in common, shared infrastructure (broadly defined).

2. Weill has years of benchmark data showing how portfolio allocation varies by industry, and how it reflects business performance.

As I get personally closer to retirement, like many boomers, I give increasing attention to my (meagre!) personal investment portfolio, which makes personal investments and portfolio theory a great analogy for IT investments.  My portfolio goals have changed over time as my circumstances have changed (e.g., putting a kid through college, getting closer to retirement).  Whatever those circumstances, I’ve had the discipline (thanks to an investment advisor) to annually re-think my portfolio strategy, to be explicit about it, and to monitor the performance of my portfolio against that strategy, and adjust periodically.

In the IT portfolio domain, the same is necessary.  How much of our IT spend should be leveraged across the firm?  (By the way, a common challenge is the funding mechanisms for common infrastructure are often weak – another Level 2 trap is that funding in Level 1 and early Level 2 tends to be by the project, and for given business units – nobody likes to fund cross-business unit initiatives!)  How much should we be spending on “risky” but potentially high value initiatives?  How much on informational (business analytics/decision support)? 

Another Level 2 trap is that a firm’s earliest entree into IT portfolio management is typically limited to new spend.  However, the reality for most enterprises is that new IT spend represents less than 30% of total spend, so there is bigger value in applying IT portfolio management to the steady state services (bringing us back to Service Management mentioned in an earlier post)

My key points through all this are to get through Level 2 to Level 3:

1. You need great project management as a fundamental discipline.

2. You need great program management as a bridge to portfolio management.  You can’t easily go from project to portfolio – there are just too many projects, and projects are focused on deliverables, whereas program focus on business outcomes – which is what portfolio management needs to focus on.

3.  The biggest impact in terms of advanced IT practices comes from portfolio management (the IT investment strategy), and if you are weak in project or program management, you will never get the full potential of portfolio management.