Introduction by Planview AgilePlace COO Jon Terry
As many of you know, we’ve been working for a while to develop a new version of Planview AgilePlace that, among other things, will allow our customers to manage their enterprise projects and portfolio with a hierarchy of multiple levels of kanban boards. Some of you might have seen a demonstration at a conference recently. We’ve been on the road — a lot. And we began upgrading beta customers to the new functionality several weeks ago, gave everyone a sneak peek, and announced the schedule for upgrading all other customers just yesterday. The feedback has been fantastic. People are really excited, and, of course, we are, too.
What perfect (and we promise, completely coincidental) timing to have the latest submission in our guest blogger series arrive today, with a topic of portfolio management with Kanban. The author, Pawel Brodzinski, is a long-time friend of ours from the Kanban virtual and conference community. He’s a frequent (and extremely effective) speaker at Lean-Agile conferences around Europe and the world. We saw him speak recently in Madrid on how best practices in Kanban often (usually) emerge from evolution within the teams rather than a top-down approach. And, we’ve been reading with great interest his articles on his own experiences with implementing Kanban as a portfolio management approach for a development organization of more than 100 people. We’re very excited to have him write something specifically for us on this topic — especially since it fits so well with what we are working hard to provide for our customers.
Portfolio Management with Kanban
Using Kanban to deal with a project portfolio is a concept that is becoming more and more popular these days. One could question whether Kanban brought to portfolio level still fits the definition but, as you may know, I’m not orthodox when it comes to semantics.
Anyway the first question that pops up is: why? Why use Kanban to organize a project portfolio, aside from the simple fact that it is possible?
Definitely one thing is visualization. The power of having a concise view of the information for all the projects happening in an organization is hard to overvalue. Actually I’m not going to try to convince you to that. I just ask you to run an experiment: use visualization for your project portfolio for a couple of months and then see whether it helps you. Or rather how much it helps you.
With a visualized portfolio your everyday project-related decisions are more informed, thus very likely better. It also reminds you over and over again about these less important pieces of work that your organization is committed to, even if they rarely hit the headlines.
Another benefit will be the change management mechanism that you get from introducing Kanban. I’ll be honest with you, though. As Kanban at the portfolio level is still sort of immature, expecting that it will steer improvements there is more of an educated guess, based on our knowledge of Kanban applications in different areas, than a proven truth.
Personally, I’m using project portfolio Kanban and I already see improvements happening. However the domain of the problem is so wide that it is hard to find and describe general patterns of improvements or changes. In other words, Kanban on a portfolio level is more of an ongoing experiment than a proven tool that produces predictable results.
A reason that might also be true in some cases is convenience. If you’re using one of the available software Kanban boards for your teams, you already have a lot of information there, so adding another layer – the portfolio one – comes at a small cost and yet it can give you valuable information, if nothing else.
Despite the fact that the general expectations from portfolio Kanban are somewhat similar to those for Kanban on a team level, the implementation is different.
The first challenge is to decide the granularity of items we want to put on the board. Projects, by their nature, can vary a lot. If you work in an organization like mine, a project can mean anything from a couple of months’ work for 2-3 people to undertakings involving 25+ people for more than a year. If we brought this to the scale of team level Kanban it would be like having tasks that takes anything between 1 day and 4-5 months. Crazy, isn’t it?
It is a bit easier when you work in product organization as then the size of “projects” you put in your backlog is under your control. You can for example use epic stories, minimal viable products, etc. You don’t necessarily have this comfort when you work on custom projects; their size is driven by your clients.
Once you’ve decided on what exactly you are going to put on the board (most likely some sort of representation of projects or products in your context) the next decision is what data you want to track on your portfolio Kanban board. Again it will strongly depend on the type of work you do in your organization.
Design of the board itself, in context of project portfolio Kanban, is a big challenge. Using a typical board design seems to be a pretty natural choice, and this is exactly the design I started with. However, such design doesn’t prove to be very useful in the long run, especially when an index card represents a bigger chunk of work. After a while you realize – nothing is moving.
This is why it is worth remembering that we aren’t forced to use any specific board design and alternatives will often work better. In my case the board was completely redesigned so it presented important data in more accessible way. It also meant that index cards started to look and work differently than on a typical Kanban board.
The struggle to develop the optimal board design has an important goal – limiting work in progress. As WIP limits are what steers positive changes when we use Kanban on a team level, we’d also want to see similar impact on portfolio level. The problem is that, because of the huge variability of projects sizes, limiting WIP simply by limiting the number of projects that are concurrently built rarely works.
This is why you should keep WIP limits in mind when designing your portfolio level Kanban board. The approach you end up with may vary. In smaller organizations it may be possible to build two-level board which covers both work at the portfolio level and tasks at the team level. In this case, limiting WIP is pretty straightforward. On the other hand this approach doesn’t scale up very well, as eventually such board becomes overcrowded and its value quickly deteriorates.
With separate a portfolio board limiting WIP won’t be that simple, thus I stress: keep it in mind when designing the board.
Even if initially you don’t have all the answers or you’re still looking for sensible board design there is much value in experimenting with portfolio Kanban. Visualization is a low-hanging fruit. Availability of basic information about all the projects in the organization is improved. Transparency of what is happening is better. Remember: you aren’t doing it just for PMO. Team members are also interested what is happening in different teams.
A portfolio level board is a power tool in terms of middle-to-long term planning. It should signal your capabilities telling you how much you may commit to. As long as the board is kept up-to-date it likely is the most user-friendly, and yet reliable, tool you may use when planning new engagements.
Finally, if you are able to make WIP limits work for your portfolio-level Kanban, this should work as an improvement vehicle as well.
Sounds interesting? Why don’t you try in your organization?
![A Global Collaborative Work Management Blueprint [Video]](https://blog.planview.com/wp-content/uploads/2019/07/A-Global-Collaborative-Work-management-blueprint.png)
