Pawel Brodzinski
Transcript
which leaves me a huge gap to learn and probably huge potential for frustration till tomorrow. I may either way end up doing it in English, I guess. Anyway, for this session, I want to cover the topic of portfolio management. And interestingly enough, recently, this is kind of an ongoing theme for me. When I'm talking with different organizations and they approach me, hey, Paweł, can you help us to improve the way we work? And they start talking about problems with their teams, engineering teams, project teams. And we quickly turn the discussion into discussing what they do actually have in their portfolios, their product portfolios or project portfolios. And we end up finding major problems there. So interestingly enough, no matter where we start, very frequently we end up talking about the portfolio level. And this is what this session is going to be all about. For those of you who don't know me, my name is Paweł Brudzinski. And my daily job is running a company, Lunar Logic. Lunar Logic is a web development shop in Krakow, Poland. And it's a very unusual web development shop. So we are a case of extreme self-management. So there are no managers at the company.
Besides of the stuff that we are building web projects, the organization itself inside is organized in a very, very different way. So if you... wanted to get some sense of feeling how it is to work with such an organization, you can always hire us. We are always looking for new interesting projects to build for our clients. I also run a blog, which you can find at bradzinski.com, where I cover topics that are interesting for me from a kind of professional perspective. So you would find stuff like portfolio management, you will find stuff like change management, which is a topic of my tomorrow session. You will find a lot around lean, Kanban, but also stuff like designing organizations, leadership. So these are themes that you can find on the blog. And finally, my Twitter handle is Pavel Brudzinski. I really do appreciate any feedback you may leave for me there.
So let me start with addressing a question, why portfolio? Typically when we are at Lean and Agile events, we are discussing teams, how to improve our teams, how to improve our engineering teams, project teams. Recently, a few years ago, we started also talking about scaling everything up. So we have teams and we want to scale that approach up. So these are like common themes of what I hear speaking at the international events. At the same time, my focus is much more narrow. I say, so let's look at portfolio management. Why is that? Well, if we focus on teams and teams only, even if we are if we choose kind of scaled approach, we would end up improving efficiency of only parts of the organization. And as Eli Goldratt famously said, system of local optima is not an optimal system at all. So if we're improving our teams and we don't pay attention to what work is worked on, what kind of projects or products we build, we may end up
doing efficiently what shouldn't be done at all. So this is kind of the ultimate waste, as Peter Drucker phrases it. And Stephen Parry phrases it somewhat differently. He says that delivering waste more efficiently is basically cheaper, neater, faster waste. Not really something that we would like to do. Now, I wonder why we are seeing so many problems when we are looking at portfolios of different companies. So why I end up talking with different organizations, I typically end up looking at their portfolios and finding problems there. And part of the answer is what Dan Kahneman defined as what you see is older is. So our brain works in a way that when we are about to make a decision and we have some data available at hand, we would use that data and make a decision. Even if We could easily dig for a little bit more data points and significantly improve our decision. So our brain is somewhat lazy, if you will.
And this is how our brain works in general. And by the way, if you haven't read Dan Kahneman's Thinking Fast and Slow book, go read that. This is probably the best book you can read if you haven't.
And especially this what you see so all there is principle and the tools we have when we are managing portfolio, we end up making many, many, many bad decisions. Because what kind of tools we have when we are looking at our PMOs? Well, we typically have something that I call Excel frenzy. Those humongous spreadsheets filled with numbers. And don't get me wrong, I have nothing against spreadsheets. I'm a pervert, I love spreadsheets. The thing is that this is the wrong tool to help us to manage portfolio. Not only the tool is wrong, and we'll focus on that in a few minutes, but also the content of those spreadsheets is misleading. Because what kind of data we have in those spreadsheets? Just imagine what happens when a new project, when you want to start a new project in your organization, or you start developing a new project, product. Typically the first thing that we check is we want to get some sense of expected cost.
So we would go to our development teams and ask them for an estimate. And I don't want to start a discussion about how we estimate, this is a whole different discussion, but they would end up providing a number or a range of numbers. So here is what we expect it would cost to build that thing. Now, if we're talking about a project, we probably want that project to be profitable. So we want to have some assumptions about revenue. So we would say, we will take the number from our developers, say a million dollars, and we'll be like, oh, so we want to be profitable. So let's sell it for, let's offer it to our client for 1.5 million. And what we end up with is a very attractive project to run. I mean, ultimately it's profitable. I mean, this is what we expect. So why shouldn't we start that? There is another version that is more popular in product development organizations, which is, oh, so we want to build that product or that feature set to our product. So again, we go to our engineering teams, we ask them, okay, so how much it would cost us to build that? And they would come up with a number again. And then the benefit side of the equation would be, we need to have that because our competitors do have that. So again, in a way, it's an attractive product to build. I mean, we don't even discuss the benefit part, but we say, yeah, we have to build it. I mean, like, we have to have it. So, no wonder that we end up with bloated portfolios doing way too many things. The other problem with this kind of decision-making process in the context of managing portfolio is what actually drives our decisions. So if you go again through those examples, you would end up realizing that we are talking about
Oh, sorry.
We are talking about the cost a lot. So we start with cost. In fact, in the story about the project, the benefit part is derivative of estimated cost. And note, it's not even a real cost, because that we will know after we finish the project. It's an estimate of a cost.
So we base a lot of our decisions on estimating and we kind of know that we are not that good when it comes to estimating. And oh, by the way, as Johanna Rothman points, if we choose estimation as a way of valuing our projects in our portfolio, we are literally doomed to fail.
There is another perspective to that, that is offered by Tom DeMarco and Tim at Lister. They say that we are pretty good at keeping people accountable for the cost part of the equation. But we are not nearly as rigid when it comes to keeping people accountable for the benefit part of the equation. So we start with this idea, oh, so we will build that product and it will prove to be super profitable. And then we are talking about being on budget and on time, all the time. You've heard it, right? But we are not nearly as rigid when it comes to validate whether promised benefits were delivered after all. And this is, by the way, something that is the outcome of our approach to how we manage our portfolio.
Now, this is Klaus Leopold, my friend and fellow Lean consultant. And so Klaus works with different organizations.
And he works in different contexts with those organizations, very frequently helping them throughout the board, including what happens in their portfolios. So there is a story from Klaus. So he starts working with one of his new clients. They brought him on board. To help them, you know, to deliver something, to help them to improve the flow of work. And as they are talking through their problems, they suddenly start at the board and they realize that in that organization, 25 developers are working on 113 projects concurrently.
How sane is that?
I mean, no sane person on planet Earth would think that this may be an efficient way of working.
And I bet that guys in that organization started every single one of those projects with goodwill. They thought that it is an attractive project to run. I mean, ultimately, I don't think that they just simply wanted to make the life of their engineers more miserable. I don't think that. They thought that each and every of those projects make sense. So they started it. And it means that there are almost five projects per person in the organization.
And there is an interesting story to back up that. A few years ago, I've been at Kanban Leadership Retreat, and there was like portfolio management was a common theme. So I started asking different people questions like, Whenever the topic popped up, I was like, so how many engineers are in your organization? So people would say 100. And how many ongoing projects do you have? And they would be like 200. So what I realized was that ratio, a number of projects to a number of engineers, was like anything between one and six. And note, these weren't just kind of random people from PMOs. These were who are supposed to be bleeding edge lean consultants. And their clients. So the situation is really, really sad. We are overloaded with a number of things that we are trying to run concurrently. And this was also my personal story. Several years ago, I've been with an organization, I was leading a team of 150 engineers, and I've had this gut feeling that we are trying to do too many things at once. So I figured that since Kanban was working so well for me in the context of teams, It might have yielded similar results in the context of portfolio. So this is how my story with portfolio Kanban started. So just to frame what I name as portfolio Kanban is I typically use Kanban method as defined by David Anderson as a reference point. So here are six core practices and four principles of the Campbell method. And I'm happy to have a long discussion how you would apply all of those practices in the context of portfolio management. But the important part is this.
The important part is there are two principles that say a lot about mindset. Start with what you have. Don't reinvent your portfolio. You can't, by the way, because all the ongoing commitments just agree to evolve away from the appalling situations that you are in right now. And there are two core practices that are pivotal for a change. So visualizing, I frequently say that visual management as a separate practice is this tool that allows us to harvest. hanging fruits. And this is true in this case as well. And finally, limiting work in progress, which feeds the evolution mechanism of Kanban. So let me start with visualization. When I started with portfolio Kanban, I obviously started with visualization that is based on what we would see in teams. So kind of flow-based board. So instead of work items like features, user stories, what have we, here we have projects or products or MVPs or feature sets or what have we. The problem with that approach was that I actually found that there is very little sense of flow. Because suddenly a work item, an index card on that board, is not something that we finish in a matter of hours or days. It is something that it takes months or quarters or even years to finish. Portfolio Kanban, I obviously started with visualization that is based on what we would see in teams. So kind of flow-based board. So instead of work items like features, user stories, what have we, here we have projects or products or MVPs or feature sets or what have we. The problem with that approach was that I actually found that there is very little sense of flow.
Because suddenly a work item, an index card on that board, is not something that we finish in a matter of hours or days. It is something that it takes months or quarters or even years to finish.
So there's little sense of flow, we don't see change on the board, so suddenly we stop paying attention to the board, we stop updating the board, and by that time it becomes useless. Not the best design I've seen, but it was like the first experiment I ran.
But my frustration peaked when I was trying to defend myself and my team from starting yet another product, and I couldn't find a way on that board to justify saying a no to that.
So in my frustration, I decided to trash all the sticky notes, wipe the board, and start from scratch. And this is what I ended up with, which is like very different board design. Here you see two dimensions. The vertical dimension are capabilities, in this case, teams. The horizontal dimension is the timeline. And what's here in the middle are all the commitments. And what's important in the context of managing portfolio is that commitments happen over time and they change over time. So we have projects or products that we run and then we stop building them. And all the white space on that board are available capabilities that give us information what on the top of what we have already in our portfolio, what else we can start. And then there is the left side of the board where we have all the potential things that we can work on. In this case, this is... One of the early versions is like super simple, but the upstream part can be also very sophisticated and have like a number of stages. So I validated that approach with a few companies and I thought, oh, so we may have something like a standard visualization of portfolio.
Except, not much later I started seeing board designs like this one. Like, this is the organization where deadlines are really important. Deadlines are really important. Or as Lee Skiog would say, sad lines. Because, you know, Nobody's going to die when they miss the date. It's just someone is going to be sad. So this is the organization driven by sad lines, and they really want to pay attention. So they designed their board so they literally see whether they are by the due date or they are late. So here the columns represent weeks, so again the timeline, and the projects are put in a specific part of the board to represent when the deadline was.
And we have kind of moving window of now. So everything that is to the left from now is already past the deadline. Anything that is right from now is due in the next couple of weeks. So this is a very different... Here is another one, this is two-tier portfolio board, which is fairly popular in product development organizations, where they are in control of how big chunks of work they work on. So each of the large stickies is basically a feature set or an epic or an MVP, and then it lands in a swim lane, and each swim lane is basically a board by itself, where the flow happens in the swim lanes. So this is another approach. And then finally one of my favorites, this is a board from an organization where visualizing flow was very important. The problem was that flow was non-homogeneous. In other words, for each project they've had a different flow of work. So they couldn't design a single flow-based board other than to-do, doing, done.
So they decided to go with something very different. So flow is described by those decorators, those small stickies attached to the big index notes.
And they show not only that the flow is different for each project, but also the status of specific stages. So the lesson to learn from that is that there is no such thing as universal portfolio Kanban board design. In fact, depending on an organization, it would end up with different designs. And why visualization? is so important then. So let me run a quick experiment with you. So here is a portfolio of a small company. There are seven projects run by that company, three of them being new projects, four of them being maintenance projects where there is kind of ongoing work, and there is one product run by that company.
And you have some numbers. You have estimated cost of building the product, you have expected income, you have estimated profit, you have even profitability, and it's even better because you also have information about person complete. So how big part of the project is already done. And we are in the 1st of January, we have also deadlines, all you need to know about portfolio of that small company. And you have a new potential project. Estimated cost, you went to ask developers and they estimated time, you multiplied it by the cost and estimated cost of the project is 400,000 euro. Which is a fairly regular big project for a Zet organization, isn't it? We have at least two projects of that size. Expected profit is pretty good, 250,000. Better than anything that we have on the board. There is one major risk, there is a tight deadline. We have only three months to build that project. The question is, should I... organization accept that project.
Does it look attractive?
Damn yeah.
Nothing comparably attractive in existing portfolio.
Thanks to what you see is all there is, if you're looking at something like that, I would like to say, let's try that. Let's totally try that. There's easy money laying on the table. So now let me present exactly the same data in a slightly different way. This is exactly the same portfolio visualized in this using this pattern where we present available capabilities and we try to balance available capabilities versus demand.
So now we see that we can hardly fit anything into next three months. So accepting that project would likely end up with seeing a huge screw-up in that new project, or a series of screw-ups in the existing commitments, or most likely both.
And note, it doesn't end up, when you end up in a situation when there are major screw-ups because you committed to too many things, it's not just that work
slips down the timeline, but also recovering from those screw-ups take additional time. So the same way where a traffic jam happens, it isn't enough to remove the obstacle that slows the traffic down. It takes time to get back to the normal rate of driving.
So this is exactly why visualization is so important and why it allows us to understand better the work we do. Now, I already mentioned that there are very different approaches to visualization. So now I can give you a bit of advice how to choose the one that would fit in any given context. And the guidance I can share is thinking about risk assessment. So when we are thinking about risk assessment in the context of portfolio, managing projects or managing products, we typically think about assessment in the individual context of this specific project, this specific product. We say, oh, so here there is connected to the team, here there is connected to the technology, here there is connected to funding.
Now, when I'm talking about designing portfolio board, I'm thinking more of risk dimensions that are relevant not to a single project, but to all the projects in the portfolio. So I'm thinking about, oh, we tend to overcommit. So we need to focus on how we balance demand versus capabilities. Or we are missing deadlines. We should focus on timeliness. Of our projects. Oh, we are having troubles managing dependencies between our initiatives, we should focus on that. So these are risk dimensions that are interesting. And earlier this year at Kanban Leadership Retreat, I ran a long workshop around portfolio Kanban, and one thing that we did during the workshop was discussing different risk dimensions that we face in our organizations. And a clear winner, no surprise for me, a clear winner was managing capabilities versus demand. And the outcome is like failing at that means that we over commit and we end up seeing those bloated, overloaded portfolios of projects. A runner up was managing dependencies. Between projects, then we've had managing different kinds of work. So planned versus unplanned work. So think classes of service in the context of portfolio management. There were more. So this is basically the outcome of the session. There were a few of really crazy Kanban board designs, portfolio board designs. So there are a few examples. And those examples we consciously focus on kind of less popular risk dimensions. So it is possible to define, to design different board to focus on a specific risk dimension that is most important or most painful to us. And this is exactly the pattern of portfolio board that we should be looking at.
Whatever is the most painful or most important risk dimension to us should be visualized as a structure of the board.
And we shouldn't be focusing on more than a single context. So if we try to put too much into the board design, we would end up with visualization that is incomprehensible. And if it's incomprehensible, it's going to be useless because we won't be using that to get the information that we need when we are making decisions. Remember, What you see is all there is. If you're looking at the board and you don't understand what's on the board, you stop using the information that is on that board. And one context applies to another thing as well, which is we should focus on only one granularity of work. So if you are thinking about large organizations where portfolio can be organized in different layers of work, so think you have feature sets, feature sets are organized in projects, projects are organized into programs, programs are organized into product lines. You have different layers of work. If you are working in such a context, you should focus only on one layer of work on a single board. So don't try to put there too many things at once. If you are dealing with different layers of work, just add one more board. Which by the way, may mean that when you are looking at a program board, so kind of the board with programs, you may end up realizing that a different risk dimension would be more relevant in that context, then a risk dimension would be relevant in the context of a project within a single program. So you may end up designing different boards for different layers of work.
And what to do with the other risk dimensions that we have? I mean, like, ultimately, we don't want to focus only on balancing demand versus capabilities. And just don't give a damn about deadlines, right?
We want to get this and that. So for other risk dimensions, we can use index cards. There are lots of things that we can code using decorators, using additional data on index cards, etc., etc., etc. So put on the visualization everything that is important for decision-making process, but from a perspective of designing the board, focus on the most painful risk dimension that you face. So visualization is this practice that allows us to gather those low-hanging fruits, that helps us to understand where we are, what kind of problems we face, and possibly gives us a hint where we are failing mostly. Now, there is also limiting work in progress. which is this mechanism that helps us to improve. The thing with limiting work in progress, besides the fact that many teams resist limiting work in progress in any given context, is that on portfolio level we deal with huge variability in size. So my common experience is that the smallest initiative run by an organization will be 200 times smaller than the biggest one. This is by no means a proper research. It's just a common theme that I see. So think of a project development organization, a smallest project that they run, a pair of developers who are working for a few weeks. They would call that a project. The biggest project that they have in their portfolio would be 15 people working for two years. We are talking about huge variability in size. Now, if we try to apply this kind of naive way of limiting work in progress, saying we don't want to have more than eight ongoing projects, we don't want to have more than four ongoing MVPs, we would end up exchanging one of those huge initiatives for one of the small ones. Doesn't make sense. Because once we are done with this huge project that required attention of 15 or 20 people, we can run a bunch of smaller ones.
And once we finish the small one, we cannot really start the huge one, right? So because of that, it doesn't really make sense to use this kind of hard working progress limit as a number.
How can we address limiting work in progress then? Well, there is this nice technique that is called Whip Limits by Conversation. It's like super lightweight, very straightforward.
It takes some time till you get really familiar with that and you get more value out of that. But it's really easy to start experimenting with that. So the technique is very, very simple. Whenever you are about to start something, whenever you are about to commit, to work on a new project, to work on a new product, you start a conversation, you start asking questions. What kind of capabilities we need to have to build that?
By the way, by the time you answer those two questions,
Most of the time the answer will be, oh, we can't start that. And you are done. But if it just so happens that you answer that, well, we need this, this and that kind of capabilities, and we do have them available, you go further. So how starting that new project would affect all the other commitments that we already have in our portfolio? So here we are talking about dependencies.
And then you start talking, okay, so we can start all sorts of things, not only that one thing, which one of those things we should start?
And sometimes you will end up in a situation where the answer is like, oh, we don't have available capabilities to start that new initiative. But then it won't be your decision to take. It will be like, oh, this is the biggest project in the history of the company, and this is our best client ever, and there is no way to say no. And then again, conversation that you have is about what can we do. So if we put that project in, something has to go.
which commitments we want to deliver on.
And then again, this is a way of prioritizing. Which of our ongoing commitments are more valuable for an organization and which are less valuable for our organization. So it all boils down really to prioritization, to prioritizing some projects over the others, some products over the others.
So when we are at prioritization, there is one gentleman you need to meet.
Who is familiar with Don Reinertsen's work?
You sir know nothing about Don Reinertsen's work. So I used to say that there are two kinds of people in the world. Those who are familiar with Don Reinertsen's work and those who should be.
One of the things that Don introduced to the world is cost of delay, which is a great mechanism to help us to figure out how to prioritize things.
So now I'm stressed because if I make a mistake,
I mean, someone would call that a mistake. So these are urgency profiles for different products. So what you see here are charts. The vertical line is benefits over time. The horizontal line is time. The red line is what we expect to get by delivering a product. The blue line is what we expect to happen when we deliver late. So on the left, and the orange part is basically a difference in benefits. So if we deliver late, we basically get less benefits. So on the left, the left chart is for a product that has short life cycle. So if we deliver late, the peak is affected, it's lower, and the decline is faster, which is kind of obvious. market starts declining, declining, and so our product sales are declining as well. So we earn basically less money. The right charts are for the products with long life cycle. The first one is where being late to the market doesn't affect the peak. Think Google search. I mean, they still won their part of the market despite the fact that they weren't early. The lower chart is for the product where being late affects the peak. Think Windows Mobile.
I mean, the game was over before Microsoft even knew that there was a game.
But anyway, the thing is that when we are trying to assess basically economical value out of our decisions, we should look at how big the orange area is. The bigger it is, the more potential benefits we lose. And by the way, cost of delay is kind of a neat trick that Don played on people because it's not really about cost, it's about the value. That is named cost of delay. So in this case, it's like kind of lost value.
But the reason is that if we want to figure out which initiative, which product is more valuable, we can do that assessment and try to figure out in which case the orange area would be the biggest one. There is an interesting realization when you are working in a project. open organization, which is that you would see cost of delay curves like that.
The thing is that if you don't have capabilities to start working on a project, your clients very rarely would wait for you. They are like, okay, you cannot start that project, so we will choose another vendor. So you may realize that there is a cost of delay of being late. Is not doing a project at all. But the general rule stays the same.
The bigger the orange area is, the more benefits we lose. So you can use that technique to prioritize things that you have in the backlog. There is another figure that is really important to Lean Kanban community and it is Stephen Bangay. And besides of all this stuff that he teaches us about leadership, there is one contribution to Lean Kanban community that's called the Spice Wells question. Which goes, tell me what you want, what you really, really want.
And this is a way of phrasing a question, what's the strategic intent of the organization? What's the goal number one we're trying to achieve here? Why answering that question is important? Because we may consciously decide that we want want to run initiatives that are aligned with achieving our strategic goal, even if economically there are other kind of unrelated initiatives would yield potentially bigger financial outcome. So understanding both of those sides, one, economical equation, and two, what are strategic goals and what's alignment of specific initiatives with strategic goals in an organization can help us to prioritize things. And then we may choose wisely what we work on and what we don't work on. Now, in most organizations I know,
even if we did prioritization well, we would end up with way too many things that we can work on.
So there is a nice technique that can help us to make some sense out of it.
This is capacity planning, something that is proposed by Chris Matz.
And I think this is not a final name yet. It's kind of a working title, so it may change. And it's basically an approach to plan the work once we prioritize the work. So once we did our homework and we know which products or MVPs or feature sets are more important than others, which projects are more important than others, capacity planning can help us to figure out how much we can chew. So we start with the prioritized lists of our initiatives. Then we do very rough estimation, something that Chris Matz calls swag estimate.
Swag goes from sweet wild ass guess. And it's purposefully, it's very rough. So basically, Chris Matz asked, so the exercise that product owners or product managers need to do is they need to figure out which teams will be working on building those initiatives.
Once they know which teams would be working on those initiatives, they need to go to those teams and figure out how many weeks, team weeks, they think it would take them to build that. And they put that on a list. So here we have all these field wireless gas estimates from the teams. So initiative alpha, team D, two weeks, team G, three weeks. Initiative Bravo, team B, two weeks, team D, two weeks, team E, four weeks, etc.
By the way, Chris Matz reported that when they first did that in Skype, and they allocated all the time in quarter because they were planning quarterly, and they delivered nothing. So the next quarter they cut the time available by half. So for a quarter they are planning only... six weeks.
So once they do have those estimates, they start planning in planning cadence, whatever that is. In Skype it was quarter, whatever that is in your organization, it would be here. And they start planning like that. So the first initiative was alpha and we've had our Swilled by us guests. estimates, two weeks and three weeks. So we put that in a plan. Then we go through the next one, then we go through the next one, and then suddenly, surprise, surprise, it's always faster than we expect, we end up in this situation. So the next project on the list doesn't fit.
What happens then?
We don't start that at all. We don't build partial feature sets. It goes back here. So then we can look through the backlog and try to find out something that would fit the white space, that would fit available capabilities. The thing is, that the way most organizations are organized is that there are a few teams that tend to be the core teams. They tend to be involved in like everything.
So there are very, very few things that we will be able to fit into our capacity planning board and more. So let me sort those teams by utilization for you. That's easy. if you have that prepared in your presentation, one click.
So we have a situation that is very common. Again, Chris Matz reports that around 20% of the teams will be fully utilized after that exercise. Around 20% of the teams would not be utilized at all.
And the remaining 60% would basically linearly go from 100% utilization to 0% utilization.
This exercise was basically starting with what's the purpose, then figuring out what within that purpose, what are the projects or products are most relevant or yield best results, and then planning against available capabilities.
We ended up having a lot of white space, a lot of slack. What we would do with that slack? Well, slack provides us with options. So one thing that we can do is we can look for ways to use those teams to help the other teams work towards strategic goals. The other thing we can look for the gaps. Why do we end up having teams that are almost not utilized at all? What capabilities they are missing? What capabilities we should build up? Also, we can use that Slack as A way of...
Using opportunities to pop up. I mean, we are on a preferential level, we are not planning for the next week. We are planning for the next quarter or next half a year or even longer. There will be opportunities on the way.
In either case, we can use those options to introduce continuous improvements, we can use those options to do a lot of different things. The thing is that most of the time, if we decided to use those available capabilities to build partial feature sets, partial products, partial projects, we would end up abandoning that work anyway, because in a quarter from now, in a half a year from now, the priorities would change. We would be in a different situation. So the discussion about WIP limits, and oh, by the way, the important part is, we just used capacity planning as a way of limiting working progress as well.
We just decided not to start some of our prioritized initiatives. So, discussion about work in progress limits in the context of portfolio management is a way to turn the discussion from cost, estimated cost, and expected revenue toward much more important aspects like benefits, risks, risk assessment, and options that we have.
And this is the way, and this happens by saying no. Because like portfolio Kanban is not about, basically not about choosing the work we do, but about choosing the work we don't do. And by the way, we do that one decision at a time.
We don't say, let's reinvent how we manage portfolio. It's just saying, oh, we cannot handle this one thing right now.
And with that, merci beaucoup.