This is followup #2/n to my LSSC12 debrief.
As I mentioned in my debrief, I organised an evening meeting on portfolio “stuff” to take place after the speakers’ reception. What kind of an idiot arranges a meeting for 20:45, after drinks, and with a deliberately vague title? 23 people showed up at that late hour, demonstrating a significant level of interest. If you’re one of those 23, thank you!
“Portfolio stuff” became “Portfolio-level problems” in my bonus talk the next day (my slot was extended due to the next speaker dropping out). I’ll write up my talk more fully in the coming days, but what both titles indicate is a desire to spend some time identifying the problem rather than to announce that we have cracked how to do portfolio management. To describe the problem (if there is indeed only one) in the terms of the presence or absence of a particular kind of solution is a kind of sloppy thinking I wish to avoid.
I must make plain that I take seriously the evolutionary approach of Kanban and its principles of “start with what you do now”, “respect current roles and responsibilities” etc. I use “understanding, respect, agreement, leadership” as a way of bringing together both these principles and some of the Systems Thinking approaches that we teach in our classes.
So lets start with a little understanding. What does the problem space look like?
Limiting myself to the past 4 years, my direct experience ranges from leading a team of 15 (the whole of IT in that small company), responsibility for a team of 70 within a big name global enterprise, and looking at the work of an IT organisation of hundreds within one division of a major enterprise. That’s quite a spread.
My Monday night group reported projects (if that’s the right word) ranging in duration from days to months. I’ve seen worse, ie years passing before anything gets delivered. Orders of magnitude differences.
We defined “portfolio level problem” as problems seen, managed or originated (ouch!) above the organisational level of teams of individual contributors.
- The challenge of translating the objectives of the organisation into actual work
- The reverse of that challenge, seeing how actual work on the ground corresponds to organisational needs
- Managing flow day-to-day, ensuring that important work has the help it needs to progress to completion
- Managing and improving flow system-wide
Steering clear of:
- Allocating individual people to their work (it distresses me that some writers seem to think that this is even a problem, let alone a solution).
- Push, meaning any approach that seems to value starting over finishing. Includes any system with stage gates or focussed on backlog grooming that lacks strong mechanisms to balance supply and demand further down the pipeline. It is not enough to limit what you start.
It’s a very interesting and wide-ranging problem space. “Portfolio management” might be the right name for it but I’d love to have a better one that didn’t carry the baggage of failing approaches. “Portfolio Kanban” works well if it implies the method and thinking, less well if it means only stickies on whiteboards. Perhaps we need to do some work to reclaim the phrase.
Upcoming posts will explore the applicability of the Kanban method and offer some techniques for use in this space. Stay tuned. Meanwhile, a reminder to use hashtag #ppm for related posts to kanbandev.