Managing Product Development

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.

Dwayne’s comment on my post, Architecting from the Features, made me realize I hadn’t provided an example of how I’d changed the book. Head slap on me! One of my rules of writing, which I use when I’m revising because I rarely remember as I’m writing the first draft, is to explain what I’m writing with an example. Examples can be a “for instance”, a story, an anecdotes–anything that connects my writing to the reader. Some people like stories first. Some like the idea first. But both of those kinds of readers will stay with your writing if they know you’ll get to the other part sometime soon.

So here’s the before an after table of contents for the project portfolio management book. I fully expect the chapter titles and contents to change.

I’ve got the notions of the reader’s span of control in “Making Great Portfolio Decisions” rather than in separate chapters, which is making it easier for me to write that and the other chapters.

Dwayne, thanks for asking for an example.

I’ve been writing pieces of the project portfolio book, and was wondering how to explain how managers get caught in the trap of having too many projects. Then I read Joe Ely’s Minimizing Work-in-Process for Knowledge Workers, and had an “aha” moment. (Well, I think I did. You let me know.)

For many managers (and senior technical leads), meetings are their work-in-process (in addition to their email). But what happens at these meetings? Too many senior people are doing something else at these meetings. Even assuming the meetings are well-run (not needing buckets to keep people focused, as in Why Does a Meeting Need Buckets?), sometimes the senior people are still not paying attention. One cause of that lack of attention is too many projects needing some sort of management attention.

I suggested a card technique similar to Joe’s to one of my clients. He could list all the projects down the side of the card, and the number of meetings he had each week for each of those projects–just making a tick mark. He had to count the number of hallway conversations, email threads, and formal meetings. At the end of the week, he had learned several facts:

• He had more projects than he thought he had.
• He had two projects where one asked him anything.
• He had several projects where people interrupted him almost constantly.

What’s fascinating is the conclusions he drew from this data. He thought the two projects that didn’t ask him to make any decisions were not successful–but the opposite was true. Those were the only two projects making progress out of the 30-something projects. The projects that asked him the most questions made the least progress, in terms of finished features per unit time. (These conclusions may not be yours–this is context dependent.)

So, one of the issues in managing the portfolio is that some managers avoid actively managing the portfolio, because they would have to commit their time to fewer projects. If they have to commit their decision-making to fewer projects, the goodness/usefulness of their decisions becomes more obvious. For many managers, that is a Bad Thing–because they don’t have ways to gauge how good their decisions are.

But a funny thing happens when managers have fewer decisions to make. In my experience, the quality of their decisions go up, because they are not so distracted by all the decisions, and by getting confused about which decision is which. (I need to find a reference for this–does anyone have one?) Not only are their decisions better, they can see feedback on their decisions, which improves their next similar decision. This effect is similar to technical staff estimating fewer tasks and becoming better estimators because they get much more immediate feedback on their estimates.

Managers will still be wrong sometimes. Managers don’t have crystal balls. And those times might hurt a lot. But having more output in the form of more finished work can save a manager who makes a wrong decision. The more finished work, the more flexibility the organization has in releasing a product.

So, if you’re a manager, get an index card. Write all the projects down one side (you might have to turn the card to portrait orientation). Write a tick mark next to all the projects you need to make decisions for in a week. At the end of the week ask yourself these questions:

• Should this project be in the current portfolio of staffed work?
• If so, should it have the same relative priority?
• If not, what do I need to do, to remove it from the current portfolio or raise/lower its priority?

Then do that. Yeah, easier said than done. The more decisions you have, the more fractured they are, and the less context you have to make good decisions. A more lean approach will help.

PM Boulevard just published How Often Should You Review the Project Portfolio?. You have to be a member to see whole article (membership is free). You can’t leave comments there, so please leave them here.

I’ve written before about getting organized, especially when it comes to cleaning up my office. My breakthrough came the last time, when I realized I’m the kind of person who needs to see everything out that I’m working on. Same with my to-do list. (See
Cleaning Up the Office, Round 3.)

I use paper for my to-do list. I need to see the whole thing, so I can make those small priority changes throughout the day or the week. I don’t use software (although, when OmniFocus is available, I might try that). Paper works for me.

I’m coaching a manager who was organized as a technical person–he knew what he had to do, he knew when he had to do it, and he got everything done. He became a manager, and started floundering after about a year. He was still getting things done, but the personal cost was too high–too many hours at work, too much stress. As a manager, the number of tasks he had to track was higher and broader than as a technical contributor.

A manager’s work is different than a technical person. A manager’s span of influence is much broader, so managers tend to have more (smaller) tasks, especially tasks that move across the organization. For me, and for my colleague, that requires a different set of organizing skills.

Once you’re managing several people, you need a low-level project portfolio. See Courage Required. That way you can see what everyone is working on, and resolve any context-switching (so technical people get their work done more quickly). You’ll need one-on-ones to check in with folks on a regular basis, so you know if their work is at risk. These two organizing “tools” allow you to see all the work people are doing, so you know if you need to change what you’re doing.

Don’t think you can manage the management tasks with a project scheduling tool–that’s the wrong tool for disparate tasks of varying sizes with no interdependencies except for you. As with any system, first decide how you need to organize and manage the tasks manually, and then you can see if an electronic tool will help.

If you’re a manager, acknowledge that your list of things to do is different and allow yourself to see how you need to manage it differently than you managed your list when you were not a manager.

I’ve been thinking about how to manage the project portfolio, and I just realized why so many project portfolio efforts fail.

There are three kinds of cycles the project portfolio managers need to manage:

• Project cycles: when the project could release something
• Planning cycles: how often the management team assesses the project portfolio
• Business cycles: when customers want something new

To actually manage the portfolio, the project cycles have to be less than (or equal to) the planning cycles. The planning cycles have to be less than (or equal to) the business cycles (unless you don’t care if you only react to customer requests instead of planning for them). Sometimes, you do want to react to customer requests (have a customer request trigger a planning cycle), but once you have a relatively mature product, the customer requests don’t always align with your product roadmap.

To be most flexible, the Agile lifecycles shine for managing the project portfolio. If you can’t manage an Agile lifecycle, use an incremental lifecycle. You’ll have more flexibility on when to end the project–which means you can actually manage the project portfolio.

My most recent Stickyminds column is up: Are Your Pants on Fire, or Do You Suffer from Split Focus?. There’s also a podcast on that page. You can leave comments there or here.

While teaching a management class recently, one participant came up to me at a break, and said, “Why are you teaching us project management with this portfolio stuff? This is supposed to be a management workshop.”

Portfolio management, determining which projects to fund and when, is management work. The best managers actively manage the portfolio, saying yes, no, and when to projects.

When project managers try to do portfolio management, many of them feel torn when they try to balance when to start each project. They can see the reasons for each project, and may not have enough information to be able to actually determine the strategy behind what the portfolio should be.

If you’re a project manager, it’s possible you have to define the portfolio of projects, just to keep your sanity. (That’s why there’s a chapter about portfolio management in Manage It!) But it’s not project management. Your managers need to make those strategic decisions about what to do and when.

Labels: Manage It, portfolio management, project management

I recently spoke with a manager who had too many projects and not enough people. (Sound familiar?) I suggested he organize two kinds of project portfolios. The first is organized with the weeks across the top and the people down the side, explaining which people are doing what in each week, and how much work is unstaffed. The second portfolio was his running estimate of when projects would come into his group (by month) and when they would finish. This way he had pictures to discuss what his choices were with his manager and a picture of how he could make tradeoffs.

Portfolio 1

Portfolio 2

I first did this when I was a manager with too much to do. I took my spreadsheets to my manager and explained I didn’t have enough people for everything. What was the first priority, second priority, third, down the line. He said, “They’re all top priority.” I replied, “So you want me to make the strategic decisions about which projects I’ll staff and which I’ll postpone. Ok, I’ll do that. ” I turned to walk away. “No,” you have to do everything.” I’ve said before that not making a decision is a decision, and I told him that. I decided which projects to staff and which projects to postpone (and which projects we could do less for.

You may want to make sure your responses are more career-enhancing than mine But no matter how you slice it, somebody in the organization needs the courage to rank the projects by deciding which one is the most strategically important, which one is second, which one is third, and so on. If your boss won’t do it, you need to. It’s not easy, and it may feel scary. But if you have pictures of your portfolio, it might be easier.

My Stickyminds column, What’s on Your Not-to-do List? is posted. Please do leave comments there (or here if you like).

This column is based on one of the ideas in Behind Closed Doors.