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:
- 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.
- 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?