tanstaafl: An Introduction to IT Portfolio Management

I’ve already written about how the most important task of management is the proper allocation of resources.

By that, I don’t just mean figuring out that Joe and Bob need to work on Project X this week. At a higher, macro level, the issue of resource assignment deals with how the company, as a whole, plans and spawns its suite of projects.

Much of what I’ll have to say in this post will perhaps seem to be intuitive, even obvious. Yet once again, for all its obviousness, it has been astonishingly controversial at many companies. Better said, these concepts seem to be intellectually understood and accepted, yet then resisted, perhaps due to the old adage of “everyone wants to get into heaven, but no one wants to do what it’ll take to get there.”

What does it take to get there, then? You need to plan and schedule projects holistically, not one by one. This approach is commonly known as Project Portfolio Management (PPM), although that term often is used more to describe the aspect of selecting and prioritizing IT Projects based upon corporate strategic and tactical objectives, and then optimizing the whole set to ensure maximum utility. All of that is both valid and critical, of course. I’ll have more to say about project selection criteria later, and in the meantime would point you to some of the references contained in my Lagniappe section.

The Center for Business Practices, in benchmarking current business practices on PPM, determined that “most organizations are at the bottom rungs of the project portfolio management maturity ladder, and they have particularly immature portfolio performance management processes.” Kandi Miller, vice president of information management at Siemens Enterprise Networks, was quoted as, “If quality is important, then project control is essential. And project control without portfolio management is impossible.”

I’m going to take a slightly different tack here, one that for some reason is rarely discussed in the copious literature on PPM. Most organizations I’ve seen, if they know their current projects at all (and not all have a good handle on this) simply operate (at best) in the mode of “start projects one by one”. When a project gets finished, then it’s time to start a new one. This seems to make sense, until you consider the need for scheduling and commitment, as well as the frequent shifts that occur in business strategy and project priorities.

My point is that you can’t (at least successfully) schedule projects one-by-one in a large organization. If you do, you make a commitment that Project X will be done in a month. Then, things shift and shimmy underneath you, and Project Y suddenly gets introduced, with resources allocated as best as you can at that time. Subtle impacts to Project X occur as a result, of course, and Project X is in danger of not coming in on time. Suddenly it’s a crisis, and everyone gets pulled off of Projects Y and Z so that Project X can be bolstered with resources. You can see the domino effect. The next thing you know, everyone will be shrugging about how IT never delivers on time.

Don’t get into this inevitable trap. Instead, insist that projects be viewed as a set (hence the word portfolio), rather than one by one in terms of the level of effort and time line required. That approach requires a systematic examination, at regular intervals, of all projects in the immediate pipeline, and a determination of what will get worked on and what won’t.

Quick recipe: after you’ve done initial “level of effort” estimates for each and every project under consideration, schedule a major quarterly planning session, including all key stakeholders, where you weigh potential projects against “factory capacity” (the sum total of the work units that the factory can produce in the coming quarter). The outcome of this meeting needs to be the approved set of projects that (at least according to your estimates, however flawed they may be) appear achievable in that time frame and within the current capacity of your factory. Then, as the quarter progresses, hold a high-profile weekly recap, the primary purpose of which is report on progress and to fend off unnecessary changes. Your stakeholders will need to be educated again and again on the impact of changes to the plan; it’s common for these to be underestimated, even by your own IT resources.

Above all, remind your stakeholders, again and again, that scheduling resources and project planning is essentially a zero-sum game. Resources (people’s time) allocated to one project means you need to accept the opportunity costs of not having them work on another project. As economists and libertarians love to say, “TANSTAAFL: there ain’t no such thing as a free lunch.”

Lagniappe:

Comments

  1. Kathleen Kostuck says

    Peter, since maintenance continues after a project is implemented, do you include “level of effort” estimates for maintenance for each project when looking at capacity?

  2. Great question, Kathleen, and actually one that needs a whole blog post (or several) in response. In a nutshell, I’m a big believer that maintenance work has to be scheduled and planned separately (and with different resources, wherever possible) from project work. It’s a huge drain on a department in general to have maintenance work (as always, unpredictable in nature) impacting project work, or sometimes the other way around, when project timelines get tight. So it’s a separate endeavor altogether to determine and then plan for the necessary additional resource load that is likely on that maintenance group once the project has been delivered. But the gist of your question is quite right: often that planning is completely ignored, in the blithe assumption that the necessary work will just get absorbed with all the rest.

    Thanks for commenting!

Trackbacks

  1. […] The business doesn’t sit down regularly with IT to do a formal prioritization of major projects. Most critical of all: what gets worked on needs to be constantly examined and revisited, with the […]

  2. […] of committees is the Project Portfolio Management (PPM) process I’ve described frequently here on this blog.  Having a sole individual, even the CEO, decide on project inclusion simply isn’t viable […]

  3. […] who are jointly responsible for the business success of the company.  Focus on IT governance, Project Portfolio Management, […]

  4. […] the list of projects with what can be accomplished by available resources (I call this “factory capacity“). In essence, it’s meant to provide a way to overcome the natural corporate tendency […]

  5. […] is relatively easy, in other words. The hard part is PROJECTS management. As I’ve pointed out before, the most common and glaring problem I see in companies with IT in crisis relates to an unfortunate […]

Speak Your Mind

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Mastodon