Managing Product Development

I’ve noticed a common theme among the projects in trouble I’ve encountered over the past few months: functional milestones without deliverable milestones as a part of the functional milestone. Here are examples of functional milestones: “requirements complete,” “code complete.” These milestones raise these questions for me: How can you know something is complete when you’re dealing with software, and how do you know the milestone itself is met? (I’ll get to “complete” later, maybe tomorrow.)

Milestones are met when all their sub-tasks are met. For requirements to be complete, the requirements for each deliverable has to be complete. If you’re building a system with three features, then the requirements for features 1, 2, 3 all have to be complete before you mark the milestone as met. People understand this when I talk to them. But, they don’t always include each of the specific completions as sub-tasks. A common reason is “It’s too much work to put all those tasks/sub-milestones into the project plan.” Whoa, baby. Stop right there. If it’s too much work to create a project plan that tracks deliverables, why do you have such a big project? The project teams have to track their work to this level of detail, or they never meet the milestone. Oh, the people are well-intentioned and think they’ve met the milestone, but they haven’t — because they’re not tracking all the deliverables that make up the milestone.

If you’re faced with a daunting schedule because you have so many interdependent handoffs, make the project smaller. Move to iterations, start fewer simultaneous mini-projects, add more project managers, whatever it takes to be able to get your arms around the project. But whatever you do, create deliverable-based milestones. (Agile lifecycles only have deliverables; that’s one of the reasons status is so easy to see.) Project teams (and PMs) can track deliverable-based milestones. They can’t easily track functional milestones. If the project isn’t on track, it’s easy to see with deliverable-based milestones. Functional milestones can hide whether something is “complete” or not.

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.

From the “I wish I’d said that” list: Via Frank Patrick’s blog, Mike Cohn, in his User Stories Applied for Agile Software Development. Chapter 10, Why Plans Go Wrong in pdf, explains buffers and padding and scheduling:

“A Buffer Isn’t Padding — A buffer isn’t padding. Padding is extra time added to a schedule that you don’t really think you need but that you add just to feel confident in the estimate. Padding is when I take a conventional approach to building a Gantt chart, come up with three months, but tell my boss four months.”

If you use up your padding, you estimated wrong. If you use up your buffers, unexpected risks popped up. Big difference in what you choose to do.If you (the project staff) mis-estimated, you can use EQF, or other estimation techniques to learn why you mis-estimated. If unexpected risks pop up, you can review them to see if you could have forseen them, or to see if there’s something else you can do to make your project less reactive to risks.