Closing the Loop: The Framework Retrospective
Summary
- Schedule a retrospective of the innovation framework itself after every run, and protect the time before the team disperses to its next assignments.
- Gather individual input privately before any group session, so candor does not depend on who is in the room.
- Name a neutral facilitator and set a blame-free ground rule before the team-level session opens.
- Capture behaviors and assumptions, not only process changes to forms and templates.
- Assign every improvement an owner and a deadline, and approve framework revisions before the next run begins.
- Publish a short learning summary after each run and route it to a standing group, such as an innovation working group or a project management office.
- Treat sharing as a conversation, not just a database: pair written summaries with live exchanges between teams.
- Review the framework’s results and its management capability separately, and keep the review a learning exercise rather than a scoring exercise.
Why the framework needs its own retrospective
Most innovation teams are comfortable asking what they learned from a project. Far fewer ask what they learned about the way they run innovation. That second question decides whether the next run is better than the last.
Many organizations skip any review of completed innovation projects, move straight to the next one, and risk repeating earlier mistakes (Tidd & Bessant, 2018, p. 880). Learning from experience requires reflection on what happened, what worked, and what went wrong, followed by codifying the lessons and testing them the next time (Tidd & Bessant, 2018, p. 877). An innovation framework that carries ideas from team formation through handoff generates a great deal of experience in every run. That experience is lost if no one stops to examine it.
A framework retrospective sits one level above a project review. A second learning loop is needed that periodically steps back and reviews how well the whole system is working, and retunes it to a changing environment (Tidd & Bessant, 2018, p. 877). In practice, that means asking whether the team structure, the discovery methods, the stage gates, and the handoff worked, and not only whether a particular idea succeeded.
There is precedent for treating review as a catalyst for redesign. Sun Microsystems reviewed the Sun Ray failure extensively and changed its processes for developing and introducing new products as a result (White & Bruton, 2011, p. 192).
The need is sharper because this work is so easy to neglect. Review of innovative projects is highly instructive yet often neglected (Sauzet, 2026, p. 47). People finish a run tired, new priorities arrive, and the retrospective quietly drops off the calendar. The remedy is structural. Treat the retrospective as a defined stage with an owner, a block of time, and a fixed date, rather than a good intention.
Takeaway: Put the framework retrospective on the calendar when the run is scheduled, not after it ends.
Start with one-on-one conversations
The natural instinct is to gather the team and open the floor. That instinct works against honesty. When things go badly, people tend to cover up mistakes or pass blame, and group meetings can degenerate into critical sessions where little is captured (Tidd & Bessant, 2018, p. 881). A person who watched a stage gate go wrong, or who disagreed with a decision that was later reversed, may not say so in front of the sponsor or the product owner.
The goal is a culture where candor is normal. One organization found that failed ventures were once swept under the rug, and the focus then shifted toward celebrating failures as well as successes, because the organization had learned much more from failure than from success (Isaksen & Tidd, 2006, p. 337). Leaders can reinforce that shift in how they run these conversations. A project manager can create an environment of psychological safety where team members feel comfortable admitting to gaps, and can normalize test-fail-learn cycles (Runtasewee & González Sánchez, 2026, p. 92). Opening each conversation by saying that the framework is under review, not the individual, sets the tone.
Anonymity is a useful tool when trust is still developing. An anonymous team check is the safest way to surface views, while open rating raises both the challenge and the potential learning (Goller & Bessant, 2017, p. 127). Match the method to the team’s maturity: a first-run team might complete a short anonymous questionnaire before being interviewed.
How feedback is phrased matters as much as how it is gathered. Feedback works best when it describes the situation, then the behavior, then its effect, which makes it concrete and non-threatening, and when it avoids generalizations or accusations (Goller & Bessant, 2017, p. 178). Coach interviewers to ask for specific moments, such as “describe the point in discovery when you felt the most stuck, and what happened next,” instead of general ratings. Specifics are easier to act on and harder to dismiss.
Keep the interview guide short and identical for every participant, covering what worked, what did not, what surprised them, and what they would change about the framework. Summarize themes without names, and tell participants in advance how their comments will be used.
Takeaway: Hold a short private conversation with each member before the group session, using the same three or four questions for everyone, and promise that comments will be shared without attribution.
Run the team-level session
Once individual views are in hand, the team session can focus on patterns and decisions instead of first impressions. A sprint retrospective is a private team meeting to reflect on the process and identify improvements for the next cycle (Runtasewee & González Sánchez, 2026, p. 159). That description fits the framework retrospective well, with one adjustment: the process under review is the whole framework, and the cycle is the next run.
A workable structure borrows from agile practice. In one description of the practice, teams record deviations between planned and realized work, discuss what went well and what needs improvement, and select suggestions to follow next (Schweitzer & Tidd, 2018, p. 217). For an innovation framework, the deviations might include how long discovery took against the plan, how many ideas survived the proposal stage gate, and how the prototype feedback loop compared with expectations. Starting from facts keeps the conversation from becoming a contest of opinions.
Formats can be light. Retrospective formats can be playful, such as mapping what each participant is mad, sad, or glad about, and they improve team motivation and interaction (Breuer et al., 2022, p. 161).
Divide the session into two halves. Failure analysis can look backward at causes and forward at a plausible new path (Kerzner, 2023, p. 386). In the first half, the team reconstructs what happened and why, using the themes from the individual conversations. In the second half, it turns to what the framework should do differently.
The facilitator carries much of the session’s success. Participants must trust the facilitator, and a facilitator provides more questions than answers (Kerzner, 2023, p. 359). Someone who took part in the run has a stake in its reputation and may steer the conversation without meaning to. A facilitator from outside the team, perhaps from the innovation working group or a project management office, can ask the uncomfortable questions more easily. Whoever plays the role should state the ground rules at the start: the framework is under review, not the people, and every observation should come with a specific example.
Takeaway: Use a facilitator who was not on the team, time-box the session, and split it into looking back and looking ahead.
Capture what matters
A retrospective that produces only a good conversation has failed. The value comes from what is written down, in a form others can find and use. That requires deciding in advance what to capture.
A structured review explores how far objectives were met, what went well, what could improve, and what specific learning points were raised (Tidd & Bessant, 2018, p. 880). Those four prompts are a sound core for any template. A fuller report can go further. A final report can include the original plan and major revisions, budget and schedule variances, evaluation of team and management performance, lessons learned, and recommended changes (White & Bruton, 2011, p. 192). For a framework retrospective, adapt these headings to the framework’s own stages: team formation, discovery, proposal, prototyping, executive presentation, and handoff.
Look beyond mechanics. Reviews usually focus on changes to forms, guidelines, templates, and checklists, while behavioral practices that may have caused a failure get little attention (Kerzner, 2023, p. 387). A template should therefore include prompts about behavior: whether stakeholders were consulted early, whether dissent was welcomed, whether the sponsor engaged, and whether the handoff conversation happened in time. These questions are harder to answer than whether a form was complete, and they are often the ones that matter.
Capture assumptions, too. Innovation projects may warrant extra metrics, such as how many assumptions were made and how many changed over the life cycle (Kerzner, 2023, p. 387). Applied to the framework, a team can record which assumptions it made about stakeholder availability, prototype cost, or approval timing, and which of those proved wrong. That record is a practical early warning for the next run.
Good capture begins before the retrospective. Reviews run better when documentation was maintained during the project, because memory of team members is faulty (White & Bruton, 2011, p. 191). Ask the framework’s facilitator to keep a short running log of decisions, deviations, and surprises throughout the run, so the session starts from a record and not from recollection.
Finally, capture what can travel. Retrospectives can separate the learning produced, the possibility of transferring it, and the project’s positive and negative impacts on society, users, and customers (Sauzet, 2026, p. 47).
Takeaway: Provide a one-page template with prompts for results, process, behaviors, assumptions, and transferable lessons, and fill in the facts during the run.
Turn findings into a better framework
Findings change nothing until someone owns them. Organizations with mature learning practices hold formal forums with action plans that lead to changes in procedures and indicators (Bessant, 2003, p. 237). The forum matters, but the action plan matters more. Every finding should be sorted into one of three outcomes: keep as is, change, or drop. Each change needs a named owner and a due date, and the owner should be someone with the authority to revise the framework’s documents.
Be deliberate about the pace of revision. Capturing knowledge in procedures helps only if people are committed to using them, and an organization can become resistant to changing procedures it has written down (Tidd & Bessant, 2018, p. 881). Both risks apply to a framework. A framework that is rewritten after every run confuses the people who use it, and a framework that is never rewritten hardens into ritual. A good compromise is to batch changes, publish a versioned update on a predictable schedule, and note what changed and why.
Expect some resistance. Learning also involves unlearning, and there is a strong pull back to the status quo (Tidd & Bessant, 2018, p. 878). Teams grow attached to familiar steps, even weak ones. When the retrospective proposes dropping a step, present the evidence that led there, and give the people who valued that step a chance to respond before the decision is final.
Close the loop in writing. At the end of an iteration, the team should document a decision in writing for the next iteration (Runtasewee & González Sánchez, 2026, p. 99). Applied here, the retrospective should end with a brief decision record: which changes will be made, who owns them, and when the revised framework takes effect. Executive sponsors should see this record, because it shows that their investment in the run produced a better system as well as a set of outputs.
Takeaway: Sort findings into keep, change, and drop, give each change an owner and a due date, and publish a versioned framework before the next run.
Share what you learned
A retrospective that stays inside one team helps one team. The larger payoff comes when learning reaches the people who will run the framework next, including facilitators in other parts of the organization.
Sharing needs mechanisms, not just good intentions. Knowledge-sharing mechanisms should ensure that learning is accessible and usable across relevant teams (Sauzet, 2026, p. 47). A one- or two-page summary that follows a consistent format, published to a shared location, is a good baseline. Include what the run set out to do, what happened, what the team will change, and what other teams might borrow.
Be candid about what did not work. Sharing failure stories gives others a road map and a kind of vicarious learning (Tidd & Bessant, 2018, p. 880). A summary that reads like a press release teaches nothing. A summary that explains a stalled prototype loop or a missed stakeholder can save the next team weeks.
Do not rely on documents alone. At one engineering consultancy, engineers rated conversations with colleagues as twice as valuable as knowledge databases, partly because tacit knowledge is hard to codify (Bessant & Tidd, 2015, p. 445). That finding argues for pairing the written summary with a live briefing. A short presentation to an innovation working group or a project management office, followed by questions, moves tacit knowledge in ways a document cannot.
Cross-group transfer deserves attention. Knowledge transfer between groups can be helped by translators and knowledge brokers (Tidd & Bessant, 2018, p. 796). Name a person who can describe the findings in the language of each audience. Engineering leaders may care about handoff friction, product owners about stakeholder engagement, and executives about stage-gate decisions. A broker who can speak to each makes the lessons land.
Over time, the accumulated summaries become a portfolio-level resource. The more synergies a firm develops across projects, the more likely it is to be more effective and efficient than competitors (White & Bruton, 2011, p. 193).
Takeaway: Pair a written summary with a live briefing to an innovation working group or project management office, and name a broker for each audience.
Keep the habit alive
The hardest part of a retrospective is doing it again. Common reasons post-project reviews are skipped include a sense that the project is over, barriers to sharing knowledge, and management not allowing time (White & Bruton, 2011, p. 192). Each of these has a structural answer. Put the session on the calendar before the run begins, make the template short enough to finish, and ask sponsors to treat the retrospective as part of the run, not an optional extra.
Keep the spirit of the exercise learning-oriented. The purpose of reviewing innovation management is structured reflection, not scoring points, and the regular discussion matters more than precise scores (Tidd & Bessant, 2018, p. 883). If participants begin to feel graded, candor falls and the retrospective loses its value. Use ratings sparingly, and use them to prompt conversation.
Separate two questions that are easy to blur. Two questions frame an audit: how well results were delivered, and how well the underlying capability was managed (Tidd & Bessant, 2018, p. 883). A run can deliver strong outputs through heroic effort while the framework itself creaks, and a run can produce modest outputs while the framework works well. Looking at each question independently prevents a good result from hiding a weak process.
Senior leaders can take part, too. A leadership exercise in which each leader rates effectiveness on a sticky note reveals consensus and differences (Benraouane & Harrington, 2021, p. 104). Asking sponsors and executives to rate the framework before each run, and again afterward, shows where their expectations and the team’s experience diverge. That conversation often does more to build support than any report.
Takeaway: Review results and management capability as two separate questions, and ask leaders to rate both before each run.
Bibliography
Benraouane, S. A., & Harrington, H. J. (2021). Using the ISO 56002 innovation management system: A practical guide for implementation and building a culture of innovation. Routledge.
Bessant, J. (2003). High-involvement innovation: Building and sustaining competitive advantage through continuous change. Wiley.
Bessant, J., & Tidd, J. (2015). Innovation and entrepreneurship (3rd ed.). Wiley.
Breuer, H., Bessant, J., & Gudiksen, S. (2022). Gamification for innovators and entrepreneurs: Using games to drive innovation and facilitate learning. De Gruyter.
Goller, I., & Bessant, J. (2017). Creativity for innovation management: Tools and techniques for creative thinking in practice. Routledge.
Isaksen, S., & Tidd, J. (2006). Meeting the innovation challenge: Leadership for transformation and growth. Wiley.
Kerzner, H. (2023). Innovation project management: Methods, case studies, and tools for managing innovation projects (2nd ed.). Wiley.
Runtasewee, M. J., & González Sánchez, A. (2026). Managing AI projects: Drive innovation and successfully navigate the full AI project lifecycle. O’Reilly Media.
Sauzet, F. (2026). Innovation management in practice: Understanding and acting with ISO 56001. Routledge.
Schweitzer, F., & Tidd, J. (2018). Innovation heroes: Understanding customers as a valuable innovation resource. World Scientific.
Tidd, J., & Bessant, J. (2018). Managing innovation: Integrating technological, market and organizational change (6th ed.). Wiley.
White, M. A., & Bruton, G. D. (2011). The management of technology and innovation: A strategic approach (2nd ed.). South-Western Cengage Learning.