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 (0)
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 (1)
The Real Reason Your AI Project Is Going Nowhere
| Walk into any leadership meeting today, and someone has just come back from a conference. There was a demo. It looked impressive. And now there's pressure, that particular kind of pressure that doesn't have a deadline yet but already feels urgent, to "do something with AI." Budgets get approved. A team gets pulled together. The mood in the room feels like the beginning of something. Then the months pass. The proof of concept works fine in the controlled environment where everyone is watching. But moving it into production becomes a slow grind nobody prepared for. Integration stalls. The data your team needs turns out to be locked behind a permissions process that takes six weeks. Deadlines shift. The energy fades. And eventually, the project gets reframed, delayed, or quietly shelved. The official explanation is usually something like "AI turned out to be more complex than expected." That explanation is polite. And incomplete. Here's what the retrospective usually won't say: the algorithm was almost never the problem. The models being used today are advanced, well-tested, often open source. What breaks an AI initiative is whether the organization's data is accurate, accessible, and integrated, what people in this field call "data readiness." Think of it like a football pitch full of holes. You can have the best strikers, the most expensive coaching staff, the smartest tactics... but if the field is unplayable, the game is already lost before kickoff. In AI projects, those "holes" show up in three specific places:
If your AI project collapses, the cause is almost always one of these three. Not the algorithm. The foundation. And here's the uncomfortable part: most people inside the project know this from day one. Data is messy. Integration is unclear. Permissions will take forever. But because these problems feel unglamorous next to shiny demos and impressive model benchmarks, they get pushed aside until it's too late. Where Project Managers Actually Need to Step InManaging an AI project does not mean becoming a data scientist. You don't need to build pipelines or design neural networks yourself. But you do need to take ownership of whether the foundations are in place before the project is allowed to move forward. That governance responsibility gets handed off to "IT" more often than it should. And when it does, nobody really owns it. Here's what actually stepping in looks like: Make data readiness visible. Create scorecards with four or five clear metrics: completeness of fields, error rates, duplication levels, how fresh the data is. Simple enough that anyone can read them in a status meeting. And then enforce them. Projects with red scores don't advance, no matter how compelling the demo was. Build data checkpoints into your stage gates. Stage gates are the structured review points where a project must prove it's ready before moving to the next phase. Extend them. At discovery, require that datasets are mapped with clear owners. At feasibility, demand profiling results. At pilot, require automated checks running for at least 30 days. At scale, 90-day stability with monitoring and rollback plans. This stops enthusiasm from skipping the boring but necessary preparation. Make ownership real, not decorative. Everyone agrees with "data ownership" as a concept, until actual responsibility is required. Be explicit about who approves schema changes, who checks quality daily, who enforces the gates. And tie those roles to budgets and performance reviews. Without accountability, ownership is just a word on a slide. Think across the portfolio, not just the project. One failed AI initiative is painful. Ten failed initiatives across different parts of the organization, all for the same underlying reason, is something else entirely. Publish readiness heatmaps across domains. Map dependencies between initiatives. Link funding to readiness scores. If one part of the organization is consistently not ready, leadership needs to see it. Monitor after go-live. Passing a gate is not the end of the job. Data drifts. Systems change. Business definitions evolve. Build monitoring into your definition of done, from the beginning. NASA lost the Mars Climate Orbiter in 1999 because one team used metric units and another used imperial. A $125 million spacecraft disintegrated in the atmosphere because of a mismatch in definitions. The science was correct. The integration wasn't. AI projects carry the same fragility. Brilliant models cannot survive poor definitions, weak ownership, or inconsistent systems. And the people best positioned to prevent that fragility are not the data scientists, not the vendors... they're the project managers and PMOs, the ones trained to make invisible risks visible and hold the line when pressure says to move faster. So here's the question worth sitting with honestly: if your AI project stalls this year, will it be because the model underperformed, or because the data was never ready to begin with? That's not a philosophical question. It's an operational one. And answering it before the kickoff might be the most valuable thing a project manager can do right now. |
Posted on: June 01, 2026 01:00 AM
| Permalink |
Comments (0)
Why Systems Thinking Will Change How You Run Projects
| Most of us were trained to think in deliverables, milestones, and Gantt charts. You get a scope, you build a plan, you track progress. That loop feels productive, and honestly, for a long time it works well enough... until it doesn't. Because here's what no certification course really prepares you for: projects do not behave like machines. You can't take them apart, fix a component, and put them back together expecting everything to run smoothly. They behave more like living systems, full of hidden interactions, tensions, and surprises that no schedule can fully predict. And if you only look at the visible tasks, you will keep missing the forces that actually decide whether your project succeeds or quietly falls apart. That's where systems thinking comes in. Systems theory doesn't make projects easier. It makes them clearer. And clarity is worth a lot when you're caught between shifting priorities, tangled dependencies, and human drama. This article walks through five systems theories that were each born in a different discipline, yet each one carries real lessons for how we manage projects today. These are not academic concepts to memorize and forget. They are lenses that change what you see, and therefore what you can do. In 1968, a biologist named Ludwig von Bertalanffy published his General Systems Theory, the idea that no system can be understood in isolation. A system (whether it's an organism, an organization, or a project) is open, meaning it is constantly connected to its environment, influenced by flows of information, energy, and feedback from the outside. That was biology. But it fits projects almost perfectly. Think about a project with several external suppliers. The schedule looks clean on paper, each delivery neatly boxed in. Then one vendor hits a delay. The ripple moves through your plan. Resources get shifted. Pressure builds. Other teams adjust. Suddenly you're rewriting the schedule not because anyone managed poorly, but because the system reacted to something outside it, exactly as an open system does. The lesson here is uncomfortable: you cannot control a project by controlling its parts. You have to watch the feedback loops, the external pressures, the signals coming back from the environment. The real test of a project is not whether the plan was precise. It's whether the project adapted to what came back at it. Here's where most PMs quietly make a mistake. We try to run projects like miniature versions of permanent organizations, expecting stable roles, lasting culture, and built-up loyalty. But projects are transitional by design. They are born, they live for a defined period, and then they close. The people involved enter with different expectations, different levels of engagement, and often different definitions of success. And you, as the project manager, have almost no time to build trust or establish a real team culture before execution is already underway. This reframes a critical question: What does this team need in its first two weeks to actually function as a unit? And then later, as the project moves from exploration into execution and eventually into closure, the leadership style that worked in week three may actively harm you in week twenty. If you design governance that assumes permanence, it won't fit a project that exists for 18 months and disappears. Design for the temporary. Plan for the transition. The Tool Won't Save You If the People Aren't ReadyIn the 1950s, researchers Eric Trist and Ken Bamforth studied something strange happening in British coal mines. A new technical design for the work had been introduced. On paper, it looked more efficient. In practice, it broke down the informal social connections that miners had built over years. Morale dropped. Turnover increased. Productivity suffered. The technical system and the social system had been separated, and both failed. We repeat this mistake constantly in project management, just with newer tools. A new collaboration platform gets rolled out to "streamline communication." But people feel excluded from the decision, or overwhelmed by the change, or quietly skeptical of whether it will stick. So they create workarounds, keep using email, duplicate data in two places. The technical improvement becomes a coordination tax. Sociotechnical systems theory (the formal name for what Trist and Bamforth discovered) does not argue that you should care about people for sentimental reasons. It argues that the technical system only works when the social system supports it. These two dimensions are not separate concerns. They are one system. The practical question every PM should carry into any change: When I introduce a new tool or process, am I watching the human signals as carefully as the technical metrics? If the answer is no, you're only managing half of what's actually happening. Five Functions That Determine If Your Project Can SurviveIn 1972, management cyberneticist Stafford Beer published his Viable Systems Model, a framework (a structured way of analyzing complex systems) that describes what any system needs in order to survive in a changing environment. He identified five necessary functions:
Beer also argued that these systems are recursive, meaning each part of the system contains the same structure as the whole. A portfolio contains projects. A project contains workstreams. A workstream contains teams. And each level needs its own version of all five functions to operate well. When something feels off in a project, this model gives you a diagnostic question: which of the five functions is weak or missing right now? Often the work is getting done (operations), but coordination is failing and teams are duplicating effort. Or control is reporting, but intelligence is absent and nobody is scanning for what's changing outside the project. Or policy is unclear and the team is making directional decisions it was never authorized to make. Viability doesn't fail because people aren't working hard enough. It fails because the system is structurally incomplete. Peter Morris, one of the leading thinkers in project management research, challenged a comfortable assumption in 1994: that project management is primarily about executing a well-defined plan. His argument was sharper than that. Projects succeed or fail mostly at the front end, during the phase where strategy is defined, governance is established, and the project is integrated into the broader organization. He called this the "management of projects" perspective, as opposed to just "managing within a project." Think of project architecture the way you'd think of the architecture of a building, not the decoration, but the structural decisions that determine what the finished thing can and cannot do. A project's architecture includes: who has decision rights, how conflicts get resolved, what the escalation path looks like, how the project connects to its parent organization's strategy, and what the communication structure actually is. When the architecture is weak, you feel it in execution. Who really decides on scope changes? How are competing priorities resolved when two sponsors disagree? What happens when a risk escalates beyond the project level? Without those structures in place, execution stumbles, not because people aren't capable, but because the project was never properly designed. The lesson: do not rush into task planning before you have designed the architecture. A few days spent clarifying governance and communication at the front end may save months of confusion later. But look at how projects are actually run today, in your organization, on your current project, and tell me honestly: are these mistakes still happening? Too many projects still operate as if they were closed systems. Teams plan in isolation, assume the schedule is independent, and then act surprised when external politics, regulations, or stakeholder priorities break their assumptions. A systemic lens forces you to ask, what external forces are shaping us right now, and do we have channels to sense and respond to them? We keep forgetting the temporary nature. Leaders copy governance from permanent organizations and expect loyalty, stability, and cultural alignment in a project that exists for 14 months. The better question to start with: how do we accelerate trust and clarity for a team that only exists for a short time? On the sociotechnical side, the trap today is digital tools. A new platform is launched, resistance appears, hidden workarounds multiply, and leadership is confused because the technology worked in the demo. Trist and Bamforth would have predicted that outcome. And on the architecture side, organizations are rushing into digital transformations with energy, intent, and budget, but without clear governance or decision rights. Months later, contradictions surface. Unclear sponsors. Competing objectives. No escalation path. The architecture was never drawn, so execution could never hold. Five Questions Worth Carrying Into Your Next Project MeetingHere's the honest challenge: you probably can't apply all five of these frameworks at once, and you shouldn't try. But you can start with one question. Tomorrow, when you walk into your project meeting, instead of jumping straight to the task list, try one of these:
That shift from managing tasks to managing systems is uncomfortable, because systems are harder to see, harder to measure, and harder to fix than a task list. But it is the only way to get closer to what's actually happening in your projects. And getting closer to reality, that's what separates the PMs who are genuinely in control from the ones who are perpetually surprised. |
Posted on: May 25, 2026 01:00 AM
| Permalink |
Comments (1)
