When your innovation pipeline is too successful...
A large multinational company I have been training came back to me with what looks like good news: the number of projects that cleared the quality bar we set together doubled, from around 20 to 40+.
The uncomfortable truth is that a doubled pipeline is not a result the company can bank on, because it was only dimensioned to carry the initial number of projects through proof of concept and into production. Of course, our training did exactly what it was meant to do. Teams sharpened their market understanding and built a clear value proposition, without getting drowned in technicalities. It doesn't mean we don't have a problem.
The obvious move would be to fund all projects and declare a big win. This would mean allocating resources for these projects down the road and providing them with less support, reducing their chances of success. You have to understand that in real life, below a threshold of internal support, an innovation project does not advance slowly; it stalls, accumulates sunk cost, burns a sponsor's political capital, and produces nothing. Spreading thin is the most reliable way to drive a doubled pipeline into the ground.
What about killing the number of projects we intended to anyway?
Killing a project carries an immediate, attributable cost that lands on identifiable people: a team that believed in it, a sponsor who championed it, and, as a whole, a morale signal to everyone watching. Not to mention that we'll get back on the resources track, but will also have the lingering suspicion that the projects we killed might have been much better than the one we ended up selecting by a thin margin. The only upside is that this wouldn't make any waves for the upper management...
Seems there's really the possibility of "too much winning!"
For now, here's where I'm at...
Option 1. Separate the kill decision from the fund decision with a quick, time-boxed extra stage. This would mean giving a small, fixed envelope to all 40+ projects and setting a new hard deadline to produce one piece of evidence, after which the portfolio sorts by results. This keeps the budget iso and doesn't change the current setup much, but we still end up killing promising projects.
Option 2. Keep selecting down, but instead of evaluating each project on its own merits, value them for their contribution to the global innovation portfolio. Rather than ranking all projects on a single scale (an argument I have made in detail on building a proper innovation portfolio), decide first how much capacity belongs in low-, medium-, and high-uncertainty zones, so a long-shot exploration never competes head-to-head with a near-term deployment it would always lose to. When sorted by zone, the problem might take a different shape, but there's no guarantee.
Option 3. Use each project's extra ROI as a final cut. See, when working with the innovation team, they have to produce a direct business ROI (what their innovation will build in the market for the customers – whether they are internal or external) and at least one key side ROI. This is a positive impact the project will have even if it fails (cleaning an important data set for further AI development, testing unknown market waters and coming back with critical insights, implementing new technological know-how across a department, etc).
Option 4. Budget against the real constraint, not money. If the bottleneck is the coaches and stakeholders who can carry something into production, size the portfolio to their capacity and let projects queue for that operator time. We end up funding most of the 40+ projects, but on a different timeline. Twenty now, as expected, twenty later on. It's realistic and doesn't require a huge extra budget, but it will still create some frustrations on the project's side, as some teams will not move on until the end of the year or later. Also, it might push back the next innovation campaign.
Option 5. Use optionality deliberately (the central mechanism for portfolio construction) and keep some projects alive cheaply as options on an uncertain future, held in a low-cost pattern rather than pushed toward production. This would require a lot of work and "project engineering," but we'd escape most of the issues we're facing.
Option 6. The candid approach of asking for more budget is still on the table. It's the approach I am most ambivalent about, on the argument that the company has generated more validated opportunities than its envelope assumes. There is a real case here, but innovation teams, already managing many inherent uncertainties in running these projects, prefer to show that everything is under control. I understand that, but still, here's a justifiable "emergency" to address. Worst-case scenario, we get a 'no,' and we go back to the other options.
The case against asking for more budget is also cultural. In a company where innovation is effectively a top priority, such a budget would be readily available. No questions asked. Most of the time? Innovation is a 'on paper' priority. But this is an interesting discussion, as the problem shifts from delivering strong innovation outputs to dealing with unplanned success, which ultimately challenges your innovation culture.
I probably won't share further details on where we're going with this, as the answer will be too context-specific to be useful to anyone else, but I think the dilemma we have deserves our attention: What would you do if your innovation program were twice as successful as your top management expected?
