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 (1)
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 (0)
The Governance Failure Behind Every MVP That Became a Permanent Mess
| Most project teams can launch a minimum viable product. Fewer can govern what happens to it after validation. The MVP, as Eric Ries defined it in The Lean Startup, is a focused experiment designed to test a single market hypothesis with the least possible investment. Deliberate shortcuts are part of its logic: minimal error handling, hardcoded integrations, onboarding designed for a handful of early adopters. These trade-offs are acceptable when the only deliverable is a validated answer to "is this worth building?" The structural failure begins the moment that answer is yes. Instead of reclassifying the deliverable and funding a new project phase, most organizations treat the validated MVP as Phase I complete, claim the win, and begin adding Phase II features directly onto the temporary architecture. The experiment gets promoted to production without the foundation changing at all. A Lifecycle Classification ProblemThe root cause is a project management failure to correctly classify the deliverable's lifecycle stage. An MVP is a learning tool, but it is typically budgeted and governed as a final release. When the initial project charter closes, the most experienced engineers and designers often move to the next initiative. The newly launched MVP is handed to a smaller, frequently junior team that inherits a system defined by its known architectural compromises. The product has made a successful market entry. The project has created an unbudgeted maintenance liability. This classification error compounds because "the product" is not just the code. It is the capacity for sustainable future change. Every shortcut built into the MVP encodes an assumption that will cost significantly more to modify later than it saved during the initial build. The temporary architecture acts like cement poured too quickly. It validates the plot of land, but it makes every future renovation harder and more expensive. From MVP to Maximum Viable MessOnce validation succeeds, the pressure to add features becomes immense. Real customers arrive. Stakeholders bring diverse, often competing needs. The governance failure at this stage is the shift from focused experimentation to indiscriminate accumulation. Instead of dedicating the next phase to structural stability, every new request gets bolted onto the existing temporary frame. The MVP becomes the Maximum Viable Mess (MVM): a product defined not by what it solves, but by how many unrelated problems it touches. The MVM reveals itself through specific project signals. Simple change requests explode in scope because modifying one component of the fragile MVP foundation triggers unforeseen work in three others. Resources budgeted for new feature development are constantly diverted to unbudgeted maintenance. And the product lacks a coherent design voice because different components were built under different standards by teams working at different speeds, all on the same rickety base. Why the Trap PersistsTwo well-documented psychological mechanisms sustain this pattern. Commitment bias (Staw, 1976) makes it difficult to stop and rebuild something that is already working. Pausing external feature work to refactor the foundation feels like admitting failure and slowing momentum. The feature path appears low-risk, easy to justify to stakeholders. The refactoring path requires hard-to-explain justification and produces visible delay. Asymmetric cost visibility reinforces the bias. The cost of building a feature is immediate and quantifiable. The cost of not rebuilding the architecture is deferred and diffuse, manifesting as slower delivery cycles, rising bug counts, and maintenance overhead that appears gradually across quarters. Governance systems optimize the visible cost, which systematically defers the structural one. The Stabilization GateBreaking the cycle requires a mandatory stabilization phase between the validated MVP and the feature growth stage. This phase must be budgeted as a separate, fixed-scope project with a single objective: replacing temporary scaffolding with architecture that supports the product's actual trajectory. The phase refuses all external feature requests. Its key performance indicators are internal quality metrics, specifically, reduction in future maintenance overhead and acceleration of cycle time for non-trivial changes. The best outcome is an internal structure that makes the next project cheaper and faster, even if no customer-facing change is visible during the stabilization period. A critical component is a coherence review: a systematic audit where design and engineering leads standardize fundamental components and enforce consistent terminology. During rapid MVP builds, design coherence is the first casualty. The test for whether a product has crossed from scaling into accumulation is straightforward. If building a new feature consistently makes the existing team slower and more burdened, the product is not growing. It is compounding mess on a foundation that was never designed for the weight it now carries. The MVP remains one of the most effective tools in product development, and one of the most commonly mismanaged, precisely because its success creates the pressure that prevents the governance discipline required to move beyond it. |
Posted on: September 14, 2026 01:00 AM
| Permalink |
Comments (2)
My Lessons on Complexity from the PMI Pulse of the Profession 2026
| Which page of the 2026 Pulse of the Profession matters most to a working project manager? For me, it was a figure, sitting in the appendix, where PMI lists the levers that separate above average performers from below average ones:
And then the ones the profession actually spends its money and its evenings on.
So here its a little bit of my perspective. First things first… If you don’t know, the Pulse of the Profession is PMI’s annual read on what project professionals around the world are living through. The 2026 edition, titled Driving Success in Complex Projects, picks one subject and stays on it: project complexity. The base:
Complicated describes a problem with many elements whose relationships are knowable. Hard, yes. Solvable with expertise, effort and the right people. A payroll migration with four hundred interfaces is complicated. Complex describes many interdependent elements whose relationships are unpredictable. The system changes as you touch it. PMI’s own definition frames complexity as an inherent quality that emerges when interdependent parts interact in dynamic and often unpredictable ways, where the difficulty comes from adaptation, emergence and interdependence rather than from effort or expertise. The technical consequence is not soft at all, and this is the part I would underline for anyone who thinks the distinction is academic. Work breakdown structures, critical path, and formal change control are instruments built for the complicated. They assume knowable relationships. Applied alone to a genuinely complex project, they still produce beautiful artifacts. Baselines, dependency charts, a change log with signatures. What they no longer produce is control. They produce the feeling of control, which is a different product and a much more dangerous one, because it delays the moment when somebody says out loud that the plan stopped describing reality. The report’s answer to complexity is sensing, experimentation and adjustment. Not a fixed plan. Also, Complexity is not risk. Risk management deals with identifiable factors that could hit the project. Complexity describes the conditions that make a project hard to predict and stabilize in the first place. Complexity is a source of risk. Risks are consequences of complexity. Which means a complete, well maintained, fully scored risk register in a complex project is still a partially blind instrument. It catalogs what you could name at the time you named it. In complex environments, risks interconnect and emerge over time, so the register describes last month’s system. Where Complexity Comes From: Three DimensionsPMI groups the sources into three dimensions. This is deliberately simplified, and they say so, pointing to a fuller treatment in the upcoming second edition of the Navigating Complexity practice guide. For diagnostic use, the simplification works well. Organizational The internal friction. Unclear decision authority, siloed teams, competing priorities, misaligned objectives. It scales with company size: 91% of professionals in organizations of 100,000 or more report increasing complexity, against 78% in organizations under 500. Thirteen points. Environmental The external forces. Technology cycles, digital transformation and AI, regulatory movement, geopolitics, supply chains, third parties. What it looks like: requirements move not because the stakeholder cannot decide, but because the world around the project is moving faster than the plan that describes it. Human The social and cognitive layer. Competing incentives, politics, relationship dynamics. What it looks like: decision makers avoiding commitment, teams second guessing direction, and psychological safety becoming an aspiration rather than a baseline expectation. The Gap That Should Be the Real HeadlinePMI reports separately what project professionals say and what senior leaders say. On causes, leaders point outward more than practitioners do. Faster technology and tool cycles: 57% of leaders against 45% of professionals, a twelve point gap. Digital transformation and AI: 47% against 40%. Political and regulatory instability: 38% against 30%. Practitioners point at the room instead. More stakeholders across functions and geographies, and expanded decision making responsibility, both four points higher among professionals than among leaders. Same environment. Two different diagnoses. And when the diagnosis does not match, the prescription cannot match either, which is precisely the strategy execution gap that CEOs name as their top problem in PMI’s own CEO survey. Then look at the outcomes table, where the same gap gets sharper and, honestly, a little uncomfortable:
A team fatigued by one complex project carries that fatigue into the next one, and the report is explicit that this compounds. It is the cost that never appears in a status report, because there is no field for it. If you take one action from this whole document, make it this one: put team capacity language into your reporting in a form a sponsor can act on. What Actually Works, and What Only Feels Like It WorksThe finding underneath everything else in this section is that high performers do not face less complexity. They face the same conditions and respond to them differently. Projects where complexity is handled effectively are five times more likely to succeed, with 88% rated extremely or very successful when teams were highly effective at managing it, against 14% when teams were only slightly effective or ineffective. PMI surfaces five practices tied to better outcomes in complex projects.
The PMO’s contribution here is not process. It is that practices get institutionalized instead of depending on whichever project manager happens to be diligent. One more number, easy to miss: only 23% of project professionals identify systems thinking as critical for handling complexity. In a report arguing that projects are webs of interdependencies rather than lists of tasks, fewer than one in four practitioners name the lens the whole argument depends on. Ok, so? If you want it to change something on Monday, four moves:
Systems do not submit to a baseline. They get read, adjusted, and read again. What I keep coming back to is that none of the five practices are new. Sponsor alignment, stakeholder engagement, momentum, scenarios, frameworks. The difference the data shows is not knowledge. It is application, done early and on purpose, by people who already knew about it. Which is the uncomfortable part, right? The gap is not between what we know and what exists. It is between what we know and what we did last quarter. So, before your next steering committee: which of those five are you actually running on your hardest project right now, and which one have you been meaning to start since the kickoff? |
Posted on: September 07, 2026 01:00 AM
| Permalink |
Comments (0)
Stop Waiting the Status to Turn Red: Signals That Predict Project Failure Early
| Behavioral and structural signals predict schedule failure weeks before budget and schedule variance catch up. One thing that I learned over time, is that a project can be reported as green on Monday and enter open crisis three weeks later, without a single number changing in between. That sequence is common enough to be predictable, and it is rarely caused by an event nobody could have foreseen. It is caused by the choice of instrument. Budget variance, schedule adherence, and percentage complete are the metrics most steering committees ask for first. All three are lagging indicators, measuring the consumption of something already spent, which makes them accurate, auditable, and structurally late. By the time one of them turns red, the deterioration behind it has usually been building for weeks. But leading indicators work on a different layer. They are behavioral and structural signals that predict a schedule or quality failure before it becomes visible in any report, and they are less comfortable to work with, because they require interpretation rather than arithmetic. They are also the only signals that arrive early enough to be useful. And there is a documented reason these signals stay hidden longer than they should. Amy Edmondson's research on psychological safety describes how people under pressure, particularly high performers, delay disclosing a problem while they try to solve it quietly on their own. Calling that dishonesty misses the mechanism. It is a rational response to an environment where raising a problem early carries a personal cost. Which leads to an uncomfortable operating assumption. A project manager who learns about problems from verbal reports is receiving information that has already passed through a filter, and the filter tightens exactly when the project is under the most strain. Where Commitment Erodes FirstA plan holds only as long as the team still believes it is achievable. When that belief starts to slip, people do not usually announce it. They narrow their focus, protect their own scope, and stop investing energy in problems that belong to someone else. That withdrawal is observable, and it shows up in three specific patterns.
The same erosion appears outside the team, in how the wider organization responds. Every RACI model includes a Consulted role, people whose input is required but who carry no accountability for the outcome. That asymmetry is where most external delay is manufactured. The pattern is easy to recognize once named. A decision promised in three days reaches day five with no answer, a security review is acknowledged and never scheduled, and feedback arrives vague enough that it commits nobody to anything. None of that is neutral waiting. It is schedule risk that originates entirely outside the project team's control and lands entirely on the project team's timeline. Escalating it as a personal complaint about responsiveness almost never works, because it asks a busy executive to care about the project manager's frustration. Escalating the same fact as a quantified risk usually does work. A late decision that is consuming two days of project buffer per day of delay is a statement in the language governance bodies already use, and it converts an interpersonal problem into a portfolio one. Where the Plan Quietly BendsThe last category of leading indicators lives in the integrity of the work itself. Teams under deadline pressure take shortcuts and intend to return to them, and that intention is usually sincere. It is also usually wrong, because the time to repair the shortcut is rarely cheaper later than it would have been at the time. The clearest version of this signal is a compromised Definition of Done. The Scrum Guide describes it as the shared, agreed set of criteria a piece of work must meet before it can be considered complete, and its value comes entirely from being non-negotiable. A task reported as done with two steps deferred has been recorded as finished while remaining unfinished in the system. That is worse than being late, because it removes the delay from the schedule and stores it in the phase with the least slack to absorb it. The second signal is more objective and easier to track. Eliyahu Goldratt's Critical Chain method removes the padding scattered inside individual task estimates and consolidates it into a single project buffer held at the end of the plan. Because the buffer is the only protection left, its consumption rate becomes a direct measurement of schedule health. The arithmetic is blunt in a way that helps. A project consuming two days of buffer for every one day of calendar time is deteriorating twice as fast as it is progressing, whatever the task board shows. A defined threshold, commonly fifty percent of the buffer remaining, gives the project manager an objective trigger for a structured trade-off conversation rather than an instinct to argue from. Both signals demand the same unpopular discipline. Refusing a deliverable that fails the Definition of Done, and forcing a scope conversation when the buffer crosses its threshold, will make a project manager the least agreeable person in the room that week. Both are also cheaper than the alternative by a wide margin. Reading leading indicators does not require better intuition. Team proactivity, decision latency, and buffer consumption are all observable, trackable, and available well before anything in the formal report changes color. They shift the role from reporting on a project's past to managing its future, one signal ahead of a crisis that would otherwise arrive without warning. |
Posted on: August 31, 2026 02:00 AM
| Permalink |
Comments (2)
