Why Volunteer Projects Build Stronger Project Leaders
| Most project managers build their leadership inside a single structure: one organization, one reporting line, and one set of incentives that makes people at least appear to follow the plan. That structure is useful for delivery, but it hides a question every project manager eventually faces, which is how much of their influence belongs to them and how much is borrowed from the org chart. Volunteering in professional communities, with PMI chapters as the most common entry point, is one of the few settings where that question gets an honest answer early in a career. It removes formal authority, reduces resources to almost nothing, and puts the project manager in front of people who owe them nothing except the time they chose to give. In a corporate project, part of the team's compliance is structural. People respond because the project manager shapes priorities, reports progress to their managers, or controls access to budget. (Sometimes...) Volunteer teams remove all of these levers, since contributors join because they believe in the goal and can leave at any moment without consequence. This is close to the condition Allan Cohen and David Bradford describe in Influence Without Authority, where influence depends on understanding what the other party values and offering something of equivalent worth in exchange. In a volunteer context those currencies are rarely money or status. They are purpose, learning, recognition, and the chance to work on something the contributor cares about, and a project manager who cannot identify them usually loses the team within a few weeks. The PMBOK Guide, Seventh Edition, lists "Demonstrate leadership behaviors" among its twelve principles and treats leadership as something any team member can exercise, independent of title. Volunteer work is a practical environment to test that principle without the safety net of positional power. Leadership developed where authority is absent tends to hold when authority is present, while the reverse is far less reliable. PMI's Talent Triangle groups the competencies of a project professional into Ways of Working, Power Skills, and Business Acumen. Certification preparation covers the first reasonably well. The second, which includes communication, collaborative leadership, and problem-solving, is much harder to develop in a classroom, and volunteer projects exercise it under realistic pressure. Adaptability under scarcity. Volunteer initiatives routinely combine firm deadlines with rotating contributors and free or improvised tools, and delivering under those conditions trains the habit of simplifying scope, reprioritizing quickly, and protecting the core outcome, which is what PMBOK 7 describes in its principle on adaptability and resiliency. Networks built on shared work. Mark Granovetter's 1973 paper on the strength of weak ties showed that connections outside a person's immediate circle carry a disproportionate share of new information and opportunities, and volunteer teams create exactly those ties across industries, seniority levels, and countries, with the added trust that comes from months of joint effort. Clarity for mixed audiences. A single volunteer initiative may require the same project manager to brief a chapter board, coordinate a student volunteer, and report progress to community members in the same week, so jargon fails with at least one audience and plain-language status updates become a constant discipline. The widely cited 70-20-10 model, associated with research at the Center for Creative Leadership, suggests that most leadership development comes from challenging experience, with relationships and formal coursework accounting for smaller shares. The exact proportions are debated in the literature, but the direction is consistent. Stretch assignments are where leadership capability grows, and early-career project managers rarely receive them inside their organizations, because stretch assignments tend to go to people who have already demonstrated the capability. Volunteering interrupts that loop. A second-year project manager can lead a chapter event, a mentoring program, or a content initiative with real stakeholders and real deadlines years before a comparable role would be offered at work. That was actually my case in my early years as a volunteer at PMI. The value, however, depends heavily on the role chosen. Passive membership (attending events and collecting professional development units) produces little of what is described above. The benefit comes from roles with delivery accountability, where there is a defined outcome, a team to coordinate, and a date that cannot move. The most accessible place to find those roles is usually the nearest PMI chapter. Chapters run events, mentoring programs, certification study groups, and community initiatives almost entirely through volunteers, and most of them have open roles at any given time that nobody has claimed. For an early-career project manager, the local chapter is a portfolio of real projects that requires no promotion to access, only the decision to ask for one. The practical step is small. Contact the chapter's volunteer lead or check its website, ask which initiatives currently need someone to own delivery, and choose one with a visible outcome within the next three to six months. That single commitment gives influence, adaptability, and communication a place to develop now, instead of waiting for a corporate role that may take years to offer the same exposure. Every project manager's career will eventually test whether their leadership depends on the org chart. A chapter role lets that test happen early, on a smaller scale, and on the project manager's own terms. |
Posted on: October 19, 2026 01:00 AM
| Permalink |
Comments (0)
Why Most Retrospectives Produce Documentation Instead of Learning
| Most project teams hold retrospectives. Far fewer can name a process change that originated in one and was still in place three months later. The gap is rarely a matter of attendance or goodwill. Teams show up, answer the three standard questions (what went well, what did not, what could improve), record the answers, and return to work. When the next cycle surfaces the same issues, the session has produced documentation without producing learning. The Agile Manifesto frames the purpose of the practice in its twelfth principle: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." The principle carries two actions of equal weight, reflecting and adjusting. Most retrospectives deliver the first and skip the second. Why retrospectives stay shallowDonald Schön, in The Reflective Practitioner (1983), distinguished reflection-in-action from reflection-on-action. The second, the deliberate interpretation of experience after the fact, is where professional learning takes place. Without it, teams accumulate events without drawing conclusions from them. Deliberate interpretation carries a psychological cost. Findings that threaten self-image, such as a flawed plan or a failed communication, trigger cognitive dissonance, the tendency described by Leon Festinger to resolve discomfort by rationalizing or attributing causes externally. In a group setting the result is predictable: discussion stays at the level of symptoms, and vendors, tools, or shifting priorities absorb the blame. The corrective is structure. A predictable, transparent process signals that the session is fair and that its target is the system. Psychological safety, in this sense, is partly a product of design. A structure that produces changeEsther Derby and Diana Larsen, in Agile Retrospectives: Making Good Teams Great (2006), propose a five-stage model that remains the most widely used reference for facilitation.
Two conditions determine whether this structure works. The first is safety. Amy Edmondson's research on psychological safety found that higher-performing teams reported more errors, because members felt able to discuss them openly. Facilitators reinforce this condition by stating Norm Kerth's Prime Directive at the start of each session: "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand." When disagreement arises, the principle from Roger Fisher and William Ury's Getting to Yes applies directly: separate the people from the problem. A facilitator who names the dynamic ("there is a lot of frustration around this topic") without attributing it to an individual keeps the conversation on the system. The second condition is follow-through. Agreed actions belong in a visible improvement tracker, each with a single owner, and the next retrospective opens by reviewing their status before any new topic is raised. This mirrors the Plan-Do-Check-Act cycle from quality management, and a retrospective without that review step has no Check and no Act. Rotating formats such as Start-Stop-Continue, the 4Ls, or Mad-Sad-Glad helps sustain engagement over many cycles. These formats are secondary, and their value depends entirely on whether the underlying structure is in place. For early-career project managers, the practical implication is direct. The quality of a retrospective is measured by the actions still active a month later, and the facilitator's primary responsibility is protecting the two stages most often compressed: data gathering at the start and decision-making at the end. |
Posted on: October 12, 2026 01:00 AM
| Permalink |
Comments (1)
Why Projects Break During the Handoffs Nobody Owns
| Most project managers can produce a dependency list. Far fewer can say, for any line on that list, which person on their own team is watching it, and on what date that person will ask for written confirmation that the upstream work is still on schedule. That distance, between listing a dependency and managing one, is where a large share of late projects actually break. The schedule was not wrong. The estimates were not wrong. Something agreed in a hallway, or buried in an email thread from 3 months earlier, quietly stopped being true, and nobody found out until the week the dependent work was supposed to start. A dependency is any relationship where one piece of work cannot start, continue, or finish until something else happens first: another task, a decision, an approval, a vendor delivery, a person coming back from leave. Teams rarely miss them because they are hard to see during planning. They miss them because a dependency raised in a kickoff and assigned to nobody is a conversation, and conversations decay. There is a second reason, more cultural than technical. Dependency mapping carries the smell of governance theatre, the kind of artifact produced to satisfy a committee and then never opened again, so teams treat it as documentation rather than as an early warning instrument. Used properly it is closer to the wiring diagram of a house. Invisible while everything works, and the only thing worth having the moment something starts to smell like smoke. Four Relationships, Two AttributesThe precedence diagramming method, documented in PMI's scheduling practice and in earlier editions of the PMBOK Guide, describes four logical relationships between activities. The distinction is practical rather than academic, because each one fails in a different way and gives a different amount of warning.
The combination worth obsessing over is external and mandatory. Internal work is visible in a standup, a board, a hallway conversation. External work is visible only when somebody asks, and the answer arrives filtered through an account manager who has an incentive to sound calm. From Acknowledgement to MonitoringIn Normal Accidents (1984), the sociologist Charles Perrow described tightly coupled systems as those with no slack between components, where a small local failure propagates before anyone can intervene. Most project schedules are considerably more tightly coupled than the people who built them believe, because every compression of the timeline removes exactly the buffer that would have absorbed a late handoff. The collapse follows a predictable sequence. The dependency exists but is undocumented, then nobody is named as its owner, then no trigger date is set for confirming it, and by the time the delay announces itself the downstream work has already lost the time it needed to adapt. Human optimism accelerates all of this. Kahneman and Tversky named the planning fallacy in 1979, the systematic tendency to underestimate the time a task will take even with direct experience of the same task going long before. Optimistic estimates combined with untracked handoffs produce a project that looks healthy for months and then meets its accumulated delay during integration and testing, which is precisely the phase with the least remaining room to recover. Four practices convert acknowledgement into monitoring, and none of them require a tool purchase. Name an owner on your own side. For every external dependency, one person on the project team is responsible for tracking the other side's progress and raising the flag when it drifts. Nobody can own work performed by another organization, though anyone can own the monitoring of it, and that ownership is what most projects never assign. Set a proximity alarm at planning time. A proximity alarm is a date on the calendar, typically 2 to 3 weeks before the due date, when the owner obtains explicit confirmation that the commitment still holds. What counts is a confirmed status, since an assumption recorded as a fact is exactly what these alarms exist to catch. Anything short of a clear yes triggers the contingency plan immediately, while the runway to use it still exists. Keep a log with fields that force precision. A causal description ("because the vendor must complete the interface before integration testing can begin, our test start depends on delivery by 30 April") makes the risk legible to anyone skimming, where the phrase "API integration" hides it. The log needs the relationship type and attributes, the upstream owner and the dependency owner, the due date and the alarm date, a status limited to on track, at risk, blocked, or resolved, the impact expressed in days and in percentage of remaining buffer, and one sentence describing the contingency. Review weekly and look for concentration. A flat list of 50 dependencies hides the shape of the risk, while a sketch of deliverables as nodes and dependencies as arrows shows immediately which node has 6 arrows pointing into it. Those convergence points deserve the earliest alarms and the most developed fallback plans, because a slip there sets several workstreams on fire at the same moment. Escalation follows the same discipline. Reporting that a vendor is late produces anxiety and a request for more detail, while reporting that the delay is 8 days and consumes 35 percent of the remaining buffer to the integration milestone produces a decision, which is the actual point of escalating. None of this removes delays. It converts an unpleasant discovery 4 weeks before launch into a manageable decision taken much earlier, when options still cost less than apologies. For a project manager early in their career, the return on this practice is unusually high relative to its cost: one workshop that asks what must be finished first, what must run in parallel, and who outside the room holds a key, a named owner for every external link, and an alarm date written into the calendar before anyone feels nervous enough to need it. |
Posted on: October 05, 2026 01:00 AM
| Permalink |
Comments (2)
Why 31% of Complex Projects Fail to Deliver Their Benefits
| Complex stopped being a category and became the working condition. PMI's 2026 data on what that does to delivery, and to your record. In the 2024 Maximizing Project Success research, PMI measured how often projects fail to achieve the full scope of their originally intended benefits. The number was 12%. The 2026 Pulse of the Profession asked the same thing about complex projects specifically. The failure rate jumped to 31%. More than double. My first reaction was to distrust the number. Different studies, different questions, and different data slices usually have a methodology story sitting quietly behind them. Then I kept reading, and the report closes that escape route firmly. A massive 97% of project professionals say they managed at least one complex project in the past year. Over half classify those projects as significantly complex. Even more telling, 81% say projects have become more complex, and 37% describe the increase as significant. So the number that matters is not the failure rate... It is the population. Complex stopped being a category of project you get handed once every few years. It became the ordinary condition of our work. This means 31% is not describing some exotic subset of megaprojects in another industry. It is describing the environment where your delivery record is being written right now. After years of using the word in status meetings, what does PMI actually mean by complex? Complicated Is a Problem You Solve.Complex Is a Problem You Keep Answering.A complicated problem has many elements, and the relationships between those elements are knowable. You can map it out. Given enough expertise, effort, and the right resources, it resolves. A refinery turnaround with 4,000 activities is complicated. It is hard and exhausting, but knowable. A complex problem also has many elements, but the relationships between them are unpredictable. Complex systems evolve through their own interactions. Working through one calls for sensing, experimenting, and adjusting rather than just executing a fixed plan. PMI defines the difficulty not by effort or expertise, but by adaptation, emergence, and interdependence.
Complexity Is Not Risk, and This Confusion Is ExpensiveComplexity describes the conditions that make the project hard to predict, control, and stabilize in the first place. Complexity is a source of risk. Risks are the consequences that come out of it. They are not two names for the same discomfort. This explains something I have watched happen more than once, and have been on the wrong side of myself. You keep a genuinely good risk register. It is reviewed, owned, dated, and scored. And the project still gets taken apart by something that was never on it. In complex environments, risks are more interconnected and more likely to emerge over time. Organizational structures, human dynamics, and external forces interact in ways that amplify small issues into large ones. You cannot register a risk that does not exist yet as an identifiable event. You can only recognize the conditions that manufacture them. When the thing that hits you was never on the register, the conversation afterwards is almost never about the conditions. It is about your register. It is about whether you should have seen it coming. You lose that conversation every time, because you are defending an artifact that was built to answer a different question. Where the Friction Actually Comes FromOrganizational: The internal friction. Unclear decision-making authority, siloed teams, competing priorities, and misaligned objectives. Escalations take longer than they used to. Approvals stall in layers you did not know existed, and the question “who owns this?” keeps coming up. This scales with size. A large 91% of professionals in organizations of 100,000 or more report increasing complexity, against 78% in organizations under 500 people. Environmental: The external forces. Technology cycles, digital transformation, AI adoption, regulatory movement, geopolitical shifts, and supply chains. Requirements keep changing while everybody is still deciding. The world around the project simply moves faster than the plan does. Emerging technology resets what stakeholders consider reasonable on speed or cost, and a market event quietly changes what the word value means to your sponsor. Human: The social and cognitive layer. Competing incentives, politics, and relationship dynamics. Decision makers avoid committing. Teams second-guess a direction that was already given. Psychological safety becomes something you aspire to rather than something you have. This dimension requires emotional intelligence, influence, and coalition building (capabilities no methodology installs for you automatically). These dimensions interact. A regulatory shift (environmental) triggers new internal approvals (organizational), which increases anxiety and micromanagement (human). One force moves through three dimensions. By the time it reaches your team, it has stopped looking like regulation and started looking like a morale problem. Nearly half of project professionals name faster technology and tool cycles as a driver of complexity. But if you only treat the technology, you will keep treating the symptom three steps upstream from where your team is actually bleeding. The Finding That Should Change How You Spend Your WeekHigh performers (professionals whose complex projects perform above average) do not face less complexity. The report is explicit about this. They face the exact same conditions but respond to them differently, using intention and foresight. The difference is massive. A full 88% of projects were rated extremely or very successful when teams were highly effective at managing complexity. Compare that with just 14% when teams were only slightly effective or ineffective. Projects that handle complexity well are five times more likely to succeed. This is not a resourcing story. It is a capability story, and capability is the one variable you personally control. You do not need a new instrument to start. You need one simple discipline, and it costs you about 90 seconds. The next time something goes wrong on your project, before you write the escalation, classify it.
A complicated problem gets escalated with a solution attached and a request for resources or a decision. A complex one gets escalated with the conditions named and a request for a different operating agreement. You might need more frequent checkpoints, a decision right moved closer to the work, or a scope boundary that can flex on purpose instead of by accident. Most of the escalations I have seen fail happened because a complex condition was presented as a complicated problem. The sponsor gave a complicated answer: push harder, add a resource, tighten the plan. Nothing moved, because nothing in that answer touched the thing generating the trouble. You can name it now. That is real progress, and most people never get that far. What you still cannot do is measure it. That gap keeps this whole thing stuck at the level of a feeling. Feelings do not survive contact with a steering committee, but evidence does. In the next piece, I will hand you an actual diagnostic. It covers 15 items across the three dimensions. Each one is scored against something observable rather than against your mood on the day. You will be able to put a number and a profile in front of your sponsor and have a completely different conversation. |
Posted on: September 28, 2026 01:00 AM
| Permalink |
Comments (3)
The Lessons Learned Session You Never Run on Yourself
| We will happily spend two hours in a lessons learned session, taking apart a project that already ended, arguing about whether the delay came from the vendor or from the scope change nobody documented, and then go three or four years without running that same exercise on our own career. The instinct is trained, and trained well. You can read a risk register and know where the trouble is before anyone says it out loud, you can look at a status report and feel in your stomach that the date is going to move, and you can sit in a steering committee and tell within five minutes who has already decided and who is still politely pretending to listen. All of that attention points outward. At the project, at the plan, at the team, at the stakeholder who went quiet. So when was the last time you pointed it at yourself? What follows is the short version of a reflection I run on myself, built around three questions. It takes about an hour if you are honest, and about fifteen minutes if you are not. Start With Strengths, and Skip the Ones on Your CV"I know Jira" is not a strength. It is a tool, and tools show up on every profile in your feed. Your real strengths are the things you do so naturally that you barely notice doing them, and they hide in three places. How you get things done. Which part of the delivery process could you teach a new team member tomorrow morning with zero preparation? That is not a random talent, that is the thing your brain has already automated, and it is usually the most reusable asset you own. Why people trust you. Who comes to you first with bad news, and what did you do to earn that? People bring problems early only to the person who does not punish them for it. If that is you, it took years to build and it is worth naming out loud. How you move direction without authority. Think of a room where priorities were a mess and the tension was real. What did you do that made the room settle? Whatever that was, it is leadership, even if your title says coordinator. Write down one sentence for each. Three sentences, and most people find that two of them are things they have never put on a CV, a profile, or a promotion case. Then the Uncomfortable Part, Which Is Your PatternsFailures usually have external causes, and those causes are often real. The budget was cut, the sponsor changed, the vendor missed. I have used every one of those explanations, and some of the time I was right. The question that actually moves your career is the other one... What do I consistently do when things go wrong? Two prompts here are worth more than all the rest. The first: when a project starts sliding, what is your first move? Some of us take all the work back into our own hands. Some go quiet and stop communicating exactly when communication matters most. Some get defensive in front of the sponsor. You already know which one you are. The second: when pressure rises, what is the first thing you stop doing? Documentation, one-on-ones, the gym, lunch away from the screen, the Friday review nobody checks. The thing you drop first under pressure is almost always the thing that was keeping the pressure from compounding. It is a bit like skipping the car service because you are already late for work. Saves you an hour today, costs you a Tuesday morning on the side of the road three months later. And then the good pattern, which almost nobody documents. Think about your best work in the last two years, and describe the conditions around it. Team shape, sponsor clarity, how much autonomy you had, how rested you were. Most of us treat great outcomes as luck. They are usually a recipe, and a recipe can be requested. Name Your Gap, and Be Honest About Which One It IsGaps are not weaknesses. They are the places you stopped growing because the next step requires something uncomfortable, and there are three that show up again and again. The strategy gap. Could you explain to someone outside your company, in plain language, why your current project matters to the business? And here is the sharper version of the same test: you are probably very good at managing risks to the schedule, the things that make a project late. Are you equally good at spotting the risks that make a project useless? The influence gap. When you present to the people who decide, do you talk about effort and detail, or about the outcome and your recommendation? A lot of us describe how hard the work was, hoping someone will draw the conclusion for us. They rarely do. The knowledge gap. A tool, a certification, a domain you keep working next to without ever learning properly. Now, notice something. The third one is by far the easiest to close, and that is exactly why so many of us pick it. Signing up for a course feels like progress, and it is real progress, but it is also a very comfortable place to hide from the strategy conversation or from the executive you have been avoiding for eight months. One Page Beats a PlanReflection that stays in your head evaporates by Thursday. Compress everything into three sentences and one commitment. My anchor strength is the one I will deliberately use and make visible in every project. My critical pattern is the one behavior I will interrupt. My primary gap is the single thing I will close, chosen on impact and not on comfort. Then one measurable behavior change for the next 30 days, small enough to survive a bad week. Not "I will be more strategic", which means nothing on a Monday morning. Something closer to "I will not answer any non-urgent message before 10, and those two hours go to the work nobody is asking me for yet." Three months on those three items beats five ambitious goals abandoned in week two. You already know this from projects. Scope discipline is not just for the plan on your screen. The projects will keep coming, they always do, and nobody is going to book that hour in your calendar for you. So, if you ran a proper lessons learned on your own last 12 months, with the same honesty you demand from your team, what would come out of it? |
Posted on: September 21, 2026 01:00 AM
| Permalink |
Comments (1)
