Knowing when to kill a project
How difficult is it to kill a project within your organization?
In this day and age when innovation is encouraged at what point does leadership team step in and kill projects especially when organization bias gets in the way of good decision making.
Scott Cook We use an execution framework called 4DX, which is a strategy designed by Sean Covey, Jim Huling and Chris McChesney in their book The 4 Disciplines of Execution. While this framework is used to prioritize wildly important goals (WIGs) from the day-to-day whirlwind of work activities, it can be adapted for innovation management too. Essentially, part of the framework is identifying leading and lagging measures and utilizing a scorecard to evaluate results. So, in innovation management, when commercializing new products (formulation, packaging, etc.), we consistently measure industry, market, customer and category data during commercialization to determine the potential scalability and ROI for a launch. If the numbers are not where we need them to be, we exit, or postpone.
One of our innovation metrics is the number of projects stopped. It's tracked in our monthly reporting. We don't have a goal to hit, but it has made it more acceptable to kill a project for a myriad of reasons (time, money, pilot results) Great conversations and practices have resulted from this.
The key driver of any project is how relevant it is to the organization objectives and the returns that it will give when completed. The management should step in to kill a project the moment organization objectives are no longer aligned to what the project set out to achieve. What it means is even if project is successful, it will not provide anything useful to the organization per se. In today's world, fast changing Technology is one of the key drivers, but there could be many more ranging from external factors like change in govt regulations to internal issues such as change in priorities triggered by a restructuring etc.