Managing Product Development

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?

Not all projects should be done. Some projects don’t even rate discussion. But sometimes it’s a lot harder to tell when a project is worthy and should be considered. Here are some questions I ask when trying to evaluate when a project is worthwhile:

• What business need does this project fill? (Does the organization obtain value from this business need)
• Is this project a strategic project for us? What makes it strategic? (Does the strategic reason behind the project change the importance of the project?)
• How does this project fit into all the projects we’d like to do? (Does this project make sense for us to do?)
• Have we done a project like this before? Were we successful? What did it take for us to be successful? Do we have any doubts about our ability to do this project? What are those doubts? (Are we doomed before we start?)
• Do we have the staff or other resources to do the project? (If we can’t adequately fund the project, what should we do differently?)
• What is the effect of finishing this project on time, not finishing this project on time, or not finishing the project at all? What ripple effect does this project have on others?

I supposed if I wanted to make this easier, I could have arranged everything in a table with a yes or no at the top of each column, and you could just mark yes or no. If you have enough yes’s, the project is worthwhile. The problem I have with that approach is that when I ask the first couple of questions with a senior management team, the answers aren’t always yes or no. Sometimes the business need is clear. Sometimes the strategic importance of the project is to have a small project to practice a new set of techniques on. Sometimes the time constraints make the business need clear.

If you use other questions, I hope you post them in a comment. Knowing whether a project is worthwhile is a huge part of management’s necessary decision-making. Because if a project is worthwhile, it’s worth funding, staffing, and moving along. If it’s not worthwhile, it’s worth killing — quickly.

I’m in conversation with a client about a possible project. The Big Guy wanted to meet with me immediately, but had constrained time, so I shifted my schedule and met with him. It was clear from our conversation that he didn’t quite know what he wanted, but he did want a proposal from me. I sent in a proposal and waited … and waited … and waited. (Not an uncommon occurrence

As I’m following up on this proposal, something is crystal clear to me: The Big Guy doesn’t respect the project. I’m not sure he respects me either — because I work on projects like this. So, because he doesn’t respect the project, The Big Guy is delaying any decision-making about the project, including assigning a project manager.

The Big Guy is causing this project to fail. He doesn’t realize the project has already started, and that with his lack of people assignment or decision-making, he’s creating a project no one will want to work on. The Big Guy is a good person, but doesn’t realize what his waffling is doing to the rest of the potential project staff. He’s telling the potential project team that he doesn’t have the hour or two to start the project right, it’s ok for him to delay it. The inference is that the project is useless.

It’s possible the project has no value to the organization — but I strongly doubt it. In my opinion, this project has the ability transform the organization, and I think that’s scaring The Big Guy out of his normal strong decision-making mode.

If you’re ever scared by your projects, or think you’re working on a useless project, or are in some other state where you don’t respect your project, you have several options:

• You can discover reasons to respect your project
• You can ask for help in discovering reasons to respect your project
• You can leave your project and allow the rest of the project staff to succeed with you

It’s not easy to leave a project, especially if you’re The Big Guy in charge of making the project happen. But your lack of respect for your project will cause great harm to your project. You can create a project that’s not worth anything by treating it from the beginning as if it’s not worth anything. If you want to kill the project, great. But if you do think there is value somewhere in the project, but it’s not your cup of tea, then respect your project enough to leave it, so that someone else can make the project happen. Especially if you’re The Big Guy.

Based on yesterday’s comments, it’s past time for me to define what I mean when I talk about product management, product lifecycle management, lifecycle choices, and project management. Here goes:

• Product management: The activities that plan the product’s evolution from birth to obsolescence. In a product company, product managers perform these roles. In an IT organization, the functional owners sometimes perform these roles. (I think more IT organizations need sponsors who plan more than one release out for the product’s evolution.)
• Product lifecycle management: The plans, by release (project), of what the product will become and a rough guess (or wish) for when that release will occur.
• Lifecycle: The choice of how a project manager organizes the project. It may be serial (waterfall or phase-gate), iterative (evolutionary delivery or spiral), incremental (staged delivery), or agile (Scrum, Feature-Driven Development). See here for a comparison of different types of lifecycles.
• Project management: The activities in initiating, planning, steering, and closing a project (one release of the product lifecycle management)

Let me know if you have more terms you’d like here. And, I have every confidence you’ll let me know if you disagree

Oh dear. I was not sufficiently articulate in my last post. Both Frank and David in their comments asked about capacity, the output of the organization over time. That will teach me to post when I’m tired. (Maybe.) Let me try this again.

In each of these projects, senior management wanted more features than they received. Unsurprisingly (to me at least), the more features requested and the longer the project, the less the development staff (developers, testers, writers) could deliver. (Longer projects have more requirements churn than shorter projects, if only because the world keeps changing.)

The feature requests aren’t real requirements, they’re ambiguous placeholders for the real requirements, such as “electronic signature” or “improve speed.” But that’s what the organization has available at the start of the project. By the end of the requirements/design phase, they have real requirements, counted in the way the organization counts. This number is the number management expects to get out of the release. But there’s one more problem: management has set the release date. In fact, management set the release date back at the beginning of the requirements/design phase, without any estimation input from the development staff. So now, management has fixed the number of people available to work on the project, the time for the project, and the number of features it wants. The project has only one clear degree of freedom: the number of defects the project will deliver along with its features.

But, there’s an implicit degree of freedom here, that of features. Even though management claims they want all the desired features, history proves they will accept fewer features. The development organization counts on that, because the release date is set before the requirements are defined. Without firm requirements, it’s impossible to estimate the time necessary. Without estimates, each project essentially throws the dice, to see if there’s any way the project can meet its desired commitments.

The problem the organization has is in the difference between the requirements desired and requirements implemented. During the implementation phase, the developers realize that they don’t have sufficient time to implement some of the requirements as they stand.

Management was convinced it was the testers who prevented them from obtaining all the features they wanted. A senior manager said, “If we shorten the testing time, we can spend more time in development and get the features we want.” As you can tell from the data, they could have done away with testing and still not been able to get the features unless they changed the requirements and design activities. The problem with all of these projects is the inability to adequately define requirements quickly and completely enough for the developers to implement the requirements and the testers to verify them.

There are tons of reasons why the requirements definition phase can take a long time. In his comment, Frank mentioned multi-projecting. Another reason is maintenance from a previous release can take away developer time from requirements definition work. Sometimes the product managers don’t agree with each other on what their feature requests mean. Sometimes the analysts and product managers aren’t able to unambiguously define the requirements, so the developers end up making decisions or changing the requirements during implementation.

In this case, optimizing the project so that the testers could finish faster was the wrong approach. They have at least these choices: making the projects shorter, so the requirements/design phase is shorter; changing the way they define requirements and design; use a different lifecycle so they can continuously produce mini-releases; using estimates based on the requirements to estimate release date. There are probably more options.

What is clear to me, is that as Frank and David pointed out in their comments, the issue is the organization’s capacity, not the capacity of one group. Management can try to ask for more than the development organization can deliver, but unless the development organization changes how it works, it can’t. Lopping off the testing (or for that matter requirements, or any other phase), or optimizing for one phase doesn’t change the organization’s capacity (output over time). The only thing that changes the organization’s capacity is changing how people work (their practices and lifecycle).

I’m on vacation, so I’ll be blogging very little this week. In my last Pragmatic Manager email newsletter, I wrote about killing canceled projects. Here’s the summary:

1. Explain why you’re canceling the project.
2. Give people time to clean up their work before starting on their new work.
3. Cancel all meetings associated with this project.
4. Assign someone to handle the inevitable questions about the canceled project, preferably someone high up in management.
5. Perform a project retrospective and see what people learned from this project.
6. Start people on their new project as soon as they’ve cleaned up their work.