If you lead a complex program, you have probably been sold at least one method as the answer. Maybe your organization rolled out SAFe, hired a change management team, launched a Lean initiative, or tightened project governance. And maybe, a year later, the ceremonies are in place but the results are not quite what anyone hoped for.
I have worked inside all four of these approaches, and I hold the credentials to show I took them seriously: PMP, Lean Six Sigma Black Belt, SAFe Program Consultant, Prosci Certified Change Practitioner. That is exactly why I don't treat any of them as the answer. Every method is a compressed set of someone else's hard lessons. That makes it useful. It does not make it true everywhere.
It also helps to be precise, because these four are not the same kind of thing. PMP is a certification grounded in project management standards. SAFe is a framework for scaling agile across many teams. Lean Six Sigma is an improvement approach. Prosci is a change management methodology. Calling them all "frameworks" hides useful differences, so I'll use "approach" as the umbrella term.
Here is what each one does well, where I have watched each one break, and the sign to look for in your own organization.
1 Project management (PMP): saying what "done" means
It gives everyone a shared vocabulary for things that otherwise stay fuzzy: scope, baselines, risk, dependencies, change control. Its biggest gift is simple: make the commitment explicit. What are we delivering, by when, with what, and what happens when that changes?
In large programs with real budgets and real governance, that clarity is not bureaucracy. It is respect for the people funding the work and the people doing it.
When uncertainty is high and the plan pretends it isn't. A detailed plan built on assumptions nobody has tested becomes fiction with a Gantt chart.
On one program, the integration plan assumed a partner system would be ready on a date nobody on our side could verify. The schedule stayed green for months. When we replaced that date with an early integration test, the real risk surfaced while there was still time to act on it.
The sign to watch for. Status reports that stay green for months and then turn red all at once. That pattern rarely means the team suddenly failed. It usually means the plan was describing hopes rather than evidence. On programs like that, I keep precise planning for what is genuinely known, and plan the learning for the rest: what we need to find out, by when, and which decision it unlocks.
2 Lean Six Sigma: go look at the actual work
It replaces opinions about a process with a view of the process itself. Map it. Measure it. Find where work waits, loops back, or gets redone. Separate the root cause from the loudest symptom. It also brings respect for variation: many "performance problems" are really unstable processes asking people to compensate with heroics.
On work that is new every time. Knowledge work, design, and transformation rarely repeat often enough to measure the way a production line does. It breaks when measurement becomes theater: a beautiful dashboard about the wrong thing. And it breaks on problems that are political rather than procedural. You can run a flawless root-cause analysis and still find that the real cause is two departments that do not trust each other. No control chart fixes that.
On one program, two teams had argued for weeks about why requests took so long. When we mapped the intake process together, most of the delay turned out to be requests waiting for a single approval. The debate ended in an afternoon.
The sign to watch for. Long debates about why something is slow, and nobody in the room has walked through the process end to end. Wherever work repeats (intake, approvals, handoffs, reporting), Lean thinking usually pays off quickly. For one-off, high-ambiguity work, I keep the mindset (go see, find the real constraint) and leave most of the statistics at home.
3 SAFe: alignment at scale is a real problem
It takes seriously something many agile approaches gloss over: when dozens of teams depend on each other, alignment does not happen by goodwill. Shared cadence, visible dependencies, and getting everyone in the same room to plan together are powerful. A good PI Planning event can surface in two days what months of status meetings never did.
When it is installed as a costume. Roles get renamed, ceremonies get scheduled, and the way decisions are made stays exactly the same. That is not an agile transformation. It is a new calendar. It also breaks when it is simply too much for the size of the problem: a handful of teams rarely needs the full apparatus.
On one large program, the first joint planning event surfaced a dependency between two teams that had been planning in parallel for months. With both teams in the same room, it took two days to solve what status meetings had not.
The sign to watch for. Ask what decision is now made differently, or faster, than before the rollout. If nobody can name one, you have adopted the vocabulary without the change. I start from the coordination problem, not the framework: borrow SAFe's strongest pieces, such as shared cadence and joint planning, and scale up only as far as the problem demands.
4 Prosci: change happens one person at a time
It puts words to something that shows up on every program: an organization does not change; people do, one at a time. ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement) is a simple way to ask where a specific group is actually stuck. It treats resistance as information, not insubordination, and makes active, visible sponsorship non-negotiable.
When change management is reduced to a communication plan and a training schedule, delivered after the important decisions are already made. It breaks when sponsors delegate their role to a change team. And no methodology can rescue a change that is genuinely a bad idea; sometimes the resistance is right.
On one rollout, adoption stalled and the first instinct was more training. Talking with the team showed they knew the new tool well. What they did not see was why it was worth the extra steps. Once their manager explained what it changed for clients, and one redundant report was dropped, usage picked up.
The sign to watch for. The change team is first brought in a few weeks before go-live. By then, the most important question has already been skipped: who has to do something differently, and what will make that possible for them? I bring that question in at the start, not at launch.
The pattern behind all four
Looking at them side by side, the same pattern shows up:
- Each offers useful tools for the problems it was designed for. Project management for committed scope, Lean Six Sigma for repeatable processes, SAFe for coordination across many teams, Prosci for adoption by people. Useful tools are not guaranteed results; they still depend on the judgment of the people using them.
- Each one strains outside those problems. When an approach disappoints, the cause is rarely the approach itself. It is the mismatch.
- Each one breaks when it becomes the goal. The moment a team is "doing SAFe" or "following the methodology" instead of solving a problem, the approach has started working for itself.
Start from the problem, not the method
When I come into a complex situation, I try not to ask "which approach applies?" I ask what kind of problem we actually have:
| If the main problem is… | I reach first for… |
|---|---|
| Unclear commitments, scope, or accountability | Project management discipline |
| Waste, delays, and rework in work that repeats | Lean Six Sigma thinking |
| Many teams pulling in different directions | SAFe-style cadence and joint planning |
| People not adopting what was delivered | Prosci and change management |
Most real situations involve two or three of these at once. That is fine. These approaches are tools in the same toolbox, not rival religions.
Before you adopt (or blame) an approach
If you are about to roll out a method, or wondering why the last one did not deliver, a few questions are worth asking:
- What specific problem is this meant to solve? If the answer is "we need to be more agile" or "we need better governance," keep digging until it names a real pain.
- Is that problem the one we actually have? Many organizations import a solution to someone else's problem.
- What will be decided or done differently in six months? If the only visible change is new meetings and new titles, the approach has become the goal.
- Who is accountable for the outcome, not the rollout? A method owned by the people implementing it, rather than by the leaders who need the results, tends to drift into ceremony.
The best compliment I can get on a program is not "you followed the method well." It is "things finally make sense, and we're moving."
Methods are a bit like gym memberships. Signing up is the easy part.
These approaches are tools in the same toolbox, not rival religions.
Let's talk
If you are about to roll out a new method, or trying to understand why the last one did not deliver, I am always happy to think it through with you. LinkedIn is the best place to reach me.
Want the next article? It is shared on LinkedIn and in the RSS feed.