The very presence of the term Portfolio Management (in the Programme/Project Management Office context) in your organisation would suggest your organisation is of the Analytic mindset. This means it is a necessary evil for you right now and Kanban can certainly offer you some help in this space. The first two core principles in Kanban (1) Make all work visible, and (2) Limit your WIP are very relevant.
I’ve used the board design above at a number of organisations to make the portfolio visible and to limit the work in process. The backlog is prioritised with the highest at the top and the lowest at the bottom. I’ve seen some orgs divide this up further to show where the project is in it’s lifecycle – Initial Business Case, Budget Review, Approval, etc. The next column is used to drive out priorities and to give each capability visibility of what they may be working on next. The WIP should be self explanatory but each WIP box links to the backlog of a team Kanban delivery board and you can only have one project in flight for each capability. The done column would normally be self explanatory but it is normally an interesting discussion topic – when is a project done? Portfolio managers have a tendency to roll people off a project before it’s finished in a mad rush attempt to get started on another project. The consequences of this behaviour is evident in the short changed project closure activities. Portfolios are extremely bad at absorbing variation in the form of unplanned demand. Unplanned demand often comes in the form of changes in regulatory compliance, security threats, or defects and completely undermines the “portfolio plan”. The capability column is used to identify how the demand is going to be serviced. This includes internal staff members as well as 3rd party suppliers. The rule here should always be that an individual can only be in one box and not shared across multiple capabilities.
The message to execs and senior stakeholders should always be “what project do you want to finish next rather than which one do you want to start next” – thanks to Mike Burrows for that one!
The most important point that I’d like to highlight is that the Project Portfolio (aka Enterprise Portfolio Mgmt) is just one of many sources of demand placed on the system (org). You need to design a system that can service all sources of demand and absorb variation as the norm, not the exception. If you attempt to optimise the portfolio (even using Kanban) you will sub-optimise the whole. The use of a Portfolio level Kanban should be a stepping stone to a better place, but don’t get too attached to it!