Terms program management and portfolio management are used quite frequently, but let’s see where portfolio management, program management and project management exactly fit in. It is crucial to understand the difference and work relationships at each level. This becomes more important because, at the organizational level, it is imperative to know details while driving work forward and integrating it upward.

Projects belong to programs as programs belong to portfolios. A portfolio is a high-level view of all the projects an organization is running to meet the business’s main strategic objectives. At the same time, the program is a collection of projects being executed collaboratively to generate value that cannot be gained by managing them individually.

The beauty of Kanban is not just implementation at portfolio but also the comfort and value it brings at all the levels in organization or work. At its core, Kanban is a method to visualize the flow and manage work irrespective of the level implemented. Kanban can be applied to high-level strategic processes, mid-level tactical processes and, of course, Team level processes. Its flow-based approach helps visualize and manage the work from ideation, analysis, implementation, and completion.

The upstream to downstream view gives a pipeline of incoming projects and visualization of funded and approved projects to make informed decisions. At the Program level, Program leaders can track the features within their domain. While at the team level, it helps to track working software development while also giving them and program leaders a broader context of how their work bubbles up into the big picture.

To implement Portfolio Kanban, brainstorm the columns that you think will help you clearly define the progress. For example, a Backlog, Initial Customer Validation, Assessing, Ready, Building, and Collecting Evidence. Then explicitly define policies, which are exit criteria for each column. Start with existing policies first and improve as you progress. Make sure policies are explicitly defined and are not too complex to follow.

Once you define policies, define commitment points, these are the points where you commit work at the current level and the second is when you are ready to pass work downstream. In the first commitment we are committing to work, and in other point we are committing to deliver and we are starting to achieve outcomes

Once the upstream, the downstream board is designed, define cadence for replenishment, delivery feedback, board review and delivery process.

Kanban when used at various levels –

  • Portfolio — At this level, the Kanban system helps describe Go-NoGO to epics ready to be implemented.

— Establish cost estimates

— Assess technical and business viability

  • Program — Epics that are tagged for implementation at the Portfolio level are further broken down to Features and categorized as CR, new feature, Enhancement etc. Kanban System at this level also helps describe Agile Teams Implementing particular feature to deployment to Staging and further to production. It also helps identify cross-team feature level dependencies through your iterations so the team can identify and focus on cross-team communication.
  • Team — Features in the implementation phase in the Program program for the respective team boils down to forming a team Kanban. Teams might choose to define Class of Service at the team level, the actual solution development happens. Word of Caution here is teams under the program should follow cadence and plan, demo, integrate.

The collective status of these tasks represents the status at the higher level. Kanban aids represent work that makes the most sense and rolls up information (team > program > portfolio) to summarize and visualize the overall business objectives, epic delivered to fulfil enterprise vision and overall ROI generated!