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.

Tweet This Post

Now that I’m back from vacation, I’m catching up on my reading. I enjoyed David Anderson’s Management versus Leadership on ‘The Apprentice’ which prompted me to think about what I would have done in Kwame’s place. It took me a long time to learn, but a manager always has the option of firing people who can’t perform the work. I’m not saying you should fire as a first resort — on the contrary. You should exhaust your other alternatives before firing. But if firing is necessary (and I believe it was necessary in the last episode of “The Apprentice”), then fire the non-performer.Some of you are saying, “Oh no, JR, not me. It’s too hard to fire anyone here.” Ok. I didn’t say it would be easy, but you have options, such as:

• Transfer a non-performer to another team. Let some other manager deal with this headache.
• Assign that person less- and less-responsible work. Determine at what level the employee can perform useful work. Maybe the employee has reached his or her level of incompetence.
• Eliminate raises for the non-performer. In case you’re wondering, that’s all raises. No bonus, no raise, no cost of living adjustment, nothing. Raises are about increased value by the employee for the company. If the employee doesn’t increase his or her value, don’t reward the employee.
• Coach a non-performer to leave. Sometimes, the non-performer sticks around out of a misplaced sense of loyalty.
• Call your best recruiter friend and provide the name and contact information of the non-performer, along with a recommendation the recruiter send that person to your competitor.

It’s difficult to succeed with people who don’t perform. And, if you’re faced with one non-performer, with an otherwise high-performing team, the faster you move the non-performer out, the faster the output of your group will rise.

Tweet This Post

I publish a monthly (most of the time) email newsletter, The Pragmatic Manager. The last two issues have dealt with decreasing project time, before and during the project. Clearly, I don’t remember to post notices of the emails every month, so feel free to subscribe yourself.

Tweet This Post

You’re a project manager. You have too much work to fit into a project (scope) and not enough time to do it. What do you do? Timebox.

Timeboxing is a technique to fit what you can accomplish (some of the scope) into the time you have allotted. Timeboxing works when you have fixed schedule and fix team size, but the feature set is variable. If your users/customers don’t help you prioritize the choices, the project team will choose which features to implement.

Agile projects timebox as a matter of course, because they have fixed the people and iteration size, and then decide which features/stories to attack in a particular iteration. Since each iteration is of fixed duration, you only start what you can complete in that iteration, given the number of people you have available to perform the work.

In a phase-gate or non-cyclical lifecycle, you have to work harder to timebox. Here’s an example: You’re a project manager for a project that requires six months and 5 people. You only have three months and 3 people. You know the people can’t perform all the work in that time. So here’s what you do to help people perform the work:

1. Start defining the requirements and design, but limit the time allotted to requirements and design. To start these 12 weeks, define requirements and prototype a high-level design for 3 weeks (your time frames will vary, this is an example). Focus on finishing the requirements definition serially. Don’t start all the requirements; only define one thing at a time. At the end of three weeks, you’ll know where you’re going with the product. Your scope may still be flexible, but you’ve certainly decreased the scope from impossible to possible.
2. Start prototyping or designing the code, again once piece at a time, completing one prototype/design before going on to the next one. Limit your prototyping/design to 2 weeks. Whatever you can prototype/design, you can probably commit to completing.
3. Implement and unit test the code, once piece at a time. Limit this time to 5 weeks.
4. Test the product. This takes the rest of the time, 2 weeks.

At the end of this time, you have a smaller-scope product, but one that’s complete for the scope you chose to implement.

You can choose when to timebox. In this example, the entire project is timeboxed from beginning to end. But you can choose to timebox just a piece of the project, for example, requirements or design. If you timebox requirements, you’ve reduced the scope tremendously, and the project team can work towards fulfilling the requirements. If you timebox design, you have to deal with resetting the scope expectations later in the project, but you’re much more likely to meet the schedule.

Timeboxing is a technique to force the project team to make structured choices about what fits into the product and what doesn’t. The team works on one thing at a time, finishing that piece before going on to the next. If you can’t figure out how to complete all the work in the available time, and you can’t use an agile lifecycle, use timeboxing to force smaller pieces into fixed periods of time.

Tweet This Post

Because I work for myself, I frequently miss things like Secretary’s Day or Boss’s Day. This year I almost missed Take Our Daughters And Sons To Work day. When the Ms. Foundation started Take Our Daughters to Work day, many colleagues poo-poohed it. “Who needs such a thing?” But a funny thing happened. Girls started thinking they could participate in any number of ways at work.

My daughters don’t see a limit on their careers just because they’re female. They may choose to set limits because they see what Mark and I do, juggling the demands of two full-time parents who travel. But they get to make that choice. No one will make it for them.

I’m still not sure this day is enough, but I’m not sure what else to suggest. People — all people — need to know that they can find a way to contribute to work and gain satisfaction from good work in a way that fits for them.

Tweet This Post

Read Bret Pettichord’s How Did the Blackout Happen? to see how cutting yourself off from data can damage your ability to perform your job.

Tweet This Post

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.

Tweet This Post

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.

Tweet This Post

Oh dear. I was not sufficiently articulate in my last post. Both Frank and David in their comments asked about capacity, the output of the organization over time. That will teach me to post when I’m tired. (Maybe.) Let me try this again.

In each of these projects, senior management wanted more features than they received. Unsurprisingly (to me at least), the more features requested and the longer the project, the less the development staff (developers, testers, writers) could deliver. (Longer projects have more requirements churn than shorter projects, if only because the world keeps changing.)

The feature requests aren’t real requirements, they’re ambiguous placeholders for the real requirements, such as “electronic signature” or “improve speed.” But that’s what the organization has available at the start of the project. By the end of the requirements/design phase, they have real requirements, counted in the way the organization counts. This number is the number management expects to get out of the release. But there’s one more problem: management has set the release date. In fact, management set the release date back at the beginning of the requirements/design phase, without any estimation input from the development staff. So now, management has fixed the number of people available to work on the project, the time for the project, and the number of features it wants. The project has only one clear degree of freedom: the number of defects the project will deliver along with its features.

But, there’s an implicit degree of freedom here, that of features. Even though management claims they want all the desired features, history proves they will accept fewer features. The development organization counts on that, because the release date is set before the requirements are defined. Without firm requirements, it’s impossible to estimate the time necessary. Without estimates, each project essentially throws the dice, to see if there’s any way the project can meet its desired commitments.

The problem the organization has is in the difference between the requirements desired and requirements implemented. During the implementation phase, the developers realize that they don’t have sufficient time to implement some of the requirements as they stand.

Management was convinced it was the testers who prevented them from obtaining all the features they wanted. A senior manager said, “If we shorten the testing time, we can spend more time in development and get the features we want.” As you can tell from the data, they could have done away with testing and still not been able to get the features unless they changed the requirements and design activities. The problem with all of these projects is the inability to adequately define requirements quickly and completely enough for the developers to implement the requirements and the testers to verify them.

There are tons of reasons why the requirements definition phase can take a long time. In his comment, Frank mentioned multi-projecting. Another reason is maintenance from a previous release can take away developer time from requirements definition work. Sometimes the product managers don’t agree with each other on what their feature requests mean. Sometimes the analysts and product managers aren’t able to unambiguously define the requirements, so the developers end up making decisions or changing the requirements during implementation.

In this case, optimizing the project so that the testers could finish faster was the wrong approach. They have at least these choices: making the projects shorter, so the requirements/design phase is shorter; changing the way they define requirements and design; use a different lifecycle so they can continuously produce mini-releases; using estimates based on the requirements to estimate release date. There are probably more options.

What is clear to me, is that as Frank and David pointed out in their comments, the issue is the organization’s capacity, not the capacity of one group. Management can try to ask for more than the development organization can deliver, but unless the development organization changes how it works, it can’t. Lopping off the testing (or for that matter requirements, or any other phase), or optimizing for one phase doesn’t change the organization’s capacity (output over time). The only thing that changes the organization’s capacity is changing how people work (their practices and lifecycle).

Tweet This Post