What is Portfolio Management

Portfolio Definition

What a Project Portfolio

The portfolio shows the ranking of your committed projects. You make these decisions evaluating each project against each other. In a sense, the portfolio is a Big Visible Chart, which helps a project team see their relevant information all in one place.


You can use your project portfolio to show everyone what the organization is working on, and what the teams do not work on. This blog explains what is Portfolio Management with the best examples. 


Managing with a Project Portfolio

Portfolios make choices clear because they help leaders restrict which work the project staff starts and finishes. If you use project portfolios, you have the maximum flexibility as a manager. But if you’ve never seen a portfolio or you’ve never used one, you might be concerned, as one of my colleagues explained:


“But, JR, if I commit to a project portfolio, I won’t have the flexibility I need to manage what my group does when. I can’t be responsive to the needs of the organization. I won’t be a team player.”


A portfolio can help you be responsive, especially when project teams work feature by feature in short time periods. When you manage the portfolio, you limit the number of active projects. The fewer number of active projects you have, the less competition the projects have for the same people.


That lack of competition for people allows them to finish projects faster. You increase the number of completed projects, which reduces the total number of projects the organization needs to manage and allows new projects to start. That makes it easier to manage the portfolio. Managing the portfolio increases your organization’s throughput.


Managing Without a Project Portfolio

Managing without a project portfolio leaves you and everyone around you with all sorts of debt. When you don’t manage the project portfolio, you incur management debt by having to make more and more critical decisions without sufficient data.


The products incur technical debt in the form of people taking shortcuts to complete projects because they have too much to work on to take the time to do whatever they need to do right.


And as an organization, you incur capability debt, because people (managers and technical staff) can’t improve their capabilities when they’re overburdened with too much work to do.


When your organization’s management refuses to make a project portfolio, that lack of decision making is guaranteeing at least one or more schedule games.


Or people will decide which project to work on first, and that decision may not agree with yours. Without project portfolio management, you have more projects competing for the same—and limited—the number of people.


You find you can’t commit to which people work on which projects when, you’re awash in emergency projects, and you and your staff are running yourselves ragged multitasking.


If you’ve read Manage It!, you’ll recognize the Pants on Fire and Split Focus schedule games. If you’ve ever had a manager say, “Do project 1 first,” and then, hours or days later, that same manager says, “Do project 2 first,” you have been part of the Pants on Fire game. No one can decide which project is most important. The project team feels as if they have whiplash. They don’t finish enough on anything.


The Split Focus schedule game occurs when a manager tells a person, “Please work 50 percent on project 1 and 50 percent on project 2.” I most often see Split Focus with more than three projects—that somehow, a human being is supposed to focus on more than one thing at a time.


People do not “focus” on more than one thing at a time and perform well. Think of focus like a laser. The beam is coherent, a single beam with a tight circle so you can highlight one thing. When people focus on their work, they can finish it. When they try to work on several different things at a time, they don’t make progress.


Managers perform different work than technical people. Yes, managers are knowledge workers. However, they often focus on the strategic view of the work, which means they can’t finish a task to complete this afternoon.


Teams of knowledge workers can collaborate together to move a feature to do. Teams develop the products—tactical work. If you have teams that work together over time, they learn how to collaborate and learn together.


Managers often change their “teams,” so they collaborate differently than technical teams do. Managers tend to require more information for their work than a single product development team does.


If managers worked more collaboratively on smaller chunks, they might be able to work more as a project team. 


When you don’t manage the project portfolio, you prevent the people from finishing projects quickly. You have more and more unfinished projects and fewer completed projects. That increases the number of projects you have.


And the more projects you have competing for the same staff, the more disorganized and split you become, and the more emergencies you generate for overlooked and neglected projects (like the ones you or your manager forgot about until they became emergencies).


All this increases organizational complexity and makes it harder to manage the portfolio and, even worse, to finish anything of value for the organization.


The lack of decision making at the top flows down to lower-level managers and technical leads. It’s tough to be a senior manager. If you’re in a tight financial situation, making the wrong decision can make things much worse.


I’ve worked with senior managers who were paralyzed by the fear of not making enough money, not having the right mix of products or some other issue.


They literally could not decide how to rank the project priorities in a portfolio. If you’re in that position, start at How to Define a Mission When No One Else Will.


The mission will help guide your decisions. An agile approach to your projects allows you to take on risky projects, by helping you manage the risk, as in Rank the Projects by Risk.


If you’re a first-level or middle manager, it’s possible your management hasn’t decided on a corporate strategy. If that’s true, you can use your portfolio to help them decide by defining your mission along with your portfolio.  


Whatever you do, don’t hide from ranking the projects in your portfolio. When you or your manager refuses to make a project portfolio, your lack of decision making guarantees at least one or more schedule games. Or people will decide which project to work on first—and that decision may not agree with yours.


Why Some Managers Don’t Like Project Portfolios

Some managers are concerned that project portfolios restrict their options.

They do. You commit to honoring these restrictions until the next time you evaluate the portfolio.


Several managers have said, “But I won’t get to move people around day by day to where I need them.” Exactly. I assume you want your staff to complete projects. Moving people around frequently—and incurring the costs of multitasking—is the wrong action. 


Project portfolios restrict your ability to move people around. And, they help you focus on the right work for now. If you use a project portfolio, you will find you have more choices of when to start and finish which work, assuming you use lean and agile approaches to your product development; 


Beware of Multitasking

Multitasking is the fastest way to waste time. With enough multitasking, you can bring all work to a dead stop. When you manage your flow of work through the teams, you can stop—or, at the very least, much reduce—the emergencies.


Your teams will feel a sense of accomplishment as they finish projects. The teams will have a chance to complete features so the features don’t return with defects.


When you don’t manage the flow of work through the teams, every single team—or worse, every single person—decides for themselves what to work on when. Maybe your organization has a ton of work in progress, with nothing totally done. You might ask people or teams to multitask. However, multitasking is the fastest way to slow everything down and finish nothing.


Another problem I’ve seen with multitasking is the “bright shiny object” syndrome. That’s when people say, “Something interesting is over there,” and they work on that. They interrupt themselves. “Bright shiny object syndrome” is not limited to people or teams. Managers can have the same problem.


If the managers interrupt people enough, the people don’t think it’s worth focusing and finishing. When you manage the project portfolio, you can help manage the “bright shiny object” syndrome and help people finish one project at a time. If you don’t decide which project is first, second, and third, you encourage people to work on zero projects.


Managing the project portfolio isn’t easy. But it’s necessary.

Everyone, no matter where you are in the organization, needs to know enough about portfolios to collect their work, organize it, to help evaluate each piece of work against the other work, and to be able to say no to more work.


What Are Your Emergency Projects?

When your organization is in crisis all the time, you need to manage the project portfolio. On the other hand, you might have to react to the world changing. Sometimes the platform on which you develop changes.


Or your major competitor just announced a new product. You want to react to the world changing. You want to change what you’re working on.


When the world changes, you may have to throw out most of your projects and start all over again. That’s because of disruptive change. That’s why you need your mission.


With a mission, you can update your strategy and tactics (which projects to do when) so you can respond to disruptive change without going out of business. Sure, you might have to change your mission or strategy, but if you don’t know where you are, you can’t go someplace else.


But emergency projects that arise from technical debt don’t occur with disruptive change. Emergency projects exist to satisfy customers who aren’t getting what they want—for example, a lack of features, too many defects or other obvious technical debt, a project that was released later than desired.


When you manage your project portfolio, you review your entire backlog—all the organization’s work—and decide what to do.


If you don’t rank the backlog, you might be missing a feature when you need it. If you don’t check the design as you implement features, the next feature may not fit into the system. If you don’t write the code, you certainly won’t have the feature.


If you don’t test the product well enough, some features might not work or might not work in tandem in the system. Emergency projects are the result of technical debt and managerial debt.


If you’re collecting all the work and actively managing the portfolio by reviewing it often enough, you rarely have emergency projects.


That’s because you can see little problems before they become big problems; because you see progress, or lack of it, in a project; and because project teams rarely incur technical debt because you’re using the measure of running, tested features to manage the portfolio.


And, if the world changes, you’re reviewing the portfolio often enough that you can choose to commit to different projects if the world shifts. If you’ve always tried to determine a yearly project portfolio, try reviewing once a quarter and see if that works for you. 


Lean Approaches to the Project Portfolio

I’ve asked you to consider lean and agile approaches to your projects and the portfolio. Agile thinking is the frequent—no more than four weeks—release of valuable chunks of product.  


Think in terms of value. Producers create value, but customers define it. Know how you create value. The value stream is how you identify the problem you want to solve, how you manage to create the solution to that problem, and how the customer acquires the solution.


Create a process flow to make problems more transparent. The team has what they need (people, knowledge, material, etc.) to work in small chunks that they can handle and complete.


When a problem arises, they fix it. Use pull systems to avoid overproduction. Instead of creating “inventory,” you create just the piece of the product you need now.


If you are accustomed to attempting to define all the requirements up front, you instead define the most valuable requirement, and the team implements that. You avoid all the work of gathering and defining requirements that are wrong, as well as the work to implement them.


Level out the workload. Make sure people finish the work already in process before they start on new work. That eliminates multitasking. Stop when there is a quality problem.


If you work in small, doable chunks and you finish one chunk before starting a new one, you will immediately know whether there is a quality problem. If there is, you fix it before going on to another task.


Use visual control so no problems are hidden. Information radiators such as velocity charts, burndown or burnup charts, and the project portfolio backlog burndown charts make the state clear to everyone.


Avoid using the portfolio as a wishful artifact.

A colleague told me about their project portfolio. “We plan and faithfully reevaluate the project portfolio every quarter. We make a nice spreadsheet.


And then, the next day—or at least the next week—we change who’s working on what. Our portfolios look like our project Gantt charts: they look nice until reality sets in, and then the next day or week they are wrong.”


Instead of a spreadsheet, use cards or stickies on the wall. In addition, make sure you ask teams to deliver projects, not people. When you work with stickies or cards as a management team, you learn to become a management team. And, when you ask teams to deliver work instead of individual people, you increase everyone’s throughput.


That said, although the portfolio is a living document, if you change your mind more often than you change the portfolio, you’re wasting your time attempting to rank the portfolio and explain what people need to work on and not work on. 


The project portfolio is most valuable when the decision makers agree that for the next month (or two or three) the technical staff will work on these projects in this order. Then the technical staff does the work. At the end of the evaluation period, the decision makers decide the ranking for the next period.


Know What Work to Collect

You can collect work only in your immediate sphere of influence. That’s because you don’t know what people two levels up or down from you are actually doing.


If you’re a first-level manager, you can ask each person in your group what they are working on. But the more middle- or senior-level management you are, the more you have to work through your staff.


Explain what you want to know and how you want to see it. You might even use the next few paragraphs to help them understand. Don’t be afraid to depend on others to help collect the work; be clear on what you want to see.


As you collect your work or as you ask others to collect theirs, remember to look at all five categories of work—periodic work, ongoing work, emergency work, management work, and project work—to see who’s doing what in your portfolio, as in Behind Closed Doors:

Secrets of Great Management. Although you might think of project work first, remember the other work, too.


Some of your work is organized by time:

Periodic work, such as monthly reports or yearly budgets or training or vacation. If it’s something you need to do at a specific time but is not part of a project, it’s periodic work.


 Ongoing work, such as support for the operation of an organization or department. You might need to check on the status of a product owner building a product backlog. You might not want to make this periodic, but you don’t want to forget it.


In-process ad hoc work, such as emergency projects, work you are doing as the result of crises or other surprises.


In addition, you have work organized by intent:

Management work, such as meetings with your managers, peers, or staff; strategic planning; coaching; feedback; coordinating the work of other people—anything that helps you determine who should do what and when. You don’t need to be a manager to perform “management” work.


Project work, such as the project to save the company, a hotfix, or work to determine whether you want to acquire another organization. Projects are not limited to technical staff.


A project has a specific objective and a projected end date. Once you gather all the work, you can organize it week by week and person by person so you can see what’s really going on.

One way to do this is to make a weekly task chart like the one shown here.


Make a yellow sticky of each piece of work you are supposed to do. If you are working on a project for several weeks, make a sticky for that project for each week. Put all the stickies in the appropriate week, above the “Unstaffed work” line. Just get them all in.


If you’re a middle or senior manager, ask the managers who work for you to do this with their groups also. I suggest you start this as a person-by-person bottom-up activity so you can see what each person in the organization is doing and planning to do for the next few weeks.


This will provide you with an early warning of multitasking or emergency projects. When you start with the projects and work down, people sometimes forget all the other little pieces of work, and it’s more difficult to see the multitasking.


If you’re working on just one project, especially if your project is using timeboxes of up to four weeks and you work feature by feature so you finish valuable work at the end of each timebox, this is a trivial step.


However, even if you’re working in an agile way or if you’re working on several projects, collect all your work anyway. You need to see what other people expect of you.


Now, be honest with yourself, and put the work you can’t do in a given week into the unstaffed work row. Now you have something to discuss with your manager or your customers. You may have to say no to some work, as in How to Say No to More Work.


Using Tools to Manage a Portfolio

When I work with managers and management teams, they want to know what tools they should use to manage the portfolio. When you start with portfolio management, start with stickies on the wall. I have worked with teams who started with index cards on a table.


Starting with tactile tools (stickies or cards) helps people create a shared understanding of the work under discussion. If you pick up an index card and say, “This is part of a program and belongs here,” other people can ask, “What program? Why do you think these two projects are related?”


If you must work as a geographically distributed team, you have several choices:

Use paper cards or stickies in one location and use a camera to discuss where cards/stickies should go.

Use electronic cards on a virtual wall. Several free or quite inexpensive tools are available that allow geographically distributed teams to collaborate electronically.


  • Start with an electronic kanban board.
  • Wait until you’ve practiced valuing and ranking the project portfolio several times before you decide on a tool.
  • Cards on the wall help in a number of ways:
  • Cards will help everyone share the same meaning of the work under discussion.
  • Cards will help you see your flow of work.
  • Cards are easy to move from committed work to a parking lot and back again. Especially as you start, you might discover you change your mind about when to commit or not to work.


Use low-tech tools such as cards or stickies first. Understand what prompts discussion about the projects and the relative ranking of each project. Then you can decide if you want a tool. If you must use a tool, consider a kanban tool of some variety.


They range from free to moderately expensive. If you use a kanban tool before you start with stickies, the tool will dictate—even if by default—what your columns should be. I recommend you consider your workflow first.


I’m reluctant to use any high-tech tool to manage the portfolio because any tool can be difficult to use and prevent people from making decisions as frequently as they need. I much prefer stickies and index cards.


Whatever you use, don’t use a Gantt chart to manage the portfolio. Yes, the projects may have interdependencies, but the Gantt chart is the wrong tool. Gantts organize tasks in service to one deliverable: a particular release of a specific product.


Project portfolios, especially if you color-code them in some way, help you see interactions among projects in service of creating value to the organization. Gantts are okay for one project with one objective, but they do not help you see how to sequence or value multiple objectives.


Evaluate Your Projects

Once you have collected all your work into a draft portfolio, you’ll evaluate each project or program. For the purposes of managing the project portfolio, treat your programs and projects in the same way. You don’t have to do anything special to evaluate programs.


It’s difficult to decide which work is most valuable and which work should be done first, so separate those decisions. The first time you organize your work into a portfolio, you don’t have to make the ranking decision.


Your very first decision is about whether you want to commit to this project, kill the project, or transform the project in some way before continuing.


Resist the temptation to say “I want to do this project first” or third or seventh as you proceed with the initial evaluation. When you separate the evaluation from the ranking, it’s easier to make all the decisions. You’ll have an opportunity to rank after you evaluate each project or program.


Should We Do This Project at All?

Before you try to decide where each project fits in the portfolio, ask, “Should we do this project at all?”


If the answer is no, take the project off the list. If the answer is yes, select a way or ways to rank-order the projects in the portfolio. Take the time to ask this simple question of each and every project in your portfolio.


You may not feel as if you have the right to ask this question. You do.

If you’re a first-level manager in terms of influence, you have intimate knowledge of the project and the product it will create or extend. You know about the strategic importance of this project with respect to the product.


If you’re a middle manager, you can see all the initiatives and can consider the evaluation of this project with respect to the others.


If you’re a senior manager, you can see the entire organization’s strategic direction and see whether this project should be done at all with respect to all the initiatives across the organization.


Any time you have a chance to eliminate a project from consideration, do so. As you review the portfolio over time, note which projects you don’t ever give many points.


Can you take those projects off the list altogether? If not, can you create a small project or a short iteration to provide you with some information about whether this project is worth the aggravation of considering?


Sometimes, you’ll put projects into the portfolio and not get to them for a while. Sometimes a very long while. If that’s the case with some of your projects, check to see whether you still need to consider these projects.


It could be that the answer is no. If you’re not sure, move the projects to the parking lot, as described in Keep a Parking Lot of Projects.


Whatever you do, remove projects that you don’t need to consider now. At some point, you can address the projects in the parking lot. But keep projects you don’t have to consider out of your immediate decision making. Don’t waste your energy on decisions you don’t have to make right now.


Commit to a Project

When you commit to a project, it’s a real commitment, not a partial commitment. Here’s what a real commitment means: that until you make another conscious portfolio decision, you commit to funding this project.


You commit to assigning the necessary people to the project—and only to this project. If the project needs something else (space, capital equipment, desks, whatever), you commit to delivering that to the project.


When managers don’t fully commit, they revisit their projects again and again. This creates both management debt and project technical debt. They also create capacity debt because people (managers and technical) can’t improve their capabilities when they’re overburdened with too much work.


Recommitment Is Easy Now

We just finished our management review with senior management. Now that we’re using agile, we take only about five to ten minutes to explain our status in the meeting. We just show them our velocity and a demo. I let them know about project-level obstacles. Management calls them risks—which is fine with me.


Our management meets with us only quarterly, because our market isn’t changing that fast, so quarterly is fast enough. But it takes me only about ten minutes to prepare.


The hardest part is noting what has changed in the product since the last time we demo’d. Once we demo and show our velocity data, management recommits to this project, assuming there is more valuable work on our product backlog.


Before we moved to an agile life cycle, it took us a full week to prepare for the meeting, and then our management took hours and sometimes days to decide whether we should finish a project.


Not Filling a Requisition Costs You Real Money

You have twenty projects you want to staff. You have people to staff ten of them. You also have enough open reqs to staff another five. And you know that to interview will take time away from the people on the projects. What’s a leader to do?


First, try to avoid this problem of having to hire many people. Hiring costs you time and money and slows down people on the projects. The project delays are not just from interviewing; they also occur when you bring someone on and have to train that person. 


Maybe you have a ton of open reqs. You also have too many projects vying for attention. In that case, look at your top-ranked project. Can you fully staff that one project without hiring more people? If you can, do.


Repeat this decision making for every project in rank order. Fully staff the highest-ranked projects with intact teams. Now, start hiring for the lower-ranked projects. You might not have a single intact team. For some reason, all the teams need people.


In that case, hire for the highest-ranked projects first. Recommend to the teams that they onboard people with pairing or swarming or, at a minimum, use the buddy system from Hiring Geeks That Fit.


As you hire for those highest-ranked projects, keep the other projects in mind. If you find someone who will fit in another project, great. But watch out for hiring just for the lower-ranked projects. You might be hiring people who don’t have the skills to finish more valuable projects.


Remember, the projects you’ve ranked higher return more value to the organization. If you can’t fully commit to those projects, the organization loses that value. For many of you, that’s real money.


Kill a Project

Your second possible decision is the decision to kill a project. The key to killing a project is to make sure all activity associated with the project stops. Sometimes, that’s harder than it should be.  


If the need for this project has changed, it’s time to kill the project—and just the project. Move the people to another project. You may find that if a project is too ambitious, you’ll have to kill it. Or it may be that the market has vanished or your organization’s strategy has changed.


The most serious form of killing a project is to stop all work on the project and throw away all of the intellectual property associated with that project— not the people, just the code or tests or drawings or whatever you have as intellectual property. Don’t throw away the people. Assign them to other projects.


How to Kill a Project and Keep It Dead

Think you’ve killed a project? Maybe you have never worked with Marty. Marty is a well-meaning manager who didn’t want to kill a particular product or its associated projects because of his strong customer relationships.


I Kept Several Dead Projects Alive Until I Realized the Cost

I was responsible for several products for three years. After the third year, my management decided to phase out Product2 in favor of Product4. So, I was responsible for Product1, Product2 phase-out, Product3, and Product4. I was supposed to finish the Product2 phase-out in two months.


Well, we did. Except not all of our customers wanted to move to Product4. I’ve known these customers for years and had personal relationships with them. I wanted to be responsive, so I kept an active branch open on Product2 and provided updates to those customers for about a year. And then, my manager, Shelley, learned about project portfolio management.


Shelley realized I’d been staffing the Product2 phase-out for more than a year, not the three months she’d expected. Luckily, Shelley was nice about it and didn’t fire me. I’d explained that the customers had paid for support.


She agreed with me and explained how the company had prorated the support from Product2 to Product4. So, I had not only delayed Product4 releases because my staff was still working on Product2, but I had used up their support time.


I was so embarrassed. I asked if we could do something for the customers, and she said that we would have to! I kept my job, but it took me a long time to get over that mistake.


I’d cost the company the opportunity to transition customers to Product4. I’d spent too much money on Product2. And, Shelley kept a pretty tight rein on me after that. But I learned my lesson.


Marty is an example of managers I’ve met in organizations many times. Sometimes those managers are closer to the first level, managers who don’t know or understand the organization’s product strategy.


They make mistakes because the strategy isn’t clear. Sometimes, as Marty was, they are midlevel managers who don’t understand why it’s so critical to work on just the strategically important projects.


If you assign a value to each project, especially as in Rank with Business Value Points, these managers might discuss the relative merits of their project, but they’ll follow your direction. But sometimes you have senior managers with pet projects who are unwilling to kill these projects or leave them dead.


Killing a Senior Manager’s Pet Project

If a senior manager has a pet project that you think should be killed and you think that senior management is making this decision based on personal values or feelings, you have several options:


Ask about the strategic importance of this project. This is a good time to meet with that manager, prepared with a list of all the projects, possibly already ranked. Now you can ask, “Is this project more important than this one?” as you walk down the list.


If the senior manager says yes, you can ask, “Tell me about its importance and for how long you expect it to be more important. Can we phase releases and reevaluate its strategic importance at a particular time?” If you are lucky, you can move the project to the parking lot.


Offer to postpone it for a while for a more strategically important project. This is one excellent use of the parked projects list.


Say yes but mean no. This alternative can get you fired.

Say no but mean yes. This alternative either causes multitasking or trains your managers that you will do what they want without standing up for your team. Avoid giving your senior manager any ultimatums.


Ultimatums push people into positions instead of understanding each others’ principles behind the decisions. Ultimatums rarely result in anything except a career-limiting conversation for you.


“We can’t proceed fast enough to meet the release date.”


If you can’t release this project in time to meet its due date, is it worth doing anything at all for this project? Sometimes, it is worth delivering a prototype, because you can then show the prototype to the customer and gain more schedule. But if you’ve been working on the project and you know you can’t meet the deadline, stop the project now. You have a doomed project.


“We don’t have people with enough knowledge to staff the project.”

Sometimes, you have an appealing problem you might want to start as a project. Your staff might know just enough to think about this project but not enough to deliver the project.


If you haven’t done all the necessary investigation, you don’t really know whether the project is doable. Consider rethinking your project so you have an initial goal from a short timebox of providing information to research questions, not to release a usable product. 


If the project is not feasible (an “otherworld” project), see whether you can figure out how to bring it back down to Earth, to what is feasible. Otherwise, this project is doomed.


“We don’t know what real customers or users want.”

If you don’t know who your customers are or you haven’t talked to them in six months, you will not deliver what your customers want. This is a slow but sure way to create a doomed project. 


Find out who your customers are, and keep talking to them. If the customers or users don’t want to see the project team’s demos, you have a doomed project. Kill that project now, and put everyone out of their misery.


I’ll discuss using Cost of Delay in Rank with Cost of Delay. Start thinking about when you want to decide using the Cost of Delay.

You might ask these questions at the beginning of a project before you even start it. Or, if you decide to try one iteration’s worth of work, ask these questions at the end of that iteration so you can avoid recommitting to doomed projects.


Review and evaluate your portfolio periodically. If you don’t see some progress from the project team, you may have a doomed project. If you and the team can’t figure out how to make the project succeed, it’ll become a doomed project.


Transform a Project

The third option is to change the project in some way and continue the project. However, this decision to continue is not a blind continue. You might say, “We need different information before we next evaluate the portfolio.” That tells the project team they need to change what they’re doing to provide that information.


Demos Made the Difference

We were making progress on our project but hadn’t paid enough attention to how the demo looked for our management. We had what we called “hold-the-hand-of-the-demo” demo. We were early in the project and could demo but from the inside out.


We didn’t have enough structure finished that we could demo from the user interface. We had to prove to ourselves that certain features would work before we organized around the architecture. But that made our demo hard to see.


At a portfolio evaluation meeting, we had to explain our demo as we demoed the product. Management thought we were making things up and that the software didn’t actually work. But it did. Our management explained they needed to see a more real demo.


We changed our definition of done from “demoable” to “releasable” and then showed them a demo the next time where we could start the demo from the GUI, not from another program. That helped our management see what we were doing.


Sometimes the project is in trouble because of some of the project staff, such as the project manager or some team members. First, gather some data by talking with the project team, not just looking at the quantitative data.


When you transform a project, it can be as small as clearing up misconceptions about the product backlog to changing the entire team. Transformation means to change either appearance or structure. Changing the team is certainly a transformation!


Sometimes the team you have on the project is the wrong team for that project. Sometimes, the team can’t make the velocity you require, or the project manager isn’t helping the team—he or she is hurting the team, or the backlog needs to change based on new information.


Whatever the cause, make the decision to change in the portfolio evaluation meeting, and make sure a project sponsor meets with the affected people to change the tasks or the staff.


If you have the wrong team because they don’t have enough of some kind of skill, then decide whether you want to reassign the team to a different project or reconfigure the team or arrange for training. All have a cost—and the reassignment and reconfiguring have a much larger cost. Make a conscious decision.


If you desire a higher velocity, look at all the other decisions you can make with changing the makeup of the team. Does the team have everything they need in an environment?


Are there policies that prevent the team from working as quickly as they should? Does the team need tools? Do you have unreasonable expectations about the team’s potential velocity? Any number of things can depress a team’s velocity.


Rank the Portfolio

Now that you’ve evaluated each project the first time, it’s time to refine your approach to the portfolio. You have a list of projects you would like to commit to. But you need to rank them against each other so that you staff only the most important projects.


I’ll present a number of options that will help you understand the value of each project in your project portfolio. As you read, make a note of which options seem best for your context now.


The most important projects are the ones that provide the most business value. The business value might be a way to obtain more customers or retain the ones you have or create a new market altogether.


It might be a way to release products faster or make more money on support or spend less money on support. Business value will be unique for your organization and your projects.


The fastest way is to rank each project according to its business value without any discussion. That would provide you with an ordinal ranking: 1, 2, 3, 4, 5, 6, and so on. But how do you decide what the project’s value is to the organization without discussion?


Never Rank Alone

It’s difficult to decide which work is most valuable and should be done first. If you try making all the decisions yourself, you’ll likely be wrong about something. Murphy’s law says you’ll be wrong at the worst possible time.


You’ll achieve the best results by collaborating across the organization to rank the portfolio with your peers so you can make decisions for the organization, not just for yourself.


Even if you are the CEO, bring in your senior management so they understand why you rank projects the way you do. If you’re not the CEO, collaborate with your management team to ensure you can finish the projects that encompass the products your organization wants to release. If you’re a first-level manager or a technical leader, you need to support your manager’s mission.


One way to collaborate is to bring in a draft portfolio that you’ve developed yourself. This doesn’t sound much like collaborating, but it is a way to help others see what you are thinking and why you think certain projects deliver more business value than others. Don’t fall in love with your draft or assume you can stop with your draft; engage others in discussing it. 


If you work in an organization where all your managers don’t want to decide, you can decide. But before you decide without them, consider facilitating their decision making—if they will let you.


Remind them that you don’t have to all be thrilled with the current portfolio; you all have to live with it only until the next evaluation time, a form of limited consensus. The more often you iterate on the portfolio (as in Decide When to Review the Portfolio), the easier it will be to reach consensus about which projects are most important for now.


Use Your Organization’s Context to Rank Projects

Sometimes, assigning points is too difficult, or you really can’t tell which project is most valuable. In that case, look at the entire context: where you are as an organization regarding your portfolio management, who are waiting for your product to solve their problems (and reduce waste), your product’s position in its life cycle, and the overall health of the product development organization.


First, you have to define your organization’s context. If you’re new to managing the portfolio, you may have a bazillion projects, all of which are emergencies and all of which need to be done now.


In that case, you will have to make choices, but you’ll need to look at who’s waiting for which release, how many products you have, where they are in the marketplace and the overall health of your organization.


When you look at who’s waiting for your running, tested features—your customers—you may be able to define who is more important. You can use who’s more important to help you rank the projects.


It’s not always a C-level person, such as CEO, CFO, COO, or any senior manager, who’s most important. It may not be Very Important Customer if you’re in a product development organization. Sometimes, you need to do work that’s blocking your ability to produce products.


Our Most Important Project Was the Build System

We were having a terrible time releasing products. Our releases got longer and longer. We had at least thirty projects in the pipeline, and customers were screaming for more releases. We decided we had to rank the projects so we’d know which ones to do first.


Because our builds took longer than three weeks to complete, we decided that spending a month fixing the build system would help us release products faster, so that became our top-ranked project. I, along with three other senior people, worked on it for one month.


Between adding a few more computers and a rearchitecture of our build system and a little rearchitecture of the main product, we’d gotten the build system down to building in a day. It wasn’t perfect, but that was enough to allow the product teams to make progress much faster.


We actually did calculate the ROI for the project. We’d originally thought we would save about thirty person-days a month. Turns out we saved about 100 person-days a month. We had no idea how much our build system had been costing us.


We would have just kept complaining about it and living with it until we looked at all the work and realized we couldn’t move toward a more agile approach for any of our projects until we fixed the build system.


Some organizations have many products in various stages of their lifetimes. You may have only one project team attempting to develop new products, adding new feature sets to existing products, and fixing what needs to be fixed for more mature products. In that case, you need to look at who’s waiting for your projects to be completed and who are feeling the pain of the waste in the products.


Who’s Waiting for Your Projects to Be Completed?

If you are working in an IT organization, you may know who your customers are by name. Some of them might have titles such as CFO or CEO. And, although it’s tempting to finish projects for people in the organization who are C-level people, they may not need the projects done as much as some of the other people.


If you’re working in a product organization, you likely have people who represent your customers (product managers or product owners) in addition to your other managers.


Whoever your customers are, the base question is the same: “How do you calculate the value of the projects to each of your customers?” One way is to look at the waste in your customers’ current work now. You can build a waste matrix that helps you quantitatively evaluate the current waste.


Too often, we forget that waste begins at home. You may have projects on your list that will reduce your staff’s waste.


Those projects are the “figure out how to automate the testing” project, the “rearchitect the build system” project, and the “measure the performance for this scenario so we know why when we touch that code performance tanks” projects.


Use the waste matrix to calculate your staff’s wasted time to rank those projects. That matrix will help you move those projects higher up on the portfolio.


Consider Single- or Double-Elimination Tournament Decision Making

Sometimes you have groups of projects and need to put some projects against others before looking at the entire picture. This is especially helpful if you have groups of projects serving different constituencies.


A colleague in an IT group explained, “We have internal projects for our finance and sales groups, but we have external projects that allow our customers to update their information via our website.


We have to organize the projects into internal projects and external projects, evaluate them inside their groups, and then compare against the groups.” Single-elimination or double-elimination tournaments may help.


In single-elimination tournaments, such as in tennis tournaments, you start by pitting each project against another project. The “winner”—the higher-priority project—goes on to the next round. In the previous single-elimination picture, you can see of the eight projects, “Project 3” comes out as the winner.


If you have groups of projects and don’t know which group to do first, single elimination is a top-down approach to choosing. You only need one rejection for a single-elimination approach. If you prefer to have a more holistic approach, double elimination requires two rejections for a given project.


If you have many projects under consideration, you might use the Cost of Delay and double elimination to make sure you’re making the best choice for your organization at this time.


Double elimination is a form of pairwise comparison and helps everyone feel as if they have fairly evaluated all projects against one another because it forces all projects to be compared to each other. In the previous picture, the initially “losing” projects run off each other on the bottom.


A project isn’t “out” until it loses twice. Double elimination helps you see the first and second projections. If you have many projects in competition for the next slots down, consider using points to help you see the relative business value of each.


Beware of Ranking Traps

As you consider how to rank your project portfolio, beware the ranking traps. Most of the traps occur when we want to use traditional measures to rank the project portfolio. Once you move to agile and lean project approaches, the more traditional measures don’t add value to your decision making.


Story points are a relative estimation technique.

Some people might think the business value points are similar to story points. Business value points are a way to assign a relative value to each project or program. Business value points are not relative sizing. 


You might need size to consider the relative value. I don’t find that useful, because projects can change so much. Instead of size or date, consider the Cost of Delay.


If people start thinking about business value points as story points, ask them to consider the Cost of Delay for this project as opposed to other projects. They will start to reconsider what value means to them.


Single Function Ranks the Project Portfolio

In an ideal world, there would be a cross-functional team of people with the responsibility to decide the relative value of each project.


These people would meet often enough that you would always know how each project is ranked. In some organizations, a project management office (PMO) does this. In other organizations, product management does this.


Some agile organizations ask their product owners to get together and rank. In other organizations, your senior managers would do this. But your world may not be ideal.


You can rank-order the projects yourself, using the approaches in this blog. Even if you’re wrong, you’ve provided the organization information about what’s not first. I recommend you present this ranking as a strawman. Use your mission to help guide you.


You can always ask for help from your peers to help you assign points. No matter what, make sure someone decides on the rank order. Otherwise, you won’t know which projects to start and finish first.


Not Considering Highly Risky Projects

Highly risky projects may offer you opportunities you may not have considered, such as helping you either consolidate or expand your business capabilities and offerings. Consolidating your business helps you refine your mission and refine your strategic planning so you can keep your projects focused on your core market.


Expanding your business helps you find new markets and customers. Healthy organizations both consolidate and expand, possibly at different times. But what they don’t do is only consolidate, reducing all risk and opportunity.


If you’re not considering any risky projects, you have a limited lifespan as an organization. If you always play it safe, you’re preventing the organization from moving forward in any dimension.


After a while, you’ll have only risky projects. You won’t have enough data about the true project risk or value to select from among them.


If you’re in a position where you have only risky projects, use agile and lean approaches to reduce the risk of starting them. Choose the project with the most risk and the highest potential return and start work in short timeboxes, making sure the project team knows you want to see demonstrable progress at the end of every iteration.


Ranking with ROI

Many managers and organizations want to calculate return on investment (ROI) to decide how to rank or whether to fund projects. In my experience, ROI is almost always a lie or, at the least, fun with numbers. Many organizations attempt to calculate ROI as the total return for a product divided by the money invested in developing that product.


That’s because for product companies who sell to a mass market—one where you cannot identify each customer—you can’t predict sales over the product’s lifetime. Much of the time, you can’t even predict the sales for a given year.


If you can’t predict sales, you can’t calculate your ROI—the producer’s ROI. The consumer’s ROI is a different question. See Qualitative Questions That Help You Determine Waste for ways to start reviewing your consumers’ ROI.


IT organizations and custom development organizations might be able to calculate ROI, but only if they have a commitment from their customers to use or buy the product and they know how many customers they will have over time. That’s almost impossible for IT organizations. Custom development groups might be able to calculate ROI.


Return on investment is really a look at revenue over time. Most often, you want to understand how soon you will see any revenue and how long it lasts. That’s where you need a crystal ball.


You need to know how many people would buy the product, how much you can sell it for, and for how long you can keep selling the product. That’s too many unknowns for me. Sure, I can make up the numbers, but even if I do, how can you believe me?


Instead of ROI for one project, consider Cost of Delay, comparing all projects’ Cost of Delay. You will have a better idea of where you might see revenue when.


Ranking Trap: Ranking with Cost

It’s quite tempting to use project cost as a way to value projects. Cost is a ranking trap. When senior managers feel strapped for cash, they often want to release the projects they think will return revenue fast.


Do I have these questions: How can you predict the revenue from this project? And is this project part of the overall strategy? Will this project grow or transform the business?


Often, the least expensive projects keep the lights on. They don’t grow the business or transform it. Oh, you might get lucky, but I don’t like to depend on luck as a strategy. 


Instead of the project cost, consider the Cost of Delay. Cost of Delay helps you understand your strategy. If you don’t have a strategy, CoD will help you realize the strategy is missing or weak.


If you feel you must use cost, consider this approach:

Decide on a timebox for the duration of how long you will use cost as a way to rank. I suggest not longer than three months.


Ask the teams to work in an incremental or agile way. Explain that you need to see finished features to decide if you can release earlier.


Ask for demonstrations as the teams proceed, say each month as the longest delay between demos. When teams have to show the working product, you can decide if the product is ready for release. You can then rerank the project portfolio.


Urgent and Required Trump Important Projects

You rank the projects. You realize you’re doing urgent work or regulatory work. You don’t see any important, high-value work in your project portfolio —they are too far down the ranking to assign a team. What do you do?


You might have any of these problems: bottlenecks due to experts, insufficient planning on the part of the product owners to roadmap planning, or teams that multitask so they don’t finish their committed work fast enough for your desires.


If you have bottlenecks due to experts, you might be working in an organization addicted to the idea of resource efficiency. See Does Your Organization Suffer from Resource Efficiency Thinking?. Instead of thinking that people are resources, think about teams as a unit who can deliver work.


You might have urgent work because the teams don’t finish the previous work. They release with technical debt or serious problems. (They might have good reasons for doing so, such as your request that they multitask.) For every urgent project, make sure you have a cross-functional team that can complete the project by itself.


Decide how little you can do to meet its release criteria. As the team completes that urgent project, re-rank all the other projects. Make sure you review the Cost of Delay for each project.


You might work in a regulated industry, where after an audit you have required projects. You must comply with the audit findings. If that happens to you, assign a team (or teams) to the project and flow it into their work. 


You can stop what these teams work on now; have them work on the required project because it’s critical to the success of your business. After they complete that project, they can continue on the next ranked project.


If you still have teams multitasking, know that you might never get to the important projects. You will keep seeing urgent or required projects. Build a low-level project portfolio for each team.


Make sure each team works on just one project at a time. Make sure each project has release criteria. Once the team meets the release criteria for that project, release it. Do not do any more work on it until the team(s) have completed all the urgent projects.


You have a huge backlog of work that the teams must complete. Let them. Make it possible for a team to complete one project—to completion—before starting another project.


Evaluate the Cost of Delay for each project, so you can decide the relative ranking of each project. Flow the work through teams. Make sure you don’t cherry-pick people from teams and assign them to a new team. The team delivers the work as a unit.


Ranking Trap: Confusing the Project Portfolio with a Product Roadmap

Every organization has a unique customer relationship. I have not yet worked with or coached anyone in an organization who asked their customers to help rank the project portfolio. I have worked with organizations who asked customers to help rank features in a roadmap.


Remember that a roadmap optimizes features for a given product. The project portfolio optimizes all the work across the organization. You might need to release something and then rerank the features or even the projects if you are using lean startup approaches.


Remember that the project portfolio optimizes the organization’s work. The product roadmap optimizes the features for the given release of a specific product.


There Is No Right Way to Rank

I’ve presented all these ranking approaches as a way for you to select what represents value to your organization. Ranking helps you commit to certain projects for now and not work on the other projects. That allows your organization to increase its throughput and its capacity. 


A better and simpler approach is to take a lean approach to the portfolio. Lean says, “We have finished valuable stuff. We can sell it.” Once you’ve finished work, you can make a product to sell. Work in progress means you have nothing finished and therefore have nothing to sell.


You will still have to make decisions about which projects to fund and for how long. The difference, once you take a lean approach, is that you have data about the current cost of the waste in the organization, or for your customers, and an approximation of how long it takes to finish a feature or a set of features.


And you might even obtain data about how long it takes to sell the product to a customer. With that data, you don’t need to calculate ROI or predict anything. All you need to do is look at the waste and finish the projects that reduce the most waste or reduce the Cost of Delay first.


Your Project Portfolio Is an Indicator of Your Organization’s Overall Health

There are plenty of indicators of a product development organization’s overall health. For the purposes of the project portfolio, you only need to look at the backlog of projects. 


Healthy organizations have a number of high-demand projects. Once they have passed the startup point, they have several, if not many, projects. A healthy organization with an actionable mission has too many projects to do and has to decide among them.


If you have many projects you never finish, many projects in your parking lot you never remove, or any high-demand projects, then your organization is not healthy. Your mission may not be specific enough, or you may not know how to finish projects. You may not know what business you are in.


If you have an unhealthy organization because no one knows what to do next, consider some strategic planning. If you have too many projects to consider, review your mission, and consider some strategic planning.


If your organization doesn’t know how to finish projects, read Manage It!. Sometimes, the first step is to get a handle on the portfolio. Sometimes you start with a mission or with strategic planning. Start somewhere so you can finish one project and then another and another.


Collaborate on the Portfolio

Making portfolio decisions is never a single person’s problem. To make hard decisions about the portfolio, you need to work with other people, no matter what level you are in the organization.


Since you can’t make the decisions about the portfolio alone, you’ll need to collaborate across the organization. When I talk about collaboration, I do mean Webster’s definition:



Collaboration to arrive at decisions can take many different forms. You might discuss, write, vote, provide data about your current thoughts, and more. 


Come on. If I define a portfolio that meets my needs, why do I need to spend this time and aggravation working with other people to arrive at a portfolio that might not be as good?”


You collaborate on a portfolio for this reason: to make decisions at the organizational level—the highest level—not the lowest level. When you define a portfolio for the organization, you and your colleagues help the whole organization progress toward implementing your corporate or business unit strategy, not just the work of one team or group.


As a side effect, you’ll build relationships with your colleagues, which makes the portfolio management and day-to-day problem solving easier. I won’t be the collaboration police, checking on you. I urge you to collaborate to generate a portfolio that makes sense for your entire organization, not just your piece of it.


Never Make a Big Commitment

The big rule of project portfolio management is that you never make a big decision where you commit an entire organization to a huge project for a long time. I define huge as more than 50 percent of your people, and I define long as more than three months. That’s not very big, and it’s not very long. So, why am I so adamant about not making a big decision?


In three months, if you’ve allocated more than half your people to one project, that project better delivers something you can see, at least as a demo. If not, you don’t know whether you have three months of valuable work or three months of waste. You just don’t know.


Some of you might be saying, “Look, we allocate budgets once a year. We assign people once a year. We have to plan for a year at a time.” You may well do formal planning once a year, but you actually replan more often than once a year.


Every time you ask people to work on another project, you are replanning. Every time you allow a support or operations problem to interrupt a project, you are replanning.


If you never have to make a big decision (a bet-the-organization decision), you are never in the position to throw good money after bad. Make your replanning explicit so you can take advantage of it, not be a victim of it.


So if you’re not supposed to make a big decision, how can you make funding decisions? By funding projects incrementally. Just as you don’t receive your yearly salary all at once, don’t assume you have an entire year’s worth of funding for your project all at once.


If you’ve been involved with management, you know about yearly planning and fiscal cycles. You’re supposed to plan the projects—and, especially the budget—for an entire year. You’re supposed to be able to predict what you need, who you need, and when you need it and when. How’s that working for you? It has never worked well for me.


Instead of being a predicting manager, try being an adaptive manager. Adapting to reality means seeing data from your project teams and maybe from the accounting department if you need to track project cost.


It means taking that data to predict—just for a short while—what you want to fund for projects when you need to fund it, and how much you need. The shorter the predicting horizon, the safer the funding decisions. The longer the horizon, the riskier the funding decisions.


If you have the project teams work in relatively short timeboxes (no more than four weeks), you don’t have to worry about whether a project is highly risky. The risk profile for every project is much lower.


Discover Barriers to Collaboration

  1. There are times when some of your peers won’t collaborate. Once you figure out why you may be able to address the specific issues.
  2. These are some reasons people don’t collaborate:
  3. Someone is playing a zero-sum game.
  4. Someone feels as if information hiding will help his or her career, instead of sharing information with everyone.
  5. You and your colleagues do not share a common goal or strategy.
  6. Managers reward people for individual achievements instead of for the success of the larger group.
  7. You don’t have enough senior managers involved who can make decisions that stick.
  8. People are stuck in their positions about projects in the portfolio and have not articulated their principles.
  9. You are not meeting in one location at one time, so the geographic and meeting distance prevents you from collaborating.
  10. People have cultural reasons for not collaborating.
  11. Project portfolio decisions are difficult enough when everyone collaborates.


They are next to impossible if some people play zero-sum games.

To dissuade people from playing the zero-sum games, do the following:

  • Make sure you have people with enough authority to make decisions for the overall ranking of projects in the portfolio.
  • Ask everyone to discuss their principles behind the ranking.
  • Stop negotiating, and allow someone to “win.” As long as you plan to review the portfolio on a frequent basis, reality will show the value of that decision.


Someone Believes in Zero-Sum Games

In a zero-sum game, someone wins, and the other person loses. People who believe that their projects must win (be ranked first) and everyone else’s project must lose (be ranked last) are playing a zero-sum game.


Project portfolio management is a zero-sum game—between you and your competitors, not your organizational peers. It works when you rank the projects and collaborate at the highest level in the organization. However, if someone attempts to optimize the portfolio at a lower level, that person is playing a zero-sum game against peers in the organization.


Someone Believes in Information Hiding

Portfolio management can succeed when project teams are transparent with their progress and with what they have left on their backlog. If teams, including product owners, attempt to hide their velocity or demos or their backlog, the people who need to collaborate don’t have enough information to make good decisions.


We Need All the Information to Make Good Portfolio Decisions

We’ve been trying to manage the project portfolio for years. We’d run into trouble with project teams not telling us the whole story—mostly because they didn’t know but partly because the project managers didn’t provide us with all the information.


 We had a project manager who refused to give us status, except for “The project is on track.” I finally asked, “How do you know?” The project manager answered, “I have faith in my team.”


Since we’d been working in more of a serial lifecycle, that was just about all the answer the project manager could give. So, we instituted a few things: a quarterly review of each project and a demand that each project show our progress in the form of a demo. In addition, we asked to see what was left to do.


Those few requests first had the project managers up in arms, especially those who were planning to leave all the integration and testing until the end. We explained we didn’t care how they organized the project, as long as they could show us a demo so we could see what was complete and what they had remaining to do.


A number of the project teams struggled, but once they decided to show us their progress and what they had remaining, the project managers reported an interesting side effect: the teams seemed to be finishing work faster.


Now, because the teams show us completed work, they are willing to move on to other projects when we say, “OK, that’s enough for that project. Please release it.” We have very few projects that take as long as we anticipate they will.


Yeah, it took us about a year to get here. But everyone can see what everyone else has done and what’s left. The project teams can see as well as we can when a project is done enough and when it’s time to move on.


There Is No Common Goal

If you don’t have a corporate strategy, you can’t be successful at managing the portfolio. Part of what you do might have to include defining the corporate strategy. It doesn’t matter if you’re a product company or an IT organization—you need a corporate strategy to drive the portfolio collaboration.


Once We Had a Mission, We Had a Portfolio

We had a devil of time ranking the projects. We’re an IT department in a large engineering company. We have projects for our infrastructure and projects that affect our customers.


We had trouble deciding which projects to do first and which ones to postpone for a while. Part of the problem is that we didn’t define the value that we as a department provided to the company.


We built our mission from the bottom up, looking at both kinds of projects, so we could talk about the value each of the groups provided to the organization. Then we discussed the departmental value we brought to the organization. What a surprise—it was a double-pronged value.


Our mission is to “Create and maintain the infrastructure for the entire organization.” It’s not an inspiring mission, but it tells us what to work on. Now, when we work on our portfolio, our CIO first has conversations with his peers and learns about the quarter’s and year’s initiatives. That allows us to make the month-by-month decisions.


Who Needs to Collaborate on the Portfolio?

I’ve been deliberately vague about who collaborates on the portfolio. In some organizations, the people who define the portfolio are the operating committee; a project management office (PMO); the senior managers, including the CEO; and rarely, the functional managers of the technical staff. Any of these groups of people can succeed. Any of them can fail.


Every time I’ve seen the project portfolio work succeed, it’s because the group of people optimized at the highest level of the organization and worked to determine how to support the mission and goals of the organization.


If you and your peers can do that, you are ready to manage the project portfolio. If you can’t, determine the people who can do that, and invite them to collaborate with you. The results will be worth it.


Budgeting Affects Project Portfolio Management

Many organizations budget once a year. Everyone is supposed to pull out their magic wands and crystal balls and see the future perfectly.


Well, I don’t understand how to predict the future, and I can’t tell what the competitors are going to do—and neither do my clients. The result is that managers and project managers spend crazy amounts of time forecasting the budget, and by the third month into the fiscal year, the budgets are all wrong.


Since the budget is wrong in three months or less, we’ll move to rolling-wave budgeting along with rolling-wave portfolio management. We’ll still create a budget target for the year, but we’ll allocate funds only for a maximum of three months. If you’re using an agile life cycle with a shorter timebox than three months, you can have a budget cycle as short as the timebox.


Instead of thinking about the budget driving the amount of time and the number of features, use a fixed time and a fixed budget to see how much value you can deliver in that time period.


The money folks commit to some money for some amount of time—as little as a month if they want—and you commit to some set of running, tested features at the end of that time.


The money people cannot change funds during this time. If you’re using a non-agile life cycle and you don’t have an interim deliverable for six months, the money people have to keep their commitment for six months.


What happens if the economy crashes and you need to revisit your strategy and your decisions? Revisit. But this is why an agile lifecycle provides you with the most flexibility.


Most of the time, you don’t have dramatic strategy changes. Most of the time, you want to make smaller course corrections that allow you more flexibility. When the money is fixed and the time period is fixed, the iteration is stable enough for the project team to create a valuable product.


 A side benefit of budgeting more often is that you don’t have to create a detailed budget for everything—you just have to budget for the foreseeable future. You’ll spend less time budgeting and more time seeing what you need.


An additional benefit is that for a non-agile life cycle, the project team has to re-estimate how much longer they will need to finish the project. Too often, project teams have no idea how much time they need. If their estimates are off, they will gain feedback on their estimates and become better estimators.


For you project managers, even if you can’t use an agile lifecycle, you can use historical information to organize your project and its budget.


If you know from past experience that your budget will change sometime between the six-week mark and the four-month mark, you can plan to deliver something valuable, such as a demo, a prototype, or running, tested features every six weeks. That way, you’ve shown value each budgeting cycle. You’ll get more funding. (Tricky, eh?)


We’re Actually Staying Within Our Budget

We’re an IT group, so we’re on a strict budget. We used to budget once a year —what a nightmare. We tried every year to allocate money toward training or conferences, and that money got taken by projects. It was awful.


But now, we don’t buy anything in advance for a project unless we’re going to need it in the next month. Sure, for servers and big equipment, I need to anticipate and order early, so we actually receive the equipment when we need it, but most things we order only when we need them.


So when we have new people starting, I don’t buy all the furniture at the beginning of the year. That money doesn’t vanish because the projects ate the money. I buy laptops and phones only when we need them. And, best of all, we have almost no overtime, so my budget predictions are darn close to accurate.


I have a predicted budget for the year—our accounting department wants to see that. But I manage the budget week by week, a quarter at a time, and I don’t allocate money to projects unless they actually start. The CIO wants to move to monthly budgeting with a monthly portfolio review, and that will be a piece of cake for me. I bet we stick to the budget better, too.


As a senior manager, you can stop the budgeting madness. Use your span of influence to create a rolling-wave budget and portfolio. You can help your managers drive the discipline of managing the portfolio into the project teams.


How often should you iterate on the project portfolio? It depends on your project life cycles, how much change you have in your product planning, and how fixed your budget is.


The more risk you have in budget and product planning, the more you want the projects to work in short timeboxes. That way, you can review the portfolio at the end of every timebox.


Review the portfolio as often as you can and not more often. It’s not worth reviewing the project portfolio and changing the ranking or commitments if the teams haven’t finished enough work. Consider working with other leaders around the organization both to know what to do and to organize your projects so you could release something at least once a quarter.


You don’t have to actually release, but if your project is in a releasable state, you have the option of moving a project team to another project and satisfying the needs of the project portfolio. Then you’ll be able to review the portfolio and know you can make new choices about the work the organization is doing.


Defend the Portfolio from Attack

In any organization, there are people who think they can request “extra” work from developers, testers, writers, whomever. “Can you please do this as a favor to me?” is one of their favorite lines. Too often, the technical staff says yes, because they think they’re doing something good for the organization.


The problem is that people who circumvent a product backlog also circumvent the project portfolio planning. Defend the portfolio from their attacks. You will have your own way of dealing with these folks, but here’s what has worked for me. I requested all the technical staff work on the portfolio in rank order.


How to Decide If You Can’t Change Life Cycles, Roadmaps, or Budgets

You might be working in an organization desperate to start project portfolio management—not because they know about managing the portfolio, but because they can’t get anything done. You might be a first-level manager of some variety who wants to stop the multitasking madness.


If so, consider selecting a specific replanning period, such as every quarter. Quarterly portfolio management isn’t the One Ideal Time, but for people starting with a lean or agile approach, it might help projects deliver value earlier.


The problem with setting a quarterly planning and budgeting cycle is that you need your projects to deliver some finished set of features by the time you get to the review. Many organizations spend more than three months getting started on a project, which is quite common in a waterfall or iterative life cycles.


If you’re careful with an incremental lifecycle, you can make a quarterly planning and budget cycle work. Only agile life cycles, with their short timeboxes and emphasis on finishing pieces inside the timebox, can work with quarterly planning and budget cycles reliably.


We’re the Only One's Managing Our Portfolio

I have total development responsibility for several related products in our product line. I have to beg for testers and writers. We have cross-functional teams because I make the test managers and tech pubs managers assign people for the duration of a project.


I started managing our portfolio when I just couldn’t take it anymore. I didn’t know what everyone was working on, we weren’t making progress, and I was spending too much time in meetings explaining why we were always late. I decided two things: that we would work in timeboxes and that we would work on only one project at a time.


I started with two-week timeboxes so we could finish something, even if it was just a little bit. I assigned people to just one project at a time. It took me a few weeks to get the hang of evaluating each project with my managers, but once we did, it just took us about an hour every two weeks to review and replan the portfolio.


I started publishing what we would work on for the next two timeboxes, sort of rolling-wave portfolio planning.


I explained to the director of testing and to the director of tech pubs that this was how I was having my teams work. I wanted them to also assign their people for the duration of a timebox. I wasn’t going to make them;


I requested that they do so. I told our product manager that he had to rank requirements. I worked with accounting about the budget, but they refused to think about anything other than a yearly budgeting cycle. Fine.


It wasn’t easy, but we’re at a place where we have a ranked product backlog for each of our products. We still don’t have roadmaps, so I get surprised by product changes that require budget changes, but I have many fewer of them.


I have convinced the test and tech pubs folks that working in timeboxes, with a result of running, tested features, helps them, so they’re along for the ride— most of the time. Sometimes, they still have emergencies, because they still haven’t organized their portfolios, but they have fewer emergencies.


This would be easier if we had an R&D-wide portfolio, but we don’t. But I’m managing what my folks do, and we have many fewer disasters, less confusion, and very few emergencies. Even better, we actually finish projects.


We Wait Longer to Start Now

We are developing a new product in what I call a client-regulated industry. Our clients demand that we use third-party components that they have contracted for with other suppliers. These other suppliers provide us with components we’re just supposed to be able to use.


Of course, it doesn’t work that way. More often than not, these suppliers don’t meet their schedules. If they do meet the schedules, they don’t have the features we need when we need them.


We used to staff projects anyway and wait for our suppliers to finish what they were supposed to do. But then we got the idea of waiting until the last responsible moment. Now we have two choices. We can wait to start a project until we receive the first code deliverable from our supplier. Sometimes that works.


More often, we have to start a project and prototype so our customers and suppliers can see what we do. Or, we start a project and iteratively deliver the features we can do alone into the code base. Then we can postpone more work on that project until it’s responsible to fully staff it.


I would prefer to just staff the project and finish it, but that’s not going to happen in this industry. At least this way I don’t have to commit project money and people for an entire year. And I start or stop projects when the team is at a good starting or stopping point.


Make Portfolio Decisions

By now, you’ve evaluated each project and ranked it. Let’s step back and reconsider the finer points of what it means to commit to, kill, or transform a project.


Making those decisions is not easy. You’ll need to gather data about the projects and decide how to make your decisions. One way is to conduct a portfolio evaluation meeting. You may have heard of these as management reviews.


Don’t worry—this isn’t the kind of management review you’re used to. There won’t be a dog-and-pony show with Gantt charts or traffic-light status reports. This management review is crisp and is designed to provide you with the information you need.


Keep a Parking Lot of Projects

It’s probable that you have more projects than you have people to staff them. You don’t want to lose track of the projects, and you may not want to keep them on the unstaffed list for your portfolio.


And, if you’re not going to staff them for a while, you want to take them out of consideration during the project portfolio meeting but not forget about them. That’s what a project portfolio parking lot does for you—it gives you a place to put the projects without losing them or cluttering your project portfolio.


This is a good approach for people who love to cross work off their lists. They ask whether the project should be done at all, as in Should We Do This Project at All? or realize they’re wasting energy considering this project over and over and over again.


They take the project off the unstaffed work list and off the potential portfolio. They stop thinking about it. They are done thinking about this project for now. This is the same thinking as in the popular Getting Things Done.


Some people may be concerned about removing projects from consideration for a while; they are concerned about closing their project options too early. Maybe the ideas are just a little ahead of the technology. Maybe you want this project in a year or so, but not now.


Whatever your reason, you don’t want to forget about the project, but you don’t want to have to think about it all the time. That’s why you can create a parking lot for projects you don’t want to actively consider but don’t want to forget about. The parking lot solves the problem for people who like to cross things off their lists and for people who don’t want to close their options.


Parking lots make all the project portfolio decisions easier because you don’t have to think about projects, not in current consideration.


Decide How Often to Review the Parking Lot

You have a number of projects on the parking lot. That’s good because you removed them from the ranking decision. When should you review the projects on the parking lot? 


It depends on how you use your parking lot. Do you use the parking lot as a place to put projects because people are reluctant to kill the projects? If so, review the parking lot as infrequently as possible. You might consider the parking lot a write-only board.


If you use the parking lot as a place to put things for now and revisit later, I recommend you start with a review frequency twice as long as your normal project portfolio review. If you review the project portfolio once every three months, review the parking lot every six months.


If you review the project portfolio once every month, review the parking lot every two months. Make sure you provide the teams enough time to finish deliverables before you start taking more projects off the parking lot.


Decide How to Manage Advanced Projects

Does your organization have an “Advanced R&D” group? Maybe you have an “Exploratory” group or set of exploratory projects. In my experience, these teams do not release products.


They investigate and release prototypes. If so, you have several decisions: how you want to manage that project portfolio, and when those projects transition to your regular portfolio.


You might not need an “Advanced R&D” group. You might need to rank “hackathon” days or weeks in your project portfolio. When you conduct hackathons to experiment with possible new products, you still want to understand when to have those hackathons and when to transition those hacks to real projects.


 A high-demand project can be one that supports the organization, grows the business, or creates new opportunities. A change in high-demand projects will change your portfolio.


Sometimes your strategy changes, especially because of outside forces. It may not matter if the project is chugging along. You still need to know whether this project is worth continuing for now.


If you’re working in an organization that’s just moving to agile, your project managers may not be accustomed to velocity charts or other ways to show progress about running, tested features. In that case, publicize your questions in advance so the project manager or the team know the information to provide.


If they can’t provide enough data about what they’ve done and their velocity, stop the project. You can’t tell whether they are making enough progress to know whether it’s worth continuing to fund this project.


Yes, that’s a tough stance. But if your project manager and the team can’t provide you with visible progress and velocity data, how can you really know whether it’s worth your money and time continuing the project? Allowing them to continue the project is like a parent whose teenager uses more cell phone minutes or text messages on the plan and takes no action.


If you don’t make the teenager pay or at least limit the cell phone use, why would the teenager think his or her current behavior is unacceptable? In my experience, when the managers who review the portfolio stop a project because the project team isn’t gathering data, the team initiates their first retrospective and learns what they could do to supply that data.


This is the bare outline of the portfolio evaluation meeting. Chances are good that your evaluation meetings and initial ranking meetings are not going to be easy. 


Conduct a Portfolio Evaluation Meeting at Least Quarterly to Start

In Decide When to Review the Portfolio, I suggest some ways you can consider how often to review your project portfolio. When you’re starting, review the portfolio at least once a quarter.


Even if everything is perfect now —your strategy changes less frequently than once a quarter, your projects are finishing on time, your next projects start on time, you can fully staff your projects, and you can fully fund your projects—perfection is not going to last forever. You need to see the feedback the projects can provide you with for their progress and how well they continue to fit into the strategic plan.