I’m sure you’ve heard conversations like this: Senior Manager: “Candace, I know you said you needed twelve weeks to test this release, but we’re really in a jam. I need you to release sooner. What can you do for me in six weeks?” As much as you might like to say, “Um, not much,” that’s […]
Based on yesterday’s comments, it’s past time for me to define what I mean when I talk about product management, product lifecycle management, lifecycle choices, and project management. Here goes: Product management: The activities that plan the product’s evolution from birth to obsolescence. In a product company, product managers perform these roles. In an IT
I’m not a fan of project scheduling tools. I have trouble making the tools create the schedule the way I think, and I can never quite see the whole schedule when it’s in electronic form. Other people, especially senior managers, tend to believe the project schedule once it’s in electronic form, no matter how
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
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
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,
About 15 months ago, Denise Robitaille and I met for lunch. Denise was explaining how she helped her clients implement a reasonable corrective action program. I explained how I’d helped some of my clients figure out what was really wrong when they had problems. We were struck by the similarities of our approaches. So,
Want to make sure you complete your project as early as possible? Define release criteria. Release criteria are the few critically important objective criteria that define what “done” means for your project. Sometimes, it’s a combination of date, defects, and feature completion. Sometimes it’s just the date. The formula for defining release criteria is: Define
Joel’s discussion of project managers (MS calls them program managers) and developers got me to thinking about the differences between project managers and developers. The difference between project managers and developers is where they deal with complexity and decision-making. PMs deal with complexity and decision-making between people. Developers deal with complexity and decision-making in
Feature Article: Decreasing Project Completion Time, Part 2 Last month, I discussed techniques to decrease project startup time. Now it’s time to look at practices that can decrease project completion time once you’ve started the project. Ask the developers to unit test their code. There are free unit test development tools for Java, C, C++,