Stop Writing Lessons Learned. Start Writing Improvement Contracts
| Every project ends. The question is whether the organization gets smarter when it does... In most environments, closure looks like this: the team is disbanded, a final report is filed, and within days, everyone has moved on to the next initiative. The lessons learned meeting, if it happens at all, becomes a session of vague observations and careful diplomacy. Then the document is saved somewhere no one revisits. The result is predictable. The same failures reappear. Missed dependencies. Communication gaps. Unrealistic estimates. Not because the team lacked effort, but because the organization lacked structure. Knowledge observed but not applied is not organizational learning. It is organized forgetting. The Retrospective Is Broken Before It BeginsThe first failure happens inside the review itself. Most post-project retrospectives are built on two flawed assumptions: that people remember the project accurately, and that they will honestly account for their own role in what went wrong. Neither holds. Recency bias makes the final weeks feel more significant than they were. Self-protection quietly shapes how contributions and mistakes are described. The result is a distorted picture of what actually occurred. The fix is structural. Instead of open discussion, the retrospective should be organized around four specific process questions. Did the planning estimates accurately predict task duration, and if not, was the error in the breakdown or driven by external factors? When deadlines were missed, did the accountable party own the problem immediately, or did accountability diffuse? Did senior stakeholders receive the right level of information, or were they still asking basic status questions? Of the risks identified, did the mitigation actions reduce their likelihood, and did the contingency plans reduce the impact when risks materialized? These questions move the conversation from personal blame to process evidence. The findings point to specific procedural weaknesses, which are exactly where improvement is possible. One additional discipline belongs in this meeting: success dissection. When a milestone is delivered on time and with high quality, the team should ask what specific behavior or process made it possible. Continuous improvement is not only about finding what broke. It is about codifying what worked well enough to repeat. From Insight to ContractThe second failure is what happens after the meeting ends. Most organizations capture lessons and file them. The abstract recommendation, "improve stakeholder engagement," "plan more carefully next time," gets written down and forgotten. This is the gap between lessons observed and lessons applied, and it is where most improvement programs die. Every finding from a retrospective deserves to be converted into a System Improvement Contract: a structured commitment with four elements. A clear description of the process failure. A specific, measurable action to address it. One named individual, typically outside the project team, who owns the fix. And a mandatory completion date. Abstract recommendations are unactionable by design. Concrete contracts are not. This transforms "we need to plan better" into "the Definition of Done template for training deliverables must be revised to require an 85% user comprehension score, completed by end of quarter, owned by the PMO lead." The difference between those two statements is the difference between an intention and an improvement. The knowledge also needs to be pulled forward into the next project, not left behind in a file. A practical mechanism for this is a formal checkpoint at every new project kickoff, where the team confirms the status of the top improvement contracts from the previous project. If the fix is complete, the new project benefits from it. If it is not, the team must allocate resources to compensate for the gap, or secure explicit executive approval to proceed with the risk acknowledged. This single protocol makes improvement visible and embeds the expectation that every project should be measurably better than the last. The Knowledge That Walks Out the DoorThere is a third gap that is less discussed: distribution. Project knowledge tends to live inside specific teams, specific files, or specific people. When a new project manager begins a similar initiative, they often cannot access the experience of their predecessors. They start from scratch, and the cycle continues. A simple, curated repository, one that stores only validated improvement contracts and documented successful behaviors, changes this. Not meeting notes or status reports. Just the problem, the solution, the owner, and the practice worth replicating. Every project leader should be required to review the most relevant entries during the initial planning phase. That is what transforms a storage system into an active reference. When team members transition off a project, a 30-minute knowledge transfer conversation before they leave often surfaces the most candid insights, particularly around organizational dynamics and process gaps that never made it into the formal retrospective. This conversation also signals something important: that individual experience is valued, and that the organization is genuinely committed to learning, not just to documenting that learning occurred. What This Actually RequiresThe difference between organizations that improve and organizations that merely complete projects comes down to one discipline: the willingness to stop, examine what happened, and act on it in a way that changes the next project before it begins. Knowledge, unlike equipment or budget, compounds. The organization that builds a repeatable learning loop after every project creates an asset that cannot be depreciated and cannot be outsourced. The one that files the lessons learned document and moves on starts over every time. The question is not whether there is time for this. The question is whether the organization can afford to keep asking why the same problems keep coming back. |
Posted on: June 29, 2026 01:00 AM
| Permalink |
Comments (1)
We Called It Agile, Then We Buried It
| How a two-minute manifesto turned into a certification economy, and what it costs the teams still living inside it. Somewhere along the way, a simple idea got heavy. It started light. A few people sitting close together, talking often, shipping small pieces of software, getting feedback fast. If something was wrong, they changed direction the next week, not the next quarter. People felt like they had some control. Work moved. The customer was happier. Then the idea grew up. And growing up, in this case, meant getting complicated. In 2001, seventeen people met at a ski lodge in Snowbird, Utah, and wrote the Agile Manifesto. Four values. A page so short you can read the whole thing in two minutes. That was the seed. Look at what grew from it. Certifications appeared. Frameworks appeared. Coaches, badges, two-day courses, ladders of titles. Everyone had their own flavor of Agile, and most of them were selling it like a product. The lightweight idea turned into a system. The system turned into a business. Today a lot of teams proudly say they are "Agile." But what they actually run is a long list of roles, rituals, and reports. People do not collaborate better. They follow the process and hope it works. The two-minute page became a certification economy. And somewhere in that trade, the point quietly left the room. Sound familiar? At some point we confused Agile with speed. Not learning. Not adapting. Just delivering faster. But speed was never the point. Feedback was. Adaptation was. Small, safe failures that teach you something before they cost you something. Speed is what happens when that whole thing works. It is the result, not the goal. And here is the part that stings... Chasing speed actually slows you down. You build the wrong feature. You skip validation. You ship something nobody asked for. Then you spend three weeks fixing what one honest question would have caught in the first week. A team moving fast without learning is just automating its worst decisions, very efficiently. You can watch it happen. The burndown chart looks beautiful. Every sprint closes on time. The dashboard is green. And yet the product drifts further from what the customer actually needed, week after well-measured week. Everyone is busy. Nobody is sure it is working. Speed is what a healthy process produces. It is not something you can demand directly. So when someone says "we need to go faster," the useful answer is rarely a new sprint cadence. It is usually a better question asked earlier. The same hunger shows up right at the start, especially with people leading their first big project. They try to plan everything before they begin. Every step mapped. Every risk predicted. Every detail signed off before a single thing ships. It feels responsible. It feels safe. It is neither. Real projects do not behave. People change their minds. Priorities shift on a Wednesday for reasons that made no sense on Monday. A blocker shows up that no plan saw coming. The more time you pour into perfecting the plan, the longer you go without the one thing that actually moves a project forward, which is a small result people can see and touch. It is a bit like trying to draw the perfect map of a road you have never driven. You will get half the turns wrong, and you will only find out once the car is moving. The plan is not the project. Movement is. The embarrassingly small thing that worksSo what does work? Something almost too small to brag about. Deliver one piece. Quickly. Low risk. Let people see it work. Each small win buys a little trust, and trust, not velocity, is the real currency of any project. Momentum follows trust. Never the other way around. Then you do it again. And again. And the belief in the outcome grows with every visible step. You still adjust as you go. You still plan. But you plan enough to start, not enough to stall. If you are leading your first project right now, here is the whole method, with no certification required:
Notice that none of this needs a framework. It needs a clear mission, a real conversation, and the courage to deliver something imperfect on purpose. Before you blame the manifestoWhen Agile does not work, it is tempting to say "Agile is not a good fit for us" or "Agile failed in our organization." Most of the time, that is not what happened. We failed to understand it. We wanted the benefits without the mindset. The outcomes without the culture. The speed without the trust. So we took something light and flexible and slowly turned it back into the rigid system it was built to replace. We added roles, rules, rituals, and reports. We tried to measure creativity with a velocity chart. We swapped real collaboration for a standup script that everyone recites while staring at their shoes. And then we wondered why teams felt burned out and disconnected. If Agile is not working on your team, the problem is probably not the manifesto. It is the mirror (yes, you got it). That is harder to hear than "the framework was wrong," because a framework you can swap. A mirror you have to face. And facing it is cheaper than it sounds. It does not mean firing the coaches or canceling every ceremony. It means asking, honestly, which of those rituals still creates trust and which ones only create the appearance of work. Keep the first kind. Quietly retire the second. The way out is the same size as the way inThe good news hiding in all of this is that the fix is small. The same size as the original idea. You do not need a new methodology. You do not need another certificate on the wall. You need a clear mission, an honest conversation with the people doing the work, and one low-risk piece you can deliver before the end of the week instead of the end of the quarter. Pick the small thing. Ship it. Earn the trust. Repeat. And the next time someone in the room says "we need to be more Agile," it is worth pausing and asking what they actually mean. Do they want the team to learn faster? Or do they just want it to move faster? Because those are two very different projects. And only one of them tends to arrive. |
Posted on: June 24, 2026 01:00 AM
| Permalink |
Comments (3)
What Happens to Your Lessons Learned After the Meeting Ends?
| The finding gets filed, named, and forgotten. The owner, deadline, and sign-off that turn a lessons learned note into a fix the next project actually uses. Have you ever left a lessons learned session feeling like something actually changed? I have sat through ninety-minute reviews where people took turns listing complaints dressed up as feedback. I have also been the one facilitating, trying to keep the energy up while watching everyone mentally check out. You write the document. You give it a name. You file it. And somewhere in the back of your head, you already know nobody is opening that folder until the next project. Which will repeat the same mistakes anyway. So we check the box. And we move on. Or? Maybe not? What do you do? The problem is not that we skip the review. Most teams run one. The problem is what we think a review is supposed to do. Chris Argyris, working with Donald Schön, described two types of learning that I think explain exactly why most post-project reviews fail. Single-loop learning fixes the error. Double-loop learning asks why the system produced the error in the first place. Argyris used a thermostat as the example. A thermostat set to 21 degrees does its job perfectly well. Room gets cold, it kicks the heat on. Room warms up, it shuts off. It corrects the gap, over and over, all day long. What it never does is ask whether 21 is the right number. Or whether someone left a window open. That is single-loop. Reliable, tireless, and completely blind to its own assumptions. Most lessons learned sessions live exactly there. "The vendor was late." "Communication broke down in week four." "The scope changed too many times." All true. And almost useless for stopping the same thing from happening again, because they describe what happened without ever asking what in the process allowed it to happen. The shift from symptom to system is the whole game. Why did they use the wrong specs? Keep asking.Let me make this concrete with something that will probably sound familiar. An integration fails testing for two weeks, late in the project, when everyone is already tired. The typical review lands on: "The development team used the wrong specifications." The fix? "Make sure everyone uses the right specs next time." That is not a fix. That is a wish. A diagnostic review keeps pulling the thread. Why did they use the wrong specs? Because the updated version was filed in the wrong place. Why was it in the wrong place? Because nobody owns document control on this team. Why does nobody own it? Because we never assigned it. By the fourth or fifth why, you are no longer talking about a developer who slipped up. You are talking about a gap in the process that will come back, in a different costume, on the next project. That is the difference between a lessons learned document and an actual lesson. The room fills with whatever you do not put on the tableWhen a team walks in without shared data in front of them, what fills the room is emotional recall. People remember the most recent frustration. They remember the personality clash, not the structural failure hiding behind it. And almost nobody is going to criticize a process their own manager designed. I have seen this dynamic kill good reviews. The room wants to be honest. But honesty without data is just venting. The way to change this is not complicated, but it asks for discipline before the meeting even begins. The project leader puts three objective numbers on the table.
This is where the lesson goes to dieThen there is what happens after the meeting ends. And this is where I think most organizations quietly give back everything they just worked so hard to find. The finding gets written up. Someone attaches it to a SharePoint folder. The folder gets a name like "Lessons Learned 2024 Q3." And the next project kicks off without anyone reading it, because nobody made reading it mandatory. Nobody handed the fix to someone with the authority to actually change the process. It is like writing down that the smoke alarm needs a new battery, sticking the note on the fridge, and then wondering why you are buying a new smoke alarm two years later. The fix is simple. Every real finding from a review becomes a task with a named owner, a deadline, and a confirmation step at the start of the next project. Did the fix get applied? If not, the project leader needs executive sign-off to proceed with the known gap still open. That small friction is the whole mechanism. It closes the loop. Without it, you are collecting insights. Not learning. Three questions. Almost nobody answers all three.The organizations that actually get better over time are not the ones running the most reviews. They are the ones that treat every review as a conversation between the project that just ended and the one about to begin. What did we learn? Who owns fixing it? Is the fix in place before we start again? Three questions. Most teams never answer all three. Maybe worth sitting with that for a minute. What did your last post-project review actually change? |
Posted on: June 22, 2026 01:00 AM
| Permalink |
Comments (5)
The Longest Project You Will Ever Manage
| Applying baselines, risk logs, and stakeholder maps to the one project that follows you everywhere. I know... Most project managers can produce a stakeholder register, a risk log, and a full set of baselines for a client initiative. Far fewer have ever built the equivalent for the longest project they will ever run, which is their own career. The neglect is rarely deliberate. It follows from an assumption that sounds reasonable and so goes unexamined: do good work, and the work will speak for itself. Deliver the project, protect the budget, keep the sponsor calm, and the next role arrives on its own. That assumption misreads what a promotion is. A promotion is not a reward for work already completed. It is a forward-looking decision about what a person can be trusted to carry next. Organizations advance people on expected future contribution, not on a record of past delivery alone. Peter Drucker described this gap in "Managing Oneself." His argument was that knowledge workers must take responsibility for their own development and positioning, because no employer will do it reliably on their behalf. The discipline a project manager applies to external work is precisely the discipline missing from the internal one. Every project begins with a baseline. Career management should begin the same way, with an accurate reading of current capability. The difficulty is that self-assessment is one of the least reliable inputs available. Most people think they know what they are good at. They are usually wrong. That observation, also from Drucker, is the reason structured external feedback exists. The entire premise of 360-degree feedback is that individuals tend to overrate their interpersonal strengths and underrate the specific competencies that the next level demands. The gap between how a person sees their own performance and how the surrounding room reads it is where careers most often stall. The correction is to replace self-assessment with observation. Two questions, put to a manager, a trusted peer, and a sponsor, are usually enough. The first asks what single contribution saves the most time or cost, which identifies the strength worth being known for. The second asks what capability would be missing if the person were handed a project twice the size of their largest to date. That answer is the single development priority. Not a list of courses. One skill. The conventional sequence, earn the title and then perform the role, is reversed in practice. Capability is demonstrated first, and the title formalizes a contribution that is already visible. This is how competency-based advancement actually operates, since organizations promote against observed behavior rather than stated potential. The mechanism is available in most environments. There is usually an unowned problem one level above the current role: an unnamed risk on an adjacent project, a process everyone complains about and no one owns, a review that keeps being postponed. Taking responsibility for one of these, and then recording the outcome in measurable terms, converts effort into evidence. Hours recovered, a risk closed before it materialized, a delay that did not happen. Enthusiasm does not advance careers, but measured evidence does. When the conversation about a next step finally takes place, the case rests on a record rather than a request. That conversation introduces a second factor, one that operates independently of competence. Advancement decisions are typically made in discussions the candidate never attends. The relevant question is what the people in that discussion actually know about the contribution. Quiet, effective delivery carries a specific liability. Work that succeeds without visible strain is often read as work that was easy, so the better the firefighting, the more invisible it becomes. The correction is not constant self-promotion. It is accurate, occasional communication of impact to the people who shape advancement decisions, stated as fact. A risk identified in March that avoided a defined cost in June is a contribution to a record, not a performance. Peer and cross-functional advocacy carries unusual weight here. When a finance manager or an engineering lead represents a person's value in that room, the endorsement is more credible than any self-description. Management research on sponsorship, as distinct from mentorship, describes this directly: advancement accelerates when established figures actively speak for a person in their absence. This reframes the question that early-career project managers most often ask. Instead of focusing on when an organization will grant a promotion, the more productive focus is on which parts of the next role a person is already performing, visibly and with evidence. Understood this way, a promotion is largely administrative. It is the formal record catching up with a contribution that was established months earlier. Your career is a project with no defined end, no handover, and no closing phase. It still requires a baseline, one clear development priority, documented evidence of contribution, and a map of the people who will discuss it when it matters. The discipline already exists in every competent project manager. It only needs to be turned inward. |
Posted on: June 15, 2026 01:00 AM
| Permalink |
Comments (0)
Project Manager: Stop Waiting for Good Work to Speak for Itself
| Most project managers who stall in their careers are not bad at the job. They are just invisible. And the frustrating part? The work is there. The crises averted, the schedules held, the stakeholder conflicts resolved before they escalated... it all happened. It happened quietly, and that is exactly the problem. Quiet is the enemy of career growth. The Myth That Good Work Speaks for Itself There is a belief a lot of us carry, often without noticing it, that excellent work will eventually be recognized. That the right people will connect the dots. Those results open doors on their own. They don't. Not automatically. The organizations we work in are complex social systems, and senior leaders see only a fraction of what you actually do. They catch the status report, the governance meeting, maybe a quick corridor update. Everything in between, which is usually where your real value lives, stays invisible. Credibility is not a reward for hard work. It is an asset you have to build, document, and position strategically. The difference between a PM who advances and one who doesn't is rarely competence. It is almost always how well that competence reaches the people who make decisions about careers. The vendor who almost derailed the timeline. The budget risk you caught three weeks early. The scope conflict you resolved before it hit the steering committee. From where your executives sat, everything looked green. That is excellent leadership. But also, when you shield the organization from chaos, which you absolutely should, the side effect is that your most impressive work leaves no trace. The executive sees a smooth delivery and assumes it was a smooth project. You have to document the storm, not just the calm weather. A practical way to do this is what I call the CAV Story, short for Challenge, Action, Value. For every major crisis you handle, write three things down: what was about to go wrong and how bad it would have been, what you specifically did to prevent it, and what the organization saved as a result in time, money, or strategic outcome. Not a long document. A few lines. Something you can pull out when it matters. "We were facing a six-week delay and a $500K penalty. I convened the team and the vendor for a focused session, negotiated a rollback, and we held the original launch date." That is a CAV Story. Career ammunition, instead of disappearing into the noise of the next sprint. I spent years thinking delivery was enough. It isn't. Getting Your Results in Front of the Right People Evidence alone is not enough. You need it to travel. The steering committee meeting is not just a governance checkpoint. It is your most valuable stage, and most PMs use it only to report status. The ones who advance use it to demonstrate judgment. There is a real difference between saying "we have a vendor risk" and saying "we identified a vendor risk early and here is how we contained it." One makes you a reporter. The other makes you a strategist. Same situation, completely different impression. The same logic applies to how you write your executive updates. Filter complexity for your team. Elevate outcomes for leadership. Frame your wins in the language executives actually care about: time, cost, and strategic delivery. Keep it short. Make it land. And don't overlook the people around you. A colleague or sponsor who mentions your contribution in a cross-functional meeting does more for your credibility than anything you say about yourself. That kind of third-party validation is hard to manufacture and easy to earn, if you ask for it clearly and right after the moment happens. "I think I'm ready for the next role." That framing puts you in a weak position from the first sentence. You are asking for something. They are deciding whether to give it. Reframe it entirely. Walk into that conversation with documented evidence, your CAV Stories, the complexity you managed, the financial stakes you controlled, and make the case that the organization has a gap you are already equipped to fill. You are not asking for a title. You are proposing a solution to a real problem, and you happen to be the most logical person to own it. That shift changes the whole dynamic of the conversation. This is not self-promotion. It is strategic alignment of your track record with an organizational need. Senior leaders feel the difference immediately. The work was always there. Now make sure the story is too. What would change in your next career conversation if you walked in with three documented wins instead of a feeling that you deserved more? |
Posted on: June 08, 2026 01:00 AM
| Permalink |
Comments (2)
