Raf Sanga dot com

Turn a review conversation into a few owned, testable improvements. A project milestone finishes, the team takes a breath, and someone says, “We should capture the lessons.” A document is opened. People add a few polite comments. The file is saved, and the next project repeats the same delays, unclear hand-offs and avoidable rework. The problem is not that teams fail to collect lessons. It is that they stop at collection. A useful learning review does more than record what happened. It turns experience into a small number of changes, gives each change an owner, and checks whether the change actually improved the work. That makes the review part of delivery, not an administrative ceremony after delivery. Why this matters The Australian Institute for Disaster Resilience describes lessons management as a cycle of collection, analysis, implementation, and monitoring and review. Although its handbook was developed for emergency management, it says the principles can be used by a...

Before announcing a change, map how the work will differ for each role. A polished all-staff email is not a change plan. Before you announce a new system, process or policy, ask a more practical question: who will have to work differently on Monday morning? A project can be approved, a system can be nearly ready and a training session can be booked, while the people doing the work still do not know what will change for them. The problem is not always that communication arrived too late. Often, the project moved to communication and training before it understood the operational impact. A simple change-impact map makes that impact visible. It compares today’s way of working with the future way of working for each affected role or group, then connects the difference to a practical support action. Why this matters A change can look small in a project plan but feel large to the person doing the work. Replacing a shared mailbox with an online form may sound like a technology chang...

Check operational readiness before the project team hands over the service. A project can look finished on paper and still be unready for real life. Testing is complete, the launch date is booked and communications are drafted. Then someone asks: Who handles the first support request on Monday morning? The room goes quiet. That question exposes the gap between delivery readiness and operational readiness. Delivery readiness asks, “Did we build what we agreed?” Operational readiness asks, “Can people run, support and improve this service once the project team steps back?” Both matter. A successful go-live needs more than a completed deliverable. Why operational readiness matters Projects are temporary, but services continue. Without clear ownership, training, support, contingencies and measures, the project team becomes the unofficial support team and operational knowledge stays in people’s heads. PMI’s guidance on project closing warns about this exact handover gap. The peo...

A small, controlled pilot makes the benefits and limits of workplace AI visible before a broader rollout. Someone demonstrates an AI tool in a meeting. The output looks impressive. Within days, people are using it for different tasks, with different data, in different ways. Nobody is quite sure what is approved, what should be checked, or whether the tool is actually saving time. At the other extreme, a team spends months discussing AI governance without testing a single useful task. The risks are documented, but the opportunity remains theoretical. There is a practical middle path: run a small, time-boxed workplace AI pilot. Not a technology showcase. Not a promise to transform the organisation. A controlled test of one task, with clear boundaries and a decision at the end. Why a small pilot matters Its value also depends on the task. A tool that helps draft a routine internal summary may be a poor fit for making consequential decisions about people. That is why “Do...

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...