Managing Product Development

I spoke with a program manager who’d been displaced from his program because he doesn’t scream or yell at people. (No, I’m not making this up. This is true.) He’s an effective program manager, because he doesn’t tell people to do this or that task. Instead, he tells them the goal and the results he’s after.

The replacement program manager has been telling people to do this task and that one, not providing context, and has been holed up in his office creating the ultimate Gantt chart. To be fair, this is a complex product with hardware, some embedded firmware, software, and the hardware will need several iterations before it’s final. A Gantt chart to show the intersecting dates might be helpful for some people. But a Gantt chart down to 30 levels? Not time well-spent.

Folks from the program are stopping by the original program manager’s office. “Can you please come back to the program? I don’t know what’s going on. I never see the new guy. He yells, but I have no idea why he’s upset.”

The new program manager is creating a disaster/emergency. But it will be one with a great Gantt chart, and he will have yelled at everyone.

If you ask people to deliver results, you are likely to get them. If you measure or assess people on how they perform certain tasks, such as yelling at program staff, or how well people work on a task in isolation, you will get what you measure. But it won’t be what you want.

Remember to measure what done means, not the tasks people do. Your tasks might not be my tasks. As long as we agree on done and we both recognize when we’ve achieved done, we will succeed. That’s the idea behind looking for results, not tasks.

Tweet This Post

Chris asked in his comment,

how about using the word ‘abandoned’ for projects that are “finished”?

I just don’t think of completed projects as abandoned.

Let’s separate the product from the project. Projects complete. Products may never be done, but projects do finish, sometimes whether we want them to or not. I was working as a consultant when a spouse called the VP Engineering. “I’m taking Dan away on Friday for two weeks. You may want to finish that project.” The VP started to complain. She interrupted, “Look, we haven’t been on a vacation in two years. I’ve made arrangements to drop the kids with my mother. I’ll be dropping his cell phone there too. He won’t be bringing his computer. I don’t care what you say, we are leaving.”

The VP decided that we would release on Thursday. Dan and his spouse left and had a great two weeks in Europe. He returned refreshed and able to see a bunch of problems that had stumped him before.

That project was done. But the product wasn’t even close to finished.

Products live for a very long time (we hope!). Products have a lifecycle, but it’s much longer than a project. Some products even require several releases, in the form of a program, to get to a “done” place.  I suppose it’s possible to “abandon” a product for a while when you rank that product’s projects lower on the portfolio.I don’t think of it as abandonment though. If you put the project on the parking lot or on the portfolio backlog, the product isn’t abandoned, it’s just not active.

Only when you obsolete a product do you kill it. And even then, the organization typically has a migration path to a new product.

I’m still not sure what to do with abandonment, but for me, projects finish. Even if they just finish an iteration and then are consigned to the backlog, the parking lot, or are killed for good. They still finished.

Tweet This Post

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.

Tweet This Post

Program management is the art of managing an effort of multiple projects with multiple deliverables.

If you google “Program Management,” you’ll see a bunch of interesting posts, including Chris Pratley’s Program Management. To me, Chris is describing project management, albeit of a large project. When Chris talks about his “program” management, he’s discussing the coordination of a single product’s release. When I talk about program management, I’m discussing how to coordinate multiple product releases, with people who perform project management managing their piece or release. Take a look at Program Management Definitions for their discussion of how to define program management. (Yes, I realize one of their definitions is the large project with sub-projects. I still think that real program management involves multiple deliverables.)

Multiple deliverables and their tradeoffs are the major problems of program management. Program managers coordinate the work of many people, projects, and deliverables (and they should all read Frank’s excellent Multi-Project Management with TOC). They use negotiation and influencing techniques to facilitate the work across the organization. Program managers need to understand enough about the product (solution-space domain expertise) to make sure the technical decisions don’t negatively affect the company’s strategy. (If one project makes a decision that prevents another project from meeting its release date, that’s a negative affect.) One of my clients once told me program management was like grease and glue: grease to ease the way for different parts of the company to succeed, and glue to bring everything together.

Even if you’re managing projects to one deliverable, you may already be using program management techniques. If you’re managing to multiple deliverables, make sure you use program management techniques, including: working across the organization, solving problems outside of meetings, making sure each project’s goals are defined, making sure each project’s staff are working towards those goals, and creating a real program team. The program team needs a reason to consider each other’s concerns (it’s that grease thing again).

Tweet This Post

Rick commented on my last post that some engineers think that status checking slows them down. Mark said that engineers push back on demos and pointless measurements and then said in another comment, “progress metrics can always be free.” Here’s how and what I look for, to determine status.

If I’m managing a traditionally-planned project, I have weekly status meetings with everyone on the project. (For large projects, each project lead has these meetings and I meet with the leads individually.) I ask people to explain the status of their work and what they’ll do next week, and how they’ll track status. I request that people think of their tasks as to-do lists with inch-pebble level work. I won’t put their inch-pebbles into the project schedule; that’s just too complex and I’m not about to track each person’s work. I ask people to monitor when they are stuck and to tell me if they need help in some way. Asking for help is fine. Floundering is not. I request that people peer review each other’s work product (unless we have more formal reviews in practice), so that they get peer feedback about the quality of their work. If someone’s working on a big work product, I ask them to consider what they want to show me: interim designs with chicken scratches, performance measurements of algorithms, number of scripts they threw away, something that shows me progress. Since the engineers determine their tasks, deliverables, and when they need help, I don’t usually come across as micromanaging them. I hear them describe their work products, when they’ve had problems or needed help, and I have a fairly good handle on the project state.

Every so often, I run across an engineer who thinks his work requires privacy to complete. When that happens, I explain that I don’t know how to manage the project adequately with his need for privacy, and what is he willing to show me or give me so I can see his progress. That doesn’t always work, so I ask him when his deliverables will be complete. If he gives me a date of more than two weeks, I explain that’s too long. In many projects, we can afford for one person to be off by two weeks, but I’ve never worked on a project where any one person could slip a deliverable by more than two weeks without affecting the entire project. I’m willing to give the engineer the benefit of the doubt, if he can come up with deliverables that are fewer than two weeks in duration, and maybe I can wait to see the status at the end of those two weeks. If an engineer can successfully deliver work every two weeks, I’m still nervous, but I can manage my nervousness. Once an engineer misses a deadline, we negotiate a different way to track tasks and status. So far, this has worked well. I’ve run into people who hated this, but we figured out a way to deal with my need for information. (I meet with the engineer whenever the engineer wants it, as long as it’s sometime within the normal work day.)

On traditionally planned projects, I send out an email every week explaining the state of the project. Project team meetings are optional. Problem-solving meetings for the project are not optional. (They are two different meetings.) I keep people focused on the end goal and aware of interim milestones.

On agile projects, status is much more obvious to everyone on the project. Since there’s a standup meeting every day, everyone explains what they’ve completed, obstacles they’ve run into, and what they’re going to do. Since I still have to prepare a report to management on project state, I send that by email to the project team also.

When I look for tangible work products, I look for: checkins, designs, how many designs were rejected and why, data about performance or reliability (depending on the product), algorithm development and debugging, people working together on pieces of the product, people working alone, how many people are actually working on this project, number of pizza cartons or other food containers, how long people seem to be at work. If I think there’s too much overtime, I ask people what’s happening and what we should do about it. I really want to prevent people from making stupid mistakes.

When I explain why I need information and the level at which I need the information, most engineers are willing to work with me and I obtain visible progress about the project state.

Tweet This Post

Release trains, the technique of planning releases on a particular date several times a year (such as quarterly releases, on the 12th of the last month of the quarter), can help you manage your development and test staff as well as machines and tool resources. I wrote about release trains a while ago here. If you’re suffering from these problems, consider a release train:

• Your users want more releases of the software and you can’t figure out how to release faster to release more often.
• Your users want fewer releases of the software and you don’t want to maintain too many releases.
• Developers are stomping on each other’s code, in service to separate projects. Or, if the developers manage through the configuration management system not to stomp, the merging is difficult.
• You have many small projects, all of which require significant development and testing resources.
• The testers feel as if they can’t make progress on their testing, that they keep testing the same products over and over because the products keep changing due to the small projects.

Here’s what you need to make release trains work:

• A program manager who reports into the people who determine the corporate-wide initiatives, the reasons for doing all these projects. The program manager manages the release criteria, the project managers, and whatever corporate-level issues need managing to make each release successful. The program manager determines if something is going to miss a particular train and if it should be postponed to the next train. The program manager helps each project maintain its cohesion and reduces coupling between projects.
• Project managers for each project for each of the trains. Each project is a significant effort, so requires at minimum a technical lead, and more likely a project manager to make sure the developers and testers (and the other necessary staff) estimate and deliver their work on time. The project manager has to ensure the developers do no more than necessary. YAGNI, You Aren’t Going To Need It, isn’t just for agile projects, it’s for all projects. The project managers have to be close enough to the project to understand the inevitable tradeoffs and discussions of what’s in and what’s out.
• Great configuration management, both the tool and the release engineers, so you can have up to four simultaneous codelines and the developers can still build to get exactly the sources they need. The release engineers will have to merge the codelines into the mainline too, in case you need to make a patch separate from the next release. (But don’t do it, unless the lack of a patch means corporate death.)
• Enough estimation ability by developers, testers, project managers, and any other project staff to be able to estimate the necessary work, so you can meet your projected release.
• Ability to develop enough automated tests for regression testing. A release train is a combination of an iterative lifecycle, with increments for each release. You’re guaranteed to change the same modules again and again. If you don’t have enough automated tests (and I don’t have a number I can give you), you won’t be able to release when you want to.

You’ll need all of these things to create a successful release train. Cisco and Sun are both releasing product with release trains.

Release trains help you manage all your resources, because you can group similarly-sized or similar-impact projects together into one program. Because there’s one program manager whose job is to satisfy the execs or other corporate stakeholders, one project doesn’t “win” over another project. The sub-optimization that can occur at the project level can’t occur in the program, or the program doesn’t allow the train to release on time.

Software release trains aren’t the only answer. Using agile techniques also help manage resources. If you use agile techniques, your projects are more likely to complete on time. But if you don’t see how to make agile techniques work in your environment, try release trains. They are more like traditional projects, which may mean other people will accept them more readily.

Tweet This Post