A short pre-mortem turns quiet launch concerns into owned controls before fixes become expensive. The plan is approved. The launch date is in the calendar. Everyone is busy closing actions. Yet a few people have a quiet concern: training may not reach night-shift staff, the support team may not be ready, or the new process may create extra work at the worst possible time. Those concerns often surface in side conversations, not in the risk register. By the time they become official issues, the team has fewer choices and every fix costs more. A project pre-mortem gives the team permission to say the uncomfortable things early. It is a short, structured exercise that imagines the change has already failed, then asks what caused the failure. The aim is not pessimism. It is to find preventable problems while there is still time to act. Why This Matters Most projects do some form of risk management, but the quality of the conversation varies. A long risk register can create ...
A lightweight decision log preserves the outcome, reason, owner and review trigger so teams can move forward without repeating the same discussion. You leave a meeting with a clear decision. Two weeks later, the same topic appears again in another meeting. Someone missed the context. Someone else remembers a different version. A new stakeholder asks why the option was rejected. Suddenly the team is not progressing the work. It is reopening the past. This is one of the quiet ways projects lose time. Most teams do not suffer from a lack of decisions. They suffer from decisions that disappear into meeting notes, emails, chat threads, slide decks and people’s memory. When that happens, every change in stakeholder, priority or pressure creates an opportunity to relitigate something that was already resolved. A decision log is a simple way to stop that drift. Not a bureaucracy. Not a governance artefact for its own sake. A lightweight record of what was decided, why it wa...