You already know why I decided to try out Kanban as a tool to organize our project portfolio. To be honest I didn’t spend much time on considering the initial Kanban board design. Remembering about experimentation mindset you should have when using Kanban I decided to start with anything which seemed sort of reasonable and adjust the whole thing on the way.

One of observations I made recently is how we stick to standard Kanban board designs. It seems that this is a path of least resistance – to use what we already know and are familiar with. I pretty much did the same. I started with a design that I used when I was applying Kanban on a team level. I just tried to map a process in a very generic way to a list of stages, and then track projects as they go from the left side of the board to the right.

This is what I started with:

As you can see I started on a pretty high level. We had projects we expected to start soon, and most of them eventually were started. Then we had whole ongoing phase separated only to three, very generic stages.

As our clients are typically rather big companies most of the time we have pretty formalized analysis phase at the beginning of a project. This stage was worth separating as it there are significant differences, both in terms of effort we invest and people involved, between analysis and building stages.

Then there was generic building phase. I didn’t try to track details for example in projects where we had iterations. I didn’t try to show specific stages in projects where we could define them. One reason was that the development process isn’t homogenous – depending on a client, a size and a type of a project, a development team and a few other criteria this process can look differently. Another reason was I didn’t want to go into deep details, especially not with the first version of the board. After all it was expected to be changed.

The last building stage sub-column was representing projects which went into user acceptance tests. Similarly to analysis, pretty typical stage, even for clients that get iterative deliveries. And again, a part of a process we wanted to distinguish as it usually is a pretty specific in terms of team’s involvement.

Finally, there was maintenance column which is sort of done column on steroids. On a typical Kanban board done column is a way to say that we don’t plan to do anything with an item which made it way there. Eventually, we remove an index card or a sticky note from the column to make a room for incoming ones. On a project portfolio level moving cards into the last column is sort of double blessing. Not only do we know that we are done with building a project but we also switch into maintenance mode, which is usually the most profitable stage of a project lifecycle.

A pretty natural move to make was attaching team names to project index cards. Even though we were changing teams responsible for projects very, very rarely I decided to go with small stickies attached to index cards as sometimes it happens that a couple of teams are working on a single project.

Now, a couple of things which weren’t that intuitive with this project portfolio Kanban board. First, there were no limits whatsoever. I played with the idea of adding some but eventually, I came to a point that it’s not only a number of projects that matters but the size of them is equally important. In other words one team can cope with a single big project or a few smaller ones concurrently and both are perfectly acceptable scenarios. I just decided to see how it goes and make up my mind about limits later on.

Second, the board wasn’t really co-owned by everyone in the team. OK, in a team of almost 150 people it would be sort of difficult to have a board co-owned by everyone. However, considering there are just about a dozen project teams we could have one representative of each team and we all could perfectly work on a single board. Well, we theoretically could, if not the fact that we were spread over the whole building. Also, I didn’t want to enforce on each and every team a new duty which might well change pretty soon.

I decided to start with this project portfolio Kanban board treating it like a personal Kanban board. It was owned, updated and changed only by myself; although anytime I was learning a new fact on any of projects I was updating the board. Soon enough I started having visits not because I was in the room, but because the board was there.

A nice side-effect of such approach was that I could have my project portfolio Kanban board on one of whiteboards in my room which meant it was always at hand.

Either way, I knew it was sort of temporary state. The goal was either to move toward co-ownership of the board or dropping the tool all along. As later appeared I pursued this goal soon, but that’s a subject for another chapter of The Project Portfolio Kanban Story.