Managing Product Development

I received an intriguing email this week asking this question: ” [..]if we were to put a quantitative value against each best practice, summed them up, and compared the total against a possible maximum could we have a predictor of project success?”

No is the short answer. Here’s why: People need to first select which practices are best for their project, and then assess the practices to see if they are working for the project. Not all “best” practices are best for each project. I’ve worked on projects where daily builds were too infrequent and projects where hourly builds were too frequent. If people aren’t trained in inspection, then inspections aren’t appropriate, but peer review might be. I see many projects where the requirements would be better served by not writing anything down except the location of the white board where the real requirements are (and then transcribing those onto some less ephemeral medium.)

As an example, I once consulted to an organization that dutifully recorded its defects discovered per inspection, but did not record prep time. People stopped preparing, and it looked as if the inspections were going well, but the number of defects found kept dropping. Management convinced themselves they were following a best practice of inspection, but the product was so bad it died on introduction.

If you want to predict project success, first determine which pratices make sense for the project. Then determine what you need to qualitatively and quantitatively measure about each practice. Make sure you think about all dimensions of the practice (remember my six sides of the project) to make sure the measurement is not single-dimensional.

In my experience, the best predictor of project success is the people on the project. If they know how to work together and they are capable of performing the work, the work will complete with as much success as the environment allows.

I’ve been thinking a lot about Dale’s post about managers needing to appreciate the work. Appreciation isn’t enough, unless I’ve misunderstood Dale’s post about John Levy’s quote.

To be an effective manager, you have to understand how the work is organized, how to prioritize the work, how to assign the work, how to give people feedback about their work, and how to manage the risks inherent in that work. If you manage project managers, you need to understand the variety of project lifecycles and coach your project managers on when to select which lifecycle. If you’re a development manager, you need to understand how risks can prevent you from accomplishing the work, or when certain people are not capable of taking on a certain design or problem-solving effort. If you’re a test manager, you need to understand which test techniques are most appropriate under which circumstances. If you’re a mid-level manager with responsibility for several groups, you need to understand how each group’s work contributes to the entire work product(s) you have responsibility for.

Maybe this is what Levy meant as appreciation, but it’s more than simple appreciation; it’s understanding of the dynamics of the function(s) or project you’re managing. But it’s not the ability to perform the work. You don’t have to be able to manage projects or write code or develop tests; you have to understand the tradeoffs and handoffs people make, and for that you need to be able to not just appreciate the technical work; you need to understand the dynamics of the technical work so you can speak the language of your technical staff.

One of the most useful decisions a project manager can make at the beginning of the project is to choose a lifecycle for the project. Here’s the way I think about lifecycles:

Not every lifecycle is appropriate for every project. In fact, many lifecycles are inappropriate for many projects. If you can’t determine the requirements fully at the beginning, don’t use a waterfall. If you don’t have a lot of time, plan to chunk the product, either with the chunking lifecycles or with the agile lifecycles.

Test groups get into trouble when they think they can use a waterfall lifecycle. Most of the test groups I’ve met don’t know the requirements before they start developing their tests, so I regularly recommend that the test groups choose a different lifecycle from the rest of the project. Sure, it’s harder to integrate the milestones, but how else can you succeed?

Think about what your customers think is important (time to market/release, feature set, defect levels). In what order does schedule, feature set, or defects matter to which of your customers? Then, review your risks. If you think you’re going to learn a lot with this project, you have tremendous technical risk. If you know a lot about what you have to do, but the time is short, you have schedule risk. When you have both schedule and technical risk, consider using an agile lifecycle. If you have just schedule risk, consider a chunking lifecycle. For just technical risks, an iterative lifecycle. If you’re an experienced project manager, you can divide up the project into several phases, each with it’s own lifecycle (I once led a research phase using a spiral lifecycle, and then moved to design to schedule for the deliverable part of the project).

No lifecycle is completely perfect, but each has possibilities for your project. Consider which lifecycles are most appropriate for your use on this project.

Esther’s here with me this week. We’re revamping our book based on early feedback from our reviewers. We’re focusing on the core skills of managers. Of course, prioritization is in the book. In addition, we’re addressing how to speak the language of the business (to get things done through others), how to give feedback, one-on-ones, managing the project portfolio, effective group meetings, how to gain visibility into the work, and how to report status. Right now, we have a chapter on hiring also, but I’m not sure it will stay in the book.

Our challenge this week are to write so that the book is snappy and fun to read. (For your writers, that means our rule of thumb is to eliminate bullet lists Both of us can do that; it’s harder together. Our future challenge will be to include only what needs to be included in the book. Another example of how little you can do and still create something of value.

I’m supposed to be on the other coast right now. But since I start from Boston, and this Nor’easter has taken over, I’m going nowhere fast. When I planned the trip and the client work, I’d allowed about a half-day of slack in the travel. That’s normally enough. Not this time

When you manage your work, how do you prepare for risks? Aside from Murphy’s Law (Whatever can go wrong will, at the worst possible time), do you actively solicit risks from the project team? If you’re not a project manager, do you think about the risks on your part of the project and bring them to your project manager’s attention? If not, I recommend you do.

There are lots of risks that are surprises, such as this snowstorm. When I booked my travel, this was just another weekend in December. It’s hard to prepare for risks like this one, although I tend to book early-in-the-day flights as a way to manage the normal air travel risk.

But there are lots of risks you can foresee, understand, and plan to manage. If you haven’t yet read Waltzing With Bears, take the time to read it. DeMarco and Lister help you identify relevant risks and plan for dealing with them.

And, in case I’m bumped from my flight tomorrow, I’ve already started identifying alternatives. I hope I won’t need them, but I’m ready. Risks are a fact of life, and everyone needs to identify them and manage them. Preparing for risks is prudent.

At a recent presentation, (Managing the Management Balancing Act) I discussed the problems of multi-tasking. I received this feedback:

Johanna, I have to say that I think you are off the path in terms of “multiple projects.”

1) Organizations just don’t work this way - it isn’t cost-effective.

2) Today’s emerging workforce (20-30) were raised in an environment that was not FIFO. It’s multi-in, multi-out.

If you can prioritize projects and sub-divide the work, these people are fantastic “multi-project” testers. Looking around the room this morning, I see many young faces, raised with multi-tasking as the norm. I think you need to update your thinking.

Oh dear. When I read this feedback, I was sure this was an unseasoned manager, assuming he/she was encountering these problems for the first time. Unfortunately, multi-tasking has been around since people had more than one thing to do

In a recent Software Development article I discussed the true costs of multitasking (as have Hal and Esther and I in our blogs). This manager doesn’t seem to understand the costs; he/she sees the apparent completion of work.

As I reflected more on this, I realized that I believe each manager has the job of prioritizing the work as his/her first role. If you know what you’re supposed to deliver to the organization, you can select the people and organize the work to succeed. If you never choose what to deliver to the organization, you can never fail as a manager. Of course, you can never succeed either, because there’s always too much to do. But you can certainly never fail. Until the whole organization fails.

Managers who never reassess their work prioritization are inadequate managers. Managers who take on the work the organization requests (or demands) and who don’t prioritize are inadequate managers. Organizations that don’t rank their work will fail.

If you’re a manager, first prioritize your group’s work. Then assign it. Monitor the flow and the organization’s priorities. It’s not easy, and it’s necessary.