The “Project Portfolio Kanban” regularly comes up in my interventions. Too often misunderstood, this activity that ultimately doesn’t demand as much effort as one might think can be very structuring for the organization and bring a lot of value. I’ve often been able to present it and I realized that I hadn’t really formalized it for this blog. Objective of this article: to show you how I approach a “Project Portfolio Kanban”, at least the first but main steps. What is a “Project Portfolio Kanban”? (from now on I’m taking liberties with the literature on Kanban and I’m giving you my experience, my knowledge). It’s the project portfolio of the organization, department, team, represented in a visual way, which will align everyone, communicate in an equal and direct way to all, push to govern, to improve.

So it’s about displaying and governing the macro project activity (or less macro) of an organization.

Here’s how I do it in situ. My three reference points, my reading of Kanban:

• Show reality and only reality
• Adapt capacity to favor value and learning concerning your strategy.
• Adapt as best as possible to capacity and involve with a pull flow

(I’ll try to address this third “rule” in an upcoming article, this one is limited to the first two).

But when should you create a project portfolio Kanban?

When there isn’t one. When you need governance because the scope of the activity requires it. When you ask yourself this question.

Display your activity

A Project Portfolio Kanban is within everyone’s reach. You just need to start in the simplest way in the world by asking everyone to stick on the wall a project card on which each person is working. No duplicates. No post-its, it’s a small card on which we’ll add information later (but you can start with post-its no problem). Simply put on the wall all the projects on which the organization is working. It’s up to you to decide the size of these projects, they can be of very different sizes, no problem, you can mix large projects, and small projects, and evolutions, and others. I’ll address this point more in the second part. Feel free as long as you respect reality.

This seems silly. Just display the projects on which each person is working. It’s already disruptive. You take a morning to collect all this information. You already have it? Good. So from now on every project or product conversation concerns an element that is on the wall, do we agree?

I won’t insist on the importance of the wall, yet it’s fundamental

a single wall, tactile, that aligns and shares knowledge. You’re all on different sites? The Project Portfolio Kanban will serve to govern, put it on a wall accessible to as many people as possible, on the site of the people who govern. They’re on multiple sites? I hope they meet regularly.

A bit of organization

Well rather than this shapeless heap you’ll quickly give a dynamic

of reading and value creation (from left to right) by simply adding

to do, in progress, done. I imagine this step doesn’t take much time. (You can click on all images to enlarge them).

But to do, in progress, done is quickly too succinct. And not very representative of reality, and it’s reality that interests us. For this it’s worth going to interview everyone about the project or product flow and place the right steps. That’s why it becomes very important to remember this first essential rule: Show reality and only reality. Indeed from this step it would be easy to project oneself and put what we want. This is the surest way to kill your Kanban. If it doesn’t show reality, it doesn’t align anyone, it shows nothing real, nobody gives it importance. To align a group of people, to create resonance as Daniel Goleman tells us in the excellent “Primal Leadership”, it’s important to share a common and clear vision of the state of affairs of the team, department, organization. This is already what your Project Portfolio Kanban does.

Here I had fun taking a somewhat hybrid and non-agile project process. It doesn’t matter for Kanban whether it’s Agile or not. We show reality and only reality. To all the questions you ask yourself when creating a Kanban it’s the most relevant answer: display reality. If the Kanban shows reality nobody will refuse the conversation. Regardless of the name it bears.

Reality, only reality.

How many elements?

I’ve observed that a Kanban accepts at minimum around thirty elements (no precise rule, just an empirical measure), below that, the elements won’t have enough dynamic. And therefore not enough sense of progress to feel engaged. It’s probably time to think about a finer breakdown of elements: but again only if it corresponds to a reality. If you modify something on the Kanban you should immediately modify it in reality (so rather one thing at a time…). If you have fewer than ~20/30 elements and the slowness of the Kanban’s evolution demotivates you, it’s probably just a reflection of what’s happening in reality. Things aren’t moving forward enough, you’re probably working in blocks that are too large. A maximum of elements? It all depends on the size of your wall, but I’ve observed that beyond 150/200 elements it starts to become too much, like a baroque Christmas tree.

If we’re talking about projects, and each card represents a project of say 4 people (it’s a hypothesis), we can easily manage 100 projects and therefore an impact on an organization of 400 people. That’s a good start, right?

Start governance

We can start by clarifying governance and splitting our Kanban (our visual management) into horizontal lines. This breakdown could be by business domain, by geographic zones, by activities, by project types… These lines will reflect your strategic organization, how you think about your activity.

For example a sales cycle for a contact business department with columns: meeting1, presentation, meeting2, etc. And the horizontal lines: Europe, Americas, Asia, etc.

For example an HR department that manages all its activity on a Kanban with columns: ideas/requests, selection, in progress, etc. And the horizontal lines: Recruitment, Social Affairs, Employee Monitoring, etc.

For example, projects of legal types, innovations, etc.

For example, for Spotify fans, Squad 1 domain XXX, Squad 2 domain YYY, etc.

Electronic versus physical

By the way, in my fictitious example, which I organized with horizontal lines by business domain, each line can have specificities by column as indicated here (on the image above, the “agile” and “agile/devops” spaces for certain domains). To this day I haven’t found any electronic tool that can reproduce this subtlety. And naturally no electronic tool that creates this group resonance. To the question electronic or physical, the answer is simple: both. Because both bring facilities and dynamics. Both complement each other. Then people answer me “Oh my my, it’s long”. But it’s just a false intuition. We’re talking about a Project Portfolio Kanban. We’re talking about say the 60 projects of your company. How many cards will change columns per day… 5 would be huge. I grant you an extraordinary 10. 10 cards to move per day. 2min? Double the information in the tool. 5 more minutes. All in less than 10min per day. We can even duplicate the physical Kanban (at 3 walls synchronized it becomes more difficult).

And it’s difficult to render an example of a visual and tactile wall on an image through a browser…

Naturally and at the risk of repeating myself, I start with the physical Kanban. It’s the master Kanban. The electronic Kanban complements it.

But where to place it? I repeat: it’s the project portfolio of the organization, department, team, represented in a visual way, which will align everyone, communicate in an equal and direct way to all, push to govern, to improve. It should therefore be visible, accessible, but also large (tactile, encompassing), and not far from the people who manipulate it and who govern. A large room at the entrance to your offices? On a large wall in your open space? We’ll try to avoid closed offices, or hallways without perspective.

Clear rules

To facilitate involvement and initiative-taking it’s necessary to have clear rules. Clear rules allow everyone to invest optimally. In Kanban we often specify, but only if it’s reality, or if we decide it becomes reality, we often specify who owns the column, who is responsible for it, who can manipulate the elements. A person, persons, a group, a department, everyone etc, reality only reality. It’s often good to specify these owners, these responsibilities, these accountabilities. At least it’s clear, and everyone can take ownership of the information, project themselves, invest themselves.

Same, it’s often valuable to specify the exit criteria from one column to another. Establishing this protocol clarifies the ins and outs. You can only specify it here and there, not necessarily everywhere. And always: reality, only reality. The addition and clarification of exit criteria often occurs when a card goes into a column, then returns to the previous one, or even several times. Yes I allow a backward move (it’s a debate in the Kanban community).

Not necessarily readable in the examples, you can apply responsibilities and exit criteria by block. However, be careful that reading your Kanban remains simple. It’s this compact, synthetic aspect that facilitates everyone’s connection to a central and shared element. It’s the pattern vision, macro, that best helps your intuition (all the experience you’ve accumulated and that speaks without words) to make decisions. We know that all decisions go through a part of non-rational emotional intelligence. Don’t try to avoid it, work with it.

Let’s take a step back

We end up with a large wall board that tells us where we’re working, what the densities are, what the voids are, what the balances are between my different domains. At a glance I see the dynamics, the inertias, the anticipations, the densities, the lacks, the voids, the overflows, the choices, the work in progress, etc.

The project card

All this will be enriched with the project card. Each card as I told you is not a post-it, rather a quarter of an A4 page that will gather the main descriptive elements of the project. Don’t write literature! For this very reason point to your references in your electronic tools, put on the card the essential elements that will allow governance, arbitration, make weak or strong signals appear.

For example here I display the estimated deadline, the number of people assigned to the project, the estimated budget, the project type (if the horizontal lines don’t take this meaning), etc. In the actors box we specify sponsors, roles, etc.

Very important I display at the bottom of the card the entry dates in the different columns. This is NOT a projection, reality only reality, it’s when the card moves that I write the date on it. This will give me valuable indications on inertias, lead times, etc.

Let’s take even more of a step back

I now obtain a physical board that nobody can elude, avoid, on which everyone aligns, shares the same vision.

We see the densities, the inertias, the voids, the dynamics, the weights, the loads (with the cards).

We see the connections between projects, the dependencies, what’s arriving, who’s working on what.

We see when a person is present everywhere.

We see fossil projects, fictitious projects, dinosaurs and other menagerie animals.

We see decisions: what density for domain 1 projects? and what density for domain 2 projects? how many domain 3 projects are ready to start? etc. All ideas are welcome, the “dumpers” at the entry (ideas, requests), and at the exit (live/prod) can accommodate as many elements as you want. But what’s the point of putting a 66th idea in the “domain 1” box if 65 are already waiting? Prioritization is required, etc. Kanban is making reality visible sharing this knowledge, and being pushed to improve and govern.

Limits

The story of Kanban could start in an old Tokyo park that the Japanese want to preserve. And for this, limit its access because beyond 200 visitors the park suffers. Kanban means ticket: it’s enough to print 200 tickets (or tags). When someone enters the park, they take a ticket. When all tickets are taken, it’s no longer possible to enter. When someone leaves they free a ticket. Capacity is adapted to the park. The flow of visitors is adapted to its preservation.

This is how limits also work in our Kanban: they can control the capacity of our project portfolio in such a way as not to bring in too many projects before having completed some and having harvested the value (as long as it’s not in production the value isn’t there) and having optimized value, performance (complicated word) by limiting the things we’re working on. We reinforce here a Kanban adage: start finishing, stop starting. By constraining the flow at certain places we force ourselves to have a more rhythmic flow, and often this promotes inter-column synergies.

A limit therefore indicates the maximum number of allowed elements per column or block or horizontal line according to your operating mode (or all at once).

In my example I can place a limit on an entire column (here 3 max elements for the “preparation” column, but my example doesn’t respect it at all, that’s baaaad! That said when you place a limit the first time you let the column “purge” until the application of the limit becomes possible). I can also place a limit per block.

Adapt capacity to favor value and learning concerning your strategy

How long does all this take? When to place limits?

Setting up the Kanban takes a few days maximum, say 1 to 3 days. Adding clear rules to it, a few more hours. Maintaining it, 10min per day (the real “work” is coaching, explaining, supporting around it, you can decide to do it alone, or not). The first month I let the Kanban live, someone spends 10min per day maintaining it. Or more if we decide to rearrange it because we realized that it wasn’t reality, or that it was starting to change under the effect of the Kanban. At 2 to 3 months I hope that the people in the columns have taken part in manipulating the Kanban. We’ll quickly imagine having a weekly 30min meeting (for example) on it to discuss focuses, bottlenecks, decisions to make, arbitrate, etc. in a word, govern.

For limits it’s probably longer. Their application can severely shake things up. I therefore tend to first let the Kanban live a bit. Seeing the reality of value creation (from left to right) teach us things beforehand. When you judge it good, place the limits, they must impact reality.

How to calculate limits? Vast debate. Observe and place something consistent with what you’ve discovered, and with your governance.

Low limits

In this new example I’ve placed low limits: instead of limiting the flow to dynamize its rhythm, I place low limits to ensure the existence of a flow. I need at minimum elements in preparation to guarantee the non-drying up of my implementation activity.

“Strategic” limits

More strategic, more difficult to manipulate limits by horizontal line, they indicate the weight, the capacity you globally accord to each line. Very often these aren’t limits here, but rather teams that we assign, or groups, capacity, etc. There we have 3 teams, and there 4, etc.

Emergencies

When we talk about “limits” we quickly talk about “emergency”. Kanbans of this type are used in hospitals. Difficult to announce to a person affected by a hemorrhage that, sorry, but the service has reached its limit. So be careful with limits: for many it’s the key to Kanban, but it’s also a very structuring element. In my eyes not mandatory. But very powerful.

Anyway, despite limits it’s often relevant to have a horizontal line dedicated to emergencies. Emergencies that we’ll limit themselves. If everything is urgent, there’s no emergency.

Synchronization moments

As mentioned above, and here I fall back into Kanban literature, there are several synchronization moments.

Weekly global vision meeting

Probably a weekly synchronization and strategy meeting: here’s where the focus is, here’s the key element this week, here’s the action that takes priority, etc. With everyone, in front of the Kanban if possible. I recommend 30min or even a bit more. This is what Holacracy calls an operational meeting.

Monthly improvement meeting retrospective style

Like the Scrum retrospective or the governance meeting for Holacracy, it’s the moment when we can change the organization, seek to improve points, propagate learnings, etc. It’s about optimizing the system.

Daily Scrum-style meeting

As always it’s important to meet daily in a team. What Holacracy will call the stand-up meeting. Everyone inspires everyone.

Communities / Circles

By domain, horizontal line, or however you want, there are probably also synchronization moments between circles (Holacracy), or communities of practice, peer-to-peer learning, etc.

To conclude this first part

First part or not, the essential is there. Imagine that a wall renders in such a perceptible and synthetic way your project portfolio. That everyone can see, perceive, engage, get involved. The Kanban only shows reality, it’s not contestable. All discussions very quickly rely on it. If your management or if your system is too complicated to be rendered in a Kanban of this type, it’s probably too complicated to be managed simply, and it doesn’t work. Otherwise Kanban is a real telescope, a real rudder.

The second part: project portfolio kanban part 2̀.