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.

Video Posted: Lessons Learned in Project ManagementDecember 29 2008

The nice folks at SQE have posted my keynote from the Better Software conference, Lessons Learned in Project Management. Yes, some of the material is from Manage It!: Your Guide to Modern, Pragmatic Project Management.

Why Projects Don’t Need SpecialistsDecember 22 2008

I taught several PM workshops last week in Israel. The Israeli project managers have the same concerns that my US students do–it’s difficult to imagine moving to Agile or even just integrating agile methods into your project if you have specialists.

Specialists increase project delays in these ways:

1. They aren’t available when you need them. Because they are specialists, it’s too easy for the specialist to be busy on another task when you need that specific person. And, because you or the specialist estimate only the time the specialist needed, if you ask anyone else to do the task, the task will take too long.
2. The work backs up. No, you don’t need a specialist all the time. But when you do, you need them. So, since work doesn’t arrive as an even distribution, but instead arrives more in a Poisson distribution, the specialist has some periods of time when they aren’t busy, and more times when they have a queue of work.
3. Murphy’s Law will happen. Just when you need a specialist, that person will want a vacation, or want to get married, or go skiing for two weeks, or have a baby. Or, leave the organization.

PMs (and projects) don’t need specialists. They need people who are multi-talented and can finish tasks. Am I saying that we turn GUI designers into kernel developers? No, but there are many more things that a GUI designer or a kernel developer can do, rather than just one specialty.

If you have spec

I’m Disappointing AlreadyDecember 5 2008

I can’t tell if this is a compliment or not, but David Anderson is already disappointed with the Agile 2009 program. Since we haven’t even opened the submission system yet, never mind chosen the program, I’m surprised. What David is reacting to is my organization of the program committee. (The potential compliment is that David is so invested in the Agile conference that he feels it necessary to criticize our process already.)

Last year, at Agile 2008, we had 19 stages, and 37 simultaneous tracks. That was for a conference of about 1500 people. The program was overwhelming, and many people chose the main stage to hear a talk instead of going to something participatory because they couldn’t make a decision. A number of session leaders had done all the work for a session that no one went to. A number of experience report speakers had almost no one at their sessions. That’s demoralizing for the speaker/leader and doesn’t provide value for conference attendees.

I decided to have fewer stages this year (17) and fewer simultaneous sessions. We will have up to 20 simultaneous sessions, which is still plenty.

Some people requested additional stages, and for now, those stages are stages. Will product management be subsumed into customers and business value? Maybe. What happened with breaking acts? No one volunteered to produce it. I asked people as they volun

Discuss Results, Not TasksDecember 4 2008

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

Abandoning vs. Killing ProjectsNovember 4 2008

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.