Hier erfahren Sie, wie Sie nach einem gescheiterten Business-Innovationsprojekt effektiv nachbesprechen können.

As they say we learn from our mistakes so take the learnings from this and create something better. Data is king so use whatever you have

Debriefing after a failed project involves a candid and constructive approach. I start by gathering the team to openly discuss what went wrong and identify key learning points. My personal touch includes sharing my own experiences with setbacks, emphasizing that failure is a step toward improvement. We focus on actionable insights and adjust our strategies accordingly. This reflective practice not only builds resilience but also fosters a culture of continuous learning and innovation.

One of the most important, yet overlooked aspects of a team debrief is to make sure that the conversation stays objective and blameless. Teams built on trust and objectivity perform better than teams who accuse and have high levels of tension. A moderator or assigned leader should set the rules of the road for any retrospective activity. This is especially crucial when analyzing a failed project, because you need to get to the root cause and you cannot if the team is at odds with each other. A cohesive team will get better results and will better prepare for and mitigate future potential failures than a fractured team. Blameless retrospective analysis will help teams get to the real "why" instead of a surface-level understanding.

A lessons learned at the end of any project is always a good idea. In my relevant past, I'd lead an open brainstorm with the project team to gather their feedback. If the project encountered specific problems, I recommend doing a Root Cause Analysis, using a Ishikawa / Fishbone Diagram: specify the failure(s), brainstorm causes, decide on the root cause(s).

After a Root Cause Analysis brainstorm is completed, per my post above, and root causes have been defined, we need to figure out WHY these happened: did we (not) follow the existing processes, check lists, practices etc? The next question is WHAT we can change in the system, our processes, practices etc to prevent this from happening again in the next project.

When desired process changes have been identified, these need of course be implemented. What I see often happen with my clients is that they implement a change and then walk away, thinking all's good. This is where the C and A of Deming's PDCA-cycle comes in play: after Planning for a change and Implementing (Do) this change, we truly need to Monitor (Check) the effectiveness of the change. Only after we observe that the changed process is better than the original should we conclude that the new process is the new baseline.

More related to Continuous Improvement, rather than complete projects, but following the same principal approach, I recommend implementing a simple but effective Non-Conformance Reporting Process. Any time anything goes wrong, anywhere in the business, take this as an opportunity to improve the process. I call NCR's a reactive way of Continuous Improvement, one "Oops" at a time. How: - Open an NCR (make sure people understand they are not "being written up") - Describe the problem - Analyze the root cause of why this happened - Identify possible process changes - Implement the change, train staff etc - Monitor that the change is working better, enforce adherence - Confirm this is now the new process, or start from the beginning.

Add key lessons and clear rationale on why it failed backed by data. Also state the positives which are always there like key learnings and new skills acquired and how they can help the business in the future. Create an SOP for tackling such projects in the future if time allows too.