When I think of agility and portfolio management, I often think of Jim Highsmith's wise words: Do Less. Focus on value delivery, and be ruthless in stopping the projects that are not delivering value--look at the ROI of a project's backlog.
This afternoon I found myself thinking about how to identify the "right" number of projects that can be worked simultaneously in an organization before the complexity of the portfolio begins to slow down the individual project deliveries, and the subject was touched on briefly during tonight's Dallas Agile Leadership Network meeting. Managing a single project isn't easy, and the complexity compounds when additional projects are being run at the same time. How do you manage dependencies? Risks? Communication? How many test environments are needed? What tools are needed? Are the teams co-located or distributed? What other areas of the organization need to be involved?
I often coach teams to create big visible charts to help them manage their work--visibility helps ensure the team is on the same page and able to make decisions effectively together. I'd like to see organizations creating big visible charts to help them manage their portfolios. My initial thought is to use a kanban board to see the status of projects and monitor their cycle time. My coworker Jay Packlick defines agility as an organization's ability to make and execute decisions quickly. I ask, how can an organization make decisions quickly if it cannot clearly see its portfolio? If project cycle times are too long for the organization to be competitive, how can it adjust? What projects deserve the most attention? Which projects have achieved a reasonable ROI and should be stopped?
Does it feel like your organization is trying to do too much? There's a flurry of activity but the results leave something to be desired? I suggest looking at your portfolio.