Custom Blogger JS

Wednesday, March 23, 2016

Agile Portfolio & Program Management - Part III: Ultimate Agility

Executive Summary:
Using a Kanban board for Portfolio and Program Management can not only provide visibility into your processes, but also provide a path to measure and continuously improve your organization's agility.

This is the last of a three part series on Agile Portfolio & Program Management.  In Part II of this article, we discussed how a Kanban board can be applied to Portfolio and Program Management Ideation to both encourage agility while still providing oversight and governance. If you haven’t read Part II, I suggest going back and reading it first prior to this article.

In the last installment of this series on Agile Portfolio & Program Management, we are going to discuss the final validation activity, High Level Analysis, and the process prior to project launch, Project Preparation. We will also put everything together and demonstrate how a Kanban board can make the whole of a process greater than the sum of its parts. Let's get going!

Below is the basic Portfolio/Program Management Ideation process we defined for collecting, validating, and preparing ideas for implementation. Note that we included three validation gateways within the validation stage to ensure organizational alignment prior to the launch of complex initiatives.

Figure 1: Portfolio & Program Management Ideation with 3 Validation Gateways

Translating the Ideation Process to a Kanban Board
Here is how we modeled the activities of the the first stage, on our Ideation Kanban board so far.

Stage 1: Capture
Figure 2 – Kanban Columns for Idea Capture

Ideas are collected in an Idea Queue or Backlog, selected and prepared by the queue's Portfolio/Program Management product owner, where they are then scheduled for the Initial Evaluation. To learn more about the Initial Evaluation of an idea, refer back to Part I of this series.

Our ideation cards contain the following attributes:
Figure 3 – Sample Ideation Card

Card data is filled out as it moves through the ideation process.

To this point, we've discussed the first two Portfolio/Program Management gateways, the Initial Evaluation and Business Case Review.

We'll begin this discussion from the assumption that the idea passed the initial evaluation, the business case review, and that the ideation card was moved to the "Ready for High-Level Analysis" column of our Kanban board to indicate that it is now ready for High-Level Analysis.

Stage 2: Validate - High-Level Analysis
Here is how we modeled the activities of the the second stage, Validate, on our Ideation Kanban board so far.


Figure 4 – Kanban Columns for Validation
Click Image to Zoom

The Portfolio/Program Management product owner will then prioritize which items to work on next and select a card from the Ready for High-Level Analysis column. Once an idea/initiative is selected, a program or product lead should be assigned to the initiative, along with one more lead business analysts.

High-Level Analysis
High-Level Analysis is a final Portfolio/Program Management checkpoint prior to an initiative's launch.  During High-Level Analysis, the scope, cost, and basic roadmap of the the initiative will be defined and the reviewed one last time by the Portfolio or Program Management team prior to launch.

This analysis has two primary purposes:
  1. Provides just enough information to ensure that within the scope of this initiative, we are implementing the right things at the right time, and doing it within mutually agreeable budget.
  2. Provides requirements that can be dovetailed directly into our agile implementation process.
When analysis begins, one of program or project leads can move the card into the In-High-Level Analysis column of the Kanban board to indicate analysis is underway.

High-level analysis will generally consist of the following:
  • Impacted Processes, Systems, & Teams
  • High-Level Storyboards - New and/or Updated Processes & Features
  • Program/Project Epics & Features
  • Initial Program/Project Roadmap
  • High-level Cost Estimates
Impacted Processes, Systems, & Teams
Process diagrams help identify the scope of the project, along with helping to uncover impacted processes & systems.

If you don’t already maintain business process diagrams, they are severely out of date, and/or in a variety of formats, this is a tremendous opportunity for your organization to begin identifying a standard approach to modeling your business processes, technical infrastructure, and establish a definitive point in time to maintain them. Doing so, also gives you more reason to maintain them in a central repository.


Updating your process models at a consistent point in your development process, may not get every business process looking the same, but it will begin to normalize the format of these models, ensure a common location for storing them, and more importantly, identify gaps where these processes have never been fully modeled before.

More on process diagrams: 
Over time it you will find it easier and easier to perform impact analysis as your models become more current and there is less need to create these models from scratch. If you are looking for a process model standard, I recommend using BPMN 2.0 event process chains. Event process chain diagrams are extremely powerful and easy to read once you get the hang of them.

High-Level Storyboards
Some basic storyboarding can also be used to identify new and/or impacted product features and provide an idea of how they are expected to work.  David Hussman of DevJam has some great intro videos to storyboarding as well as other related techniques.  If the initiative requires a graphical interface,  consider supplementing your storyboards with basic UX designs.

Program/Project Epics & Features 
As part of your high-level analysis, you should be able to identify your highest valued epics and features.  There are various methods of doing this, but one method for this is the weighted-shortest-job-first approach or WSJF. For more information on WSJF, check out my article, 5 Steps for Using SAFe’s Weighted Shortest Job First Ratio (WSJF) for Backlog Prioritization,  on this topic.

Spending the time to define portfolio and/or program epics and features should not be throw-away work as they will end up as input to creating a prioritized list of the program and/or implementation team project backlogs. Bottom line, whatever you use for your high-level analysis output format, it should be very close in format to the epics and features that are used within your portfolio and/or program level backlog.

Initial Program/Project Roadmap
One of the core functions of the portfolio and program management teams, is to plan (or roadmap) when certain programs, processes, products, and features should be implemented. The mechanics of roadmapping your initiative and understanding internal and external dependencies would also require a separate discussion, but a high-level roadmap of your program or project is a necessary input to the process to guide release planning and backlog prioritization.

What About Risk Management?
One essential piece integrated into your roadmap, should be your risk mitigation plan.

Risk mitigation can be incorporated into your roadmap in two ways:
  1. By implementing items that have the greatest potential to delay your project as early as possible.
  2. As epics and features in your backlog no different than any other epic and feature except that they are identified as a risk epic or feature.  They are simply work that needs to be performed to reduce the risk of delay and or cost in your roadmap.
High-level Cost Estimates
Now that we have a better handle on scope, we should be able to provide cost estimates with a higher level of confidence than those provided with the original business case.  For extremely large efforts, consider only providing estimates no more than a year out at a time.  Agile budgeting requires a separate discussion, but the main objective of your budget should be to to ensure you are delivering the highest valued items of your initiative within the time and budget available to you, not committing to a definitive set of requirements within a specific time and budget constraint.

Your approach and metrics used for estimation is entirely up to you, but whatever approach you choose, planning poker, an estimation model, or locking your teams in a conference room, involving both technology and business leads during estimation gives key stakeholders a clearer understanding of the project objectives and reduces any big surprises down the road.

Too many cooks performing estimation can be a problem, so choose only the necessary people to be in this meeting. Others can attend, but they should only be observers and not permitted to speak unless there is a dedicated Q&A session at the end.

A Kanban tool can also be used to notify potentially impacted stakeholders of upcoming projects and meetings. For example, notifications can be sent to Infrastructure and Support teams when the status of cards change to a particular value, e.g. a card goes from Ready for Hi-Level Analysis to In-High-Level Analysis. This can alert them to projects coming down the pike enabling them to plan and prepare for according..

After completing an initial round of your high-level analysis, you should have a better handle on your budget, resource needs, the programs, processes, and features you plan to implement, and when to implement them. Once the the program or product lead feels the analysis is detailed enough, they can then move the card to the Ready for Hi-Level Analysis Review to signal your Portfolio or Program Management team to schedule your analysis review.

As with previous reviews, it’s recommended you set these up on a regularly planned periodic basis and make them no more than 1-2 hours.  Product owners, team leads and impacted stakeholders along with a representative from Portfolio or Program Management should be at this meeting.

Standardizing the the high-level analysis presentation materials as much as possible will ensure the presenters knows what is expected of them and your audience understands what they are reviewing.

Ideally, keep each presentation to 30-45 minutes with a 30-45 minute Q&A.  I also suggest letting a present complete their presentation prior to any Q&A or you may end up with a lot of unfinished presentations.

At the conclusion of the meeting, the representative of Portfolio or Program Management will then make a formal go or no-go decision for this initiative.

Similar to how the Business Case Review, if the idea is rejected, the card should be updated with a rejection reason and moved to the Rejected column.  If more information is needed to make a decision, update the card with the information requested and send the card back to the In-High Level Analysis column for further research. If approved, the card is moved forward into the Ready for Project Setup column.

Project Preparation
Finally, when work in the Ready for Project Setup column is ready to be worked on, a designated Portfolio/Program management resource can then move the card to the In-Project Setup column.
Remember that the "Ready" columns should be treated like a backlog and will require someone to be responsible to prioritize and ensure the cards have all the necessary information to proceed.

Figure 5– Kanban Columns for Project Prep.


Project Preparation is the process by which specific resources may need to be procured or configured and/or environments set up prior to moving the work into the appropriate execution team’s backlog. You might even use this point in time to create a collaborative charter for your program or project team.

Collaborative Chartering
Collaborative charters are a great way to kick off a project. These are not the pro-forma charter usually required by executive management that get filed away never to be seen again.  Collaborative charters are generally 1 or 2 page documents that outlines the purpose of the your project, the stakeholders involved, and any working agreements. They get everyone on the same page, literally, and also help when onboarding new team members, to understand the purpose of the project and who's who.  For more information on collaborative chartering, here’s an excellent video by David Hussman on the topic.

Once necessary resources are readied and the work is migrated to the appropriate team backlogs, your ideation card can be moved into the Project Prep Complete column and project implementation can begin as scheduled.  You could keep extending the Program and Portfolio management Kanban boards all the way thru development and even operations rollout, but this essentially completes the Portfolio/Program Management Ideation process, and your card moves to a "DONE" status. I've colorized this column green, to emphasize the process is done and ready for the next stage of development.

The Complete Portfolio/Program Management Ideation Kanban Board

Putting it all together, our Portfolio/Program Management Ideation Kanban Board looks like this:

Figure 6– The Entire Portfolio/Program Management Ideation Kanban Board
Click Image to Zoom

From one diagram, you can see what cards are waiting to be worked on in, what cards have been rejected or approved, what cards are in process, and what cards are ready to be implemented. If you want more information, you can view each individual card for initiative details, decision rationales, and task assignments.

Taking Your Agility to the Next Level
Another benefit of having the Portfolio/Program Management process maintained within a Kanban board, is that it provides a great way to measure the average time each card spends within each activity, as well as the average total time (cycle time) it takes to get from the Ideation Backlog into the hands of the implementation teams. Capturing average activity times and cycle time enables you to identify where you are experiencing bottlenecks, determine the impacts of changes to the process, and provides a measure for your organization's overall agility. Activity and cycle times are measures that all members of an organization can easily understand and can be used a simple way to communicate the overall health of your organization.

To take your agility to the next level, your Kanban board can even be used to communicate status. Imagine the time saved and the increase in productivity by minimizing and possibly even eliminating status reports and status meetings with real-time status and metrics accessible to anyone, anytime.  Doing so, will focus meetings you do have on removing impediments and celebrating victories. And isn't this what agile is all about?!

Using the Portfolio & Program Management Ideation process, we've demonstrated how Kanban can be used to improve organizational agility by simplifying complex processes, providing organizational transparency, and even provide real time agility metrics and a method for status reporting without the status reports.

Now that you have a basic understanding of the power of Kanban, what ways can your organization use Kanban in the pursuit of ultimate agility?


I hope you've enjoyed this series on Agile Portfolio & Program Management as much as I have, I would be grateful to hear you feedback, experiences, insights, and suggestions. Thank you!

No comments:

Post a Comment