Managing Product Development

Oh dear. I was not sufficiently articulate in my last post. Both Frank and David in their comments asked about capacity, the output of the organization over time. That will teach me to post when I’m tired. (Maybe.) Let me try this again.

In each of these projects, senior management wanted more features than they received. Unsurprisingly (to me at least), the more features requested and the longer the project, the less the development staff (developers, testers, writers) could deliver. (Longer projects have more requirements churn than shorter projects, if only because the world keeps changing.)

The feature requests aren’t real requirements, they’re ambiguous placeholders for the real requirements, such as “electronic signature” or “improve speed.” But that’s what the organization has available at the start of the project. By the end of the requirements/design phase, they have real requirements, counted in the way the organization counts. This number is the number management expects to get out of the release. But there’s one more problem: management has set the release date. In fact, management set the release date back at the beginning of the requirements/design phase, without any estimation input from the development staff. So now, management has fixed the number of people available to work on the project, the time for the project, and the number of features it wants. The project has only one clear degree of freedom: the number of defects the project will deliver along with its features.

But, there’s an implicit degree of freedom here, that of features. Even though management claims they want all the desired features, history proves they will accept fewer features. The development organization counts on that, because the release date is set before the requirements are defined. Without firm requirements, it’s impossible to estimate the time necessary. Without estimates, each project essentially throws the dice, to see if there’s any way the project can meet its desired commitments.

The problem the organization has is in the difference between the requirements desired and requirements implemented. During the implementation phase, the developers realize that they don’t have sufficient time to implement some of the requirements as they stand.

Management was convinced it was the testers who prevented them from obtaining all the features they wanted. A senior manager said, “If we shorten the testing time, we can spend more time in development and get the features we want.” As you can tell from the data, they could have done away with testing and still not been able to get the features unless they changed the requirements and design activities. The problem with all of these projects is the inability to adequately define requirements quickly and completely enough for the developers to implement the requirements and the testers to verify them.

There are tons of reasons why the requirements definition phase can take a long time. In his comment, Frank mentioned multi-projecting. Another reason is maintenance from a previous release can take away developer time from requirements definition work. Sometimes the product managers don’t agree with each other on what their feature requests mean. Sometimes the analysts and product managers aren’t able to unambiguously define the requirements, so the developers end up making decisions or changing the requirements during implementation.

In this case, optimizing the project so that the testers could finish faster was the wrong approach. They have at least these choices: making the projects shorter, so the requirements/design phase is shorter; changing the way they define requirements and design; use a different lifecycle so they can continuously produce mini-releases; using estimates based on the requirements to estimate release date. There are probably more options.

What is clear to me, is that as Frank and David pointed out in their comments, the issue is the organization’s capacity, not the capacity of one group. Management can try to ask for more than the development organization can deliver, but unless the development organization changes how it works, it can’t. Lopping off the testing (or for that matter requirements, or any other phase), or optimizing for one phase doesn’t change the organization’s capacity (output over time). The only thing that changes the organization’s capacity is changing how people work (their practices and lifecycle).

I’m on vacation, so I’ll be blogging very little this week. In my last Pragmatic Manager email newsletter, I wrote about killing canceled projects. Here’s the summary:

1. Explain why you’re canceling the project.
2. Give people time to clean up their work before starting on their new work.
3. Cancel all meetings associated with this project.
4. Assign someone to handle the inevitable questions about the canceled project, preferably someone high up in management.
5. Perform a project retrospective and see what people learned from this project.
6. Start people on their new project as soon as they’ve cleaned up their work.

At first, when Hal posted State of the Art of Project Management — Underlying Theory is Obsolete I wasn’t sure what he meant by #9: “Project portfolio management is an excuse not to manage each project. Each project team must be set-up for success.” Now in PMO: Obsolete Before It Gets Off the Ground, I understand what he means. I agree.

A PMO can and should be responsible for project tactics (project-by-project and as a whole), not strategy, which is what project portfolio management is. Functional management, starting at the first level and up to the top, has the responsibility for determining which projects are started (and when), which are finished (and when), and which projects are canceled (and when). No one else can or should perform this function. Project initiation, completion, and canceling are strategic decisions, and no one outside of functional management has the information they need to perform that work. If you’re a development (or test or whatever) manager and you’re also a project manager, ok, you wear two hats, and you can help each hat out. But if you’re a project manager or you’re in the project office, you can’t possibly know enough about the organization’s strategy, and how it’s changed, and what that means for managing the project portfolio.

So here’s my take on what the project office (PMO) can and should do:

• Guide project managers through the decisions about how to organize the project.
• Help project managers select among practices that may be useful for their projects and help implement those practices as necessary.
• Help project managers understand the state of their project, and especially to recognize when the project is in trouble.
• Help project managers understand their risks, how to determine the risks, and how to evaluate the risks.
• Supply people who can facilitate retrospectives for completed or canceled projects.

A PMO should be internal consultants to the project managers and to senior management, and completely tactical in focus. Of course, they’re company employees and may well have opinions on the worth of any given project. But the strategic force of managing the project portfolio has to come from management, specifically senior management.

On the face of it, higher productivity looks like a Good Thing. More products for less time. Who wouldn’t want this? But I wonder about this search for higher productivity. What do managers really want?

If you want to understand about productivity for software organizations, read Putnam and Myers’ new book, Five Core Metrics: The Intelligence Behind Successful Software Management. Putnam and Myers discuss what productivity really means.

In the meantime, I think some managers want to release more products faster. But I think more managers want to release more suitable products faster. Since they don’t know how to define or fund “more suitable,” they want everything out faster.

I know of these ways to release more products faster:

• Shorten the projects (yes, you can timebox an entire project. Use a design-to-schedule lifecycle.)
• Start the projects faster
• Use agile techniques, especially short iterations, so you can end the project faster
• Ask how little the project can do, instead of how much

If you have more techniques, please do comment.

People can only think so fast. But with a little management thinking, management can help their technical staff use those brain cycles more effectively, increasing productivity. Much easier and more reasonable than asking people to work more hours or multi-task on several projects.

Steve Smith commented on yesterday’s post, “I think managers have a tough job, especially middle managers. I think that middle managers who are respectful to their employees but choose to execute to abide with their management team’s decision are acting in a dignified manner.”

Steve is right, and it’s not always easy to balance the needs of the company, the manager’s employees, and the manager’s needs. When this has happened to me, I go back to these questions:

1. What do they pay me to do? (This helps me derive the company and employee needs)
2. What decisions do I need to make or actions I need to take that I can live with? (This derives my needs)
3. Can I reconcile those decisions or actions with what they pay me to do and how I can live with myself?

If I can’t successfully reconcile the decisions or actions with my needs, I stop working at this company. If I can, I continue to work at the company. Maybe a couple of stories will help.

Story 1: I was a Director of Quality at a company. The software stunk. They’d brought me in to fix the process. As with many change and process initiatives, we moved at glacier-like speed. The management team asked me to sign a legal document attesting to the quality of the software. I asked them these questions:

1. Am I signing in my capacity as Director of Quality?
2. Am I describing reality or wishful thinking?
3. What is my liability if I sign this?

In the past, my job was to take the heat at customer meetings, to push for change, and to lead the corporate quality initiative. This was a new responsibility, and I needed clarity. My management wanted me to take the heat. But they also wanted me to describe a process we couldn’t even agree on, never mind implement. And, I had substantial liability if the customer became angry and sued us.

This was a no-brainer. I didn’t sign anything. In fact, no one signed anything, because we couldn’t do what the customer wanted. I helped my management see what was happening, something else they paid me to do.

Story 2: I was a Director of Development and had inherited a “problem” employee. My boss came by my office one day, and said, “Fire Sam.” I asked why. Boss said, “I’m tired of his expletive deleted questions. I don’t care how good he is, fire him.”

I told my boss that if he had problems with my employee, he should come to me. I would work with the employee manage his behavior. If that didn’t work, I would fire him myself. But, they didn’t pay me to fire someone whose interpersonal skills were inadequate. At least, not without providing feedback, and coaching if necessary. I chose to provide feedback. The employee chose coaching. We were successful.

I’ve participated in layoffs before. If the senior managers make the decisions, they get to have the joy of the announcement. If they let me make my own decisions, they are also balancing the needs of the business, the employees, and their needs. Once they take over my decision-making, they’re not thinking about one of the pieces. That’s when layoffs go bad and seem irrational. And, that’s when the middle managers can’t be respectful to their employees, nor act in a dignified manner.

Sometimes, it’s not clear that you should fund or staff a project. If you’re not sure how to discriminate between alternative projects, here are four questions to ask:

1. What’s the strategic reason behind this project? (Does the strategic reason behind the project change the importance of the project?)
2. How does this project fit into all the projects we’d like to do? (What tradeoffs do we have to consider?)
3. What environment/staff/resources do we need to make this a successful project? (If we’ve never done a project like this, or if we have doubts, or if we’re missing necessary resources, are we dooming this project to failure?)
4. Can we adequately fund this project as we’ve envisioned it?

If you can’t define the strategy behind the project, or how this project fits, or the prequisites for success, or the necessary funding, you can’t have a successful project. So don’t start it. Ask your four questions, and listen to the answers.