30+ Portfolio Management Tips (2019)

Portfolio Management Tips

Portfolio Management Tips

This blog explores the 30+ best Portfolio Management Tips used in projects. The portfolio is the Big Visible Chart that shows the ranking of your committed projects.


In very large organizations, you might realize you work in functional silos. I know of a large organization of more than a thousand product developers.


Note that the teams are silo teams. In fact, the directors managed pools of people as resources. They never thought twice about moving people from one project to another or having people work on several projects at one time.


  1. When they wanted to manage their project portfolio, they had several decisions:
  2. What projects did they want people to work on?
  3. Which teams did people work on? They had to assign people to work on just one cross-functional team.

If you are transitioning from a waterfall approach to a more agile approach for your projects, you might also have an organization that looks like this.


Portfolio Management Tip: 1

Qualitative Questions That Help You Determine Waste

Start with the qualitative questions, no matter who you ask. The qualitative questions help you see the problems your customers are trying to manage.

  1. What kinds of workarounds are you using now?
  2. After this project is complete, what changes?
  3. Do we know what success looks like for this project?
  4. Quantitative Questions That Help You Determine Waste
  5. Once you’ve finished with the qualitative questions, ask questions about data.
  6. How will this project affect revenue?
  7. How will this project help us acquire new customers or retain existing customers?
  8. How will this project reduce our operating costs?
  9. 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.


Portfolio Management Tip: 2

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.


Portfolio Management Tip: 3

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.


Portfolio Management Tip: 4

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.


Portfolio Management Tip: 5

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


Portfolio Management Tip: 6

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.


Portfolio Management Tip: 7

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.


Portfolio Management Tip: 8

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.


Portfolio Management Tip: 9

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.


Portfolio Management Tip: 10

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.


Portfolio Management Tip: 11

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


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.


Portfolio Management Tip: 13

Portfolio 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 a 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 happened?” 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.


This organization had a huge problem: each director had MBOs (management by objectives) that put that director in competition with the other directors. If they had tried to collaborate to create a project portfolio, some of them would not have received their bonus.


In reality, they had several projects and programs. They decided to organize the programs first because they accounted for much of the work. They explained the notion of programs and projects to the CIO. They also asked to change their compensation structure so they could start to collaborate.


The CIO was a fan of incremental work. He was new to agile, so he was a little suspicious. On the other hand, he understood the compensation structure was in the way of managing the project portfolio. He agreed. 


The directors created cross-functional teams, assigning the teams to projects and programs. They didn’t change where people sat or the reporting structure.


When you have silos and you reinforce those silos with compensation, decide how to start the change to having people work by project. If you have an organization based on function, decide how to manage that problem before you start scaling any project portfolio work.


Portfolio Management Tip: 14

Does Your Organization Suffer from Resource Efficiency Think?

Some managers think of people as “resources.” One consequence of that thinking is that managers think they or the teams can split work to make people more efficient. We split this work by work type, creating experts. The name for this is “resource efficiency.”


You can see evidence of resource efficiency thinking in these conditions:

  1. Managers want to see 100 percent utilization for each person, optimizing for the person, not the team.
  2. People have narrow expertise. Work queues behind those people for multiple projects.
  3. Managers refer to people as resources.
  4. High utilization makes no sense for knowledge work. People need time to think and to innovate. 


When we flow work through teams, we see the highest throughput. It doesn’t matter if we talk about features or projects. Flow efficiency allows us to finish work faster and therefore increase our capacity for more work. Use a view that helps your organization realize it’s the finished work that counts, not the started work.


If your organization has trouble managing the project portfolio, rethink how you consider teams and people. I like to show management which people are working on what projects—and which projects they are not working on.


That helps everyone see the flow of work through your organization. When you add WIP limits, everyone can see that pieces of people—especially alone—do not help a project finish fast enough.


What if You Need a Little Bit of a Person?

I’ve worked with many teams that thought they needed a part-time person: DBA, UX, or tech writer.

It’s possible you only need that person once for ten hours one week. It’s unlikely. What I’ve seen is you need this person for a couple of days now and a couple of days next week. Then you need that person more in a week or two.


That’s when you discover the person needs to change something. Or maybe the team found a problem with the original contribution. Your project needs that person more and more.


The person is a part-time contributor on two or three projects. Murphy’s law (and other arrival curves) explain this person is now a bottleneck on several projects. This is a great example of resource efficiency thinking creating a substantial Cost of Delay. 


Instead of thinking about bits of people—resource efficiency thinking—think about how that person can help a team over time, not once in a while. Can you ask the team to work together to share this person’s expertise?


The team might not become an expert in what the expert can do. On the other hand, maybe they can maximize the expert’s time with the team.


When you work in flow efficiency, you reduce the Cost of Delay due to experts and multitasking—any wait states. When you work in resource efficiency, you maximize the Cost of Delay because you’re always waiting for something. That decreases your organization’s overall throughput and capacity.


Portfolio Management Tip: 15

Flow Similar Work Through Teams

I’ve seen management change project assignment for teams. Their rationale is that they want the teams to learn other parts of the product. I like this idea of team learning. Know that it takes time for a team to learn.


You can flow work—including different work—through teams. Each team will have a different amount of time to learn that area. And it’s likely that the team will forget what they learned the next time they work on this area.


This “change what teams work on” is another form of resource efficiency thinking. You will incur a Cost of Delay due to team learning time. What if you really want to get the next-ranked project done and the “right” team isn’t available?


Go ahead and use the available team. Recognize that the team might need training or time to learn. You will not see the predicted project completion time because the team needs time to learn.


Portfolio Management Tip: 16

Create a Holistic Perspective of All the Work

When each group has a project portfolio, you can see them. And the portfolios might not be coherent across the organization, especially when everyone has made their own decisions.

At this point, leave the decisions alone. Your first role is to make the information transparent.


Show the Work Now

I recommend you gather each product line or business unit’s representatives in a large room with enough wall space to show everyone what’s going on. Ask each business unit to provide a large poster of their quarter’s plan. The poster should be about four feet by six feet, so everyone can see one quarter’s work in large-enough lettering.


I ask people to post their boards. I ask one person from each business unit to stand by their board, and everyone else to walk around. As people walk around, I encourage these questions:

  1. What principle(s) is(are) behind your decisions?
  2. How did you determine value?


Are any of these projects really programs?

If your organization has other questions, ask them. I tend to stick to data-gathering at this point. I want to know how people made their decisions. I don’t want to pass judgment on those decisions.


Portfolio Management Tip: 17

Define the What for Each Product

Once you know your strategy, it’s time for product management to define what goes into each project to implement the strategy. That often means the product management people have this work to perform:


  1. Define a roadmap of what the product will be over its life cycle:
  2. beginning, middle, end of life.
  3. Define a roadmap for the next few quarters (or months) to show what interim releases will deliver.
  4. Define a given project’s backlog: what this next milestone will deliver.


Note that roadmaps are not requirements documents. They are a high-level picture of what you want to achieve when.


In Agile and Lean Program Management: Scaling Collaboration Across the Organization I recommend you have at least these two roadmaps: the big picture for several quarters out and not more than one quarter at a time The big picture roadmap shows you where you want to be after several quarters. Here, I’ve shown six quarters.


The small picture roadmap shows where you want to be after one quarter. I’ve shown monthly internal releases. If your organization can release more often than once a month, that’s great. I recommend for the purposes of the project portfolio you release at least monthly. 


Roadmaps are a wish list. They are a planning mechanism. There is no guarantee the teams can produce what is on the roadmap in the time you want them to. On the other hand, if the teams don’t know what you want, they cannot deliver it.


Portfolio Management Tip: 18

Define How You Will Deliver a Great Product

The goal of project portfolio management is to calm the organization so you can increase your throughput. As I said your customers don’t care about your project portfolio. They care about what you deliver to them:

  1. Is what you delivered what they need?
  2. Does what you delivered work?
  3. Does what you delivered solve their problems?


In addition, you want to know if the projects in your project portfolio create a healthy business. You can assess that by seeing if the projects meet your driving force as described in Define Your Driving Force, Your Why. Your ability to deliver is key to being able to manage your project portfolio.


Your delivery is related to the life cycle a given project selects. You can use any life cycle for your projects. Depending on your risks, some are better than others.


For the purposes of managing your project portfolio, an incremental or an agile approach will provide you more frequent opportunities to assess and replan your project portfolio.


If you are delivering well now, what about your project approaches work well for you? Continue as you are.


However, if you are not delivering well now, or not as well as you would like, what do you need to do to deliver finished features more often?


The more often you deliver finished features, the more often you can obtain feedback about what your customers need, whether what you delivered works, and if what you delivered solves your customers’ problems.


Portfolio Management Tip: 19

Ask These Questions for Each Business Unit

You have the work as in Show the Work Now. You understand the principles by which each business unit made its decisions. You know the corporate strategy and your driving force. Now it’s time to ask these questions:

  1. Will this work help us implement our strategy?
  2. Will this work distract us from our strategy?


Your project portfolio implements your strategy. If you don’t know your strategy, your portfolio will be random, not coherent. If you do know your strategy, you can make better decisions. If you want to change your strategy, decide which projects to fund now and later.


Beware of the Sunk Cost Fallacy

In high tech, we change our driving force over time. We often call this a “pivot.” 

I sometimes hear people say, “We’ve invested so much in this effort. Can’t we just finish it?” Back in Don’t Recommit Because of Sunk Cost, I warned you about recommitting because of sunk cost. It’s the same idea here.


If you are pivoting or changing your driving force, do not consider sunk cost. You’ve spent that money. You may never do anything like that again. Conduct a retrospective, have a celebration and say goodbye to that work. Look forward, not backward.


Portfolio Management Tip: 20

Start with Strategy and Paper

One of the problems I encounter in large organizations is that they want to see all the portfolios. They look for a tool first. Don’t start with a tool. Start with your strategy and paper on the wall. 


I have nothing against tools. However, all tools have one shortcoming: they don’t ask you if you understand the strategy, or if this work will help you implement the strategy or distract from it.


Once you have practiced reconciling your strategy with your current project portfolio, investigate tools and try one (or more). I find the discussions about strategy are more difficult than making decisions about the project portfolio.


Start Here with an Agenda for a Corporate Project Portfolio Meeting

I can’t provide you with the definitive agenda for a corporate project portfolio meeting. That’s because some of you are in the midst of market change or internal change. Those changes will require you to change how you work. I recommend you start here and adjust it to your needs.


Portfolio Management Tip: 21

Before the Meeting

Decide who you need to invite. This is a decision-making body. I’ve seen names such as “Operations Committee,” “Project Management Office,” and “Senior Management Team.” I don’t care what you call yourselves, as long as you can make decisions about the corporate strategy.


Explain to everyone what they need to bring to the meeting. Make sure every business unit provides paper versions of their current project portfolio. See Show the Work Now.


Do you have a need for everyone to provide the information in some way? You might need to see what is in Advanced R&D for each business unit. See Decide How to Manage Advanced Projects.


Ask everyone to provide their driving force and the mission for the business unit. Decide how much beauty you need in these displays. I ask people to use large stickies or cards on the wall. I specifically ask them not to spend much time making the cards beautiful. This is preparation work. I liken it to paper prototypes.


Portfolio Management Tip: 22

During the Meeting

1. Explain the state to everyone.

I ask people to walk around and spend up to ten minutes per business unit, reviewing the contents of each board. If you have many business units, you might want someone to brief the room, spending no more than five minutes explaining the board contents.


If you need more than five minutes to explain your board, consider the level of work you are explaining. Are you detailing all the fixes, each in its own detail? Or do you have a project labeled “Fixes,” or can you integrate fixes into “Project A and Fixes”?

Make sure each business unit clarifies its position: mission, principles, and current project portfolio.


2. See where you have disconnected.

Is one business unit spending more time and energy on something another business unit ignores? List all the disconnects. List all other concerns, such as “I will need that product in time for Q2, and you folks aren’t starting it until Q2.” Capture these disconnects and concerns on stickies.


3. Bucket the disconnects and concerns.

  • I have used these categories for disconnects and concerns:
  • Strategy differences. We disagree with the strategy, which is why we have a problem here.
  • Timing problems. Your results are too late for me. We need to address this and possibly transform these projects.


Other problems. You may find that you discover other challenges. When you group stickies together as an affinity group, you can see patterns. Those patterns might help you see possibilities.


Affinity-group and name these groups. If you wrote the disconnects and concerns on stickies, you can affinity-group all the problems. I always create the buckets of strategy and timing. Some teams discover they have other problems such as obstacles.


4. Resolve the strategic differences first.

Strategic differences affect the entire organization. Resolve those first. You might need some of the facilitation or project portfolio questions in blog 6, Collaborate on the Portfolio. You are deciding on how to implement your strategy. You all need to collaborate to do so.


5. Solve the other problems next in order of importance.

I find that the buckets are not the same importance. I discovered that if we fix the most urgent challenges, we have fewer/none of the remaining challenges.


6. Decide on the view you want to provide the rest of the organization about the relative priority of the projects for the organization or each business unit.


Do you need to provide a single view of the project portfolio for an entire organization? To be honest, I don’t know how to provide enough detail without making people berserk. I do understand how to explain a business unit’s work, but not an entire organization once you have more than a few business units.


Portfolio Management Tip: 24

Decide How Often to Review Your Corporate Portfolio

If your teams work in an agile way, they will make substantial progress every month, never mind every quarter. How often should you check your strategy?


In my experience, startups and small companies need to review their corporate strategy and portfolio more often than larger organizations do. Make sure you are doing work that advances your organization, not staying in place.

  1. If you are in the midst of a disruptive change in your current strategy, you also need to review the strategy and portfolio more often.
  2. If you are not in the midst of disruptive change, consider a three-to-six-month review of your strategy and portfolio.


Here are my guidelines (not rules) for changing your strategy:

Do not try to overhaul your strategy every three months. That is too much change for the organization. Instead, consider how you can make the smallest possible change to nudge the organization toward the direction you want.


Once you have a reasonable strategy for each business unit, see how to use the project portfolio to nudge changes. If something disrupts your industry or market, feel free to redefine your mission and driving force.


Then, update your strategy and ask people to deliver running, tested features, so you know the work is done. You can then try experiments.


Experiments have a hypothesis or supposition, measurements, and a timebox. Let’s look at some examples of experiments. Say you want to experiment with different payment transaction systems for one product. You’ll experiment with one product before expanding all products to use these transaction systems.


For Product 1, you integrate five different payment systems into the buying experience. You measure at least this data:

  1. The number of people who click to add something to a cart.
  2. The number of items in carts. You might have to measure the median as well as the minimum number of items and the maximum number.
  3. The pages where people spend the most time.
  4. The number of abandoned carts.
  5. You might have more data to measure.
  6. Measure this data each day or week, depending on your transaction volume.
  7. At the end of your timebox, you assess the results. You have several choices:
  8. You have learned what you want from the experiment. You end the experiment.
  9. You have more questions. Decide what data to collect and how long to let this version of the experiment proceed.


If you are not sure of something, experiment. Make certain you decide on your hypothesis, your measurements, and your timebox so you can know if you have enough data for your decisions.


Portfolio Management Tip: 25

Evolve Your Portfolio

When you shift the focus from “project” to “running, tested features,” you’ll change what your project staff works on. Instead of planning for the future, they plan for the now—to get to “done,” whatever that means for their project.


You’ll find that the management focus changes as well. The way you use and manage your portfolio will be different. You’ll begin to apply a lean approach. Lean approaches work well when you’re having trouble deciding which project is number one. With lean, you don’t have to know about projects; you only need to rank features.


Instead of having to manage the relative ranking of projects, you can manage the portfolio as a backlog of related features. All you need to know is the relative value of each feature and approximately how long it takes your team to finish a feature.


Of course, you do have to do a little strategic planning all the time to make sure your vision and strategy match what you’re asking the team to do. You’ll find that it’s easier to plan a little, do a little, check that it’s all coherent, and replan than it is to have to cancel an eighteen-month project that no longer has any value. Right?


Portfolio Management Tip: 26

Lean Helps You Evolve Your Portfolio Approach

If you don’t have to think about projects anymore, you can use lean and agile approaches to making the portfolio decisions. With the lean principles in mind, you can see that organizing work as agile projects and using pull approaches to organize the work, provide you with the maximum flexibility in managing the project portfolio.


Review your portfolio. Do you see projects that are contributing to waste, rather than removing wastes? Sometimes that waste arises from how the projects are organized. For example, if your projects are based on everyone multitasking all the time, you have tremendous waste.


If you try to define all the requirements up front and implement across the architecture instead of by feature, you will have waste. If the project team does not think in terms of value and finishes the most valuable features first, you will have waste.


If you’re not sure how to apply lean principles to your projects, try stabilizing something about your project work, such as the timebox, queue length, item size, or cost per feature. But you can’t use a waterfall lifecycle at all; a serial lifecycle won’t work.


You may be able—with a lot of work—to modify an iterative or incremental life cycle if you keep whatever you’re fixing to a small size. If you’re going to do that, why not use an iterative/incremental or agile life cycle? Agile lifecycles match lean principles. The other lifecycles don’t.


When you choose to stabilize something, such as the timebox, queue length, item size, or cost, you rarely need to make a big decision (Never Make a Big Commitment). And you can avoid having projects.


That might seem like a strange thing to say in a book about project portfolio management, but hang in here with me a minute. If you can deliver value every week or two or three or four and have a releasable product as you deliver value, the idea of a project may not make as much sense anymore.


Instead of thinking about projects, you can think about releases: internal and external. If your external releases are always the same as your internal releases, you don’t need to be tied to projects. Instead, you can work based on a fixed time, a fixed size of work, a fixed queue of work, or a fixed cost of work.

Deciding what to stabilize can be tricky.


Portfolio Management Tip: 27

Choose What to Stabilize

To decide what to stabilize, look at your work now. Are you already working in timeboxes? If not, start there. Projects using any lifecycle can use timeboxes. Moving your projects to work in timeboxes is the easiest start at working to deliver small increments of value that will allow you to reassess each project fairly as you manage the portfolio.


Once you’re working in timeboxes, are your teams able to meet their commitment to what they intend to accomplish in a timebox? My experience is that until teams are allowed to work together for several iterations without changes to the timebox’s content or team makeup, it’s impossible for a team to accurately estimate what they can accomplish in a timebox.


If your teams are having trouble meeting their timebox commitments, consider stabilizing the item size.


Once you can reduce item sizes so they are relatively small, you can move to a fixed-size queue of work. Then it won’t matter what project your team is working on.


Stabilizing a feature cost requires small item sizes because it’s impossible for a team to accurately estimate large chunks of work. Short timeboxes help you fix a particular cost and help project teams predict what they can finish in a timebox.


Joe asks:

How Does This Work for Hardware Projects?

Just as I explained in Incremental Funding for Hardware, it’s a little more difficult to make these ideas work for a product that has hardware as a piece of the released product.


It’s not impossible. Fixing the timebox is easy. Fixing the cost per feature is easy. You may want to conduct another portfolio review meeting just before you commit capital equipment or non-recurring expense (NRE) money. But for the bulk of development, this works for hardware projects as easily as it does for software. 


Portfolio Management Tip: 28

Stabilize the Timebox

When you use an agile life cycle, you define the timebox duration at the beginning of a project. Use the same starting day and duration timebox for each team so you can decide the following at the end of each timebox (or at the end of every x timeboxes): how much value is left in continuing this project (or work or collection of features)?


You can use timeboxes in any life cycle. Timeboxes are ideally a week or two but can be as long as four weeks—any longer, and people lose the focus the timebox provides. You’ll find that shorter timeboxes require little planning, certainly less than a couple of hours. You will use a sequence of timeboxes to help people build a rhythm. 


If you move an entire organization to work in timeboxes to decide when to release, make sure the teams meet these conditions: Know what “done” means for each feature. Teams cannot predict and measure velocity if they don’t define “done” for each feature.


Every team must have running, tested features at the end of every timebox. If a team can’t complete some specific independent feature in a timebox, that might be OK. It’s not OK if they break the product.


At the end of every timebox, the product must be releasable. That allows the project team to have a stopping point, which mentally frees them to work on the most valuable project next, whether it is this one or not.


Management and the product owners must agree on a minimal set of releasable features. If management and product owners don’t agree, you will never release a product to your customers. Well, you will when some senior manager yells, “Ship the damned thing already,” but that’s not a planned release.


Timeboxes must be short enough so a team doesn’t fall out of its rhythm. That’s a timebox of no more than four weeks, with a releasable deliverable at the end. If a team loses its rhythm, it ceases to be productive. Just because you have a timebox does not mean the team will maintain its velocity.


When You Can’t Stabilize the Timebox

If you have to integrate software or hardware from someone else and they are not accustomed to working in timeboxes, you may not be sure how to maintain your timeboxes. In that circumstance, you might be able to maintain a timebox for your work, but not work for the entire product.


For example, at the beginning of a timebox, you might assign some tasks that say “Work with a drop from vendor” without a specific size attached to it. In addition, you may have to change your definition of what “done” means for the end of a timebox.


I can’t think of another reason to not be able to maintain a timebox. If the technical staff overcommit to work and can’t finish all of it in a timebox, reduce the duration of the timebox so that they can learn to estimate how much work they can do in a shorter period of time.


Portfolio Management Tip: 29

Stabilize the Number of Work Items in Progress

Fixing the work size means fixing the amount of work in progress. That can work on two levels: the number of tasks in the process for a given project, what I’ll call kanban-in-the-small, and the number of projects in process, what I’ll call kanban-in-the-large.


Kanban is a system of seeing the work in progress and knowing when it’s time to put more work items in the queue to be worked on. Kanban literally means a signboard, as in Toyota Production System. The team can see the work in progress—one feature and the work yet to do, all on one board.


For example, in all serial life-cycle projects, you have a list of features. Most iterative and incremental life-cycle projects have a similarly long list of features. That feature list changes and tends to grow the longer the project is.


In agile projects, there is a product backlog that is reranked for each timebox, and the team takes the next chunk of what they think they can complete off the backlog.


Why is an MMF so important? It’s because that’s the basis of project portfolio management. Projects don’t matter; the set of MMFs you are ready to release is what your customers buy, as we discussed earlier. A completed MMF provides value to the organization.


When a team uses a kanban system, the team limits the number of tasks in progress at any time. At Agile 2007, Arlo Belshee described what he called naked planning, a way to limit what the team sees to no more than seven MMFs. The team works on one MMF at a time.


There is no minimum or maximum feature size, but the customer who requests the feature tends to ask for smaller features to limit the time the team is unavailable to work on new features.


You don’t need to have a queue of just seven items as Arlo describes. Your queue can be of any size. The key with kanban is that enough people work on one MMF and complete it before taking another feature of the queue. 


With kanban systems, your project team can even work on multiple MMFs as long as the team can release the product once one MMF is complete. This means the team has to have great source control so the team can work on multiple MMFs and still be able to release as soon as one MMF is complete.


To use kanban effectively, the team must keep a sustainable pace, and someone (or some defined set of people) decides what the ranking of each waiting item is.


But the team doesn’t care what they work on. They just take the next item off the list. That’s why you can use kanban for projects as a whole to manage the whole portfolio and for a given project to manage when you complete each feature.


Portfolio Management Tip: 30

Fix the Number of Tasks In-Process, Kanban-in-the-Small

One way to avoid projects but still manage the portfolio is to stabilize the number of feature sets in the process. Here you can see that one feature set, a minimally marketable feature set, is in progress.


That set has seven tasks. Of those seven, four have not yet been started, two are in progress, and one is done. Once all the tasks are complete, the team can release the MMF.


When you stabilize the number of in-process tasks, especially if you are able to define a minimum marketable feature set as a relatively small number of tasks, you see a number of benefits.


With so few in-process tasks, people actively work together to complete tasks. Projects complete faster because there’s no (or at least less) wasted work. Because you’re implementing by feature, the team and you can see the project’s progress easily.


Fix the Number of Projects In-Process, Kanban-in-the-Large

Some management teams, even when they’ve ranked the portfolio, have a difficult time assigning teams to just one project until that project is complete. But aside from the benefits to the team of avoiding multitasking, you receive a ton of benefits by fixing the number of projects underway:


You know you are never going to starve a project of its necessary people. That’s because you never assign more projects than you have teams. The teams all learn all the projects. You don’t have to worry about cross-training because the idea of specializing in types of projects goes away.


 Developers (or testers or writers or whomever) never have to worry about projects that are like albatrosses. That’s because the team has responsibility for the project, not management. And the team may not be assigned to this project each time a particular product needs more work.