Detecting the Pulse of Failure in Project Delivery: What Do You Do?

There is a particular kind of organisational pain that comes from reviewing a project that has failed and recognising, in hindsight, that the signals were there all along. The scope that was never properly baselined. The risk that was logged but never owned. The sponsor who stopped attending governance meetings six weeks before the crisis became visible. The team that was raising concerns quietly, informally, to each other, because the culture had never made it safe to raise them formally.

Project failure is rarely a sudden event. It is a process, and like most processes it has a logic that can be understood, detected, and interrupted. The question is not whether delivery programmes develop the symptoms of failure; most do at some point. The question is whether the organisation has the discipline, the governance, and the culture to detect those symptoms early enough to respond effectively.

This article examines where in the project lifecycle the pulse of failure most reliably originates, what the diagnostic signals look like at each stage, and what a leadership team should do when those signals are found. It draws on the five-process framework that underpins both PMBOK and the principles of good project governance, and it connects the process discipline of delivery to the broader organisational conditions that determine whether recovery is possible.

The Five-Phase Process System: Why It Exists and What Breaks It

The five core process groups of project management, initiation, planning, execution, monitoring and controlling, and closing, are not sequential stages in a linear timeline. They are a connected, continuous system in which each phase both depends on and feeds back into the others. Planning continues during execution. Monitoring happens throughout. Adjustments are made as the project evolves. The system is designed to keep a project aligned between its original intent and its current reality at every point in its lifecycle.

What breaks the system is the treatment of these phases as discrete, completed activities rather than as ongoing disciplines. Initiation that produces a project charter and a stakeholder register and then considers itself done has not initiated a project; it has documented a starting position. Planning that produces a baseline schedule and then files it has not planned a project; it has created a reference point it will never use. The process groups only deliver their value when they are maintained as living practices throughout the life of the work, not when they are completed as onboarding tasks at the start.

Understanding where in this system the failure signals appear most commonly, and what those signals look like in practice, is the foundation of effective delivery assurance.

Reading the Pulse: Failure Signals Across the Five Phases

Initiation: Where Ambiguity Becomes a Structural Risk

Of all the phases in the project lifecycle, initiation is the one whose failure is most consequential and most difficult to recover from, precisely because its outputs form the foundation on which every subsequent phase rests. A project that begins without a clear, agreed definition of success, a committed sponsor, and a business case that has survived genuine scrutiny is not a project that has been initiated. It is a project that has been started. The difference is significant.

The most common failure signal at initiation is a reluctance to spend time on definition when there is pressure to begin delivery. This is one of the most reliably destructive dynamics in project management. The time invested in a rigorous initiation phase is not overhead; it is insurance. Every hour spent achieving genuine clarity about objectives, scope, and success criteria at the start saves multiples of that time later in managing misaligned expectations, contested scope, and governance disputes.

A second and closely related signal is the treatment of the business case as a document to be produced rather than a question to be answered. When the business case is assembled to satisfy an approval process rather than to test whether the proposed initiative is the right response to a genuine problem, it will contain assumptions that are not surfaced, risks that are not acknowledged, and benefit projections that are not credible. Those weaknesses do not disappear when the document is approved; they migrate into the delivery.

Planning: The Phase Most Frequently Rushed and Most Expensively Regretted

Planning is the phase that project professionals most commonly identify as underinvested, and it is not difficult to understand why. Planning produces no visible output for the organisation's end users. It generates no news. It creates no momentum that senior stakeholders can celebrate. The pressure to move to execution, to begin doing something that looks like delivery, is almost universal, and it is almost universally damaging when it results in planning being compressed or bypassed.

The failure signals in planning are primarily signals of absence. There is no documented and agreed risk register, or there is one but the risks are unowned and unreviewed. There is no credible resource plan, or the resource plan assumes the availability of people who have not been confirmed. The schedule has no baseline, meaning there is no reference point against which progress can ever be meaningfully measured. Assumptions that are driving the plan are implicit rather than stated, which means they cannot be tracked, tested, or updated as conditions change.

The planning phase is also where the seeds of communication breakdown are typically sown. A communication and stakeholder engagement plan that is absent, superficial, or disconnected from the stakeholder analysis will not become more effective during execution. It will simply become a more expensive problem.

Execution: Where Structural Weakness Becomes Visible

Execution is the phase that receives the most attention and, perversely, the phase most likely to be blamed for failures that originated elsewhere. When execution struggles, the instinct is to look for problems in the team, in the process, or in the tools. These are rarely the primary cause. Execution difficulty is almost always the symptom of inadequate initiation, insufficient planning, or both.

That said, execution does generate its own characteristic failure patterns. Scope creep is the most common: the gradual, often well-intentioned expansion of what the project is expected to deliver, without a corresponding adjustment to time, budget, or resource. Each individual addition may seem reasonable. The cumulative effect is a project that is trying to deliver significantly more than its original plan accounted for, within the same constraints, and without any formal acknowledgement that the scope has changed.

A second pattern is the breakdown of integration between workstreams. In a well-run programme, the leads of individual workstreams coordinate regularly, surface dependencies, and escalate conflicts early. In a struggling programme, workstreams operate in parallel without sufficient coordination. Interfaces are discovered late. Assumptions made in one workstream are incompatible with decisions made in another. The integration failure may not become fully visible until the workstreams converge at a system test, a user acceptance milestone, or a go-live date, by which point it is expensive to resolve.

Monitoring and Controlling: The Phase That Governs All Others

Monitoring and controlling is the connective tissue of the five-phase system. It is the discipline that maintains the alignment between what was planned and what is actually happening, and it is the mechanism through which corrective action is triggered when that alignment breaks down. When it functions well, problems are identified early, when they are still small enough to be addressable. When it is absent or nominal, problems accumulate silently until they are no longer manageable.

The most dangerous failure mode in monitoring and controlling is not the absence of reporting structures but the corruption of the information that flows through them. When programme teams know, consciously or unconsciously, that governance bodies respond badly to negative news, they learn to manage the information they provide. RAG ratings are softened. Risks are downgraded. Issues are described as being in hand when they are not. The governance structure continues to function, meetings are held, reports are produced, escalations are managed, but it is operating on a false picture of reality and is therefore incapable of triggering the responses that reality requires.

Tools such as earned value management, lookahead schedules, variance analysis, and S-curves exist precisely because they make the health of a programme visible in quantitative terms that are harder to manipulate than narrative reporting. Their value lies not in the sophistication of the analysis but in the discipline of maintaining an honest baseline against which current performance is measured, and in the willingness to act on what the analysis reveals.

Closing: The Phase That Determines Whether Success Was Real

Closing is the most consistently underestimated phase in the project lifecycle, and its neglect has consequences that extend far beyond the individual project. When a project is declared complete at the point of go-live rather than at the point of confirmed handover and benefits realisation, several things happen simultaneously. The team disperses before the organisation has demonstrated it can operate the new solution. Lessons that could improve the next programme are never captured. Benefits that were promised in the business case are never measured. And the organisation has no reliable way of knowing whether the investment it made actually delivered the return it was promised.

Good closing discipline requires that closure criteria are defined before execution begins, not after it ends. It requires a structured lessons-learned process that captures not just what went wrong but what went right and why. It requires a confirmed handover to an operational team that understands what it has received and is equipped to sustain it. And it requires a benefits tracking mechanism that continues after the project team has moved on, maintained by a named owner who is accountable for reporting realisation against the business case assumptions.

The Pulse Diagnostic: Phase-by-Phase Signals and Governance Responses

The table below provides a practical reference for identifying failure signals at each process phase and calibrating the governance response. It is designed to be used as a standing agenda item in project health reviews and programme assurance conversations.

When You Find the Signals: What to Do

Detecting the pulse of failure early is a necessary but not sufficient condition for recovery. The more consequential question is what happens after detection: whether the organisation has the governance discipline, the leadership courage, and the delivery capability to respond effectively. Failure signals that are identified and then acknowledged informally, discussed in corridors, and never formally addressed are not early warnings; they are early confirmations of a governance culture that will allow the project to continue deteriorating.

An effective response to identified failure signals has three components.

Stop the Bleeding Before Diagnosing the Cause

The immediate priority when serious failure signals are identified is to stabilise the project, not to produce a root cause analysis. This means freezing scope if scope creep is the primary symptom, establishing a clear decision log if decision paralysis is the pattern, or convening an emergency governance session if the information being provided to the steering committee is unreliable. These stabilisation actions buy the time needed for a proper diagnostic without allowing the situation to deteriorate further while the analysis is being conducted.

Conduct an Honest, Structured Diagnostic

Once the immediate situation is stabilised, the recovery effort requires an honest assessment of where the project actually stands across the full range of delivery dimensions, not just the technical or financial ones. The diagnostic should be conducted with the involvement of the delivery team, not solely by external reviewers or the governance body, because the team holds the most accurate picture of the current state and the most important insights into what is driving it. The output of the diagnostic should be a clear, evidence-based account of the project's current position, the root causes of the failure signals identified, and a prioritised set of recovery actions with named owners and realistic timelines.

Reset the Baseline and Rebuild the Governance

Recovery is not the restoration of the original plan. It is the construction of a new plan that reflects the actual current position, the realistic capabilities of the team, and the genuine priorities of the organisation. This typically requires a formal rebaselining exercise: a revised scope, schedule, and budget that has been approved by the sponsor and the governance body, and that is supported by a renewed set of commitments from the people responsible for delivery. Rebaselining is not an admission of failure; it is the act of restoring the conditions for honest performance management that the original plan has ceased to provide.

The Recovery Diagnostic Framework

The following framework provides a structured set of questions for assessing project health across the dimensions most commonly associated with failure. It can be applied at any point in the project lifecycle and is particularly valuable at programme gates, when a project is showing distress signals, or as part of an independent assurance review.

The Organisational Conditions That Make Recovery Possible

Behind every recoverable project is an organisational culture in which the conditions for honest, effective governance are present. Those conditions do not appear automatically. They are created, deliberately, by the choices that leaders make about how they respond to bad news, how they treat people who raise concerns, and whether they are willing to hear an accurate account of reality even when that account is uncomfortable.

The McKinsey 7-S framework, applied to the question of delivery recovery, surfaces the systemic nature of this challenge. A project that is failing is rarely failing in isolation. It is usually failing within an organisational context in which one or more of the seven elements of the 7-S model are misaligned: a strategy that has shifted since the project was initiated, a structure that creates ambiguity about accountability, systems that incentivise the management of information rather than the honest reporting of it, shared values that treat setbacks as personal failures rather than as learning opportunities, a leadership style that discourages challenge, or a capability gap in the staff and skills available to the delivery team.

Understanding which of these conditions are contributing to the failure signals is as important as understanding the project-level symptoms they produce. A recovery that addresses the project-level symptoms without addressing the organisational conditions that generated them will produce a recovered project that operates in the same environment that caused the original problems. The next project will follow the same pattern.

Process Discipline Is a Human Discipline

There is a risk, in any discussion of project management process, of making the work sound primarily technical. A better-structured risk register, a more rigorous schedule baseline, a more honest RAG report: these are all valuable, but they are tools, and tools only deliver their value in the hands of people who are willing and able to use them well.

What separates the projects that detect failure early and recover from those that do not is not primarily a difference in methodology. It is a difference in the quality of the people leading the work, the clarity of the accountability structures around them, the honesty of the culture they are operating in, and the commitment of the organisation's leadership to governance that is genuinely designed to surface and address problems rather than to provide the appearance of control.

High-performing delivery teams share a characteristic set of behaviours that transcend any particular methodology. They think ahead rather than reacting. They ask the right questions rather than accepting comfortable answers. They turn data into decisions rather than into presentations. And they understand that the connected process of initiation, planning, execution, monitoring, and closing is not an administrative burden imposed on delivery; it is the system that makes delivery possible, and every time one part of the system is short-changed, the cost appears somewhere else, usually later, usually larger, and usually harder to absorb.

The Hervey Dickens Perspective

The pulse of failure in a project is almost never invisible. It is visible in the stakeholder who has stopped engaging, in the risk that has been amber for three consecutive cycles without a credible mitigation, in the team that has become reluctant to speak openly in steering committee, in the benefit that was projected in the business case but has not been referenced since. These signals are present in most struggling projects. What determines whether they are acted upon is the quality of the governance culture around them and the capability of the leadership to respond.

At Hervey Dickens Consulting, we work with organisations to build the delivery disciplines, governance structures, and cultural conditions that make early detection and effective recovery achievable. That means designing governance frameworks that are honest rather than performative, investing in the programme leadership capability that makes good process discipline a reality rather than a policy, and maintaining the independence of assurance so that the information reaching decision-makers reflects the actual state of the work. Our digital services are built on the conviction that technology and process together create the conditions for genuine transparency, and that genuine transparency is the precondition for everything else.

A project that knows it is struggling, and that has the governance and the leadership to say so clearly and act decisively, is a recoverable project. A project that knows it is struggling and that has learned to manage the appearance of progress rather than address the reality of failure is not. The difference between those two outcomes is made long before the crisis becomes visible, in the decisions that leaders make about the culture they are willing to create and the governance they are willing to sustain.