IT Business Edge has just published a short slideshow on “Four Common Mistakes in IT Portfolio Management“, re-purposing a post of mine from January 2008.  I think they did a great job simplifying and bringing to life some of the key points in the original post.  Enjoy!

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

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!

I’ve been working with a couple of clients around PMO’s and the thorny space of Portfolio and Program Management.  Not coincidentally, this continues to prove to be an area of great leverage for organizations trying to drive up their business-IT maturity (and with that, increase the business value delivered through IT investments, assets and capabilities.)  It also continues to be among the most popular topics on which I blog.

Each client quickly found the need to get themselves aligned around the terminology, and asked me to create a simple Glossary that would help them differentiate and standardize on the various terms that are central to IT Portfolio Management.

To that end, I offer here a “starting point” for such a glossary.  Of course, in our industry, where terminology is used inconsistently, and where opinions about meanings tend to differ widely, I realize that this exercise is fraught with danger.  However, I offer this as an initial point of reference.  I’d be delighted to hear any major issues with my use of these terms, and suggestion for modification and for extension to this list.

An IT Portfolio Management Glossary of Terms

(Note:  * Source is Wikipedia)

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.

I’m doing a research on how do organizations group their projects into programs, please tell me how do they go about doing that. e-mail me as soon as possible.

First off, this is an important question.  Second, my blogging philosophy is that if a question is worth answering by email, it’s worth offering on the blog, so others might get into the discussion and benefit from it.  Mostly, I reply to a comment with a comment, but when a question is as important as I believe this one is, then I think it deserves a post of its own.

What is Program Management?

Wikipedia covers Program Management well (as usual!) Their simple definition is:

Program management or programme management is the process of managing multiple interdependent projects that lead towards an improvement in an organization’s performance.

Wikipedia goes on to say:

Projects deliver outputs; programs create outcomes.  Program management is concerned with doing the right projects, whereas project management is about doing projects right.

These are key distinctions, and begin to get at the heart of the reader’s question above.

Another great reference is from IBM and their white paper entitled Program management: Different from project management.  In this, IBM says:

Many enterprise IT organizations are tackling large, complex efforts that combine the delivery of software elements, new and changed business models, and overall changes to organizational structure and capabilities. Typically these efforts involve several parallel projects, and managers are finding that “traditional” project management approaches fall short for such undertakings. Consequently, many IT professionals are turning to the substantial body of experience, and the smaller body of documentation, that supports the discipline of program management. This discipline describes principles, strategies, and desirable results for managing large-scale efforts comprising parallel projects.

This description, like the Wikipedia definition, provides clues to the question posted as a comment in my earlier blog entry.

Beware the Language Traps!

A caveat here – organizations tend not to be rigorous (and certainly not globally consistent) with their use of terminology here.  So just because you use the term “Program Management” does not necessarily mean you are doing it.  (Nor does the fact that you use the term Project Management mean you are doing that, or that you have Project Managers mean you are actually doing good project management practice!)  By the same logic, you may actually be doing great Program Management, even though you don’t use the term.  (I have to say, I have never seen this, but it’s possible).

Another language complication is that the term Program Management may have already been adopted by your organization – perhaps with accurate and appropriate usage, but perhaps not.  I’ve worked with aerospace and defense companies where the term “program” has a very specific meaning related to government procurement.  This is a tough issue, because they are not going to throw out that terminology, so you really need some other terminology to distinguish between those sub-units of work that focus on deliverables, timeframes and budgets (project management) and those collections of mutually dependent projects that collectively produce business outcomes.

So, How Do You Group Projects Into Programs?

This is part art, part science, and frequently involves both top-down and bottom-up planning approaches.  The key element is wrapped up in the notion of a business outcome.   A business outcome is a measurable result – both in terms of time and quantity – that is significant to business leaders.  “We will increase the results of cross-selling our services by 15% by the end of 2009″ is a business outcome example.  Note, it is specific as to degree and timing.  It is also of value to the business – sufficient to drive change, and relatively easily turned into one or more financial impacts.

So, how will be achieve this increase in cross selling?

• We will implement a Customer Relationship Management solution
• We will re-engineer our customer acquisition process
• We will reorganize our sales force
• We will change our sales compensation, reward and recognition model
• We will retrain our sales executives
• We will realign our service portfolio to make it easier and more logical for our customers to buy additional services that cross traditional boundaries.

These changes might involve technology, organizational change, change in HR practices and compensation, training and development, changes to the service portfolio, and changes to our marketing approach.  All in all a complex set of changes that are collectively necessary to achieve the outcome.  In this case, the program is likely to be  the “Cross Selling Enhancement Program” or something similar.

The underlying projects that will be grouped into that program are typically defined by organizational units and their primary responsibilities.  The technology changes will be owned by IT, and may include software, data base, and workflow projects (or analysis, design, implementation projects as a different way of breaking things down.)  The sales reorganization and process changes will be owned by Sales, the HR changes will be owned by the HR organization, and the service portfolio changes owned by product management.  The overall program might be owned by Sales and Marketing, or there might be an Enterprise PMO, that could be part of the IT organization, or a separate entity.

The process I’ve outlined about is essentially top-down – start with the outcome, and decompose into component parts by organizational impact or specialization, form into projects and connect together in an overall program plan.  This is ideal.  Often, however, things happen much more organically and chaotically.  A sales VP gets on a kick about cross selling, but after a few months talking about it and hoping it will happen, decides they don’t have the right tools.  She reaches out to Salesforce.com, but fairly quickly realizes she’s going to need help and support from the IT organization.  And, as the onion gets peeled back, new layers of complexity and new issues occur, and the number of projects spawned by the desire for more cross selling mushrooms.

Unfortunately, these individual projects have little or no sight into the original outcomes – increase the results of cross-selling our services by 15% by the end of 2009!  So, the projects loose sight of the goal (and therefore miss it).  They also attach their own “pork” or “earmarks” (to put this in the context of the latest US political debates).  “While we are creating our partnership with Salesforce.com, let’s experiment with their platform to bring some social networking capabilities to bear.”  “While we are training the salesforce in cross-selling, let’s also teach them solution selling.”  While we are cleaning up our customer relationship data base, let’s build a data warehouse to support our business analytics.”  And so it goes.  All potentially worthwhile ideas, but none of them may be essential to achieving the original business outcome, and may potentially derail or de-focus us from achieving that outcome.

Anyway, in the bottom-up case just discussed, the program may be created by recognizing a growing collection of projects that need to be better connected, coordinated and shaped to meet an outcome of importance.  That might mean killing some projects and re-chartering others.

A Question of Governance

So, how do you group projects into programs?  Above all, based on the business outcomes you are trying to achieve.  Ideally, this is a top-down planning exercise, then a bottom-up governance and control exercise to keep the projects collectively on track to achieve the outcomes.  In a less than ideal world, it is first and foremost a governance exercise – you need a mechanism that produces visibility into all the projects going on.  That mechanism also needs visibility into the enterprise and business units strategic intents and desired business outcomes, so that it can recognize opportunities to synchronize, coordinate, refocus, delay or even kills projects that are consuming time and resources, but may not be moving the enterprise or business unit towards its stated goals.   And, by the way, just as Projects group into Programs, so do Programs group into Portfolios.  But that’s a topic for another day!

Is Finance Your “Worst Offender” in the IT “Value Leakage” Stakes?

So, yesterday my colleagues and I were working with a global manufacturing client.  We were sharing some of our latest research into Managing IT During Recessionary Times, and looking for ways to apply the findings to their specific situation.   We were talking about the need to revisit the IT portfolio of installed systems, and work with business partners to do almost a ‘zero-based‘ exercise to re-justify legacy systems.  When we have done this with clients in the past, we have typically identified at least 20% IT cost savings by eliminating legacy systems that have been superceded by newer solutions, but that are still kept in the active portfolio, typically because a few individuals “like the reports the old system generates” and have not taken the time to learn the self-service query/reporting tool that came with the new solution.

I mentioned that I have found that enrolling the CFO in this exercise can help provide the “air cover” to get the portfolio “work-out” accomplished, when the client CIO laughed and said, “But finance is the worst offender in terms of keeping redundant systems on the books!”  I guess I should not have been surprised.  Sometimes, the so-called support functions (e.g., finance, HR, facilities, legal) are not among the most responsible consumers of IT capabilities and assets.  Exacerbating this, I often find that the IT relationships with the other support functions are not the most healthy and constructive.  Perhaps, the current economic climate is a great opportunity to forge stronger partnerships with the support functions, and take out some IT costs?

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?

Beyond the Business Case

These things are all necessary, but are woefully insufficient to drive value realization.  In fact, they can be a trap, creating a false sense of security.  “We’ve done a solid analysis of the business case, so now we can just blaze ahead with the system and the results will naturally and inevitably follow!”   Wrong!!! It’s quite likely that the results that do follow bear little, if any, relationship to the business case.

Seven Steps to Value Realization

There’s a level of analysis, engagement, measurement, control and accountability here that is essential to driving business value and that does not automatically come along with business case development.  So, here are some techniques I recommend to help ensure value realization, not just project approval.

1. Be deliberate and explicit on the language of ‘business case’ versus ‘value realization.’  Whether you use those terms, or other terms, differentiate between things you do/artifacts you use to analyze a project’s or program’s merits and risks, versus those things you do to drive value realization.  They are both critical to success, and many more people do the business case well than do value realization effectively, which is a shame – leaves lots of money on the table!
2. Get really clear on costs and value and accountabilities for each.  Each accountable party should be a party to the value realization plan, and sign up explicitly for their part.  See my earlier post, Lack of Accountability – Who’s Dirty Little Secret?
3. Don’t limit value realization to financial return.  Get explicit about the “value system” at play in your organization.  ‘Time’ may be an important value (e.g., this will reduce new product time-to-market from 6 months to 4 months through…). Quality may be an important value (e.g., this will reduce defect rates from 1% to 0.25% within 12 months enabled by…)  Employee engagement may be an important value (e.g., this will increase overall employee engagement scores as tracked in our annual engagement survey from 85% to 95% within 12 months due to…)  As long as it is an important value, and can be quantified in terms of degree and time frame, and can be measured, it is meaningful to value realization.   Even if you can’t predict with accuracy or precision what a 10% increase in quality is worth, you can measure it and learn the relationships between intermediate outcomes and financial implications over time.
4. Figuring out the value system and the outcomes and intermediate metrics and goals is not easy.  Therefore, it is a great opportunity to engage a broad audience of stakeholders in figuring the metrics out.  This not only ‘spreads the load’ but engages stakeholders in the value realization conversations.  Sometimes, it surfaces problems and opportunities early on, while there’s time to do something about them.  For more on this, see my earlier post on Measuring the Business Value of IT – Where You Can Win by Simply Trying.
5. Once you’ve figured out the outcomes and intermediate metrics, create the measurement plan and document it as part of the program.  I don’t favor post-implementation audits as the primary vehicle for value realization assessment.  Audits are good for lessons learned, but value realization is so important, it is better if you can build the instrumentation into the implemented solution.  The difference is like designing cars where you have to get out every now and again and dip a stick into the fuel tank to figure out how much gas you have (bad), versus designing a fuel gauge into the car (better) versus designing a widget that tells you how many more miles you can travel and that sounds an alarm when you are 50 miles from empty (best).
6. Implement the measurement plan, and take measurement seriously!  Get a senior executive sponsor who’s going to pay attention to this.
7. Ideally, find ways to ‘close the loop’ between measured realized value and individual and/or group rewards and recognition.  This need not be money in someones back pocket – there’s tremendous power in an internal newsletter or collaboration hub celebrating the success of value realized through a system, and congratulating those associated with the program.

If all this sounds simplistic, it is – deliberately so.  I find people obsess over false precision and accuracy, rather than see this whole exercise as on of learning and growth – of driving the right conversations to increase understanding of and commitment to value realization.  Keep it as simple as you can, especially to get started.  Once you’ve got some momentum going, you can get more sophisticated if you feel the need (and the value!)

There’s several things wrong with the picture characterized by long project lists:

1. First, long project lists typically reflect an IT organizational tendency to think in terms of “projects” rather than “programs.”   Projects reflect an IT-centric view, focused on work effort, budgets and schedules. Programs, on the other hand, at their best represent packages of interdependent projects that collectively deliver business outcomes of importance – programs represent a business view, one that is more oriented to value delivered rather than the typical project orientation work effort, budget and schedule.
2. Long project lists typically do not lend themselves the to clear alignment with business strategy and strategic intents.  Programs stand a far greater chance of achieving that.
3. I’m always suspicious of huge lists (often hundreds) of projects as a representation of the work of the IT organization.   They often reflect a “everything is top priority” mindset, and from my experience over years of consulting, are symptomatic of a confused management agenda.

Hopefully, one of the by-products of the current recession is that IT organizations will have every reason to get focused on “the few really big things.”  How does your project list look?  Would your business partners recognize how it aligns with top business priorities?  Does it make your organization simply feel busy?  Or, does it make it feel valuable?