After a failed project, I open a blank document and write down what I promised, what I delivered, and where the two diverged. Before I start the next task, I want to name the problem. Closing a browser tab feels pleasantly final. Unfortunately, the browser doesn't run the agency.
Running an agency in Tomaszów Mazowiecki, I treat this review as an ordinary part of the job. As necessary as sending a proposal. I don't need a stage, a presentation, or a speech about embracing failure. I need to know what I'll change so I don't have to sort out the same mess on the next job.
How do you review a failed project in a small agency?
I start by comparing the agreements with what was actually delivered. Then I retrace the decisions, look for the point when the problem could have been spotted, and choose a specific change to how we work. This review is useful if it affects the next project.
A project retrospective is a structured look at completed work that helps identify what to keep, what to improve, and how to check the improvement. I use the term without reverence. If it sounds too corporate, call the document “what went wrong.” It serves the same purpose.
I don't wait for a spectacular disaster. A project delivered through a frantic rescue at the end is a signal too, as is a result nobody knows how to sign off. The invoice may be issued while the way we work still needs fixing. Accounting doesn't assess my decisions. Probably best. It has enough problems already.
First, I check my own assumptions
I'm tempted to start with what someone failed to send or approve. That's a comfortable starting point. But I'd rather ask whether I clearly defined what I needed and what would happen without it. Managing a project includes noticing when the conditions needed to do the work no longer exist.
I consider accepting ambiguity a mistake of my own. “We'll sort it out somehow” isn't an agreement. It's a loan from my future self. The interest usually comes due when I wanted to close the laptop. I'd rather write down an uncomfortable unknown than cover it with optimism.
I'm not talking about taking all the blame. I separate what I could influence from what was beyond my control. I might not receive the materials. But I can decide whether to continue without them or agree on a new deadline and explain the consequences.
How do you separate facts from blame?
I describe events, decisions, and the information available at the time, instead of assigning intentions to people. I check agreements in correspondence and tasks, leaving gaps in my knowledge as questions. That lets me discuss the cause without pretending I can read minds.
“Communication was poor” explains nothing to me. I need to establish which decision didn't reach the person doing the task. The same goes for the label “difficult client.” Even if the conversation was exhausting, that label won't reveal whether we lacked approval, materials, or a shared understanding of the outcome.
I write a brief sequence of events. At each important turn, I add what I knew then. This protects me from hindsight. Today the solution may look obvious because I know the ending. During the project, I might have had only an incomplete email and a belief that everything was on track.
An example: approval that explains nothing
Imagine a hypothetical website project. The business owner approves the homepage design, and the contractor takes that as agreement on the entire site structure. Only at handover does it emerge that part of the offering was meant to be presented differently. Nobody had to deceive anyone. Different meanings of “I approve” were enough.
In this example, I wouldn't finish the review with “we need to communicate better.” I'd check exactly what was sent for review, which decision was requested, and what was recorded after the reply. I'd look for the point where the scope of approval could have been specified without another meeting.
My fix would be simple: when requesting approval, list what the decision covers and what remains open. Then put the response in the shared place for agreements. I wouldn't assume new software would solve this. Software can store misunderstandings very efficiently.
What should change after a project so the lessons leave the document?
I choose a change linked to a specific problem, name the person responsible, and decide when to check it. To start, I prefer a small improvement we can apply immediately. A wish list without an owner remains a wish list.
When recording an action, I answer these questions:
- Which observed problem should this change solve?
- Who will prepare the template or improve the way a task is handed over?
- At which upcoming stage will we use the new rule?
- How will we know whether the rule helped or merely added paperwork?
In the approval example, at the next handover I'd check whether both sides can identify the same approved scope. A new field in a task doesn't convince me on its own. If people still have to guess, the fix hasn't worked. I change it rather than defend a document because I wrote it.
I also leave room for what worked. I don't want to rebuild the entire agency after a difficult project just because I'm in a bad mood. I keep useful agreements, remove unnecessary steps, and fix something specific. That's less impressive than announcing a fresh start. But the next morning, I know where to begin.
Frequently asked questions
Is this review worth doing when I work alone? Yes. Working alone, I still make decisions based on assumptions. A written record helps me spot a recurring mistake instead of explaining it away as an exceptional situation every time.
Should I invite the client to the retrospective? When I need their perspective, I ask about a specific stage and unclear agreements. I do the internal review separately. The client conversation should clarify how the collaboration went, so I don't dump my frustrations on them.
When should I do the review? Once the immediate problem is under control and I can calmly retrace the decisions. I don't put it off until all that's left is a vague impression of the project. If emotions still get in the way, I collect facts first.
What if the same problem keeps returning? I check whether the previous change was ever put into practice and whether it addressed the cause. Another reminder to “be more careful” isn't a fix for me. I look for a working condition that lets us spot the mistake earlier.