Managing Product Development

In July, I sent out the Pragmatic Manager email newsletter: 90% Done is Not Almost Done. I have finally posted it. Enjoy!

Glen Alleman has a post about program management, Managing Multiple Projects is Called Program Management which got me thinking. (I’ve written about program management in the past also: Program Management: Multiple Projects With Multiple Deliverables.)

But in the portfolio management book, I defined a few ways to think about your projects as programs:

1. You, and two other colleagues are managing projects that have interdependencies. In fact, you don’t have a product unless all three of you release at the same time. That’s a program and you need to treat it as such.
2. You are managing a bunch of checklist projects (you’ve done similar things in the past, and the risk is not in the project, the risk is in just finishing the work), but when you’ve done all of them, the company gains some sort of strategic advantage.
3. You are phasing releases of a product. That is, you’re working on release 3.2, then 3.3, then 3.4, and eventually 4.0. A program manager can manage the interdependencies among the releases, and a project manager would manage each release.

It’s the strategic part of “we don’t have success unless we all have success” that makes these examples programs.

BTW, I disagree with the difference between project and program managers that Glen quotes from the PMI Portfolio Management Guide. The same table (with the addition of portfolio management) is in the PMI’s Standard for Portfolio Management. IMNHO, a useless book.

Great project managers act like program managers in the table Glen quoted. But it’s worth thinking about program management, collecting related projects or project-like activities to fulfill a common strategic goal.

If you’ve never been a victim of Medieval software project management, wow, I’m impressed. You don’t have to read the rest of this post. But if you’ve ever tried to break free of a legacy product/project, and haven’t been able to, you are not alone.

The problem is we can’t create a knowledge management system that can copy everything in a developer’s head. So we attempt to keep the developer chained to that product, only to break free if he or she leaves the company. I left a job, and the company asked me to keep a listing of all of the files for that product. I explained I had a limited short-term memory, once I started with other things. “But what if I need you?” the manager wailed. “How else will I know what’s in the code?”

Uh, read the code. That doesn’t always work–some people like to make complex code. Or maybe, their code needs to be complex and I just don’t get it. In that case, read the tests. Oh, there are no tests? Hmm, maybe pair-write the product before you get into the one-person-one-product conundrum.

Here’s what I did when I was a manager inside organizations, and what I suggest to clients now: make sure a team works on each project. That means no single-person projects, ever. A team to me contains all the people necessary to release a product. Certainly a developer and a tester. Maybe a writer, maybe a release engineer, maybe an analyst. Maybe a DBA. Whatever it takes to release a product, everyone’s on the team. Everyone participates. If they can automate their work and explain it to other people, great. But it’s not a team unless the team can release the product.

When enough other people know about the insides of a product, it doesn’t matter if all the developers leave–the testers can explain what’s going on. Same if all the testers leave, the developers know. If all the writers leave, the testers and developers know what’s going on. Sure, there’s a learning curve, but no one is hamstrung by legacy projects.

There is no such thing anymore as a single-person project. If all you’ve got is one customer, you’ve still got a two-person project.

Managers create legacy projects because they don’t understand productivity and capacity. What managers need to care about is the number of projects a team can complete per unit time, not how busy any one person is. If you can’t complete n project because you’re still fixing legacy project (which was project n - 4), your manager is not being effective and neither are you.

If you have a legacy project, insist on a team to finish it. Or, if you’re like me, you quit after a while because you didn’t get the team and you couldn’t take it anymore.

If you’re a manager, count those legacy projects, and stick them in your portfolio to either finish or kill or park somewhere if you really think you can’t kill them outright. But stop the partial-staffing of legacy projects. That’s nuts. Either staff it or not. Don’t make people leave because you can’t decide what to do with this project.

I ran into Dan North at the Agile conference today, and explained a little about the project portfolio book. I’m writing it because I have a number of clients who are having trouble breaking the multitasking habit (working on more than one project at one time.)

Dan said, “Oh, you want them to commit to serial monogamy project management!” I cracked up.

He said exactly the right thing. No one has to be married to a project forever–just long enough to finish an iteration. (That’s why serial lifecycle projects are so hard. You have to stay married to the darn project forever.) But once you finish an iteration, you’re free to marry another project.

Thanks, Dan!

A reminder: I’m teaching a public project management workshop in Waltham, MA, Sept 22-24, 2008. If you would like to:

• Understand different lifecycles and when (and how) to use them
• Practice pragmatic approaches to organizing and estimating a project
• Learn a variety of ways to steer a project to success
• Learn how to develop and use release criteria
• Design the data you want to use to measure your project
• and practice, practice, practice this and more

You’ll want to join us. Everyone receives a copy of Manage It! Your Guide to Modern, Pragmatic Project Management. (If you have that one, I’m happy to substitute another of my books.)

The more formal syllabus is here. The registration form is here (note the discount for multiple registrations at the same time). If you have questions, email me. I hope you join us.

I’ve published a podcast: How Many Emergency Projects Do You Have? Enjoy!

I’ve been working with several clients on their transitions to agile–or at least, more agile approaches to their projects. In each case, the managers decided to move towards agile because the technical staff were in their words, “naive” about the project goals. To be fair, none of the projects had a vision or release criteria, so it’s not surprising the technical folks didn’t understand the project goals.

But waterfall, with it’s emphases on understanding up front,  helps create that naivete. If you could understand requirements or design up front, then the project is just a SMOP (Simple Matter of Programming). And the testing is just a SMOT, and the writing is just a SMO (Testing and Writing). With a SMOP attitude, everyone assumes the predictive schedules are correct, creating a sense of naivete for the entire project–not just the technical staff. The managers are naive about what the milestones really mean, and everyone’s naive about the entire schedule.

But there’s an even more insidious  assumption in waterfall: that the time to finish the project doesn’t matter. This attitude arises even more if a senior manager or program manager or project manager says something like, “Quality is Job 1.” At some point, this project has to end and the product has to ship. Maybe not next month, maybe not even next year, maybe the year after. But at some point in time, the product will ship, regardless of the technical staff’s perception of quality. And that’s where waterfall lets down the entire project team.

I haven’t worked on a project or consulted with a company where they had endless time to get to release for at least 20 years. (I can only remember one project where we were not under time pressure back in the early 80’s. But maybe I can’t remember much Granted, I tend to work on or with projects in commercial organizations, so if you’re working on a government project, maybe you have more flexibility in time.

But a waterfall project organization, where you have milestones such as “requirements complete” or “feature freeze” or “feature complete” provide a disservice to the entire project and management team. We know the requirements are not complete. We know the features will change. Saying they are complete or frozen won’t change reality. But those complete or frozen milestones provide a sense of inevitability about the eventual ending of the project, and infer that since we’re “meeting” (ha!) the project milestones, that we will continue to. That’s the naive part. (See There is No Such Thing as Percent Complete and Showing Project Progress (NOT percent complete) for why.)

Waterfall is fine for a few weeks (4 or fewer), and a few people (4 or fewer) and where you’re sure the requirements are not going to change. Absolutely, positively sure. No surprises. But if you have a larger project or a longer project or you have a suspicion things might change, you want to work differently. I recommend you read my recent Cutter IT article, What Lifecycle? Selecting the Right Model for Your Project to see ways to organize your projects so they make more sense.

Naivete can be charming in people. But it makes for badly organized and executed projects and programs. Waterfall reinforces naivete. Any other lifecycle allows you to take a more empirical approach, rather than a more predictive approach. The agile lifecycles are all about empiricism, so they banish naivete–at least, about schedule–completely. Choose any other lifecycle, and you can take a mature, not a naive, approach to your projects.

I recently spoke with a project manager. He was concerned about the product managers handing off the requirements to the development staff.

He was right to be concerned. Handoffs don’t work.  The more people think they are done with “their” part, the less likely you are to receive/finish a great product. That’s because no one can tell what they really want until they see it.

The more often the requirements-generators see the product as it’s being built, the easier it is to modify the product. The more the developers see the testers test the product, the easier it is for them to incorporate that feedback into their development.

A successful product requires everyone to participate fully throughout the whole project.  That means you can forget about people coming off this project to start the next one. That’s because the people who are supposed to come off the project need to continue their work until everyone is done.

Handoffs don’t work. Collaboration does. Keep everyone on the project until it’s really done-done-done.

One of the problems I see in projects is that there is not a sufficient definition of done. For agile teams, it’s not clear what done means for a timebox. For non-agile projects, the team may not agree on what done means for a milestone or for a release.

For an agile team, do you know what done means for your timebox? Is all the code tested? By whom? Is it all checked in? Does it build without problems? Can you demo the product? Can you release the product? I much prefer product that is developed, fully tested by developers, system tested by the testers, and could be released–what I call release-able. But that might not fit for your project. If the product is only demo-able, make sure everyone knows that you still have technical debt and will need another timebox for testing and fixing.

For every team, develop release criteria. That way you’ll know what done means for the project as a whole.

For a team using any lifecycle other than agile, make sure you have interim milestones and criteria for those milestones, so the team has early feedback about the project’s progress. And, measure your progress towards your release criteria.

I’m particular about two things: calling a prose plan a project plan and calling a Gantt chart (or yellow stickies) a schedule. One of my colleagues emailed me last week, explaining he’d spent a week developing a project plan and was hoping I could take a look at it. “Sure,” I said. “Send it along.”

He did. It was a Gantt chart for the next three months, with one- and two-week tasks. I called him and asked for a project plan, with release criteria. Did he have any? No. Had he checked with the people who were going to do the work to see if they could buy into the schedule? No, none of them were assigned yet. Dead silence on my end, trying to figure out how to ask the next question: Did he realize his schedule was already behind because 6 people were supposed to have already started?

I finally just asked the question, ignoring tact. He was quiet. I asked, “Why is this schedule so important to you?” “My manager wants the project done in three months.”

Managers can want anything they want. But wanting it doesn’t make it happen. This is where it’s critical to get started on working by chunk, so you can finish some work, and see where you’re going (I use velocity charts).

He challenged me, “What do you use for a schedule if you don’t make a Gantt chart?” I explained I kept a three-to-four week rolling wave schedule, using inch-pebbles.

If you’re given a deadline, you don’t need a long schedule. You need a short in-depth schedule, along with knowing what done means. You need to spend your time managing the project, not defining a schedule.

If you want to try some templates for a project plan, take a look at the Manage It! templates.