Toluu

Managing Product Development

Management, especially good management, is hard to do. This blog is for people who want to think about how they manage people, projects, and risk.

Announcement: PSL Mar 22-27, 2009 Albuquerque, NMYesterday

Esther, Jerry, and I are leading another PSL in Albuquerque, NM March 22-27, 2009. If you’ve been thinking of participating, this is the time to sign up. Contact me if you have questions, or to sign up. We would love to have you join us.

Discuss Results, Not TasksYesterday

I spoke with a program manager who’d been displaced from his program because he doesn’t scream or yell at people. (No, I’m not making this up. This is true.) He’s an effective program manager, because he doesn’t tell people to do this or that task. Instead, he tells them the goal and the results he’s after.

The replacement program manager has been telling people to do this task and that one, not providing context, and has been holed up in his office creating the ultimate Gantt chart. To be fair, this is a complex product with hardware, some embedded firmware, software, and the hardware will need several iterations before it’s final. A Gantt chart to show the intersecting dates might be helpful for some people. But a Gantt chart down to 30 levels? Not time well-spent.

Folks from the program are stopping by the original program manager’s office. “Can you please come back to the program? I don’t know what’s going on. I never see the new guy. He yells, but I have no idea why he’s upset.”

The new program manager is creating a disaster/emergency. But it will be one with a great Gantt chart, and he will have yelled at everyone.

If you ask people to deliver results, you are likely to get them. If you measure or assess people on how they perform certain tasks, such as yelling at program staff, or how well people work on a task in isolation, you will get what you measure. But it won’t be what you want.

Remember to measur

Projects, Products, and FinishingDecember 1

Chris asked in his comment,

how about using the word ‘abandoned’ for projects that are “finished”?

I just don’t think of completed projects as abandoned.

Let’s separate the product from the project. Projects complete. Products may never be done, but projects do finish, sometimes whether we want them to or not. I was working as a consultant when a spouse called the VP Engineering. “I’m taking Dan away on Friday for two weeks. You may want to finish that project.” The VP started to complain. She interrupted, “Look, we haven’t been on a vacation in two years. I’ve made arrangements to drop the kids with my mother. I’ll be dropping his cell phone there too. He won’t be bringing his computer. I don’t care what you say, we are leaving.”

The VP decided that we would release on Thursday. Dan and his spouse left and had a great two weeks in Europe. He returned refreshed and able to see a bunch of problems that had stumped him before.

That project was done. But the product wasn’t even close to finished.

Products live for a very long time (we hope!). Products have a lifecycle, but it’s much longer than a project. Some products even require several releases, in the form of a program, to get to a “done” place.  I suppose it’s possible to “abandon” a product for a while when you r

How Long-Term is Your Strategy?November 20

I was thinking about the automakers, and how they want many billions of $ from Washington (please, noooo). I don’t know what their strategic planning is, but it seems not to have changed from the 1960’s. Certainly, when I started buying cars in the 1970’s, I could not afford the low quality/high price/low gas mileage. When we bought our minivan 11.5 years ago (yes, I’m still driving it), we did buy a Dodge Caravan, because at the time it was the best value for our money.

Now that I’m approaching the end of my minivan years, I’m looking for a relatively high mileage four-door sedan. I have a few other requirements, but if you look at the comparisons of cars, you still don’t see US carmakers in the top tier for high quality/low price/high gas mileage. And if they are, the cars are not fun to drive.

I know enough about the car business to be dangerous, not to be helpful. But one of the reasons Detroit is in so much trouble is that they have such long cycle times. It takes any of the US automakers much longer to bring out a new model than any of the other non-US automakers. The longer it takes to finish a car (and let’s not talk about what done means here)–the cycle time, the longer it takes to see if your strategy is right. If it takes you 2-3 years to take a car from idea to manufacturing, and it only takes your competition 1 year, who’s more flexible? Who can react to a relatively changing market?

In my work with high tech companies,

Abandoning vs. Killing ProjectsNovember 4

John Cook, wrote a lovely post, Peter Drucker and abandoning projects, explaining how Drucker talks about abandoning projects. (John, thanks, I will definitely be referencing Drucker in the PPM book.)

I haven’t been using the word “abandon” when I describe stopping projects. I’ve been using the word “Kill” and the concepts of permanently stopping projects (killing them) and putting projects on the parking lot (stopping them for now). John actually says the words from a developer’s perspective:

It can be a tremendous relief to abandon a project.

He’s right. It is a huge relief to stop working on a project.

Here’s why I’ve been using the word “kill” instead of abandon. I want people to make a conscious decision that this project is not worth continuing at all. (The three possible decisions are commit to; kill; or transform a project.) Abandoning feels more like we can just stop the project in whatever state it’s in and walk away from it.

But I don’t know people who can do that. Every time I’ve seen managers attempt to abandon projects, the technical staff want to wrap things up, or get them to a state where the project can be shelved and restarted again later. That’s why I separate the ideas of stopping a project for now (and putting the project on the parking lot) and killing the project.