Managing Product Development

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.

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).

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.

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.