When applying Kanban on project portfolio level you’re dealing with different challenges than in case of standard Kanban implementation on a team level (if there even is such a thing). Both the flow dynamics and task granularity is very different, thus you need to focus on different aspects when designing Kanban board.
This is basically why typical Kanban board design will often be suboptimal.
At the same time the biggest challenge you face on project portfolio level is defining and applying WIP limits. For the time being my thoughts on a subject are that depending on a specific environment teams would be choosing very different measures to manage WIP on portfolio level. However, as we as a community still lack experience from addressing different scenarios I’ll focus on the path I’m following. After all the story format I chose requires that.
In my case the most reasonable thing I was able to come up with was a number of people involved in project work. Unfortunately the scale of the team (more than 130 people) didn’t allow me to use straightforward approach and scale up WIP limits with numbers.
Instead of continuing my struggle to find a perfect measure that suits the current board I decided to redesign it completely.
Whenever you read about Kanban you learn that it is an evolutionary approach. Kaizen and all the stuff. However one advice I have on designing a Kanban board in general is that when you start running circles with board evolution and see little or no improvements throw the whole board out and start from scratch. From one point of view it can be considered a revolution (kaikaku) but from another: you don’t really change your way of working, you just try to visualize it differently.
Either way I took my own advice and started from a clean whiteboard. I also remembered another advice: not to stick to standard board designs. This is what I ended up with.
First, there is no value stream or process in a way we understand it on a team level. Since the flow of index cards wasn’t dynamic I decided this isn’t information I should focus on that much.
Second, on horizontal axis, instead of process there is a time line (monthly granularity). As variability of project sizes is huge I decided I need some sort of time boxes which I measure WIP against. With very few small engagements, ones that take us less than a few weeks, monthly time boxes looked reasonable.
Third, I created swim lanes for teams. We don’t have 130 generic engineers, or Average Full-Time Equivalents, or whatever other inhumane label you can think of. We have teams that we strive to protect and teams do have specializations. It means the context of a team is very important and if it is important it goes to the board, thus swim lanes.
Fourth, having such board construction I had to change my approach to index cards. Instead of having a single index card representing single project I ended up with territory-driven approach. A project covers a territory both in terms of team(s) and time. Looking at index cards with a project name you can instantly guess which team is working on the project and how long it’s going to take them. And the best part: a size of index card in any given month represents roughly how big part of a team would be involved in work on a project. This way we can easily show a few smaller projects as well as on big or any combination of those two.
Fifth, as one of Kanban base concepts is pull it is represented by backlog area – green cards on the left side of the board. These are projects that aren’t yet started. The specific swim lane they are neighboring show preferable team to work on a project. However, it rarely is such a direct dependency: this team will do the project as there is no other one suitable to do the job. Most of the time we assume that another team can build the project too. Each time a project goes into development we decide, at last responsible moment, which team will take it.
Of course there are some nice additional flavors here as well. Violet and yellow index cards differentiate maintenance projects from new ones. Green card are for projects that aren’t yet started and once they are we switch to yellow. Red index cards represent overrun in projects that are late. As we work on fixed price, fixed time projects we roughly know up front how much time and people we want to invest into a project. When something bad happens and this plan changes we show that. After all we put more attention to challenged projects.
A simple fact that we are working on fixed time, fixed price projects doesn’t mean our arrangements never change. They do. Any time something changes we just update it on the board, same as we’d do with any other board. We just keep the board updated as other way its value would diminish.
This Kanban board design definitely tells more than the initial one but I started this whole revolution to deal with WIP limits. What with them?
Well, there still aren’t explicit WIP limits. However at this moment there are implicit WIP limits and information about them can be pretty easily extracted. Considering that I use territory-driven approach to index cards WIP limit is show by vertical axis of the board. Each team has a limit of one full-sized sticky note (representing whole team) per month which can be split in any way.
In other words we won’t start another project unless there’s some white space that this project would fit into as white space represents our spare capabilities. Actually, it may be a bit of simplification as on rare occasions there are project we just start, no matter what. But even then we either can make such project fit the white space in a reasonable way or we need to make some more white space for it.
Even though such WIP limits aren’t explicit, after some time of working with the board I can tell you they do the job. They do, not only in pulling new projects into development but also, and more importantly, in long-term planning as we have visibility a year ahead and can confront our capabilities with planned sales etc.
With this board, for the first time from the beginning of my journey with project portfolio Kanban I felt satisfied.
See how we come up to this point – read the whole story.
Advertisement: Infragistics® NetAdvantage® for Windows Phone gives you rich, innovative mobile UI controls to build high-end mobile user experiences for Microsoft® Windows Phone®. Their high performance, eye-catching data visualizations, mobile form factor optimization, touch gesture support, and alignment with Metro usability guidelines take your social media connected mobile applications to the next level.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
21 comments… add one
Interesting change. But there’s something unusual (at least in my environment): your teams are separated static teams, aren’t they? Often in our projects, we take some people with skill A, some people with skill B,… to form a new team. Does that affect how we use this diagram?
Thanks for the food for thought, Paweł. As always with boards, I’m somewhat concerned about scalability. One question – how’s this information accessible to others, i.e. what’s the physical availability of this board in your case. Any reflections on this?
“At the same time the biggest challenge you face on project portfolio level is defining and applying WIP limits.” Enlightenment ensues. Thanks!
@Le Do Hoang Long – Teams are sort of static. I mean I see huge value of maintaining stable teams, where people can integrate with each other and they have a leader who can guide their growth as professionals. However, since we are working mostly on custom projects we often adjust teams to a current situation, moving people between teams (either temporary or permanently), temporary making one team a sub-team of another etc.
It may happen that one third or even more of a team is working with different teams on different projects. We even have a “project” named “Loans” which we use when significant part of the team is working with different teams.
I can think of a similar design with a completely ad-hoc project teams although in such case swim lanes would be changing pretty often. It might be a better idea to rethink the design of the board in this case as you don’t want to redesign the board too often.
BTW: How many projects you work on concurrently?
@Lech – This is actually the discussion I had the other day on Twitter. It boils down to this:
* You can only have that many items on the board and still keep it useful. Beyond that there’s information overflow and board can’t be comprehended by a single person, thus it loses its value.
* Given that you keep items on the board of the same size, the bigger the team, the more items you have on the board.
* It means that scalability of the board requires moving to more coarse-grained items from time to time, thus I don’t have features of a specific project on project portfolio board and just the projects themselves.
* Moving to more coarse-grained information also means that some people won’t be interested in information from the board anymore. For example a developer who is working on a single project for a year won’t need information on every project built by the organization on a daily basis. With different levels of the board you have different “clients” for it.
In my case board’s implementation is on a physical whiteboard on wheels which most of the time is placed in a hall, next to kitchen and my room. It means that people heading to grab a coffee (or a coffee and me) pass by it. Since it is on wheels I can take it to my room, e.g. when we’re discussing future projects with execs, or roll it to the meeting room for weekly management meetings.
There are around 30 people who are (or should be) heavily interested in the board’s content (managers, PMs, sales people) but since it is accessible to everyone there’s no problem when someone just want to take a quick look what is happening in the whole organization.
@John – You’ve caught the most important message of this post. It took me about half of a year working with portfolio level Kanban to realize that.
Hi Pawel, often I have 2 projects in line: one small “main project” where I do the major job, one big “side-project” when I devotes as a part of a fairly big team.
In general, besides some big projects that the involved people must devote a long time for developing and maintaining (later, once in a while), our teams periodly switch people to fit the project purpose, or simply let potential developers learn new things. And I think it’s good for both: increasing the ‘bus number’, and gradually improve young developer skills.
@Le Do Hoang Long – With just 2 project I would likely go with different board design. Actually with 2 projects project portfolio management can pretty much happen in one’s head. In other words, I’d start with questioning whether you even need a tool on this level (but I don’t say I know the answer for this question).
I just kicked off a portfolio Kanban in my company using a standard board design. I had the executives holding Sharpies and index cards. What a wonderful sight to see!
Anyhow, your “better board” design is somewhat intriguing. In my case, we have 9 Scrums and 1 Kanban just within IT. We are also experimenting with some Scrumban for different areas of the business. Meanwhile, 1 index card on the portfolio board represents a project or epic and can be worked on my multiple teams. With your “better board” design, how do you handle projects/epics that hit more than one team?
@Stephanie – If more than a single team works on a project there are stickies with project name in two (or more) rows. This way we can also show that one team is only partly engaged in work on the project.
Hi Pawel – Have you tried the Portfolio Kanban board with months in reverse order and flow from left to right? I understand this might confuse calendar manufacturers but from a Kanban viewpoint I’m confused by right-to-left flow!
@Andy – It’s not right-to-left flow. The flow here is sort of obscure, but in general it goes from left (less advanced project phase) to right (more advanced project phase). Well, unless there is something here that I didn’t understand.
I mean if you took a snapshot at one point in time, and then another a month later, wouldn’t you expect the cards to have moved to the left? (I’m rather assuming that the left most column is “this month” – am I misinterpreting? Apologies if so.)
@Andy – Ah, now I understand. Indeed, with such an approach you move the index cards to the left. Or you leave them as they are, but you move “the current moment” marker to the right, which is almost the same.
Talking about flow-direction, although I most frequently use left-to-right flow, it’s not always the case. I guess I first started struggling with this approach when I dealt with non-homogeneous flow, which forced me to give on left-to-right flow as the only solution, so I don’t mind other approaches.
In this case, on one hand, I think the right-to-left calendar would be more confusing than sort of right-to-left flow. On the other if yous show time perspective (and I do) the further in time you are the more uncertainty you have, thus it makes sense to put it further to the right I think.
Basing on your comments I think that interesting tweak for that design could be resigning from long term planning perspective (or showing that from a very general perspective) and focusing instead only on the closest future, but showing the internal flow of features. Definitely an idea to remember – might be pretty useful in specific contexts of small-to-medium organizations.
Nice Job! But to be sincerely, This Kanban sounds a lot strange to me… looks much more like a Gannt than a self-management system. But if it works for you, that´s the purpose!
Is it possible to visualise dependencies between projects? I am trying to visualise a program of several projects. Some are fairly independent, but sometimes the output of one is necessary as an input for another. I don’t know how to visualise that on a Kanban board, so I keep on using a Gantt. Thanks.
@Stephan – There are two answers to that. In many contexts a total number of projects would be limited and thus few hard dependencies that you have will be fairly obvious for everyone interested. This means that there wouldn’t be any extra mechanism that you need to introduce to make people aware of the dependencies.
The other scenario is when there’s enough concurrent initiatives and interdependencies that you need to introduce something to have that visualized.
Depending on specific context I may think of different approaches:
– rearranging the board so that specific, dependent projects are grouped together
– using color coding to show initiatives that depend on each other
– using additional markers to show which work needs to wait on other things to complete
– etc.
After all Gantt chart does exactly that – it shows dependencies with lines.
Another approach that I can think of would be redesigning the whole portfolio board so that the main thing that is visualized are dependencies. I would go down that path if failing to manage dependencies properly was identified as the biggest issue in my current context.
As a rule of thumb: visualizing portfolio you may choose one main dimension that you show. It may be flow, capabilities, deadlines, etc. Depending on the dimension you would end up with different designs of the board. See https://www.youtube.com/watch?v=0j1L2lBXAnk for more on that.
This means that portfolio board tend to be very different one from the other. That’s actually perfectly OK.
Thanks for the quick reply. Great talk by the way. Lots of good ideas to start experimenting with …
I found very close interface here – Kanban Tool In case of our team most important is simplicity and usability.
Pawel, so 3 years later has me wondering, are you still using this approach?
One of the benefits (or drawbacks) of the traditional kanban setups is that there’s less worry over long term planning. With this approach each team needs to plan out their work/projects accordingly. How were teams tracking estimate changes (e.g. the horizontal axis)? How was the estimation process in general?
FYI, great Teal presentation at Agile2015 btw!
@Jason – Interestingly enough, despite my much deeper understanding of the challenges of portfolio visualization, I still use the same pattern for Portfolio Kanban board.
You may look at this article as a summary of some approaches to portfolio visualization as well as how the thinking behind the process has advanced.
You may also wait for videos from Lean Agile Scotland 2015 once they’re made available. In my session there I discussed the challenges of portfolio visualization. BTW: here are the slides.
The reason why the default pattern of my board hasn’t changed, even though I changed the workplace context, is that the most common issue on portfolio level is balancing capabilities with demand and, as a follow up to this one, over-commitment. The outcome is overburdened teams and inefficient and ineffective work. That’s why visualization strategy that focuses on available capabilities, ongoing commitments and demand (that part typically being more enhanced than in the example used in the post) is still one of the default options to consider.