The Project Portfolio Kanban Story: First Changes

Those of you who remember my Kanban Story probably remember how important experimentation mindset was for me since the beginning of my journey with the method. On project portfolio level the only difference was that I was well aware that such attitude is crucial even before I started doing anything at all. In other words I planned to adopt such attitude.

With this kind of approach you should expect changes in the process and, as a result, changes on Kanban board as well.

OK, let’s start with what I had on the day one:

What was wrong with it?

Well, maybe not really wrong, but it soon appeared I needed more information from the board than I’d already had.

First thing, which became clear and actually could have been predicted, was that throwing all future projects into a single “planned” bucket was an oversimplification. Actually a planned project was pretty much any project which wasn’t yet signed, meaning that there were still many bad things which could potentially happen before we were 100% sure we would be doing it.

Soon enough I had two groups of planned projects: these which were still expected to be built in near future and those which were in doubt for whatever reasons. Once I realized it I just added another column to the board. Since it was very unlikely that a project “in doubt” would automatically go into development and most probably it would go back to “planned” stage before, I added the column on the very left and index cards could freely go between “planned” and “in doubt” back and forth as I was learning new facts on the projects.

Second problem was related with general status of projects. As I needed to pay more attention to challenged projects than to these which were doing perfectly fine this information was crucial to have it at hand. I decided to go with a simple green-yellow-red statuses, meaning respectively that project was going as planned, wasn’t going as planned but changes could be absorbed by project team or agreed upon with clients or wasn’t going as planned and unless something was done we were likely to fail.

Technically I just grabbed a bunch of color magnets and attached them to all projects in “ongoing” phase. I was changing magnets to different colors whenever a project changed its status according to above definitions. Once I clearly saw which projects are at risk, and I saw that a dozen or more times a day, I could easily ask for more information on a project, look for risk reduction actions, set a higher priority to a project or whatever I felt could help to bring it back to the right track.

After changes the board slightly changed:

However that wasn’t all. Third issue I was facing was that I couldn’t tell looking at the board when we were expected to deliver a project. It was super-important information as without knowing the dates it was hard to say whether project was going according to the plan or not. After all without dates I could hardly say I even knew the plan. It was also very difficult to plan future projects as I couldn’t really tell when this or the other team would be free.

And this is why my index cards started evolving as well. At the very beginning an index card for a project was very simple:

As process described on the board wouldn’t tell me anything about dates I decided to add this information to index cards. I wrote any key dates we knew for a project. It could be stage deadlines if we had multiple stage deliveries or deadlines for delivery, user acceptance testing and project closure, etc.

Then, as you may easily guess, these dates started changing, either in controlled or uncontrolled manner. Either way I ended up crossing out the old dates and adding new ones. Despite the fact that index cards started looking a bit cluttered I realized that the fact that dates had changed was important to me as well so decided to keep it this way.

And then I had all the discussions on budgets. I mean one thing is to deliver on time, another one is to keep a project within budget. So yes, I was having these budget-related chats pretty regularly. Of course I could refer to budgeting application, but then I wanted to work on the data which is up to date. This disqualified the budgeting app as sometimes we had old data there. What more, there was a number of different reasons why we had it this way, be it anything from preserving initial budget estimates to bug in the system.

Anyway, I ended up writing budgets on index cards. And again, whenever budget was changing I was crossing the old number out and adding a new one.

A new index card looked like this:

Besides the initial information, which was project name and team or teams working on a project, I had project status and a sort of notebook for important facts regarding the project (dates, budgets). Why do I say that it was a notebook? Well, after some time handful of index cards looked not-that-clean:

Anyway, I had the information I needed.

Of course all these improvements didn’t happen in a single day. It was more of a constant process of small adjustments and tweaks spread over a longer time span.

There’s also one approach I used, which you may find useful. When I was adding dates or budgets to index notes, I didn’t checked them for each and every project which was on the board already. I just set the policy that each new index note which makes it to “ongoing” column had to have the data filled. In terms of projects which were already in development I was adding this information slowly over time, usually whenever I was discussing the very project and somehow dates or budget became important in the conversation.

It meant that eventually I’d have had complete information either because I gradually updated all the index cards in “ongoing” column or because projects were finished and the cards were moved to “maintenance.”

After all these evolutionary changes I was still kind of unhappy with the board. I still didn’t feel I had any explicit limits and, what even worse, I didn’t see any simple method to add them. I also noted that sometimes I found it hard to keep all the information updated, as the board was still fully owned and managed by myself. However I decided not to go with it to the outside world unless I was sure it was going to work.

So no, that’s not the end of the story. However, I encourage you to read it from the beginning.

Advertisement: Want to have such nice Kanban boards in your presentations or blog posts as well? Check InfoDiagram Kanban Toolbox. Use pawelBBlog code to get $10 discount.