Part 1 was about seeing the value in the various projects. I called the value stream a product so that people would think about who would use it and why. I suggested that we stop work on specific products when you have more products than teams. That would allow you to work on other projects in service of different products.
Now it's time to see what you've got.
Ranking: Slicing and Dicing or Who Gets Which Teams When
If you work in an organization that sells products to users or companies, it's a lot easier to rank the work and assign that work to teams.
If you work in a centralized IT department, that ranking and assigning projects to teams can be crazy-making. Ask each division to organize and rank its work. (I know, easier said than done.)
In either case, you have to organize the work in some way. I recommend thinking about customer-based “buckets” of similar work in each division:
- All the IT work (where IT is the customer)
- All the Finance work (Finance is the customer)
- All the HR work (HR is the customer)
And so on. When you organize by division and then by customer, you can rank the work for those various customers.
Now, with each bucket, you can compare the top-most projects in each bucket against each other to see which project has the most value. See Why Cost is the Wrong Question for Evaluating Projects in Your Project Portfolio for more details.
I prefer Cost of Delay to either ROI or NPV. (See Cost of Delay: Why You Should Care, Part 6.) For other ranking alternatives, see 7 Tips for Valuing Features in a Backlog. For the project portfolio, I rarely use shortest project (WSJF) because we often mis-estimate projects.
Assess the Kinds of Projects in the Project Portfolio
Once you rank the projects, you can assess them—what kinds of projects do you have? This is where taking an agile approach to the projects can really help your project portfolio decisions.
When teams finish work on a frequent-enough basis—and I'm thinking of short projects, such as one to three months—the project portfolio team can reassess the work in the project portfolio.
In Manage Your Project Portfolio, I suggested three ways to think about the work:
- Projects that keep the lights on. They support the organization.
- Projects that grow the current business.
- Projects that potentially transform the business with new opportunities.
I don't know what the right percentage of projects is for you. I have a guideline for my clients:
- Not more than 25% in (KTLO) Keep The Lights On.
- About 40-50% in GCB (Grown Current Business).
- About 20-25% in potentially transformative work (PTW). I like very small, very short projects so you're not betting the company, but creating small, safe-to-fail experiments.
In my client work, I often discover that organizations need closer to 75% of their work in KTLO to start. That's because their speed of delivery is so slow. They don't have sufficient build or test automation. Until they pay off their accumulated decision-debt, they can't move forward with an agile approach.
If you can create a portfolio with the 25%-50%-25% and the potentially transformative work is short, the teams can excel. As teams finish their primary product work (KTLO or GCB), each team has a chance to experiment with the potentially transformative work (PTW). When teams experiment, they learn together.
It might not matter if that potentially transformative work ever turns into “real” products. What the teams learn will inform their current work. Innovation will breed innovation.
Assess Your Portfolio
What kinds of products/value streams do you have? Are you organized by customer type? How much work do you have in the KTLO, GCB, and PTW?
If you're not satisfied with how much is in each bucket, ask yourself how small you can make the projects so you can change more easily.
When I moved to “how little” thinking, it changed my life and my throughput. It might change yours, too.
The previous post: Projects, Products, and the Project Portfolio: Part 1, Organize the Work