Managing Product Development

I’m particular about two things: calling a prose plan a project plan and calling a Gantt chart (or yellow stickies) a schedule. One of my colleagues emailed me last week, explaining he’d spent a week developing a project plan and was hoping I could take a look at it. “Sure,” I said. “Send it along.”

He did. It was a Gantt chart for the next three months, with one- and two-week tasks. I called him and asked for a project plan, with release criteria. Did he have any? No. Had he checked with the people who were going to do the work to see if they could buy into the schedule? No, none of them were assigned yet. Dead silence on my end, trying to figure out how to ask the next question: Did he realize his schedule was already behind because 6 people were supposed to have already started?

I finally just asked the question, ignoring tact. He was quiet. I asked, “Why is this schedule so important to you?” “My manager wants the project done in three months.”

Managers can want anything they want. But wanting it doesn’t make it happen. This is where it’s critical to get started on working by chunk, so you can finish some work, and see where you’re going (I use velocity charts).

He challenged me, “What do you use for a schedule if you don’t make a Gantt chart?” I explained I kept a three-to-four week rolling wave schedule, using inch-pebbles.

If you’re given a deadline, you don’t need a long schedule. You need a short in-depth schedule, along with knowing what done means. You need to spend your time managing the project, not defining a schedule.

If you want to try some templates for a project plan, take a look at the Manage It! templates.

Also this week, over at the AYE Conference, my Starting With Rolling Wave Planning is up.

In one of my classes earlier this week, one project manager explained that he spent an entire day each week working the Gantt chart in a scheduling tool. He has a project of roughly 20 developers, a few testers, and a few other people (I’ve forgotten the details).

I asked if he had one-on-ones with everyone every week, even just an informal checkin to see how things were going. No, he depends on his technical leads (4 or 5 of them) to do that. He then integrates everything into the humungous WBS.

That’s not my style. I’d much rather have a less detailed schedule in the scheduling tool (or hire some administrator kind of person to manage the WBS) and spend time with the people. When I spend time with the people on the project, they are less likely to stretch the truth about their real status. I can see demos or other visible progress. And, I’m much more likely to hear bad news early.

This fellow seems to be succeeding, but I don’t think spending a day a week on a WBS is a scalable idea. I prefer to do rolling wave planning and only plan for a few weeks at a time, and block out the rest of the schedule, and keep talking to the people. And, when I work for people who require a long detailed WBS, I hire a project administrator, who has a full-time job keeping the schedule.

My first choice (and second and third choice is to manage the project in a way that the WBS works for me, not the other way around. And I choose to work for the people on the project, not the schedule.

Sometimes I discover that one of my great ideas has already been discovered by other people I first wrote about rolling wave planning in 1997. For those of you who can’t stomach the paper (it was one of my earliest pieces of writing), here’s an updated description of rolling wave planning:

Loop:

• Plan what you know for the next few weeks (I use a 3-4 week rolling wave). If you’re managing a traditionally planned project, make this as detailed a WBS as you like. If you’re managing an agile project, you may not have to do any more planning than what you already have done.
• As each week goes by, use the knowledge you’ve gained about the project to replan the already-planned weeks and plan the next week at the end of the current schedule.

Endloop

As the project proceeds, you’ll replan frequently, but you won’t replan a lot of the work.

The idea behind rolling wave planning is that you can’t know everything about the project in advance, so don’t bother trying to plan a lot in detail. Plan the next few weeks in detail, always staying about 3-4 weeks ahead of the project. Of course, if you know you have hard dates like end of quarter or a trade show, put those events in the schedule. But rolling wave planning is much more likely to help you achieve any of those hard dates.

I incorporate adaptive planning into my rolling waves, by using the knowledge I’ve gained about the project to (re)organize the work as necessary.

If you haven’t tried rolling wave planning, give it a shot. I find it especially helpful when I want to timebox to meet a specific date and I want early warning if the date is impossible.