The ins and outs of IT project portfolio management

Do companies sometimes have to estimate what projects will cost and how long they’ll take, even though they have no foundation for their estimates? Yes, they do. As RobertRadina pointed out in a comment on last week’s Advice Line, companies typically plan their project portfolios as part of their annual budgeting cycle, when many of the projects are nothing more than concepts. What do you do?

Next-generation IT doesn’t have this problem. It does what you would do if you could, which is a better job of project portfolio planning. But if your company isn’t hospitable to next-generation IT, you have to estimate anyway. The question then is how to go about it.

[ Find out the 10 business skills every IT pro must master, beware the 9 warning signs of bad IT architecture, and steer clear of the 12 “best practices” IT should avoid at all costs. | For more of Bob Lewis’ continuing IT management wisdom, check out his Advice Line newsletter. ]

How to estimate projects when you know nothing about them

In another comment last week, Mild Mannered Henry suggested taking your worst possible estimate, multiplying by two, then adding another 10 percent. Another commenter, Mike, suggested a more aggressive approach: Start with the worst possible estimate, then square it.

These are fine algorithms, but better is a technique I learned way back when I was earning my reputation for spaghetti coding in my Fortran days: Take your initial gut-feel guess, multiply by two, and move to the next higher unit of time. Thus, a project that feels like it should take four weeks gets an estimate of eight months, while a two-monther gets an estimate of four fiscal quarters.

Do these all sound like jokes? Of course they do. But any estimate given to a project that hasn’t been subjected to scrutiny beyond assigning it a name is going to be a joke. Telling one of these jokes because you have an annual planning process to feed is an example of the third-axle syndrome: getting a flat tire, and instead of fixing or replacing it, bolting on another axle while leaving the flat tire alone. In this case, the flat tire is having an annual portfolio planning process in the first place.

Project portfolio planning uses a master schedule, not a master list

Let’s start with this: What does a project portfolio look like? To answer, let’s start with what a project portfolio isn’t: a list of projects with assigned priorities. It doesn’t look like this because:

1. A list of projects is about as useful for project portfolio management as a list of tasks is for project management — which is to say, not at all.
2. Priorities are just as useless, for the same reason.

In case that isn’t clear: If you were managing a project, would you build a list of tasks, then sort it based on the relative priority of the different tasks?

A useful project portfolio looks a lot like a useful project schedule: It describes what’s supposed to happen, when it’s supposed to start, and when it’s supposed to finish. Project portfolio management is a matter of managing a project master schedule, not a master list. It consists, that is, of everyone involved in managing the project portfolio agreeing on what’s going to happen and when.

Understand this and you’ll understand why “prioritization” is useless: If managing the project portfolio means managing the project master schedule, there are no priorities. As the governance practice (not process!) evaluates each project proposal, there can only be two outcomes: “no” and “when.” Projects are either added to the master schedule or rejected. There’s no other outcome because, really, what would be the point of another outcome?

Annual planning isn’t often enough

A master schedule depends on reliable estimates for every project: their costs, benefits, and duration. This means no project is added to the portfolio until after it has been evaluated well enough to answer these three basic questions.

Which in turn leads to an inescapable conclusion: Once a year is far too long of a planning cycle. Once a quarter? Maybe. Better, once a month. Either way, the project portfolio committee examines the stack of new project business cases (that’s what an assessment of costs, benefits, and durations is) and modifies the project master schedule to accommodate the ones worth adding. This can mean adding projects to the end or inserting them in the middle, thereby pushing back projects already on the schedule, depending on the committee’s judgment on the best project order.

Making project portfolio management synonymous with project master schedule management leads directly to another requirement: Projects have to be short — ideally, never longer than six months. Otherwise, inserting a project and delaying others can be a multiyear disruption instead of a ripple. Need more than six months for a project? Chunk it down into a road map of smaller items.

The “no hold” rule

Here’s a rule that matters: Except for dire emergencies or game-changing opportunities, never put a project on hold once it’s launched. Putting a project on hold is no different from killing it. By the time the staff who have been diverted to other efforts are returned to the tabled project, they’ll lose at least a month figuring out how to reactivate everything while rebuilding team cohesion and remembering the myriad agreements and design decisions that had been part of the team’s collective unconscious before the project had been placed in stasis. While they’re doing this, they’ll also be figuring out whether the original project business case is still relevant, now that so much time has passed.

And a tip: The best way to eliminate the temptation to put projects on hold is to keep them short. If you’re four months into a five-month project, finishing it will clearly make more sense than putting it on hold. But if something urgent comes up that needs staff currently working on a three-year project running for four months (or, for that matter, for a year), putting the running project on hold is far more tempting.

All projects are fully staffed projects

Here’s another rule: No project is scheduled unless the staff needed to work on it will be available — which means an effective project portfolio planning practice depends on keeping track of who will be doing what, when, and for how many hours a week.

In case you need a definition: A project is fully staffed when it never waits for someone to become available to work on it. Staff availability (not “resource” availability) is where managing the master schedule gets complicated. No surprise here: It’s less complicated if all projects are short projects.

Which leads to this week’s punch line and next week’s teaser: Next-generation IT depends on short projects (the punch line) or on having no projects at all.

This story, “The ins and outs of IT project portfolio management,” was originally published at InfoWorld.com. Read more of Bob Lewis’ Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.