Journey Management Is Not Project Management

The confusion between journey management and project management is understandable. Both involve cross-functional coordination. Both use structured rhythms. Both aim to keep complex work moving toward defined outcomes. But they operate at different altitudes, have different accountability structures, and serve fundamentally different purposes.

Conflating them leads to journey management being absorbed into project management tools and methodologies — which usually means that the strategic, customer-experience orientation of journey management gets replaced by the delivery-focused orientation of project management. The result is a well-coordinated delivery process that has lost its connection to what it is delivering toward.

What Project Management Manages

Project management manages delivery: whether the right things are being built, whether they are being built on time and within budget, whether the dependencies between work streams are being tracked, and whether the team has what it needs to keep moving.

These are real and important concerns. In the context of Big Solutions, the teams implementing them absolutely need project management. Their sprints, their Jira boards, their demo cycles, their stakeholder reporting — all of this is project management, and it belongs with the teams doing the delivery work.

Journey management does not replace any of this. It exists at a different level.

What Journey Management Manages

Journey management manages coherence: whether the portfolio of Big Solutions still connects to the customer experience outcomes they were designed to serve, whether the organization's picture of the experience is being updated as new evidence arrives, and whether the OKRs that connect delivery work to customer outcomes are being maintained as priorities shift.

The journey orchestrator does not manage delivery details. They do not attend every sprint review. They do not own the backlog. They do not resolve technical dependencies or negotiate with procurement about third-party licenses.

What they do is maintain the perspective that connects all the delivery work to a shared purpose. When a team's sprint produces a feature that addresses the performance of the Activation stage, the journey orchestrator ensures that progress is tracked against the Activation experience score OKR, that adjacent teams are aware of the improvement, and that any implications for other stages of the journey are surfaced and discussed.

"Journey Management is not about managing each project's sprints, demos and Jira details. The journey orchestrator does not manage delivery details. Their role is to ensure that Big Solutions remain coherent, owned, measurable, and anchored to the journey stages they are meant to improve."

The Scrum Master Analogy

A useful analogy is the Scrum Master in an agile team: a person who does not own the backlog or manage the developers, but ensures that the team's process is healthy, that impediments are removed, and that the work stays oriented toward its stated goals.

The journey orchestrator plays an analogous role across multiple teams, at the journey level rather than the sprint level. They own the coherence of the journey, not the execution of any team's work. They are accountable for the experience score improvements, not for the delivery of any specific feature.

This positioning matters because it preserves the separation between strategic orientation and operational execution — which is the condition that allows journey management to keep asking "are we improving the right things?" even while the teams are asking "are we building things correctly?"

When these two questions collapse into one, the answer is always "yes, we delivered what was planned" — which is a valid answer to the operational question and a non-answer to the strategic one.