Managing Product Development

I’m close to falling into “Crossing the Desert” syndrome. A project team focuses on an interim milestone, works like the devil to meet that milestone. They meet the milestone, look up, and realize they’re not at the end of the project–they still have to finish the darn thing. They’re living the Crossing the Desert syndrome.

The problem with focusing on an interim milestone (and too typically doing lots of overtime, late nights, weekends to meet the milestone) is that the team is burnt out once they’ve met the interim milestone. And you still need them to finish the project.

If you’re a PM in this position, encourage people to take some time off. If they haven’t been taking weekends, and if they’ve been working overtime, have people go back to a regular 40-hour week. NO extra time. If they’ve missed some holidays or vacation, have them take time now. You need people who have brain cells left in their heads, not people who are about to–or already have–made stupid mistakes.

Be prepared for people to be a bit down, even after they’ve met the milestone. Because they pushed so hard, they may not be able to see how much progress they made, or how good the product is. They may only be able to focus on what they didn’t do. You may need to be a bit of a cheerleader.

You may need to replan the rest of the project. If people had to work like crazy to meet an interim date, chances are good that the rest of the schedule is too aggressive, too. Gather everyone in a conference room, hand them all yellow stickies, and ask them to organize how they can finish the rest of the project.

Make sure you acknowledge their hard work, refocus them on the last part of the project, and good luck.

I first heard of Crossing the Desert from Jack Nevison of Oak Associates.

Labels: interim milestone, project management

I’ve had several discussions about maintenance in the past few days. I’m beginning to think I have a different definition of maintenance than other people do :-). For me, maintenance is fixing problems in code. Maintenance is short, small, well-contained and code-based, and should be fixed by the developer(s) who created the problem.

So what happens if there’s a requirements problem that led to a design problem that led to a larger (greater than a couple of days worth of work) development problem? To me, that’s a short project. Once the problem is larger than just coding errors, it’s not maintenance, in the sense that I think about it. If you have to rewrite requirements or fix the design or involve more than just the one or two authors, it’s bigger than “maintenance”. And once it’s a small project, I can manage it with all the other small projects that are part of a release.

This means that when I work on projects, I see the work differently than others seem to. Because I believe everyone has to fix the problems they created, and because I see maintenance as just fixing those problems, I don’t have a problem with maintenance. I do have a problem with scope creep, but not in the sense of new requirements. I have a problem with trying to finish the work the project staff said was already done but isn’t.

That’s why I ask people to plan inch-pebbles, why I use milestone criteria, why I ask developers to implement by slice instead of by architecture, why I request that technical staff completely finish one thing before they go on to another. A by-product is that I don’t normally have to deal with maintenance, unless I’m coming into a project after it’s already started.

What’s your definition of maintenance?

James’ comment and Eric’s comment asked good questions about why I differentiate between milestones and handoffs.

Milestones can be a collection of events (handoffs) that culminate in one milestone. Let’s take the milestone “code freeze” or “code complete.” The code doesn’t magically all become complete on one day; some of the code is completed earlier than others. The code complete/freeze milestone (or more often, code slush) is the last date by which the code is supposed to be complete/frozen. But normally, the code isn’t complete. Some pieces of the code are not yet done, and that implies a delay for the rest of the project.

James noted this phenomenon in his comment: “I often see handoffs that occur on schedule but later turn out to be incomplete, not always easily detectable by the receiving group at the time of the handoff.” That’s why I like to check on handoffs, not only milestones. I’ve seen this happen with all kinds of milestones, but especially with the “code complete” milestone. When the test group starts to test, they realize the milestone hasn’t been met (the code isn’t completely done), even though the schedule has been supposedly met. Eric said, “Each of these milestones also have associated a set of deliverables. In addition, each milestone also has a deliverable called exit criteria so everyone on the team understands what needs to done in order to achieve an exit from the milestone and move on to the next milestone. To me this is a handoff.”

Exit criteria can help make milestones real and accurate. But if the phase exit criteria are not defined, except by the date, or if the PM is only tracking major milestones (because each group is supposed to track their interim milestones), then the project team can miss the milestone, even if the date has occurred. Earned value, if you can calculate it, can help with this. But I find that if I understand the interim handoffs and track them, I know more about the project.

Here’s an example: For projects with several components or several teams working on multiple components, I would expect the designs or code to finish at different times. If I only monitor a “code complete” milestone, I miss all the handoffs between the development groups (which code is ready when and what are the risks of which code is not yet complete?) and the overall handoff of product to the test group. I want to prevent the risk of thinking we’ve met the schedule when we haven’t.

In the last couple of years, I’ve worked with some project managers who thought the reason they made schedules was to know when the milestones would be met. They thought if they knew when “design complete” or “feature freeze” or “code complete” occurred, they could track the schedule.

I’ve never been comfortable with that, and now I think I know why. The PM can track the milestones from release to release and understand — in general — how the project’s process is working. And if you want to know if your general project management process is helpful, track interim milestone estimates and actuals. But to track a specific project, I prefer to track handoffs between groups.

When I manage projects, and especially when I manage programs, I develop a schedule of handoffs. Knowing when this particular design is ready for those particular development groups to implement or use, especially if there’s an API that other development groups need helps me track the dependencies more effectively.

In reality, most interim milestones are irrelevant. (If you have an external event or deliverable, that interim milestone is certainly relevant.) The release date is relevant, but if you meet or beat or slip an interim milestone by a few days, does it matter? Most of the time, no.

What is relevant is if the handoffs arrive to each person or team working on the project. And if you track handoffs, you’re more likely to know earlier if the interim milestone will be met.

Tracking milestones is late information for the project manager. Tracking handoffs provides earlier information.