How to Measure the Value You Create as Project Manager When No Spreadsheet Can
| "What are we actually paying this person for?" Sometimes... It is a fair question. Most people, unfortunately, use it badly. Once a year, I sit with a version of it myself. Not the salary, not the title, but something harder to put on a payslip. What difference did I make, and how would things have gone without me? I mentioned in another article that I use a note-taking system to highlight a few of the contributions I made to the projects I was working on, and try to be very specific about the things that are not easily showcased in a "project overview". Because, of course, many of those will not be quite clear. For example, if I took the lead to avoid a big project risk or remove an impediment, or the way I negotiated a scope trade-off with a stakeholder, etc However, there was a point in my career when I learned a term from economists that supported this whole thinking about "project management ROI": Utility. Utility is one of those words that sounds academic until it describes your normal Tuesday morning. In economics, utility is the satisfaction or benefit you get from something. It is personal, it shifts with the moment, and it almost never matches the price tag. Picture the first coffee of the day. You are tired, foggy, three emails behind. That three-dollar cup feels close to priceless. Now picture the third cup. Same coffee, same price, far less benefit. Economists call this diminishing marginal utility, the idea that each extra unit of the same thing gives you a little less than the one before. The lesson hiding in there is simple. Value is not a fixed property of the thing. It depends on what it does for someone, at a specific moment, under specific pressure. A project manager is worth thinking about the same way. Some of what we deliver is easy to count. A project kept on time and on budget. Scope creep stopped before it quietly doubled the work. A vendor rate renegotiated. These land in numbers a CFO recognizes, and the numbers can be large. The data backs the instinct. PMI's research, through the Salary Survey and the Pulse of the Profession, keeps pointing the same way: organizations lean harder on project management precisely because complex work fails expensively without it. I think about one project that taught me this the hard way. After enough digging and a few honest conversations, the math became clear. Finishing it would burn more than a million dollars on something that was not going to work. My recommendation was to cancel. Stop it. Not a popular thing to say in a room that had already spent and promised. But it helped executives make a decision, freed the money, the people, and the calendar for work that had a real chance. Here is where the spreadsheet runs out of room... A team that trusts each other solves problems faster. A risk caught early never becomes the crisis everyone remembers. A confused goal made clear on a Tuesday saves a hundred small wrong turns later. None of that lands cleanly in a budget line. All of it changes how a project ends. Not only what we deliver, but how. The same result can leave a team burned out and quietly job-hunting, or steady and willing to do it again. How we deliver shapes whether anyone wants to work with us a second time. That part rarely makes the performance review. It is often the most durable value we create. How to Catch Your Own Impact Before You Forget ItThe trouble with utility is that it is forgettable, especially your own. By December, you cannot remember the March decision that saved the project delivery. So I keep a running note I have kept for years, sometimes a plain file where I drop the moments that mattered as they happen. If you want to track your own, a few honest categories help:
They are evidence, the kind you want in your hand during a performance conversation, when good work rarely speaks for itself. The Better QuestionMost organizations ask what a project manager costs. Far fewer ask the question that matters more: how much worse off would we be without one? Measured well, a good project manager tends to create more value than they ever take home. That is not a flattering story we tell ourselves. It is the arithmetic of utility, applied to a role that spends most of its time preventing the disasters nobody ends up seeing. So maybe the year-end question is worth stealing. Not what you were paid, but this: If your seat had been empty all year, what would have gone wrong that nobody would have thought to blame on the absence? |
Posted on: July 08, 2026 01:00 AM
| Permalink |
Comments (2)
The Drivers Behind Every Motivated Project Team
| Two project teams. Same technical skill, same tools, same brief. One delivers something that quietly impresses everyone. The other delivers the minimum and goes home. Same skill, right? Should be the same result. It rarely is. And the gap is almost never competence. The answer is usually somewhere else entirely. It is in whether the work matched the thing that actually moves each person doing it. Motivation is not a fixed trait. It behaves more like a phone battery. It drains, it recharges, and not everything charges it the same way. The most useful frame for this is Self-Determination Theory, from Edward Deci and Richard Ryan. They argue that people stay motivated from the inside when three needs are met: some control over how they work, the feeling of getting good at something, and a real connection to other people. When those are there, the energy renews on its own. When they are missing, people fall back on the contract. They do what they are paid to do, and not a gram more. The first mistake is easy to make and hard to catch. Most project managers assume everyone wants what they want. If you are driven by ownership and visible progress, you hand people ownership and visibility, wait for them to light up, and cannot understand why some do not. The projection is natural. It is also quietly damaging. Give a public award to someone who values stability and you do not reward them, you make them anxious. Put heavy process around someone who needs room to work their own way and their output drops. Same gesture, opposite effect. The motivation was never universal. It was personal, and you were reading it through yours. How to find what actually charges each personYou do not find this by watching. You find it by asking, and asking well. The question that works best is simple. Ask each person to describe a moment at work when they felt most engaged and most proud of what they did. Then stop talking and listen for the pattern under the story. Three patterns come up often enough to be worth naming. Some people light up around autonomy and mastery. They want control over their method and a problem hard enough to be worth their expertise. Daniel Pink put this at the center of Drive, and it holds up. These people tell stories about designing their own solution, not about being handed one. Some light up around people and purpose. They talk about a customer's reaction, about helping a teammate get unstuck, about whether the project actually matters to anyone. The work has to connect to a human on the other end. And some light up around advancement and recognition. They talk about the next step, about owning something bigger, about presenting their work to the people who decide things. Visibility is not vanity for them. It is fuel. Finding what charges someone is only half of it. You also have to find what drains them, and that is a different list. There is a whole category of things that inspire nobody but quietly cost you. Status meetings that exist out of habit. Priorities that change every week. Forms that take an afternoon. None of it motivates anyone. All of it drains the battery. For someone driven by deep technical work, three hours of weekly status reporting can erase most of the satisfaction the actual work gave them, and you will not see it on any dashboard. Match the work to the driver, on purposeSkill decides whether someone can do the work. The driver decides how much of themselves they bring to it. Those are two different things, and we keep treating them as one. Once you know what drives each person, the assignment stops being random. The person driven by autonomy does their best work as the single owner of something complex and technical, given control of the method and shielded from oversight they did not ask for. The person driven by people and purpose is who you want on the cross-functional seams, the coordination and the knowledge transfer, where the human impact stays in view. The person driven by recognition is who you put on the visible deliverable, the milestone presented to senior stakeholders, where being seen is built into the job. Put the stability-driven person on the big stage and you get strain, even when they are completely capable. The reward of the task fights the thing that keeps them going. Capable, and still drained. It happens more than we admit. Alignment sets the baseline. Momentum is what holds it. The strongest driver of daily motivation is not a reward at all. It is the feeling of making real progress on something that matters. Teresa Amabile and Steven Kramer found this across thousands of daily work diaries and wrote it up in The Progress Principle. Small, frequent wins beat rare big ones. So break the work into pieces that finish something visible every day or two, then acknowledge each one out loud, in the language of that person's driver. Same win, said three different ways, depending on who did it. The burnout you will not see comingBurnout is not really about hours. It is about effort that goes on and on with no sense of progress or reward. The work feels heavy, the wins stop landing, and slowly the person stops caring. The hardest part is that your best people hide it. They keep delivering right up until the day they withdraw or hand in their notice, and by then it is late. There is a simple fix. A short recurring check-in, just two questions. On a scale of one to five, how is your energy right now. And what is the single biggest thing dragging on your focus. That turns something invisible into something you can see, which means it is finally something you can act on. Remove the drag, or lighten the load. It is a different way of leading entirely. You stop moving people around like line items and start working with the specific person in front of you. A project leader who knows what charges each person, hands them work that fits, and protects their sense of progress is managing the one input that budget and tooling cannot substitute for. Technical capability gets a project staffed. Motivational alignment determines whether that capability is actually spent. So maybe the question worth sitting with is not how skilled your team is. You already staffed for that. Maybe it is this: when was the last time you asked someone what actually charges them, and then changed the work because of the answer? |
Posted on: July 06, 2026 01:00 AM
| Permalink |
Comments (5)
Will AI Take Your PM Job? You Are Asking the Wrong Question
| The real risk is not automation. It is staying busy with work a tool could do while the work only you can do goes unbuilt. There is a lot of noise right now about how AI will change project management. New tools every week. Bold predictions. The same anxious question sits under all of it. Will this take my job? I think we are asking the wrong question. The better one is a little uncomfortable... Which parts of my week could a tool already do, and which parts does this project depend on only me for? If you cannot answer that clearly today, that is the signal to stop and look. So here is a small exercise... You take your real tasks, the ones that actually fill your week, and you sort them into three lists. List 1: Tasks AI Can Do Today, Not Someday
List 2: Tasks Only You Can Do as the Project Manager
List 3: Tasks Nobody Should Be Doing Anymore
McKinsey has estimated that knowledge workers spend close to 30 percent of their time on work that existing tools could already automate. In project management, that 30 percent has a familiar shape. Admin that never ends. Reporting loops. Busywork that feels productive and moves nothing forward. AI taking your job is not really the risk. The risk is that someone finally looks at everything in your List 1 and automates it for you, and you are left exposed because you never built the muscle for List 2. Your value was never in producing the report. It was in the judgment behind it. That muscle gets built now, not when the next tool ships. And you do not need software for this. A scrap of paper or your notes app is enough. The format is not the point. The honesty is. When I run this with teams, I ask for 20 minutes. Write the three lists, put them on the table, and compare them openly. If you do it alone, do not overthink it. Write what comes to mind first. The gut answers are usually the honest ones. And if you are brave enough, share your List 1 with your team. Show them what you are willing to hand off. You might find out how many of them were quietly thinking the same thing. Projects do not succeed or fail in the formatting of a deck. They turn on the human, messy, high-pressure moments. The decision nobody wants to own. The conflict everyone is tiptoeing around. The stakeholder who goes quiet at exactly the wrong time. That is List 2, and it is the part of the job no tool is coming to do for you. The longer you stay parked in Lists 1 and 3, the harder it gets to reclaim your space in List 2 later. This is the quiet version of becoming a Jira jockey, the PM who stays busy and slowly stops leading. Sometimes we all need a small, uncomfortable mirror. This one helped me see my own week more clearly. So before your next planning session, try it. Three lists, twenty minutes, no editing for comfort. Then look at where your week actually goes. Is that where your value is? |
Posted on: July 01, 2026 01:00 AM
| Permalink |
Comments (2)
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)
