Managing Product Development

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.

I gave a talk at the local PDMA group called “Setting Expectations Between Engineering and the Three PMs”, attempting to clarify how the roles of product management, program management, and project management are sometimes confused, and to suggest practices that help people unconfuse them. I set up teams of people to create a little project (making greeting cards), having people take on roles as one of the PMs or as an engineer. During the debrief, one of the participants said something like this (I’m paraphrasing because I don’t remember the precise words): “We spent a bunch of time trying to organize around the most efficient way to do things — in an assembly line way — and we were dead last. In fact, we didn’t finish the task. We were the least efficient.”

That team had attempted to plan and implement via the architecture. One person would do all the fronts, one person would do the insides, and one person would do the backs. (In the talk, I’d recommended they implement by slice, doing one feature all the way through the architecture, but that was foreign to this group, so they tried the normal-for-them-approach.)

I’ve run this simulation many times, and this was the most obvious example of how assembly line organization isn’t the most efficient for brand new or not-repeatable-work work. In software, every project is unique. By definition, it’s unique, because if you already have software to do it, you don’t have to write more. If I’d had the teams generate 6 or 7 greeting cards, then assembly line organization might be effective, because the work is repeatable (in the boring sense of the word). But for one card, taking the time to organize in an assembly line wasn’t worth it.

The lesson here is not to prevent people from organizing themselves. We rarely perform 5-10 minute projects. Even if we do, it’s probably worth taking the time to make people comfortable in their organization. But the lesson is this: If you’re developing a unique product, don’t bother trying to optimize around when you do which piece. (Don’t bother organizing all the GUI work together as an example.) The lesson is that implementing by slice, implementing one complete feature at a time is more efficient than grouping all like work together.

In Greg’s provocative comment, he says, “The idea that contributor initiatives are a drag on an organization speaks more to the insecurity of the management than to its skills.” I’ve been noodling that comment since I received it. I agree with Greg that some managers are insecure enough to insist that they make all the decisions about the work that the organization should do, who should do it, and when. But that’s not where I was going with my general suggestions about not allowing skunkworks projects to continue. Here are two examples of skunkworks projects that hurt the organizations:

In the early ’80s, I worked for a machine vision company. As an organization, we were bad at estimating, managing, and finishing projects. We started having a layoff every quarter. One of the people who’d been laid off kept coming back into work to finish his project. This project had one potential customer (it was a specialized application). The developer wrote the code so no one else could understand it. However, he needed changes to the set of libraries for his application to work. He worked for free, but the work to support his project consumed several people over the course of several weeks, starving other projects of necessary people. Our management wasn’t talented, but they had decided on a strategy, and this project didn’t fit. But this project stole cycles from other projects, preventing them from success. And the potential customer wasn’t willing to pay for it.

A few years ago, a very large client reorganized their product offerings. One of their strategies was to stop supporting old products and migrate customers to a newer product that cost less to support and had more features. The manager could not bring himself to stop supporting the customers for the old products, and attempted to support both old and new products — an impossibility given the number of staff. Here, the first-line manager was the one keeping the skunkworks projects going.

Maybe neither of these is a typical skunkworks project. I’ve certainly worked on skunkworks projects where the technology was new and exciting, and our current management could not see how to exploit it. That’s why I believe every technical person needs some slack time now and then, so they can be thinking of ways to exploit the technology they are working on. As much as I respect the talented marketing guys and senior management strategy (when it really is a strategy), there’s nothing like letting a technical person play around with prototypes, a whiteboard, and a few good buddies to develop/exploit a new technology/product. That’s what happened in the Graphing Calculator story.

But what I mostly see in skunkworks projects is not exploitation of a great idea or new technology. Most of the time, I see people wedded to projects that no longer fit the organization’s strategy — old products that should be put to death. And the more people work on them — even for free — the more those old products cost the company. Greg, I agree with you that managers who feel the need to micromanage everything are insecure and don’t belong in a healthy organization. But I don’t agree with the notion (not that you said it) that all technical-contributor-led projects need to continue. Sometimes technical people are wrong-headed about their product ideas too.

I wish I knew of a recipe to develop a reliable product strategy. I don’t think you can create a real product strategy without input from the technical people (in the form of prototypes, or even partially finished products), nor can you create it without understanding what your known buyers want (product marketing input). The technical people may well create something that breaks you out of your current market — or breaks open your current market to something much bigger. But that comes with hard work on all sides: management for taking the time to think about a strategy and eliminating the dead products; marketing for looking for the needs that exist and the needs no one knows about yet; and the technical people who know how to exploit the technology looking for something new and different. Ignore one of these, and you’ve eliminated at least 1/3 of the potentially great ideas.

A little slack time for technical people goes a long way towards developing a product strategy — and reducing management insecurity.

Read The Graphing Calculator Story. (Thank you to Obie Fernandez for finding this gem.

Some ideas that stood out for me:

• The secret to programming is not intelligence, though of course that helps. It is not hard work or experience, though they help, too. The secret to programming is having smart friends.
• …he told his manager that he would start reporting to me. She didn’t ask who I was and let him keep his office and badge. In turn, I told people that I was reporting to him. Since that left no managers in the loop, we had no meetings and could be extremely productive.
• we needed professional quality assurance (QA), the difficult and time-consuming testing that would show us the design flaws and implementation bugs we couldn’t see in our own work. [...] One guy had a Ph.D. in mathematics; the other had previously written mathematical software himself.
• … my sanity was saved by the kindness of a stranger (there are several stories of people who helped in various ways)
• Sitting behind a one-way mirror, watching first-time users struggle with our software, reminded me that programmers are the least qualified people to design software for novices.
• Dozens of people collaborated spontaneously, motivated by loyalty, friendship, or the love of craftsmanship.

When I’ve written about canceled projects in the past, I’ve recommended that managers not allow skunkworks projects like this to continue, because there is too much drag on the organization. However, for this project, the drag appears to have been minimal — but I’m not sure. Can you say that your project is composed of people who collaborate, are internally motivated to create something wonderful? If not, do you know what you could do to move the project staff towards that frame of mind?