What a Project Portfolio Is Portfolio definition
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 tutorial explains the portfolio definition with the best examples.
How I Started to Manage My Project Portfolio
I’d been managing testing and continuing engineering groups at a company that made complex hardware/software systems. Then the company started a large program and asked me to be the program manager. I stopped being the director and ran that program.
About four months before our planned release, a customer canceled a contract. We could not sustain the number of people in the organization. Management decided to lay off about half the engineering staff (software, hardware, mechanical, you name it).
They assigned someone else to manage the program and asked me to be the software director. And they canned my boss, the VP.
We were down to about forty people in development, half the number of people before the layoff. We had to finish the development work on the program and continue to respond to problems in the field. Each field problem was a crisis and required several weeks of work.
So here I am a director, with an interim VP, people who’d been working crazy hours for months, and a release we had to get out. And huge problems we had to fix. We had to do it all. We had no choice.
I made a spreadsheet of what everyone was working on so I could understand where the time was going. I’d made spreadsheets like that before when I’d managed testers and developers who were matrixed into projects, but I had never had to staff quite so many simultaneous projects. Everyone worked on everything.
After two weeks of people working the way they’d been assigned, I realized no one was making progress on anything. I sat down with my management team, the people who helped me organize the software department.
We discussed what work we would staff and not staff. We assigned people to no more than two projects in any given week. Instead of everyone working on everything, everyone worked on no more than two projects in one week.
At the end, we had small teams assigned to one problem each. As they completed one problem, we had a ranked list of problems to provide them. Each team knew what problems to work on in rank order. We knew if we could fix the problems, we could give ourselves time to work on the program.
In about two weeks, we were half-staffed on the program. The developers were thrilled to finish something—especially fixing problems that bugged them as much as the customers.
The managers were happy about not having to move people around. I was happy that we finally got some things done. My senior managers were still unhappy with my progress.
Over the next few weeks, we discovered new problems. We continued to ask teams, not specific people, to fix problems. After two months of this, we finally had the problems under control.
The developers could focus on the program because the continuing engineering department was able to address and fix the field problems. That’s when we started to make huge progress on the release because we worked by feature and assessed our progress bi-weekly.
We used a combination of approaches: continuing engineering used a kanban approach because the problems were smaller than the features for a release. They could limit their work in progress and work on one problem at a time until it was fixed. The developers and testers worked together on features, using two-week timeboxes. They finished chunks of work, already integrated.
By the end of the four months, we had a release, although we didn’t have all the features our senior management wanted. We had the field problems under control. We hadn’t added a ton of technical debt.
And the people who remained learned that they could work on one project at a time, one task at a time until it was done. They could make more progress doing one thing (a problem or a feature) at a time than splitting their time among several pieces of work, even if the work was related.
If I could manage the project portfolio with an organization reeling from a layoff, where we had an unstated strategic plan, where the senior managers had trouble deciding what to do on any given day, you can do this for your work. You may need different approaches for different groups.
One group might need to limit the work in progress, especially if you’re in a serial lifecycle and people with different expertise cycle in and out of the project. You might decide to work in one-week timeboxes instead of two weeks.
When you finish features regardless of your life cycle, you have more flexibility to manage what the teams do. You can manage the project portfolio because the teams finish work. The teams don’t multitask between several pieces of work.
The Project Portfolio Flows Work Through Teams
Keep that flexibility in mind as you work with your project portfolio. The portfolio is not an end—it’s a means. Think of your portfolio as a pipeline of potential work. You see how you can flow work through teams.
Use your project portfolio to help you make the right decisions to start and release valuable products often enough to fulfill your customers’ needs.
The best way to do this is to use a lean and agile approach to your projects and to your project portfolio. Agile and lean provide you with an adaptive approach for the portfolio work.
Agile and lean approaches allow a project team to finish small chunks of valuable work and get feedback sooner rather than later. Because the team finishes small chunks of work, they can change what they work on next. The team always works on the most valuable work.
In a way, that’s like saying I’ll introduce you to your appointment calendar. You don’t value an appointment calendar or a project portfolio until you start using it to shape your days, weeks, and months.
You collect all the work from the pipeline of projects and rank it. Then make the commit/kill/transform decision so you can provide maximum value to the organization. Repeat as often as you decide you need to make the decisions about which team should work on what.
Agile Approaches Help Project Portfolio Management
If everyone in your organization (senior managers, middle managers, technical leads, functional managers, and project managers) is wedded to a serial lifecycle (phase-gate or waterfall, where people work in their functions as opposed to working by feature) and no one is willing to consider finishing valuable chunks of work frequently, you can’t use a pragmatic approach to managing the project portfolio.
But if you’re willing to consider frequent releases of running, tested features, you will discover you can use agile approaches to the project portfolio.
If you’re already using an agile approach for your projects or an iterative or incremental life cycle where you have an opportunity before the end of the project to finish features, you can use the ideas here to be a successful leader in the organization, no matter what level you are.
If you use a serial lifecycle where you can’t see any progress until the end of a project, you will find these ideas more difficult to use. If you use a serial lifecycle, try to create interim deliverables, say, every month.
The more frequently the projects deliver something you can see, the easier it will be to manage the project and to manage the project portfolio.
It will help you decide the following:
When to commit to a project to a product development team can start or continue a project.
When it’s time to end a project and free a team for other work.
When to transform a project and commit to the changed project.
When it’s difficult to decide between projects, the portfolio provides a visual tool that helps you negotiate which project to do when.
You’ll keep all of the work in progress and all of the planned work in your project portfolio. This is not a static document or useless artifact. This is a tool the product development teams and managers use to make the necessary trade-offs of which work to start and finish now, what to do later, and what to do never.
The teams use the portfolio to see which projects to spend time on now and what they might do in the future. Most important, they know where not to spend their time. The managers use the portfolio to make sure the organization is working on the most valuable work—the strategically important work.
Those product development teams may have any number of names: IT, R&D, engineering, or even something else. The name doesn’t matter. What matters is that there are teams available to the organization to innovate, to create, and to develop the products the organization uses or sells to improve its business.
The portfolio is the closest thing to the product development organization’s backlog because it’s organized by priority. But the portfolio also provides you with a picture of the projects over time, so you can manage project interactions, who are assigned to which projects, and the general risk and value of each project.
Managing the project portfolio is context dependent. Your project life cycles, your budgeting process, and how you create and use roadmaps all affect the project portfolio. If you’re willing to adopt lean concepts, you’ll find it easy to manage the portfolio.
These ideas include eliminating waste as you work your way through projects; discovering and eliminating roadblocks to throughput; evening the workload for people and teams; optimizing for the entire organization, not just one piece of it; completing valuable features in short time periods, and not creating an inventory of partially completed work.
See the High- and Low-Level Views
Just as you want to see your calendar in high-level views (yearly and monthly) and in more detailed views (weekly and daily), consider visualizing your portfolio the same way. I use the big picture so I can see the whole organization to know where we have committed to projects.
I use the low-level picture to understand who is doing what and when. I find the detailed view especially helpful when the managers try to start assigning teams instead of people to projects and when a team has urgent support work.
I like using “unstaffed” for projects that haven’t started yet or for ones I wish I could start but don’t have the staff to start yet. That’s because I want to know the following:
Have we started to work on this project at all? If so, can the project team measure its capacity and use that as a prediction of when we’ll be done enough with this project?
Do we need to reevaluate the portfolio if we have not yet started this project?
Based on changing market or business needs, do we need to change which team we assigned to this project, whether we should staff this project, or whether we should change the project?
Answering yes to any of these questions means it’s time to rethink your management decisions about projects.
If you use an agile life cycle, the figure shows how your portfolio might look, especially if you have to support already-existing projects:
In this portfolio, you can see that the teams work on one project for a two-week timebox, do a week of support, and then work on a project for another two-week timebox. While they had Search, R2 in their backlog, they decided other work was more important. That’s why Search, R2 is unstaffed.
Notice that all of these portfolio pictures start and end neatly on month or week boundaries. That’s not because portfolios work like that but because it’s easier to show the month or week boundary in a picture.
If you finish a project or a feature on a Wednesday, your next project or feature would start on Thursday. In Fix the Number of Tasks In-Process, Kanban-in-the-Small you can see alternative ways to manage the project and support work.
This next portfolio is another view of a low-level portfolio, where you can see who is assigned to which projects and, in this case, features for the projects. Because the project teams work incrementally, each person works on a feature.
That helps everyone see what everyone else is doing. Because people are not working in stable teams, it’s difficult to see what’s happening in this group.
When you assign people (and not teams) to projects, you will find it difficult to see which project is #1. You can see which work is unstaffed. If you ever discover that features take longer, you will have to rejigger the entire portfolio when people can’t finish their work when you want them to do so.
I included this low-level view so you can see a way to start seeing the project portfolio even if you don’t have stable teams working together. You might help other people see that creating stable teams—regardless of your life cycle —will help you manage the quantity of work the organization wants you to complete.
See Does Your Organization Suffer from Resource Efficiency Thinking? for a larger discussion of how you might think about teams so you can flow work through the teams, not people.
Connecting Management’s Desires with Reality
My manager came to me with yet another project. So I showed him my monthlong project portfolio, with all the unstaffed work. He said, “But we want these three projects done,” as he pointed to the high-level portfolio. I swallowed and said, “Well, we can’t do them in this time with the other work we have.”
He sighed. With the evidence in front of him, in a picture with colors, he couldn’t argue. Well, he could, but it wouldn’t have helped. I said, “Look, we can work in shorter timeboxes. We can start—and finish—fewer features. You could even give me more open reqs so I can hire more people.
I guess we could incur some technical debt, but that would anger Major Big Customer. Have you really ranked the projects in the order you want them? If you have, we need magic. But maybe you can rerank and have everyone in the group work on just one project. We could finish that one and then go on to the next one.”
Having a high-level perspective helps the whole organization see what the company expects each group to do. Having the low-level perspective helps the project team and first-level managers make the current reality match expectations.
There is nothing like showing your manager data to help set their expectations about what you can—and cannot—do.
See Your Future
Portfolios make the organization’s choices transparent. When you decide what to work on first, second, third, and never, you calm the interruptions. The people and teams work on the most important work.
They don’t multitask or get distracted with “bright shiny object” syndrome. People and teams can deliver what the organization needs when the organization needs it.
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.
Signs You Need to Manage the Project Portfolio
You might not think you need to manage the project portfolio. I’ve seen these signs in organizations when they need to manage their project portfolio:
1. You have emergency projects.
2. You have to respond “right now” to projects in progress and fixes.
3. You have too many emergency fixes.
4. You have many projects that are in progress and you can’t tell when any of them might finish.
5. You don’t seem to have the “right” people on any project. Even if you move people around like chess pieces, the projects never seem to finish.
6. When you release projects, the teams don’t feel as if they are “done.”
7. You’re surprised by some projects you do finish. Not all the projects appear to be congruent with your corporate strategy.
8. You can’t actually tell the status of the projects in flight. Some look “green” until they are “red.” Some require fire-fighting to complete.
9. You feel as if you have the same experts working on more than one project or fix. You always need Tom or Susan to finish every project.
You might have more problems. The real problem is you have no throughput through the organization, so everyone works on everything, with the result that you can’t finish anything when you want. Your Cost of Delay is huge.
You’ll still have difficult decisions to make. You may not know if your mission needs to change. You may have loud discussions about which project really is number one.
And, as you work through those decisions, you’ll discover that you are performing the difficult work of leading the organization by deciding what to do now, what to do later, and what not to do.
When you live with a project portfolio, the portfolio allows you to create a master plan. It creates a transparent link from the projects with their deliverables and releases to the portfolio.
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.
You might be a manager wondering why I’m saying this. “Johanna, I split my focus all the time. I’m always working on several projects. I can’t take the time to focus on just one thing at a time.” If you are a manager, I believe it.
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 done. 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 “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.
A Tale of Three Projects
I’m sitting at my desk, completely stuck. I have three must-finish-now, ultra-high crisis projects. Every time I start one, someone interrupts me with a question on one of the others.
I can’t escape anywhere—people have found me in the cafeteria, in the meeting room, in the lab. My manager came by yesterday morning to tell me the first project needs to be done now.
Then he came by after lunch to tell me the second project needs to be done now. I stopped working on the first and started on the second. Then he told me at the end of the day that I need to finish the third.
I can’t decide what to do first. What’s the point of working on any one of these projects? He’ll just come by and tell me to change before I finish anything. Maybe I’ll work on my résumé or play a game of solitaire.
You want people excited about working for your company. That’s part of creating a great work environment. Continuous multitasking doesn’t just prevent people from accomplishing work; it also creates low morale.
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.
Review how long your project portfolio decisions last. If you need to change your mind more often, consider your options:
Review your project portfolio more often.
Ask the project teams to deliver finished features more often, so you can make different project portfolio decisions.
See where you have organizational impediments to delivering features or reviewing the portfolio and maintaining a decision for at least a month.
I often see problems where the organization confuses a product roadmap (which optimizes decisions for a given product or project) with a project portfolio (which optimizes decisions for the entire organization).
Product roadmaps can be wish lists. Project portfolios are decisions the organization agrees to honor until you review the portfolio again.
Why You Should Care About the Project Portfolio
If you’re a senior or middle manager, you care about the project portfolio, because that’s how you predict whether the organization can get enough value out of its projects to remain stable—or, even better, to grow.
The more projects your organization can complete, the more value you can realize from the work (assuming you’re evaluating the projects in a way that makes sense), and the more value you provide to the larger organization.
As a middle manager, you are trying to finish and then start more projects. Without real data about project progress, or without the ability to make a reasonable prediction of how long a project might take, you can’t be successful with all of your responsibilities.
As a technical lead or first-level manager, you care about finishing projects, but you likely have a more immediate problem—how to get enough people to finish the projects your management wants you to finish. The portfolio helps you show your managers when you need more people and what types of people they are.
Why Technical Leads Care About Portfolio Management
If you’re a technical lead, do you still need to care about the project portfolio?
Yes. If you have responsibility for a product, you are a technical lead and need to make sure you and your team are working on the highest-value work and that your work is transparent to the rest of the organization.
Keeping Up with All My Projects
I haven’t been here long, but I’ve already accumulated projects that only I have worked on. One of the projects encompasses the financial reports for the CFO out of our site. It was supposed to be a short, small project two years ago. It was, then. Since then, I’ve added at least 20 new features and fixed a bunch of cosmetic problems.
It’s not hard work, but every time I got heads-down on something else, the CFO called my manager and asked me to do something else.
I finally got tired of it and created a portfolio for my boss and me and a product backlog for the CFO. Now, when he calls, I can show my manager what I’m doing, and we can schedule his changes in a way that makes sense for everyone.
Sure, I had to do a quick fix last week when we got a new request from our auditors. That was an interruption—it didn’t go on the backlog.
But that’s just one problem out of the last few where I’ve had to interrupt myself. The portfolio helps me organize my work. And, the backlog helps my customers know when I’ll get to their problem and in which order.
Project portfolios make your work visible. Without them, no one realizes all the little pieces of work you’re doing. You have to make that visible, and a portfolio is an ideal tool.
Even if you produce a whole product, as in the case of an agile team or even a program of agile teams, but you don’t have the ability to determine which project is number one, you’re a first-level manager for the purposes of the project portfolio.
Create the First Draft of Your Portfolio
Now that you understand the basics, it’s time to collect all the work you and your group are supposed to be doing. It’s easy to get caught up in evaluating the work while you are collecting it. Don’t. First, make sure you know about all the work people across the organization expect of you.
Then and only then will you be able to assign the work to your portfolio by evaluating it and determining whether you need to do it now. Don’t try to do everything at once; start collecting all the work before you attempt to evaluate it.
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.
Is the Work a Project or a Program?
I meet lots of technical leads, project managers, and functional managers who claim to be working on seven, eight, nine, ten, twenty, and forty-seven projects. No one can manage that many projects. You might be attempting to manage or work on a program that’s not organized as a program.
Programs are collections of projects and work across the organization where the value is in the total deliverable. You might have valuable projects. And your organization recognizes more value when you organize all the projects together and deliver one product or system as a whole, the program.
When I see this problem—people working on many projects simultaneously —I ask questions to see if I can lump the work into any of these categories:
Large projects that evolve because the project team is not working feature by feature. Or the team doesn’t deliver value every day, or at least, in short, timeboxed iterations.
Because it’s not clear when the project will be done, people across the organization request more and more features, resulting in the “never-ending project.”
The project is valuable to the organization; it’s just not clear if or when it will ever be done. These projects are part of a program and need a program manager to corral the deliverables into something coherent.
Small projects that are unique and that result in a particular valuable deliverable.
Small pieces that are needed for a single deliverable but have limited use by themselves. These projects are part of a program and need a program manager.
Large projects that aren’t due yet but will be an emergency when they are due if the project teams don’t start on them. Because they aren’t due yet and the project managers and the teams have so much to do, they postpone working on these projects until they are an emergency. These projects are also programs.
Don’t be afraid to manage the different kinds of work differently. Any project that has a valuable deliverable, whether it’s small or large, needs to be in your portfolio, with a unique team and due date associated with it.
But those small pieces of projects—those are not projects per se. Consider creating programs to collect large projects with many teams and/or deliverables from across the organization.
If you have a collection or series of small pieces that individually don’t add up to significant value—but together do create substantial value, consider collecting them as a program. Now you can add that program to your project portfolio.
Organize Your Projects into Programs as Necessary
As you collect the work, especially if you have many projects, think about how to organize the projects. Are some of the programs from collections of projects? Do some programs have phased releases? Do some products need to be separated into smaller salable or releasable products?
A program is a collection of projects that all together deliver significant value. Each project may have some value by itself. But the real value is the collection of projects into one deliverable: a program.
You might have a program of a number of projects all with one release date. Or you might have a program of phased work, where each phase delivers some significant value.
Many of My Projects Are One Program
I was trying to manage about twenty-five projects. I was going nuts. Then I realized we didn’t have a system unless all twenty-five projects were done. Our system was a program. Even though all my projects were projects in service of a program, I could work with the business to define when the business side wanted to see which feature.
That meant I didn’t have to manage each project separately; I had a context for all of them. I could sequence them and still provide a status report for my managers. And, if they canceled the system, I didn’t have to keep managing all of those projects.
Now it made sense for me to make sure I had people assigned just to the projects (which we defined as feature sets) we needed done now, not the ones that could wait. Programs can take several shapes.
Be ready to organize the projects into programs where several projects have one interdependent goal, whether that goal is one release, phases of releases, or several products.
Organize Projects into Programs
You might work in an organization that needs program management but doesn’t realize it. Here’s a simple test. Do you work in an organization where Steve has one project, Jane has another, and Tim has a third, but none of them can release their project until all of the projects are ready? If you have interdependencies between projects, you need program management.
Program management can take several forms, but a common form is a mechanism of organizing several interdependent projects together as one program so that the program manager and project managers can manage the interdependencies and successfully release the product.
Steve, Jane, and Tim all need to complete their projects so that the program can release at one time.
If you’re a project manager, your management may not realize they’ve created a program when they initiated Steve’s, Jane’s, and Tim’s projects. As you collect the work, talk with Steve, Jane, and Tim to see whether they should be working as a program team.
If so, it’s time to help your colleagues realize the program is one entry in the portfolio, not three entries as separate projects. If you’re a middle or senior manager, assign a program manager to bring interdependent projects together.
Organizing Projects into a Phased Program
Another form of a program is a phased series of projects for one product. Sometimes, Steve, Jane, and Tim are working on “independent” projects because the projects are in a phased development.
That is, Steve’s project is responsible for a feature set. Jane and Tim are working on “independent” feature sets—independent as far as what the customer sees. This looks complex because it is complex. It’s also much harder to manage a phased program and to make portfolio decisions about it.
If the projects access the same code base, the projects are not independent. The work may be sufficiently long or challenging that you want the projects working at the same time.
They are another kind of a program: a phased program where you have release 1, followed by release 2, followed by release 3, and so on.
You might need to start working on follow-on releases (which your management thinks are projects) in order to complete them by the desired release date. But those projects are interdependent and you (or someone in the organization) needs to manage them as interdependent programs.
You especially want to avoid the situation that release 1 has been released, the market changes, release 2’s goals are completely changed but release 3 doesn’t change. If you manage the projects as a phased program, you will at least ask whether release 3’s goals should be changed—or even whether you should continue with this project.
Part of the problem with a phased program is that you want to understand how much planning went into these phases. In a number of agile environments, you might see five levels of planning:
Product vision: A long-term guiding vision for the entire product created by the product owner and/or product manager
Product roadmap: A time-based view of high-level features that the
product owner and product manager may want in the product
Release plan: For a given release, which of those features the product owner wants the team to deliver
Iteration plan: For a specific iteration, what the team commits to deliver
Daily commitment: For a specific day, what the team commits to do
Phased programs occur when one team cannot—by themselves—deliver on the product roadmap via a release plan in the time the organization wants the features.
Here are some guidelines for managing phased programs:
Develop release criteria for each project in the program. Know what done means for each project.
Develop release criteria for the program as a whole. When can you release?
Consider shorter program phases so you can release more often and reduce the number of overlapping phases.
Convert the overlapping program phases to one release. Ask to reevaluate the program value once that program completes.
For more information about how to manage programs, read Agile and Lean Program Management: Scaling Collaboration Across the Organization.
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.
Decide to Commit, Kill, or Transform the Project
Once you’ve decided you should do this project, you have a limited number of decisions to make. You can commit to a project, kill a project, or transform a project to increase its chances of success.
Making a commit/kill/transform decision requires data about project progress, project value, and obstacles. If your projects are all using a serial lifecycle, the data doesn’t exist.
In a serial lifecycle, you have no data about whether this project is valuable until very near the end of the project—after you’ve spent virtually all the money and assigned people to this project, excluding other potential projects.
The problem with serial life cycles is that they do not adapt to change. Phase-gate and waterfall approaches are examples of serial life cycles. In a serial lifecycle, you are supposed to plan the entire project and then finish first the requirements, then the architecture, then the design, then the code, and finally the testing.
Serial life cycles do not expect change. Serial approaches do not use deliverable-based planning.
Schedule games can occur in other life cycles, but serial lifecycles hide the games longer. For example, if your project teams have been implementing through the architecture instead of by feature, they run a high chance of encountering the 90 Percent Done schedule game near the end.
That’s where you finish 90 percent of the project and realize you have 90 percent remaining. The team discovers they have all that work to do at the “end” of the project because they haven’t integrated features as they proceeded.
You can use a serial approach to your projects and succeed. The shorter the project, the more useful a serial approach is. And, for the purposes of managing the project portfolio, where you want flexibility on which teams to assign where to decide how long your project should be.
The shorter your serial project, the more often it delivers value. You might have releases: release 1, release 1.1, release 1.2, and so on as one way to shorten your serial approach. Then you can assess the value of the remaining projects for that product against all the other projects in your backlog.
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.
Understand the Requirements of Commitment
A commitment to an ongoing project is not a blind commitment. If the project requires two DBAs and you have only one available because the other is on another project, think about your options.
You might Start the project and realize the team will be slower than you wish. That’s because you committed, but the commitment is not complete. The team is missing necessary people.
Wait to start the project until you can create a fully staffed team.
If you have agile teams that have been fully staffed up until now, let the team tell you what they need. The team might work with the product owner to discuss the need for this much database work into this iteration’s backlog.
Sometimes the team will estimate more time for the features so that other people can learn more about what the DBA does. With those discussions, the product owner might make other decisions.
What I most often hear is not a discussion about which features to commit to when but a blind request or demand from people who say, “We need these features now.” If you are not working in an agile way now, it’s easy to encounter those demands.
If you or your team receives a demand for this feature now and you don’t have another DBA, you have to decide which project is more important than the other. If you can’t fully commit to a specific project, don’t start it in this time period. Wait until the next time you evaluate the portfolio.
You might tell the project team you are happy with their progress and the potential value on the product backlog—you recommit, and they continue. If you’re ready to recommit to an ongoing project, do so. If you’re ready to commit to a new project, do that. If you’re not ready to commit, you might need to kill or transform the project.
Commitment is not a “We’ll give you part of what you need, but….” It’s a full commitment.
This is a hard line. Here’s the problem. If you can’t fully commit the necessary people and money to a project, you are guaranteeing the project will not provide the value you want it to provide. Why would you waste your people, time, and money on a project you can’t fully commit to?
If you have open requisitions and you haven’t filled them yet, know that part of the value the project team will provide to the organization is the interviewing and hiring workers. You won’t get the benefit of those people on the project, but the project will be providing value to the organization.
But if you don’t have open reqs and if you know you need more people, you are fooling yourself if you think you can somehow commit to a partially funded or staffed project.
You would be better off, from a throughput perspective, either having generalists or having at least a pair of specialists so you can fully staff a project when you need to do so.
If you are trying to staff a project with people who are working part-time on your project and part-time on other projects, you have an uncommitted project. That’s because the cost of context switching will erase any potential ability to focus on this project.
Don’t partially commit to a project; that’s a lack of commitment. Be honest. Take that project off the committed list. You may have to move the project to the parking lot. You might have to transform it. But never make a partial commitment.
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.
But I Want to Finish This Project!
One of my developers, Marcus, was devoted to a particular project. It was quite difficult. We, as a management team, decided to kill the project by putting it on the parking lot. We needed more powerful hardware before we could consider this project again.
Marcus was devastated. He was emotionally invested in the project. For three weeks, Marcus arrived at work early and stayed late to “finish” the project. It took me that long to realize what was happening. I finally had a one-on-one conversation about this.
I tried to help him realize that the hardware available today was not powerful enough for what we needed the product to do. Marcus told me the project was critical to his self-esteem and career. I said, “No. You need to stop working on this project now.”
I asked Marcus to join a four-person team—he would make five people on that team—and to please work on this other project. After about another three weeks, Marcus finally integrated into the new team and stopped working on the old project.
I learned a number of lessons: never have one-person projects; always allow a day, and not much more than that, for cleaning up a project to put it to bed; and continue to have more one-on-one with people once I cancel a project.
People derive significant self-esteem from their work. I feel a little idiotic not realizing that at first. But I learned.
Postponing a project is another form of killing the project. If all the team was supposed to do was learn about architecture or proof of concept or your customer doesn’t want that project now and won’t fund it, you can postpone the rest of the project, realizing there will be a startup cost later if you restart it.
You can choose to put this project on the parking lot if you don’t want to lose track of it. I assume that the startup costs for restarting a project later are a minimum of two weeks. That’s because the team needs to understand what’s changed since the last time someone touched this project.
The kill decision is difficult to make when you’re using a non-agile life cycle. Any decision is difficult with a serial lifecycle. You have more data with an iterative or incremental life cycle. You have the most data with an agile lifecycle.
If the project teams don’t have to get to the releasable product at the end of every iteration, the project team will have some putting-away work before it’s safe to kill the project. This is where many project teams and managers get confused.
How much time do they need to clean up? No matter how much time you give them, it’s not going to be enough, which is why I recommend you give the project team no more than two working days. At the end of two working days, ask the team to conduct a retrospective, and assign the project team to another project.
My Project Was Canceled, Parked, and Restarted
We started a new project, trying for a particular kind of communication product. We had to achieve a certain level of performance and reliability. We tried a number of ideas for several timeboxes, but we encountered the “laws of physics” and just couldn’t do what we needed to without different hardware. So our project was canceled.
In another company, that might have been the end of the story. But our managers knew we had to keep this project in mind, so it went onto the “parked projects” list.
I’d thought that’s where projects went to die, but every quarter our managers assessed this list. One day, my boss came to me and asked about a new chip he’d heard about. Would it work on our project to give us the speed we needed? I had no idea.
At the next portfolio evaluation review meeting, our project was reinstated. We had some different people—it had been two years since we’d tried to do this project. But that was OK. It was cool to see that we could kill a project for excellent reasons and then reinstate it for excellent reasons.
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.
Kill Doomed Projects
As you evaluate each project, you might realize you have some doomed projects in your portfolio. Here are some questions to ask if you suspect your project is doomed:
When do we need this project to release? Do we have enough time to do something useful before that date?
Can we make progress fast enough to meet the market window?
Do we have people with problem-space domain expertise to staff this project?
Do we have any insights into what real customers might want out of this project?
Do we know our Cost of Delay for this project?
Let’s take each one of these in turn.
“We don’t have enough time to provide anything useful.” If you haven’t started a project in time to meet its release date, you are creating a doomed project. If you can’t meet a project’s release date, don’t start it.
At least, don’t start it under no-wind conditions. Make sure the project environment (staffing, tools, and other resources) will support the release date. One way to do that is to start a short timebox (two weeks is good), estimate the team’s velocity, and at the end of the timebox see what the team has delivered for an actual velocity.
“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, and that project has significant technical risk. Your staff might know just enough to think about this project but not enough to deliver the project.
(You’ve met a number of almost-PhDs with that problem. Those are the people who’ve done all the coursework but couldn’t finish their thesis because they couldn’t finish the research.)
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.
“We don’t know our Cost of Delay for this project.”
Do you need to release a project before a given date? If you don’t meet that date, you won’t receive the expected value from the project work. Here are some examples of date-driven deliverables. Game companies release their products before the late fall, so they can build a marketing buzz and reviews for the Christmas shopping season.
If you create a tax product, you need to release it on or just before January 1 of any given year. That’s because people start their taxes in January. If you’re late, those people might buy a different product.
I’ll discuss using Cost of Delay in Rank with Cost of Delay. Start thinking about when you want to decide using 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.
Rank with Business Value Points
One easy way is to use business value points to rank the projects. Points help you see the relative business value and ignite discussion about the relative value of each project.
When you rank with points, you’re separating business value from funding. The number of points you assign to a project represents its value to the organization, not the funding you will provide. This separation of value from funding works similarly to how separating project sizing from duration helps project staff estimate better.
Start with a large total number of points. You will assign a unique number of points to each project, showing its relative value to other people. The larger the total number of points, the easier it is to see each project’s relative value.
If you have up to eight projects, you might be able to use just 10,000 points. If you have more than eight projects, start with 100,000 points. If you have thirty or more projects, partition them in some way—by division or team or by internal or external—because it’s close to impossible for human beings to understand that many projects and their relative value at one time.
If you can, partition the ranking to no more than ten at a time; five to seven projects at a time is best.
Now, assign a unique point number to each project. The number of points you assign to a project helps you see each project’s relative rank in relationship to all the other projects. Since I said not to rank alone, I’m assuming the “you” here is a group of you.
Don’t expect everyone to be in complete agreement with everyone the first (or even the second or third) time you try to assign points to any specific project. Each person will benefit from the discussion of how to decide how many points a project receives.
If you have two projects that are critical to the success of your organization, you might decide to assign one 5,001 points and the other 4,999 points.
(Or, if you don’t mind points left over, you could assign one project 5,000 points and the other 4,999 points.) That would show everyone that no one needs to work on any other projects and that these two must be completed before considering work on any others.
The project with 5,000 points needs to be completed first. You would figure out how to create two teams to work on these projects simultaneously. I’m not saying to create one team to work on both projects simultaneously; that’s multitasking.
But I am saying that if these two projects are by far the most important work you can do for the organization, then you would staff these two projects to the exclusion of all other projects and have the two teams work on them concurrently.
With just two projects, if you have only enough staff to work on one project at a time, you can even ask the project staff to work in one-week or two-week timeboxes, alternating on each project.
If one project becomes more valuable, you can decide then to have the staff work on just that one project for more than one timebox, assuming you review the portfolio after every timebox. See Decide When to Review the Portfolio for more information on how often to review the portfolio.
Is there an ideal team size?
The real issue in team size is communication cost. The more people on a team, the larger the number of communication paths. Communication paths expand exponentially with the number of people on a team. Assuming you have N people on a team, the communication overhead is N*(N-1)/2.
Teams of size five and fewer have no more than ten communication paths among all the team members. Once you have six people on the team, the team requires fifteen paths. For seven people, the team requires twenty-one paths.
If you add more people to a project in the hopes of finishing it faster, you may well slow it down. Every time you add more people to a project, the new person has to learn the project and you increase the number of communication paths.
Don’t move someone on to a project just to keep that person busy. Optimize at the team level to ensure finished projects so you don’t create bottlenecks as in The Goal.
Keeping people “fully productive” if they can’t add value to the most valuable projects is not keeping them productive or adding value to the organization— it’s splintering the efforts of the people who are adding value. To see more about productivity, take a look at Measure Capacity by Team, Not by Individual.
This is the whole point of going through the aggravation of relative ranking of all the projects in the portfolio. You know what’s worth your time to start. You know what’s not worth your time to interrupt. You know which projects you have to staff now and which ones can wait until later.
Remaining Points Provide Metadata
As you rank the projects, you might find you have points left over. That’s fine. There’s no rule that says you need to use all your points. Beware, however, of a lack of high-demand projects. Think about your projects in this way:
Projects that keep the lights on—that support the organization
Projects that grow the business
Projects that create new opportunities
Are any of them high-demand projects? If you have more projects that keep the organization running and no projects that grow the business or that create new opportunities, you may not have high-demand projects. Review your mission (Define an Actionable Mission for the Organization), or initiate some strategic planning to see how to grow or create new opportunities.
If you have many points remaining, say up to a third of your points, it’s time to review your mission to see whether you should consider other projects. Many points remaining might indicate no one is demanding your projects. How do you provide value to the organization? Consider and propose projects that reflect that value.
Or, if all the projects have a relatively small number of points, other people in the organization don’t care much about these. Again, review your mission to see what other projects you might offer to move the organization forward.
A project portfolio with projects that aren’t valuable enough to have people clamoring for each of them is a sign that your organization is losing sight of its strategy or mission—or that the marketplace doesn’t want what you offer. The more “keep the lights on” projects you have, the fewer people care about your projects. Reconsider where you’re headed.
I bet you have more than two projects. As you assign points, make sure each project has some point value—unless a project has no value. In that case, remove the project from your portfolio list now.
That’s why it’s worth asking the question for every project: “Should we do this project at all?”. Read How to Kill a Project and Keep It Dead for ways to kill projects and keep them dead. Now, you can rank-order the projects you want to consider.
Now that every project has a unique number of points, identify the highest-ranking project, and assign a team to that project. Proceed down the project list, assigning a team to each project, until you have no more teams to assign. If your organization has been agile for a while, let the teams self-assign.
When you assign teams, assign an entire cross-functional team so that the project is fully staffed. Staffing a project with just developers or just testers doesn’t provide you with a “completed” project—it means you have unknown technical debt because the project staff isn’t getting feedback from the other people who help create an entire product.
If you’re a functional manager, you can’t assign a cross-functional team to each project, because you don’t have responsibility or authority for those other people. In that case, make sure your ranking reflects the value of the project to the entire organization, not just your group.
And work with your peer functional managers, Collaborate on the Portfolio, so you and your peers are all staffing the same projects at the same time for the most value to the organization.
You will probably run out of teams before you run out of projects. If you have more people available than projects to finish, make sure you’ve staffed the projects with enough people, and revisit your mission, as discussed in Define an Actionable Mission for the Organization. You might not be considering all the projects you could offer to the organization to add value.
Rank the Projects by Risk
If you’re working with other people to decide about the project portfolio for the organization, recognize what senior management needs to know: the risk of doing this project, what the project will provide, and whether the return outweighs the risk.
You may have seen risk/return decision matrixes like this before:
You’re not supposed to start the high-risk projects, because they’re too risky. You’re not supposed to start the low-return projects, because they don’t provide enough value to the organization.
I have two questions: How are you supposed to know in advance? And is there a way to start some of those high-risk projects and see whether they are as risky as you think they are or have the potential to return as much as you think?
You can’t know in advance of starting the project. But you can start a project for a short timebox, ask the team to measure their velocity and report on their obstacles and ask them to predict their future velocity. You can even leave those projects for several short timeboxes before you actually assess the relative risk of the project.
In all honesty, the only projects that are too risky to start are the ones that can’t return anything you can see in a few weeks. Once you can see some progress (or lack thereof), the project is no longer as risky because you know how long it took for you to see this much progress. Now you just have to evaluate the potential return.
This means that the period in which you want to reevaluate the portfolio dictates how long your waterfall life-cycle projects can be. If you want to evaluate the portfolio every quarter, your waterfall projects have to be no longer than a quarter in duration. Otherwise, you’re not being honest about the portfolio evaluation.
Many of the high-return projects are high risk, which is why I suggest you forget the idea of looking at risk at all. Manage the risk by using an incremental or, even better, agile approach to the project. Start with your organization’s context of what moves the organization ahead instead of risk.
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 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.
Qualitative Questions That Help You Determine Waste
Start with the qualitative questions, no matter whom you ask. The qualitative questions help you see the problems your customers are trying to manage.
What kinds of workarounds are you using now?
After this project is complete, what changes?
Do we know what success looks like for this project?
Quantitative Questions That Help You Determine Waste
Once you’ve finished with the qualitative questions, ask questions about data.
How will this project affect revenue?
How will this project help us acquire new customers or retain existing customers?
How will this project reduce our operating costs?
How will this project move the organization forward?
Once you know the answers to these questions, your customers can calculate their ROI. Listen to them. If they can’t see enough value to somehow increase revenue, obtain or retain their customers, or reduce their operating costs, your product has little value for them.
Rank the Work by Your Products’ Position in the Marketplace
If you’re selling a product outside the organization, you may have a tough time calculating your customers’ waste, especially if you’re trying to decide which feature has to be built when.
Yes, that’s part of the product backlog decision, but if some of your customers are clamoring for feature 10 and others are clamoring for feature 47, which one do you really do first?
The key is to review where your product is in its marketing life cycle.
Once you’ve hit the early majority, you don’t need to release a given product as often as you do before the chasm.
But it still makes sense to finish projects internally so you have choices of when to release which product for which marketplace. Now you can ask your best customers where their waste is so you can make your choices.
Those early adopters are valuable customers, but you need to be careful. The more you ask them what they want, the more they think you have promised them something.
That’s a problem when you reach a larger audience and the early adopters still think they have the same influence and that you’ve promised them features. Careful management of your project portfolio can save you here.
Use Other Comparison Methods to Rank Your Projects
If you can’t use points or it’s too hard to calculate waste, you still have several choices to rank your projects. Try pairwise comparison, single elimination, or double elimination.
Use Pairwise Comparison to Rank Projects
For pairwise comparison, make a simple list of all the projects. For our purposes, a project is a unique release of some collected set of features. (That specification may be vague where you work.)
If you wrote your projects on stickies when you were collecting all the work, as in Know What Work to Collect, this part is easy. If you didn’t make stickies or index cards before, make them now.
Place all the stickies on a wall. If you’re using index cards, put them on a table. Take two stickies. Hold them up so everyone can see them, and ask, “Which one of these is first compared to each other?” Of the two projects, one is a higher priority than the other. Put the higher-priority project at the top of the list, and put the next one underneath it.
Now, take the third project. Compare it to the first project: “Which one of these is first compared to each other?” If the third is a higher priority than the first, put it at the top of the list.
If the first one is still a top priority, compare the third to the second. Keep going until you’ve looked at all the projects and compared them to each other. In the end, you have ranked your entire project list.
This is just like what the eye doctor does when you’re being fitted for new glasses. My eye doctor says, “Which one of these is clearer: this one or that one?” first for the left eye, then for the right eye, and then finally for both.
You have to make only one decision at a time. Imagine if you had to look at each image with each eye before she changed both at the same time. Too confusing.
Consider Single- or Double-Elimination Tournament Decision Making
Sometimes you have groups of projects and need to pit 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 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.
Ranking Trap: Treating Business Value Points as Story Points. If you work in an agile environment, you might know about “story” points.
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 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.
Ranking Trap: 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.
Ranking Trap: 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 Trap: 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 into 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 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.
Ranking Trap: 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. (Agile approaches work quite well for this. If not agile, use a staged-delivery approach to finish features.) 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.
See The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses for more information on lean startup thinking.
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 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 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. For some ideas, see The Facilitator’s Guide to Participatory Decision-Making as well as The Art of Focused Conversation. You might be rolling your eyes, “Collaborate, JR?
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.
Organize to Commit
Work at the highest span of influence you can in the organization, and you will maximize the return your work brings to the organization. Avoid optimizing decisions at the lowest possible level, maximizing your group’s return instead of maximizing the organization’s return. Instead, optimize the decisions for the organization.
Maximize Value for the Organization, Not Our Departments
As directors, we each have two primary responsibilities: to make sure our groups are producing at the highest level of capacity and to build that capacity. But we had problems with each other, because our measurements were about our individual capacities, not building organizational capacity jointly.
Tony started: “My objectives were all about delivery date, without thinking about the quality of the product. Joyce’s objectives were all about defects and the numbers of them, not whether they actually improved what the customer wanted. After a couple of years of fighting with each other, we decided to take a higher-level perspective of organizational capacity.”
Joyce continued, “Once we began thinking in terms of value to the organization, we started thinking about completed work. We stopped counting things that weren’t completely done and releasable. That way, Tony’s features and my defects became our product.”
Tony explained, “When we started thinking about whole products and working together, we were able to present a united front, convincing our management to change how we worked.
We’d both been using timeboxes for our work, but when we started working together to complete first features and then projects, we were able to improve our value to the organization.”
Joyce added, “Given that we have functional groups, we don’t add value by ourselves. We add value when we work together to provide a complete product. We’re able to work for our organization by collaborating with each other and by helping our manager see that our objectives needed to be interdependent.
If our manager had insisted on measuring each of us by what only our departments could deliver as a silo, there’s no way we could have provided the value for the organization. We each would have optimized what our groups could do and damn the organization. But now, we can work for the greater good, not for our personal good.”
The biggest barrier to collaborating on the project portfolio is not how you muddle through the meeting. The biggest barrier to collaboration is lack of trust. If your colleagues trust you, they will collaborate with you. There are other barriers to collaboration, but trust is a necessary prerequisite.
Your organizational culture affects how people perceive you as trustworthy. For example, in organizations where you can say just about anything to almost anyone, being sarcastic may be fine.
However, in other organizations, being sarcastic is not acceptable and breaks trust. Schein explains that culture is what you can discuss, what’s rewarded, and how people treat each other.
Hofstede looks at several dimensions of culture. The two most relevant here are power distance and uncertainty avoidance. Trust—or lack thereof—can be a consequence of your culture.
Building trust can be difficult if you’ve never tried to work as a leadership team before.
Deliver what you promise to deliver.
Be consistent in your actions and reactions.
Make integrity a cornerstone of your work.
Be willing to discuss, influence, and negotiate. Don’t get stuck in your position.
Trust in yourself and your colleagues.
To build trust with your colleagues, first identify your goal: a project portfolio for your group or organization so everyone is focused on the same work. For your team, determine how you will deliver consistently. For me, that means an agile approach to project work. Make sure you determine how your project teams will deliver.
Personal integrity, active listening skills, self-trust, and extending trust all are parts of your relationships with your colleagues at work. One way to think about all of these is to consider congruence.
Congruence in relationships means considering yourself, the other person, and the context of the situation for each and every interaction. When you balance all three, it’s easy to have integrity, to listen, and to believe in yourself and the other person. It’s easy to understand but sometimes hard to do.
Here’s an example of congruence. Assume you work in a matrixed organization, where the functional managers assign people to projects. If the development and test manager blame each other for the quality of the code, they are not being congruent; they are considering themselves and the context and ignoring the other person.
On the other hand, if the development manager and test manager work together to determine what causes defects and work together to eliminate those problems for this project, they are congruent.
Building trust is the first step in building a collaborative team.
They have a common goal.
They listen closely.
They concentrate on just the issue at hand.
They are in control of their work.
They are willing to blend their work.
They are familiar with each other and the problem at hand.
They practice their communication often.
They move the conversation forward.
They learn from failure and move on.
Keep these characteristics in mind as you consider how to prepare for the portfolio evaluation meeting and how to work at the meeting.
Define Your Principle so You Can Collaborate
You’ll be using collaboration, influence, and negotiation to arrive at a portfolio that will fit the needs of the organization.
As you prepare for this discussion, make sure you know why you ranked each project as you did—the principle behind your ranking.
That information provides you with the foundation for collaboration because you can use that principle to articulate how you think you can arrive at the team’s common goal. Being able to discuss your principle behind the ranking will help you with the portfolio collaboration.
Context Defines My Principle
I’m at a startup now, and the principle behind all my portfolio decisions is this: How do we make forward progress on the product?
Sometimes, that means we choose a few features and fix the few known defects. More often, it means how many major features and how many minor features can we put into a given release? Our portfolio management is much more at the product backlog level. When we have more than one product, I’m sure this will change.
A few years ago, when I was at a large product company, it was harder. We had several legacy products, each with tons of technical debt, and we had a bunch of long-standing customers and were acquiring new customers slowly.
We had a couple of newer products where we were acquiring customers quickly. We changed our principle every quarter or so.
Sometimes, we received more value by doing something to get new customers for the new products. Sometimes, it was by adding something or fixing something for our long-standing customers for the legacy products. Sometimes, it was fixing problems. But it changed based on the market and where our customers were.
Your principle can be as short as “We have to release our flagship product because it has been two years and we promised in our support contracts a yearly release.” Your principle could be “We commit to projects that move our website forward for our customers so we build loyalty before we commit to internal projects.”
It doesn’t matter what your principle is—what’s important is that you have one. Once you have a principle behind your decisions, you can collaborate, because you have a vision that’s driving your decisions.
Articulate Your Mission to Prepare for Collaboration
You need this information to collaborate on the portfolio with your peers: your mission, which is what drives you (and your group) to succeed; the principle by which you will make portfolio decisions; and a strawman portfolio if you created one.
To be honest, you also need a corporate mission so you can discuss each project’s value to the organization. You can’t manage your portfolio without a mission because you won’t have a clearly articulated big picture of where you are headed.
Part of what you do might have to include defining the corporate strategy. It doesn’t matter whether you’re a product company or an IT organization—you need a corporate mission to drive this collaboration.
Facilitate the Portfolio Evaluation Meeting
Let’s assume you’re in a portfolio evaluation meeting. The purpose of that meeting is to gather data so you can make the portfolio decisions across the organization. That means you need to evaluate each project, rank it, and see which projects you can commit to so you can create the unstaffed project list or the project backlog.
Everyone arrives with two pieces of data: his or her ranked portfolio and the principle by which each person ranked the projects. If you’re facilitating the meeting and you are not the most senior manager, be ready for some people to be unprepared for the meeting.
The portfolio evaluation meeting has four parts: looking at each project to evaluate it, ranking each project, making the commit/kill/transform decision, and publishing the decisions. Make sure you manage each piece on its own. You may have to stop projects that are proceeding well because circumstances have changed.
Facilitate the Ranking Part of the Meeting
If you need some background on facilitating meetings, I recommend The Facilitator’s Guide to Participatory Decision-Making. There are three parts to the ranking part of the meeting: making sure you’ve collected all the work, discussing the ranking, and actually ranking the projects.
Make sure you separate all the parts. You need to see each project’s state before you rank it in relation to each other project. You need to rank each project before you can make the commit/kill/transform decision. And you have to make that decision before you can publish the portfolio.
Facilitate the Commit/Kill/Transform Part of the Meeting
Once you’ve ranked all the projects, each manager has to make sure he or she has sufficient staff to assign to each project. This is especially challenging in organizations where managers have responsibility for functional groups, who then are matrixed into projects. If you have enough people to assign to all the projects, no problem.
But, most of the time, one or more functional managers do not have sufficient people to staff all the projects. In that case, consider asking the incomplete project team to list the lack of specific people as a risk and to transform their project.
How to Say No to More Work
As you proceed with the collaborative decisions, you may find you have too much work for the people you have available.
In fact, in many health organizations, you do have too much work to do for the people you have available. See Your Project Portfolio Is an Indicator of Your Organization’s Overall Health to know whether your organization is healthy.
No matter who you are, at some point you will have to say no to someone asking you to do more work. One way is not have projects at all and make all your decisions in a lean and agile way, as in Lean Approaches to the Project Portfolio. But, if your organization has to have projects instead of just timeboxed work, consider these approaches.
If you have a portfolio and someone—especially someone higher in authority —asks you to do more, try these approaches.
We Could Add More People
As you show this person the portfolio, you can say, “If we need to staff this project, we need more people.” If you could add more people, either as additions to your current project or as another cross-functional team to increase velocity for the project, explain how that would work.
Maybe one project should come off the current portfolio list and be moved to unstaffed work to allow the requested project to be staffed.
This is a great alternative if you have many people working solo on little bits and pieces of a project. Sometimes, a group of people swarming around a problem makes the problem easier to solve and helps the team progress faster.
This is not a good idea if you are in danger of violating Brooks’s law from The Mythical Man-Month: Essays on Software Engineering: adding more people to a late project makes it later.
What Should We Drop?
It might be time to discuss the unstaffed work and see whether your ranking was successful. You can say, “Here’s what we can do. What should we drop?” Once you’ve assigned the teams to the projects, you’ve staffed all the projects you can do. It’s time to either reevaluate or move more projects to the unstaffed list.
This is a good time to make sure the same people are not attached to multiple projects. For managers new to portfolio management, the idea of stopping work, even just for now, is a foreign concept. They are tempted to ask people to multitask instead of stopping work on one or more projects. Asking what to stop doing, what to drop, is a good first step.
I See These Alternatives
Let’s assume you’ve ranked the portfolio with your peers, and you all agree on what to do first, second, and third, as well as what, to leave on the unstaffed list.
If your manager comes to you—and only you—explain that portfolio is a contract between you and your peers. In addition, walk your manager through the alternatives as you and your peers discussed them.
If your manager wants all of you to change your minds, explain the alternatives as you saw them and why you ranked the portfolio this way. “Here are the alternatives we discussed.”
Sometimes your manager can see alternatives that you can’t. Maybe you can break a current project into smaller groups of related features and have several teams work on that project in parallel. When they finish, maybe those teams can all work on this project that’s not currently staffed.
Steps Toward Incremental Funding
You or your organization might be attached to the idea of yearly funding and yearly project portfolio decisions. You might have some of the problems outlined in Discover Barriers to Collaboration. If so, consider these steps toward incremental funding and incremental decision making about the project portfolio:
Ask the question, “What do we want to have happen?” Listen for answers. If the answers are about how people do their work instead of results, see if you can move the conversation to results.
You might hear something such as this: “We want people to report on their progress.” You can ask, “What value will we see from this status?” You can then ask if seeing demonstrations as opposed to project status will work.
How often do we need to see results from the teams? If people say, “Every month,” you can suggest, “How about if we fund monthly and reassess the project portfolio each month?” Listen to what people say.
Ask the question, “Is there a limit to what we want to spend on this project?” If you do have a limit, you can decide if you want to allocate all of that at the beginning, or see project progress before you commit more money.
In each case, listen to what people say. They are explaining impediments to incremental funding. Remove those impediments and you have a clearer way to achieve iterating on the project portfolio and incremental funding.
Incremental funding makes commitments easier. Incremental funding makes collaboration easier because it’s clear the project portfolio is a commitment for now. Incremental funding makes it more difficult to spend a ton of money and then realize you need to stop a project or program.
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 deliver 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
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.
These are some reasons people don’t collaborate:
Someone is playing a zero-sum game.
Someone feels as if information hiding will help his or her career, instead of sharing information with everyone.
You and your colleagues do not share a common goal or strategy.
Managers reward people for individual achievements instead of for the success of the larger group.
You don’t have enough senior managers involved who can make decisions that stick.
People are stuck on their positions about projects in the portfolio and have not articulated their principles.
You are not meeting in one location at one time, so the geographic and meeting distance prevents you from collaborating.
People have cultural reasons for not collaborating.
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 “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.
Iterate on the Portfolio
If you want to consciously make portfolio decisions rather than have the projects whip you around, you’ll need to plan how often you will want to review and adjust the project portfolio.
If you don’t plan to iterate, you’ll have emergency projects (Signs You Need to Manage the Project Portfolio), which throw the whole organization and the portfolio into disarray. If you plan your iteration period, you’ll prevent emergencies and help the project teams make the most of their time for their projects.
When most people slot their projects into a portfolio, they easily have twelve to eighteen months of planned work in the portfolio. That’s way too long. You can’t possibly predict the future a year in advance.
At some point—way before you finish the projects—something happens, and you’ll need to readjust the portfolio. You and your colleagues must determine how often you need to review the portfolio so you can adjust the relative priority of each project and the staffing or funding for each project. Reviewing the portfolio includes the actions of planning and replanning the portfolio. Your job is to make decisions as you review.
Decide When to Review the Portfolio
You can plan for the adjustment in a portfolio review, but how often should you review the portfolio? Too often, and you aggravate everyone involved because nothing has changed. Not often enough, and the projects underway have no relationship to the list of staffed and unstaffed work.
Match the frequency of your portfolio review to your development style, and make sure that if you’re using a serial lifecycle, you don’t wait until the end of any project. If you use incremental funding for your projects, make sure you review in enough time to fund the next cycle of project work.
If you’re using iteration boundaries for your projects, that’s a good time to review the portfolio. If you’re using a serial lifecycle, review the portfolio at least quarterly to ensure the projects are still valuable.
If you opt for more frequent reviews and decrease the project scope, you can avoid or better respond to emergencies. With an iterative or incremental lifecycle, you can review the portfolio after the teams complete a prototype or a feature chunk.
If you plan to review and readjust the portfolio periodically, your project teams will adjust to your time period. That’s because you need a demo and data to make decisions about committing to the project again. If you explain to the teams what results you want (a demo and project progress data) and you tell them when you need it, you’ll get it.
You might need to review the portfolio when release dates change when your customers want something new, when your competitors announce or release new products, or when new technology is possible.
Because you can’t control most of these events, you’ll need to be flexible about your review cycle. But you do have ways to decide when is the right time to review the portfolio.
The ideal time to review the portfolio is
When a project finishes something you can see (the project cycles)
When you have enough information about the next version of a product (the planning cycles)
When it’s time to allocate budget and people to a new project (the business cycles)
These cycles are interdependent. Here’s a true story about how one group recognized the interdependencies.
Select an Iteration Length for Your Review Cycles
Your project portfolio review cycles depend on the choice of life cycles for your projects and how long the projects are, on how frequently you need to plan or replan the product roadmap, and on how much budget planning and replanning you need to do.
Project Life Cycles Affect Project Portfolio Management
Because your review cycles depend on your projects’ durations, you’ll need to adjust your iteration length to match your projects’ durations.
If you use an iterative, incremental, or agile life cycle, you have opportunities during a given project to review and replan the portfolio. But if you use a serial lifecycle, such as a waterfall or phase-gate, your portfolio review cycle is the entire duration of the project.
If you contain the requirements, the team is familiar with the product, they don’t run into technical difficulties, and the schedule is short enough, then you may be able to make serial life-cycle projects work for your portfolio management.
But too often, I see time-bound projects with high technical risk try to fit everything into a serial lifecycle for a project that’s more than three months long. That’s not a recipe for success, for the project, or for managing the portfolio. Instead, consider another life cycle for your projects.
If one project takes longer than six months to complete, you are deciding not to staff other projects that might need to start, and even finish, before the team is done with their original project. If you feel enough pressure, you’ll ask people to work on more than one project, leading to multitasking and waste.
Help the project team choose a life cycle that fits your business requirements of when the project needs to finish and that fits your time need to review the portfolio. As an organizational leader, this is where to put your energy.
If you use an iterative lifecycle and integrate the product as you proceed, leaving only final testing for the end, your project portfolio review cycle can be as short as the time it takes to implement one feature, integrates it, and test it.
If you use an incremental lifecycle, such as staged delivery, your review cycle can be as short as the time it takes to finish one feature. If you’re using an agile life cycle, your review cycle is the duration of one timebox, not more than four weeks long.
If one of the projects in your portfolio requires many features and a tight schedule, the more you want that project team to use an agile or incremental life cycle. Because the project team completes features inside a timebox, you have the most flexibility in replanning the project portfolio.
You might not care what kind of a life cycle you use for a relatively mature product, assuming you don’t want to release it more often than once a year or so, and you don’t need that project team for other work.
The more projects compete for fewer project teams, the more you need an agile life cycle for your projects. If you have only a few projects waiting for project teams, you might be able to use an incremental lifecycle.
But if you have many more projects than you can staff, it’s time to move to agile. You can’t get the throughput out of your teams and the ability to decide and change quickly in any other life cycle.
Two Teams, More than Twenty Projects
We’re a small software company doing custom development, and we want to retain our independence. We can pay people the way we want and not have to answer to anyone if we stay independent. But a couple of years ago, we were in trouble and were considering looking for financing.
We had way too many projects to do and not enough time or people to do them. We had only two project teams and about twenty-two projects. At first, I told my VP that we needed everyone to work on more than one project at a time. That didn’t work. So, I told him to find another way.
First, he had all the project teams work in timeboxes so we could see what they could do in three weeks. Then he changed things so they were implementing and testing by feature inside the timeboxes.
That worked really well because we could demo to the customers. If the customers wanted some time to think about it, we could say, “Take three weeks. We’ll be ready for you then.” We got great feedback from them.
Long story short, we started using two-week timeboxes. We still have a ton of projects—way more than twenty now—and we’re able to juggle things because we know how to slot the work into the portfolio, and we can allow our customers enough time to review our work to date.
Some of our customers know they have a three-month wait before we’ll show them the first demo, and they are willing to wait because of how we work with them.
Now, when we close a contract, we work with our customers to slot them into the portfolio. We always have people working on only one project.
And, because people are so focused on one project at a time, they really learn the guts of the product. They’re much faster on that project, and they can take their knowledge and apply it to the other projects more easily.
Product Roadmap Planning Affects Project Portfolio Management
It makes sense to make your planning cycle—the readjustment of the product roadmap, which features you want in which quarter—occur every quarter, especially for less mature products or for a market in flux.
If you’re using an agile life cycle, you can readjust the roadmap every timebox, fine-tuning which features the project team will finish when, as well as when you can release the product.
With an incremental lifecycle, you have almost the same flexibility as with an agile life cycle, but you’ll have the project startup time, plus the varying time to complete a feature.
For an iterative lifecycle, you’ll have to allow for the time to add in all the prototypes for a given feature and test it. For a serial lifecycle, you’ll have to restrict the number of requirements you can address in one project to meet your need to review the portfolio.
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.
If they received other requests or requests for work not in the backlog, I asked them to use this phrasing: “That sounds great. Please talk to JR about slotting that request in.” That’s all they had to say. They were the good guys and could continue their work. I would work with the managers and product managers across the organization to determine what to do.
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.
Make Decisions as Late as Possible
Maybe you’ve decided you’ll try this portfolio management business. But you need to fund some projects now to see what they can deliver.
One of the lean principles is to defer commitment to a project until the last responsible moment. The problem is, with software projects and with software/hardware combination projects, you might need to fund prototypes or some early development until you know just what the project will be able to deliver.
That’s OK—both to wait until the last possible moment and to fund some of the projects and then decide what to do, as long as you decide what to do and know how you’ll decide to keep going or stop. That decision making will differ based on where you are in the organization and how strategically you need to think or act.
One way to make decisions as late as responsibly possible is to use short, time-boxed iterations for your projects. If you use two-week timeboxes, you can see some initial progress on a clear set of work.
You can reevaluate your decision about this project in just two weeks. I’ve used timeboxes up to four weeks long, and if we’re experimenting, I find shorter timeboxes work better for my decision making and the team’s progress.
The short timeboxes help the team feel that I really do want to measure what they can accomplish in a short time. If they can’t accomplish what they thought they could, I have some easy choices: give them another timebox or two, or stop the project right now. Two weeks is long enough to learn something and not so long that we (the entire organization) have spent the time we can’t afford.
If you’re really crunched for time, consider one-week timeboxes and limit the number of timeboxes to three or fewer. If you don’t know enough in three weeks, you can take a bigger-picture view and assess the overall risk of this project.
The waste matrix in Who’s Waiting for Your Projects to Be Completed? may help you see how to look at the risks of doing or not doing this project.
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.
There are no right or wrong answers. I like a board that shows the flow of work through the project portfolio, like the following:
In this kanban, you see how the people who decide on the project portfolio might review all the projects. All the projects start in the Create Backlog state. Then, the projects move to the Evaluate state. Does a project need pre-work? If so, that project might go to a different board.
Once the organization commits to the project, the project goes into the Project Work column. When the project delivers some value or it’s time to reevaluate the project, it might go into the Assess/Validate state. When the project is done, it goes into the Maintain state.
Note that some projects might require pre-work to see if they are ready for a team. In addition, a kanban board doesn’t show cycles well, so there might be projects that move from Project work to Assess/Validate? and back to Evaluate because the organization needs to transform the project in some way.
I like using the Maintain state to help people realize that we have to consider issues from “Completed” projects. Software projects are never complete unless people stop using them.
I have seen too many organizations overwhelmed by the number of projects they have in Maintenance, in addition to the new projects they have. This board helps managers see that potential problem.
I do not recommend you use this category to define an architecture for a project or a program. In my experience, you cannot define all you want up front. You will be wrong and will waste the time you spent on the pre-project definition. On the other hand, you might need to experiment with a proof of concept before you commit to a project. I recommend you manage these pre-work projects this way:
Determine the questions you want this project to answer. The questions are the entry criteria for the project. Timebox the time you will devote to this project so you know when you will receive the answers. If the pre-work team can’t answer the questions in that time, that tells you metadata about the project difficulty.
Make sure the pre-work team creates a list of open issues for the eventual project team. The timebox and the open issues list are the exit criteria for this project.
If you have other kinds of pre-work projects, decide what their entry and exit criteria are. Under what circumstances will you transition this project to the Project work or the Parking Lot lists? Decide the circumstances for funding— or not yet funding—this project.
Conduct a Portfolio Evaluation Meeting
When you evaluate the portfolio, you’ll hold a special meeting. In the past, you might have called this a management review or a project status review. Many people have worked in organizations where management review means the dog-and-pony show for serial life cycles, so I prefer to call these meetings portfolio evaluation meetings because that’s what they are.
You have just one goal for a portfolio evaluation meeting: to rank each project. In order to do that, you’ll decide for each project whether you should commit to the project, kill the project, or transform the project in some way. You do not have a goal of solving project problems. Your job is to facilitate the decision about the project’s future. That’s all.
To make the decision, you need the right people at the meeting. The people who need to make the decisions are those who set the strategic direction of the organization and those who provide the information about the project.
For many organizations, that’s an operating committee of some sort plus the product owner/product manager and the project manager for the projects under consideration.
Once you have the right people present, you need two pieces of project data: what the project demo looks like (can you see the visible project progress?) and what the team’s velocity is since the last time you had an evaluation meeting (a historical velocity chart for the project). You also need to know about project obstacles and what the organization’s strategy is.
I like to ask four questions at the evaluation meeting:
Does this project still fit into our strategy? Check to see it still fits.
What have you finished since the last evaluation meeting? The project team provides the demo here.
Where are you in the product backlog? The project team provides velocity and a backlog burndown chart.
Where are your obstacles? This will tell you whether there is a risk for continuing this project in the same way.
Publicize your project evaluation list so each project can prepare their information in advance. This information should come directly from what the project team already creates for their project dashboard.
If you work in an organization that tracks project cost, you’ll need to know the run rate (the cost of the project per unit time), the total project cost, and possibly the monthly/quarterly/yearly project cost data. For possible measurements, see What You Need to Measure About Your Projects.
Consider what you need to know about each project. With projects already underway, you might need to see a demo to know if this project is still more valuable than another project. You might need to see the product roadmap and how much progress this project has made on the roadmap for the project.
Consider which data you need to see about the project to know if you should continue the project. The data you need is about running, tested features. You don’t need any other data.
As you consider these questions, think about which of these projects have become high-demand projects since the last time you evaluated the portfolio. 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.
Our Business Changed Almost Overnight
We handle the communications between delivery vehicles and the main distribution point. We’re tooling along, adding new features to our reporting service. We had a client/server application we’d developed back in the 90s.
First, we heard from one client that they wanted web-based reporting. Then another. And another. Then we learned of a potential competitor who didn’t have as good a product but had the kind of reporting our customers wanted. We know we have to do this.
We’d done small web-based apps for use in-house. We’d never done one where our clients’ private information had to be available 24/7, with security. I realized that if we could do this, we could expand our business dramatically. But we didn’t foresee this and didn’t know how to do it.
Before we did anything, we gathered as an operations committee, looked at all our projects, and asked, “Is there a project that’s a higher priority than this one?” No. We would be out of business—not today, not tomorrow, but within a few years—if we didn’t do this project.
That’s when we decided the risk of not doing this project was higher than any return we might realize from our current projects. We finished that project, and now we have several skunkworks-type projects to explore other kinds of communications among our clients’ different locations: the factories, the trucks, the distribution points, the offices.
We realized we are in a different business than we thought we were. Luckily, we were able to redirect our efforts quickly. If we hadn’t had a project portfolio, I don’t know whether we would have known about all the projects people were working on, so we wouldn’t have known how to reorganize who was working on what and when.
There are times when you might want to evaluate the portfolio more frequently than once a quarter. If you are in a volatile market and your competitors are releasing products at least once a quarter, you want to be able to change more quickly than once a quarter.
If you are new to agile and you’re not sure how well the project teams are progressing, conducting a portfolio evaluation more often than once a quarter will help the teams provide data and learn about the other data they might need in order to do a great job for the projects.
Do We Run the Risk of Never Finishing Anything?
You may be concerned about evaluating the portfolio more often than once a quarter. If you change your mind about what to commit to each time you evaluate, can you ever finish anything?
Yes. And you do have to watch how often you change your mind about the ranking.
Ask yourself this: Does the value of this project change that much each time you evaluate the portfolio? In my experience, the top few projects don’t change rank every time you evaluate the portfolio.
Until they are done, they are still the top-ranked projects. And those are the projects that will provide the most value to you. If you do find that your top-ranked projects do change every time you evaluate the portfolio, ask yourself, “What business are we in?” and take another look at your mission.
Normally, it’s the lower-ranked projects that change their value to the organization.
I have not worked at an organization that could successfully evaluate the portfolio every six months or even less frequently without missing too many opportunities to manage which projects to commit to, to kill, or to transform.
When these organizations didn’t make explicit portfolio decisions, each manager (and some technical staff) made their own decisions. The organization did not have a unified approach to the portfolio. If your organization does not need frequent evaluation, then decide how often to review the portfolio. But make an honest decision.
Review Your Decisions
As you conduct the portfolio evaluation, make sure you have a decision about each project: commit, kill, or transform. If you haven’t made a decision about each and every project, you’re not done.
Managing the project portfolio isn’t difficult at all when you’re using an agile life cycle. It’s close to impossible with a waterfall, and it varies with the length of the project if you’re using an iterative or incremental life cycle.
If you can’t use an agile lifecycle, keep your projects to no more than six months in duration so you can iterate on the portfolio at least twice a year.