Why Everyone Needs to Manage Their Own Project Portfolio

John Cook wrote a blog post, Scaling the number of projects, that starts addressing the issue of why it's everyone's job to manage their own project portfolios. Here's an example of the problem he's noticed:

It sounds easy to manage independent projects: if the projects are for different clients and they have different developers, just let each one go their own way. But there are two problems. One is a single developer maintaining an accumulation of his or her own projects, and the other is the ability (or more important, the inability) of peers to maintain each other’s projects.

I've seen this in IT organizations, where one or two developers work on a “small” product, which, of course needs “maintenance” (more features, some problems fixed, more documentation, whatever). Since that developer wrote it originally, somehow that project is supposed to stay with the developer forever. (That's a bad idea.)

I've seen this in product organizations, where even if it's a larger team, once you've put your hands on the serial driver, or the engine to drive the application, or the version control system, or any other piece of a product or infrastructure, you couldn't get rid of it no matter what you do.

Developers (and testers and writers) need to let go of old work. Their managers need to stop assigning everything that smells like that old thing to those specific developers, and add in the new requests to the entire project portfolio.

The interesting question is: Why does this happen? Why are people stuck with these old projects and legacy work (not in a negative legacy way, just that they've always been assigned to it and it looks like they always will be)?

Because the work is invisible. No one realizes all the little pieces of work. You've got to make that visible, and I like to make it visible in a portfolio.

One way to do that is to start collecting all the work you're supposed to do. (I'll address a product's backlog at some other time). Here's a template to start you off. I like to put this table on a whiteboard or a flip chart. If you must, use a spreadsheet, but please, not the first time. You will be moving stickies around.

Here's how you collect all the work. Make a yellow sticky of all the work you are supposed to do. If you are working on a project for several weeks, make a sticky for that project for each week. Put all the stickies in the appropriate week, above the unstaffed work line. Just get them all in.

Now, be honest with yourself and put the work you can't do in a given week into the unstaffed work row. Now you have something to discuss with your manager or your customers. (I'll talk you through how to do this in my next podcast, which is already recorded, but not posted.)

If you receive a lot of little requests for products you can't get rid of, you can create a product backlog for each product, or a product backlog for your time. (You either fix the requests by product, or fix your time and allow your customers to negotiate among themselves for what you do first. Sorry this is rough, but I haven't written enough about this before to be articulate yet without gesturing with my hands.)

The key is for everyone to know what they are working on for a short while, and what their personal backlog is. That's why I only ever plan for 4 weeks at a time. If you're working in shorter timeboxes, plan for the shorter iteration. But using the portfolio like this allows you to do some rolling wave planning for your work as a whole, especially when you have lots of pieces of work to do.

Leave a Comment

Your email address will not be published.

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

%d bloggers like this: