Why Projects Fail, Part 2: The Absence of a Systematic Methodology
Six weeks before handover, someone asks who signed off the design.
Nobody has a clear answer. The engineering lead assumed the client's technical representative had approved it in a meeting. The client assumed a formal approval was still coming. The project manager, who joined three months in, inherited a folder of documents and no record of which of them had been agreed and which were still drafts.
Nothing here was incompetence. Everyone worked hard, and everyone acted reasonably given what they knew. What was missing was a defined decision point — a moment in the project where design approval was required, recorded, and visible to everyone before work continued past it.
That is what the absence of a systematic project management methodology actually looks like. Not chaos. Something quieter: a series of small ambiguities that individually seem manageable and collectively decide the outcome of the project.
What a methodology actually is
A methodology is often mistaken for a set of templates. Templates are the visible part, but they are the least important part.
A systematic project management methodology is a structured approach that provides a logical sequence of activities — supported by proven processes, tools and techniques — guiding a project from initiation through planning, execution, monitoring and control, to closure. Underneath that sequence sit the things that actually do the work:
- Decision points. Defined moments where something must be approved before the project proceeds, and a record of who approved it.
- Governance. Who has authority to make which decisions, and at what threshold they escalate.
- Roles and responsibilities. Not job titles, but explicit accountability for specific deliverables and decisions.
- A common language. When the project manager, the sponsor, the team and the client all mean the same thing by "approved," "complete," and "at risk," a large category of failure disappears.
That last point is undervalued. Most project communication failures are not failures of frequency — people are usually talking constantly. They are failures of shared definition.
What consistency buys you
Organisations that apply a methodology consistently across their project portfolio tend to see:
- Objectives and scope defined more clearly at the outset
- More realistic planning and scheduling, because estimates are built the same way each time
- Risks identified earlier, while intervention is still cheap
- Better control of cost, time and quality
- More predictable outcomes across projects, not just on the well-run ones
The mechanism behind all of these is the same. When project information is gathered and reviewed the same way every time, deviations become visible. A schedule slip that would be invisible in an ad hoc status update stands out immediately against a consistent baseline — and it stands out while there is still time to do something about it.
This is also why methodology matters more to organisations than to individuals. A capable project manager can run one project well through experience and judgement alone. What experience and judgement cannot do is make the next project, run by someone else, go equally well. That is what a methodology is for.
No single methodology fits every project
The right approach depends on the size of the project, its complexity, the level of uncertainty involved, and the organisational environment it sits in. A predictive, stage-gated approach that works well for a construction project may be actively harmful on a product development effort where requirements are expected to change.
The choice matters. But the pattern holds regardless of which one you select: projects managed through a structured, systematic approach succeed more often than projects managed through improvisation.
Five questions worth asking about your own projects
If you want to know whether your organisation is actually operating a methodology or simply owns one:
- Can your team name the next formal decision point on the current project, and say who has authority at it?
- Would two different project managers in your organisation produce a status report that a sponsor could compare side by side?
- When a risk was last raised, was there a defined route for it to travel — or did it depend on someone thinking to mention it?
- Is there a written record of what has been approved, distinct from what has been discussed?
- If your project manager left tomorrow, how much of the project's state would leave with them?
An organisation that struggles with question five usually struggles with all of them. Project knowledge held in one person's head is the clearest symptom of a project run without a methodology, and it is the one most often mistaken for indispensable talent.
This is Part 2 of the Why Projects Fail series. Read Why Projects Fail (Part 1): The Critical Role of Stakeholder Engagement
Go deeper
These principles are covered in depth in Project Management Principles, Practices and Scheduling, the University of Pretoria's short course and the first of eight modules of the Programme in Project Management (PPM).
Presented online by Prof Herman Steyn, with a face-to-face option available. Successful participants earn 20 PMI Professional Development Units, 5 ECSA CPD credits and 5 SACNASP CPD points.
For more information, visit: Online Short Course on Project Management Principles, Practices, and Scheduling
