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!

Agile Portfolio & Program Management – Part II: Governance

Executive Summary:
Capturing great ideas, obtaining consensus on their definition, objectives, budgets and schedule can be a complex and daunting process within any organization . Using a Kanban board, the Portfolio and Program Management ideation process can be structured to provide organizational oversight without impeding organizational agility.

This article is part of a three part series on Agile Portfolio & Program Management.  In Part I of this article, we discussed how a Kanban board can be applied to Portfolio and Program Management for the capture and approval flow of new ideas and suggestions.  If you haven’t read Part I, I suggest going back and reading it first prior to this article.

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 4: 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, Idea Capture, on our Ideation Kanban board.

Stage 1: Capture

Figure 5 – 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 article.

Our ideation cards contained the following attributes:

Figure 6 – Sample Ideation Card

Ideation card data is gradually filled in as it moves through the ideation process.

In the Portfolio/Program Management Initial Evaluation, the Portfolio/Program Management Team determined if the idea can be fast-tracked directly to Project Prep activity, or requires a business case developed for further evaluation.

For those ideas that required further portfolio or program evaluation and analysis, we documented the reason within the ideation card, and the card was moved to the Ready for Business Case Development column of the Kanban board.

We'll begin this discussion from the assumption that a business case is required for this idea and a card for this idea resides in the "Ready for Business Case Development" column of our Kanban board.

Stage 2: Validate - Business Case Development

Figure 7 – Kanban Columns for Validation - Click Image to Zoom

Up until now, our evaluation of ideas has required a limited set of data and informal discussions. Now that we are considering a reasonably sized initiative, we want to provide just enough information to get thru the second gateway in the process, Business Case Development.

Once a card moves to Ready for Business Case Development, a task or tasks can then be assigned to the submitter of the idea, the product manager impacted by the idea, or an appropriate stakeholder, to create the business case deliverables for this item.

Business Case Development
As with this entire process, keep the business case deliverable simple. You should be able to boil it down to reusable template of no more than 1 or 2 pages of PowerPoint slides and some appendices.

Items to consider in your business case are:

• Impacted business area of the organization
• Impacted business strategic area or theme
• A high level description of the suggestion (1 or 2 sentences)
• The financial investment rationale for the suggestion (1 or 2 sentences)
• ROI chart by investment, revenue, expenses (1 – 5 year)
• Scored Costs & Benefits (Fibonacci scored or simply High, Med, Low)
• Metrics used to gauge success or failure of suggestion
• Assumptions

You will likely have other items to add or remove based upon your own organization. The more you can standardize this information the better.

Here's how one organization structured program and project business cases into a single snapshot.

Figure 8 – Sample One-Page Business Case Template

Note that the Benefits & Costs sections of a business case are further elaborated in a separate more detailed document (not shown).

Once the business case deliverable is ready for review, the Product Manager, or appropriate stakeholder, can move the card into the Ready for Business Case Review column. A card in this column alerts Portfolio or Program Management that item should be prioritized and scheduled.

Just like the initial review, business case reviews should happen on a predictable schedule and be no more than 1 -2 hours. Once scheduled, the scheduler can move the item into the In-Business Case Review column.

The Business Case Review
The overall objective of the business case, is to demonstrate the organizational value returned by the initiative within a specified time frame.

The value identified, should be something you can quantitatively measured to determine success or failure of the initiative.

Your business case review should result in one of three paths:

1. Rejected - The idea’s investment/costs outweighs its value.
2. Business Case Refinement Needed – Further refinement of the business case is needed in order to make a decision.
3. Accepted - The idea seems feasible, in alignment with company strategy, its business value seems clear, but its complexity requires a deeper analysis for further assessment to validate this.

For rejected business case’s, the rejection reason should be documented on it's card and moved to the Rejected column.

If a business case needs additional refinement, perhaps there are some unanswered questions, these requests should be documented and the card moved back to the In-Business Case Development column and rescheduled once the information has been gathered and the card is ready for review again.

If the business-case is approved, it should move to the Ready for High-Level Analysis column of the Kanban board.  Note that it's possible that as a result of the business case review, it's determined the idea can be fast-tracked, and moved directly to the Ready for Project Prep column.

Leveraging a Kanban board to monitor the flow of the Portfolio & Program Management Ideation process, we've demonstrated how Kanban can be used by the Portfolio/Program Management team to provide a clear and transparent process, ensure appropriate governance of larger initiatives, and still encouraging agility by only requesting just the right amount of information at the right time.

It takes time for governance processes to evolve.  If you like the idea of a Kanban board to manage these processes, I recommend starting out by mapping your existing process activities first without consideration to Kanban, then once everyone agrees on the process, only then should you begin translating it to a Kanban board.

It's rather daunting to approach existing complex processes within any organization.  Part of agility is being able to evolve and improve. Be sure to incorporate periodic retrospectives to continually review your processes with your team and make incremental improvements along the way.

In the next and final article in this series on Agile Portfolio & Program Management - Ultimate Agility, we are going to discuss the final validation activity, High Level Analysis, and the the Project Preparation stage. We will also put everything together and demonstrate how to monitor and continually improve your overall organizational agility.

It would be great to hear about your experiences with addressing organizational governance, get your feedback on Portfolio & Program Management, and any suggestions you may have.

Agile Portfolio & Program Management – Part 1: Ideation

Executive Summary:
Being able to evaluate the influx of project ideas in large organizations can be a tedious and time-consuming process for management, and a confusing process for stakeholders. Using a simple Kanban board for the process of collecting and approving these suggestions, helps guide stakeholders through the process, provides approval visibility, and most importantly, prevents the loss of some really great ideas.

This article is the first of a three part series on Agile Portfolio & Program Management.

For quite some time now, both small and large organizations have been successfully executing agile and Kanban practices to manage individual projects at the team level, but one often overlooked area, is where agile and Kanban can be applied to portfolio and program management, especially at the point of ideation.

Simply stated, ideation is the process by which new ideas are captured, evaluated, and if approved, prepared for implementation. Ideation is the inflow of ideas and suggestions to both portfolio and program management. These ideas and suggestions may relate to the development of new programs, product enhancements, new products, improvements to a process, changes in infrastructure, or just about anything that a stakeholder might want to do that they think brings value to the organization.

Some Basic Terms:
Portfolio Management is the activities an organization performs to determine its overall strategic goals (e.g. Customer Care, Mobilize Workforce, Operational Efficiency) and the tactical programs made up of various initiatives to achieve those strategic goals. These types of strategic goals are referred to as Themes in Dean Leffingwell’s SAFe (Scaled Agile Framework) methodology.

Program Management is the process by which the organization prioritizes, manage dependencies, and oversees the implementation of initiatives within each program. These initiatives are performed at the team level.

Here’s a bird’s-eye view of the Portfolio & Program Management ideation process:

Portfolio & Program Management Ideation

Figure 1: Portfolio & Program Management Ideation - Bird's Eye View

Because new initiatives may impact a significant number of teams, customers, clients, and/or may require lots of resources, some level of governance is usually instituted to evaluate and validate these ideas to confirm their value (i.e. value returned over time vs. investment & expenses). If approved, these ideas are then formalized for implementation. Unfortunately, this evaluation and approval process can be very time consuming and complex, involving multiple sign-offs, reviews, documentation, and impact multiple teams and systems etc. This is where Kanban can come to the rescue!

Unfamiliar with Kanban? - Here is the basic Kanban pattern:
Within Kanban, although there are many ways to tweak a Kanban board, at its simplest, a Kanban board uses the following to represent the flow of work within a process.

Image Source: www.powerretail.com.au.

Figure 2: A Simple Kanban Board

Work is represented by a card containing a description of the item being worked on.
Work cards begin in the To-Do column, when work is selected from the To-Do column to be worked on it is assigned to someone and the card is moved into In-Process column. When work is complete, the card is then moved to the Done column. By looking at a Kanban board, you can see what work still needs to be addressed, what is currently being worked on, who is working on it, and what work is completed.

A Kanban Model for Ideation
You don’t need to be implementing the Scaled Agile Framework to use Kanban for ideation, but since the release of SAFe 4.0, the SAFe framework also encourages the use of Kanban for handling ideation.

Image Source: The Scaled Agile Framework

Figure 3 – Kanban Portfolio & Program Ideation in Safe 4.0 - Click Image to Zoom

The only issue with this recommendation, is that SAFe doesn't necessarily tell you how to implement this process, that's up to you.

Having worked with organizations attempting to tackle this problem, I’d like to outline a generic approach involving three validation gateways that can help your organization simplify this process, make it more transparent, and improve your overall evaluation and approval (aka cycle) times.

Here's a revised bird's-eye view of an ideation process with three validation gateways.

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

Gateways are activities performed by a Portfolio-Program Management team and/or a PMO to ensure organizational initiatives are aligned with the organization's strategic goals, feasible, provide timely value to the organization, and if so, are budgeted appropriately.

The next step is taking this process and representing it as a Kanban board to manage and monitor the ideation workflow and gateways until the idea is ready for implementation.

Your Kanban board can be a physical board on a wall, an electronic board using software like VersionOne , Atlassian’s Jira, or Leankit. You might even consider using both physical and electronic boards.

I like to use the term ‘Ready’ for work that is ready to be worked on (i.e. To-Do), once work begins, a card is moved to an ‘In-Process’ column, and when work is completed, that work is then moved into a ‘Done’ column. If the there is another activity in the process chain, the card can be moved into another ‘Ready’ column.

Here’s how the idea capture process might be represented.

Stage 1: Capture

Figure 5 – Kanban Columns for Idea Capture

First we capture the idea as a card in a queue or backlog (To-Do), we then may need to do some cleanup and preparation on the idea to prepare it for a formal review (In-Process), and finally after it is ready to be reviewed, we move it to the ‘Ready’ column awaiting to be reviewed in the Validation stage. You could consider this its own independent Kanban board, in which case the ‘Ready’ column would be considered ‘Done’, or if we expand the board to include the evaluation process, it would be considered as a ‘To-Do’ column.

Essentially, anyone in the organization should be allowed to submit an idea, but you may want to establish some of your own limits on this as well as a standard set of attributes and supporting documents you want to include on your ideation cards. Consider setting up a general mailbox account to receive ideas and have someone from the program or product management team actually enter each suggestion into a queue rather than allowing anyone to create cards directly.
The card attributes you choose should primarily be configured to handle different levels of analysis and evaluation.

As a guide, try to keep things simple and only require the submitter to include the information needed for each upcoming step rather than trying to capture everything at once. For more detailed information, incorporate the ability to associate supporting documents to card via links and/or file attachments.

Here are some example ideation card attributes. You will need to determine what works best for your ideation process:

Figure 6 – Sample Ideation Card

For continuous process improvement, you should be reviewing and refining your overall process, the board columns, and the card attributes on a periodic basis; think ‘agile retrospectives’.

Another important aspect, is to have a product owner to manage the Ideation Backlog/Queue. The product owner is responsible to groom the queue, ensure appropriate information is included for each card, merge duplicates, remove obsolete items, and prioritize which items should be reviewed next. The product owner will move cards they wish to work on into the In-Initial Evaluation Prep column. During this time, they may need to go back to the submitter for additional information or clarification. Once an idea has all of the appropriate information, the product owner will move the card into the Ready for Initial Evaluation column.
Now that you understand the basic Kanban board flow, let’s look at a process that involves three sets of activities.

Stage 2: Validate

Figure 7 – Kanban Columns for Validation - Click Image to Zoom.

Initial Evaluation
Once a card is in the Ready for Initial Evaluation column as a result of our idea capture process, the product owner or someone designated from Portfolio or Program Management can decide when to schedule this item for review. Note that the Ready for Initial Evaluation column is technically, the backlog (To-Do) for the Evaluation section of the Kanban board. Any card that shows up in this column is a signal to the owner of this queue to do something.

It’s recommend that you have specific periodic days each month or each quarter for this initial review. E.g. The third Tuesday of every month. The person, who scheduled the item, should pull those cards into the In-Initial-Evaluation column of the Kanban board, the week or month that that the review is expected to occur. This gives the reviewers a head-up on what items are coming up.

The first evaluation should be more of a discussion rather than a formal presentation, with the goal to determine if the idea has promise and is worth evaluating further.

Appropriate management, business stakeholders and tech leads should be invited to this session. The meeting should probably be no more than 1-2 hours, but this is entirely dependent on your process. Over time, you will get a sense as to how many cards can be scheduled for one evaluation session and you can set a work in process limit for the In-Initial-Evaluation column.

Your initial evaluation should result in one of three paths:

1. Rejected - The idea is not feasible, may not be appropriate for the business, or may already be addressed by an initiative in-flight.
2. Fast-tracked - The idea is clearly feasible, in alignment with company strategy, its business value is obvious, and is small enough that it could move directly to a team’s feature or story backlog.
3. Portfolio/Program Governance Required -The idea seems feasible, in alignment with company strategy, there is potential business value, but its complexity requires a deeper analysis for further assessment to validate this.

If you determine that the idea is not worth pursuing or is already being addressed the idea is rejected; the rejection reason should be documented on the card and moved directly to the Rejected column of the Kanban board.

If an idea’s value is obvious and small enough, it can be fast-tracked to project preparation, where requirements can be cleaned up, outstanding questions answered, and an implementation team assigned so that it can be added to that team’s feature or story backlog. Document the fast-track reason on the card, and move it to the Ready for Project Setup column.

Examples of fast-tracking might be application cosmetic and/or content changes, minor feature requests, and minor process changes. If it’s not obvious, consider sending it thru the full evaluation process, you can always re-route it back to project setup via fast-tracking.

One approach to determine fast-tracked items is to use the number of teams involved or impacted by the suggestion. If it requires two or less implementation teams, it can be fast-tracked and go directly to Ready for Project Setup, three or more teams may require the full portfolio/program management evaluation and analysis process.

When an idea requires further portfolio or program evaluation and analysis, the reason should be documented within the card, and the card moved to the Ready for Business Case Development column of the Kanban board.

A great feature of many online Kanban tools, is that they can also serve as a workflow application.

Cards can have tasks associated to them within each activity and tasks can be assigned to people. Once a card moves to Business Case Development for example, a task can then be assigned to the submitter of the idea, the product manager impacted by the idea, or an appropriate stakeholder, to create the business case deliverables for this item.

Identifying which tasks are performed during each activity ensures the process is followed, all appropriate information is gathered when needed, provides real-time status, and an audit trail. You may still consider maintaining a simplified physical board somewhere so that anyone can see it a glance what is going on during the ideation process.

By this point, you should have a basic understanding what ideation is, how Kanban can be used for Portfolio and Program Management ideation to, serve as a process guide for stakeholders, how Kanban tools like VersionOne and Atlassian’s Jira can be used for workflow management, how Kanban boards provide visibility into the current state of work, and finally how to use Kanban to prevent the loss of valuable ideas.

In Part II of this three part series on Agile Portfolio & Program Management, we'll discuss the next step in the validation process,  learn how to create a 1-page business case, and how to incorporate organizational oversight into the process while still encouraging organizational agility.

I’d love to get your feedback, hear about your ideation experiences, or or anything agile.
In the meantime, keep those ideas coming!