Managing Product Development

I’m writing for gantthead.com this year, about agile and lean project portfolio management. My first article was posted back when I was so sick. See The Game of Risk. You can leave comments there, or if you prefer, here.

Tweet This Post

I’ve been writing a bunch of articles about project portfolio management, exploring the ideas about committing to projects. (See Serial Monogamy Project Management for some initial thoughts.)

But, as I’ve been working with clients and writing more, I’ve been realizing that not only do the decisi0n-makers have to commit to projects, but that the project staff also have to commit to a project–and only one project–at a time.

That can be challenging. People need some time to think about future work, and maybe act on it a little. People might have an interruption from another project, that is in the best interest of the organization to answer. (If Project #1 has a question for someone on project #2, it is in Project #2’s staff’s best interest to answer the question. Not the other way around.)

So, one of the ways to make sure people fully commit is to make sure they are not fully booked 100% of the time. If people have a little slack in their day, they can accommodate the organization interruptions, the stray thought that they want to write down and explore later. Exploring later works best if you have a structure such as “20% time”, where people can take 20% of their time to work on something else.

What I’m finding interesting in my work is that people who have some slack can commit to one project much more easily than people who are 100% “committed” to a project. The people who are 100% committed have no slack to provide other projects some consulting or provide future projects some thinking. The people who are only 80% committed to one project (and not committed to something else, slack is key) are more able to finish their work and accommodate the inevitable interruptions.

When people multitask, they are not committed to a project. They have no slack. They have no time to innovate. They are always behind.

If you are lucky enough to have a leadership team commit to projects in a rank order, take advantage of that ranking. Work on one project at a time–commit to it– giving yourself a little slack, just in case. You can always use the time on your project. But if a higher ranking project needs you to answer a question, you can. You have time to innovate.

It’s not just serial monogamy project management; it’s serial monogamy project participation.

Tweet This Post

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.

Tweet This Post