If this is a book about managing projects, why is there a chapter about managing the project portfolio? When I work with project managers, they say things such as "My management can't decide which project they want first." Or, they say, "My management wants everything now." Or, they say, "My management makes decisions about projects so late that I start the project late." Or, they say, "I can't keep people just on my project; they're multitasking all over the place."
Managing the portfolio, or helping your management to manage the portfolio, might be a survival skill for you. If your management defines its corporate (or unit) strategy and tells you which project to do when, skip this chapter. But if your management doesn't always make timely decisions, this chapter can help.
Project portfolio management consists of three parts: building the list of projects [RD05], evaluating each of them, and making the decisions about which projects to fund and staff. Once you have a portfolio, you can manage it by keeping a running product backlog [Sch04] for each product. The backlog allows you to start and end smaller, more frequent projects, increasing throughput.
Not every organization knows which projects are active, which projects are supposed to be active, or which projects are planned for when. The first step is to build the portfolio of projects.
Gather the list of all the projects in your department. Note when management thinks the projects have started or are planned to start and when they are supposed to end. Organize them in a grid, month by month.1 If you used stickies on the wall, it would look something like Figure 16.1. Yes, you can certainly use a spreadsheet or a grid and make the portfolio look nicer. But if you want to be able to change it, use the most low-tech tool you can so you have the flexibility to change it easily.
once you have a portfolio, you can evaluate the projects, both qualitatively and quantitatively.
If you have some Idea of start and end dates—even wished-for start and end dates—you can start evaluating the projects. You'll want both qualitative and quantitative evaluation.
Qualitatively Evaluate the Projects
Ask these questions for qualitative evaluation2:
• How does this project fit in with all the others?
• What is the strategic reason for this project?
• Is there a tactical gain from completing this project?
• To make this project successful, are we ready to adequately fund it?
• To make this project successful, are we ready to adequately staff it?
• Do we know what success looks like for this project?
If you can't determine an answer for all these questions, it's time to ask whether the project should be in the portfolio. Sometimes, companies keep projects they can't adequately staff in the portfolio, but decide when to start them so the projects are not inadequately staffed for the entire duration.
Quantitatively Evaluate the Projects
Here are questions to ask for quantitative evaluation:
• When will we see any monetary return from this project?
• What's the expected revenue curve for this project?
• What's the expected customer acquisition curve for this project?
• When will we see retention of current customers from this project?
• What's the expected customer growth curve?
• When will we see reduction in operating costs from this project?
• What's the expected operating cost curve?
Many of my clients find these questions adequate in making decisions about the portfolio, but if your management wants more data, refer to [Coh06] where there is a great section on determining the monetary value of projects.
After evaluating the projects, you can make decisions about them. Being able to make decisions about the possible projects in the portfolio is not easy. But, that's why senior management is paid the big bucks, right? And, not making a decision about the projects is also a decision— and one that's more costly than making a decision that's reversible.
The qualitative and quantitative questions allow you to have a conversation about which projects to fund now and which projects to fund later. It will be clear from the questions and their answers that some projects should be funded now. And some should be funded only if the company has more money than they know what to do with. But your managers might run into trouble deciding among some projects—which really should be funded now and which should be funded later—and when could you change those decisions?
Here's where using agile life cycles (see Section A.4, Agile Life Cycles, on page 339) and building (and using) a product backlog (see Section 16.6, Build a Product Backlog, on page 321) can really help. If you develop in iterations and always develop the highest priority requirements first, you can change priorities as often as you finish an iteration. (I'm not recommending that you do so but that you could.)
You have your evaluated project list, so you can rank-order the projects. If you know which ones you want first, second, third, and so on, you can staff them in that order.
Ranking projects is similar to ranking the project drivers (see Section 1.4, Decide on a Driver for Your Project, on page 23). At some point, one project is more important than the others. If your management is having trouble deciding, list all the projects in a spreadsheet. Across the columns, ask the questions. Meet with your managers, and facilitate their discussion about the answers to those questions. Once they're done, you have a ranked list of projects. You know where your project fits. Once you have a ranked portfolio, you can deal with the problems of starting the projects faster.
^ How do I Decide When Two Projects Really Are the Same Priority?
Here's a common organizational problem. You have two projects, each with a different focus, that you want to fund at the same time. You don't have enough people to staff two different projects. The projects are not similar enough to be part of one program. Now what?
It's time to go back to the corporate mission. If you have two different projects, each that requires the same staff, your senior management needs to articulate their mission. Once they decide on a mission, the decision will be clear.
Typically, long start-up times are a problem of decision making, life-cycle choice, and requirements definition. As a project manager, you might not be able to solve all of these problems. But if you can identify them and point people to the causes and possible solutions, you might be able to start your projects earlier.
If it seems as if your projects never get started, your management might have a problem with decision making. Make sure your decision making includes all of these steps:
1. Defining the desired outcome, such as ranking the projects in order, so everyone knows the relative importance of each project.
2. Establishing the boundaries around the decision, such as chartering analysis of the projects and including who will make the final decision. If you have one person who will decide when to start and staff projects, you need to work with only that person. But if you have a committee, what happens when one person on that committee thinks he or she can veto a decision? Knowing who will make the decision is key to generating a quick decision.
3. Identifying the options so that the group can make a decision. I've met managers who didn't want to select an alternative (do this project or that project), so they refused to make a decision to ratify that alternative. The Rule of Three [Wei85] helps people realize there isn't just one alternative but that with multiple ways to approach the decision, it might be possible to realize what everyone wants. One management team, after years of not being able to make decisions about determining the relative importance of any project, realized they didn't have to decide on one or the other, but they did have to decide when to finish each project. That freed them to allow intermittent prototyping on several projects simultaneously but to assign staff full-time to only one project.
4. Selecting from among options, including identifying the decision criteria about how you (or your management) will make the decision. It's not always easy to choose from among projects. See Section 16.2, Qualitatively Evaluate the Projects, on page 317 and Section 16.2, Quantitatively Evaluate the Projects, on page 317 for questions to ask about how to evaluate those projects.
5. Implementing the decision. Even if you've managed to rank the projects, determine the boundaries around the decision, identify the options, and select an option, if no one says, "Yes, start this project!" it won't start. And then two or three weeks later, you're surprised when a new project lands in your lap. If you find yourself surprised by projects and feeling as if you are late before you even start, work with your management to help you know when project decisions are being discussed. You don't have to attend the meeting; you need to know the outcome of the meeting.
Senior management teams might have trouble determining the strategic outcome they desire. You might see this as an inability to decide among projects. You might even see the schedule games discussed in Section 6.6, Pants on Fire, on page 113 and Section 6.7, Split Focus, on page 115.
This might occur because some management teams have trouble defining the boundaries around their decisions. Some management teams have trouble identifying the options. More teams have trouble selecting from among the options and might try to partially fund all the projects, thinking that some progress on all projects is better than funding some projects and not funding others.
If your management has trouble deciding which project to start when, you can help. Try the pairwise comparison technique (see Section 8.3, Rank the Requirements, on page 158): looking at these two projects, which project do you want more than the other? Compare all the projects to each other, and you'll end with a relative ranking of all the projects.
16.6 Manage the Demand for New Features with a Product Backlog
Part of managing when you'll start which project is managing the demand for new features. If you fall prey to any of the schedule games (especially the one discussed in Section 6.11, We Gotta Have It; We're Toast Without It, on page 124), it's time to offer your management the opportunity to manage the demand for new features on a regular basis.
Build a Product Backlog
There are two parts to building a product backlog: what you'll accomplish in this release and what you'll list for a future release.
A running list of requirements requests—a product backlog—is different from managing the requirements of the current release. When you commit to some number of requirements for the current release, your customers are depending on you to deliver them. And, whether you're protecting the iteration from any changes or the release from too many changes, your customers will have some pent-up demand for the next set of features. A running list separates the current release's requirements from future releases.
The product backlog is a release-by-release ranked list of requirements (or things that could become requirements in the future) [Sch04].
These "requirements" don't have to be fully formed and valid requirements. They can be user stories or a promise to talk about the requirement later. But the word needs to mean something to the developers. Figure 16.2, on the following page, is what a quarterly list might look like. Few things on this list look like requirements, except for the named defects. Note the dark line in Q1. Everything above the line is needed in Q1. Everything below the line is negotiable for Q1. If the project team can't understand it or finish it for Q1, those "requirements" will be addressed for Q2.
You might find it helpful to keep a product backlog (some people call these backlogs product road maps) at several levels. The extended view is four to six quarters of information. Expect that to change relatively frequently. The midrange view is three to nine months. Again, you'd expect the information past the current quarter to change frequently. The short view is zero to three months. Depending on your life cycle, you can either expect change or manage change.
If you're using an agile life cycle, you don't care how often people change features past the current iteration you're in. The only thing you need to do as a project manager is to protect the contents of the current iteration from change. Anything can be moved around past the current iteration. Only the size and duration might cause your sponsors or managers to change their minds about what could be in which iteration. Use planning poker to quickly estimate the size of a number of items in the backlog (see Section 5.1, Planning Poker, on page 87).
If you're using an incremental life cycle, especially one where you timebox requirements and architecture work, you can accept change once you've started developing chunks, even if the chunks aren't all the same duration. Then your sponsors and managers can make decisions based on size, duration, and the availability of certain people.
If you're using an iterative or serial life cycle, you can use a quarterly backlog as long as you keep your releases relatively short or you modify your life cycle to produce chunks during the prototype or coding phases.
You manage the product backlog by discussing it periodically, either as a program team or as a management team, depending on how your organization works. (If you have a product owner or product manager, that person might decide what's in the product backlog or facilitate the discussion of the backlog.) During the discussion, you allow reranking of all the features in the backlog as often as necessary. For an agile life cycle, that means you review and rerank the product backlog before the next iteration starts in order to finalize the backlog for the iteration.
If you're using a serial life cycle but managing to implement by feature and keeping the duration of the release to three to six months, you probably want to discuss the product backlog every month or so. Before planning the next release, discuss as often as you want, and decide before the release starts what's above the line.
You can change the ranking of the items in the product backlog at any time. You protect only an iteration's backlog contents. Once you've started an iteration, you don't change the contents of the backlog for this iteration; any future iteration or release can be changed at any time.
You've tried. You generated the list of projects and a quarterly backlog for each product. And you still have two projects that your managers rank #1. You have a limited number of people. You don't really want them all to work on both projects at the same time, but you don't see another option. It's time to see whether you can put a price or value on the multitasking that people will have to do.
In Section 5.4, Estimating with Multitasking, on page 93, I told you not to allow multitasking. If you really want speed, don't allow multitasking. But speed isn't the only variable. Sometimes multitasking can benefit the organization.
Let me be clear. The more multiproject multitasking you allow (or even worse, encourage), the longer your projects will take. But sometimes, because of revenue concerns, customer experience, or the ability to keep a particular customer, your company will ask you to change project priority. If you make decisions with thought and understand the trade-offs, you can manage the multitasking. You won't obtain the benefit of finishing the project you shift people from. But you will obtain the benefit of completing a different project.
Say you're managing a program that won't be released to the customers for another two months. You're making progress, and you're on track to meet your deadline. Imagine that one of your developers is needed for a Crucial Fix to an already-existing customer. You know that losing that developer will prevent you from meeting your deadline. As a project manager, you don't want to let this person move to the Crucial Fix. But as a relatively senior manager in the company, you realize that turning a happy customer into an unhappy customer is a Bad Idea. What do you do?
As long as you don't bounce any members of the project team back and forth (as in Section 6.6, Pants on Fire, on page 113) between projects incurring cognitive overload,3 look at the relative value of each piece of work. You might decide that keeping your already-existing customer happy is the highest priority. (Your context might not be about customers; it could be about revenue.) You might decide that finishing the program on time is the highest priority. But whatever you do, decide. Asking the developer to work part-time on both programs is a guarantee that nothing will get done fast.
Convincing Management That Context Switching Is a Bad Idea
Managers, especially senior managers, don't believe context switching wastes time because all they do is context switch. Senior managers frequently have several projects in the air, most of them waiting for input from other people. But that's not how technical projects work. Most
of the time, technical people are not in wait states but can continue to work productively on projects. Senior managers don't understand or remember that the work technical people perform is substantively different from the work they perform.
To reach managers and convince them that context switching is a bad idea, make sure you speak their language. First, set the stage by explaining the cost of multitasking technical work. Next, make sure you've developed a project portfolio, so you and your manager can discuss the relative priority of each project. once you do understand not just the cost but also the value, block out the work, and keep your management apprised of the status.
Managers expect to work on several projects and be in wait states for several of them. And, managers typically have assistants to help manage the projects, work on the projects, and monitor the manager's time. But technical staff don't have assistants. They feel the costs of multitasking much more strongly than a manager will.
In Figure 16.3, you can see a picture of two tasks, each of which takes a week to complete. If you work on one task at a time until it's complete, Task 1 finishes at the end of week 1. Task 2 finishes at the end of week 2.
End of Week 1 End of Week 2
Figure 16.4: Two tasks with multitasking
But consider Figure 16.4, which happens when multitasking. Assume that Alice, the person assigned to these two tasks, is working on Task 1 for an entire day and Task 2 the next day. And, let's assume Alice has no other interruptions.
The earliest Alice can complete any task is near the end of week 2, when Alice completes task 1. Sometime early in week 3, Alice completes task 2.
The more tasks Alice has (questions, other projects, whatever), the longer it will take Alice to finish anything. That's because Alice incurs costs each time she switches tasks. The costs for your developers include the following:
• Stopping the work you're doing. The stopping cost is the time it takes to mark your place, save your work, and so on. You haven't stopped thinking about what you're doing, but when you stop to take a phone call or answer a question, there's a stopping cost. If you're in flow, this is surprisingly high.
• Swapping out what you're working on. The swapping out is the act of clearing your mind of the work you had been doing so you have room to swap in the new work. If you were in flow or concentrating deeply, this can take anywhere from five minutes to thirty minutes. Sometimes, it can take even longer.
• Swapping in the new task. Swapping in depends on the complexity of the work and how long it has been since you last touched the task. The more complex and the longer the time since you last touched the task and the more people you have to talk to, the longer it takes.
• Waiting for someone else to stop what they're doing to talk to you about your new task. There's a multiplicative effect of waiting for other people to be available when you have to pick up a new task.
• Swapping the original task back in. Depending on how complex that task is, it can take a few seconds to an hour to wrap your head around what you were doing. (And from a project management point of view, this is when the defects creep in—because it's so hard to remember all the little details you had when you stopped.)
Once you've articulated the cost of multitasking, make sure you understand the relative priority of each project. Review your project portfolio with your manager. If you ask the qualitative and quantitative questions, do you still receive the same answers? If so, then nothing has changed, and your manager will agree to not staff the new work. But maybe things have changed, and it is appropriate to change priorities for now. Develop an agreement with your manager for how long you need to move people from one project to another and when you'll revisit the decision. Then make sure you're using an incremental or agile approach to the project so you have the maximum flexibility.
You and your manager recognize that the desired work does not have more value than the current work—at least not now. And either you or your manager is having trouble saying no to more work.
Sometimes it's politically incorrect to say no. Sometimes you feel like a heel because you want to say no. And there are some organizations in which it's not just politically incorrect—it's career suicide. You have many ways to say no to more work, without actually using the word no. I've used these and found them effective. Find some ways that work for you. Otherwise, you'll constantly be in the schedule game discussed in Section 6.12, We Can't Say No, on page 126.
"Not right now" and offer a new date. You can say, "I can't fit that in right now, but the team can start in April. Here's when we could start, and here's when we could finish." That helps your management see your other priorities and helps them see what you could stop doing if you really need to start this new work.
"Here's what I'm doing—what should I stop doing?" A caution here: make sure to say this nicely. If you say this sarcastically, you are not helping yourself.
As you show your manager (or your manager's manager) the list of the all the work, explain the priorities. "We're doing this project for Laura. Tom and Betty are doing that project for Sidney. And, we have that project for Allen. My team can't do more—there just aren't any more people. Which project do you want us to stop?"
Build a product backlog with your manager. Sometimes, managers ask you to do more work because they don't know or can't depend on any work getting out of your group. In that case, you can move to timeboxed iterations and build a product backlog with your manager to discuss what the manager will see out of your group and when. See Section 16.6, Build a Product Backlog, on page 321.
Prioritize the work with a project portfolio. If a more senior manager asks you to do one more thing, causing multitasking, try this conversation. "Jim, I know you have five or six ongoing projects now. But it will take us longer to do the work if we multitask. And the feedback I have from the product managers is that this release is really important. Let's prioritize the work with a project portfolio so I understand your priorities."
Take your product backlog, and break the work into iterations or relatively short releases (no more than three months). You can plan a project portfolio of what you'll do when for which project. I've used a technique of moving to one- or two-week iterations to finish pieces of work for each project. You don't have to try to do each project simultaneously; even moving to one-week iterations and finishing some work for a given project is better than multitasking.
These are the risks/consequences of the request. Try pointing out the business risks of the multitasking request. "John, we can do that. And if we do that, the writers will be behind for this release because the developers were off working on that other project. I don't know if you remember from last year, but Very Big Customer called our Big Cheese to explain that the undocumented workflow cost them tons of money and time. I'm concerned we'll do that again. Is that a chance we can take?"
"When do you need this" Sometimes, the manager is asking you to add more work to your portfolio, not actually start it now. It's worth asking, "When do you need this? I can put it on the backlog for the next iteration." If it's an entirely new project, asking when the organization needs it means you can respond, "I can slot it in here, after Ron finishes this project. OK?"
If you try all of these, and your sponsor still doesn't accept "no," you are headed for project failure. In that case, consider whether it's time for you to leave. See Section 7.7, Know When It's Time to Leave, on page 148.
• use a product backlog, no matter what life cycle you're using.
• Develop a project portfolio to obtain a visual perspective on all the projects, in process and planned.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.