The project lifecycle
Every project follows a lifecycle, typically split into five phases: initiation (initial scoping, objectives), planning (task breakdown, resources, schedule), execution (doing the work), monitoring and control (tracking progress, adjusting), and closure (delivery, retrospective). These phases aren't always strictly sequential — monitoring and execution often run in parallel — but they structure the reference vocabulary of the whole discipline.
This breakdown still holds in an agile context, where the lifecycle repeats at the scale of each iteration rather than once across the whole project. Understanding this foundation before tackling agile actually makes it easier to compare the two approaches.
The scope-cost-time triangle
This triangle formalizes a simple reality: you generally can't improve one of the three axes (quality, cost, time) without degrading at least one of the other two, given fixed resources. Cutting a deadline often means increasing cost (extra resources) or reducing functional scope. This model serves as a reference to make trade-offs explicit, rather than treating them as arbitrary decisions.
- Quality: the expected level of conformance of the deliverable
- Cost: the budget and resources mobilized
- Time: the time available until delivery
Scope, the often-forgotten fourth variable
Many bodies of knowledge add a fourth variable to the quality-cost-time triangle: scope, meaning the full set of features or deliverables included in the project. Scope creep — the gradual addition of unplanned requests — is one of the most frequent causes of schedule and budget overruns.
Clearly defining and documenting scope from the outset, then formally framing any change request, is one of the most effective practices for limiting this risk.
Governance and stakeholders
Project governance defines the decision-making bodies — project committee, steering committee — their frequency and their level of authority. It answers a simple but essential question: who decides what, and when? Without clear governance, decisions escalate in a disorderly way and slow the project down.
Stakeholders, in turn, aren't all equal: some have strong decision-making power but little direct interest in the project, others the reverse. Mapping them along these two axes — influence and interest — helps decide who to inform, who to consult, and who to directly involve.
An example of a simple committee structure
A weekly project committee tracks operational progress with the project team. A monthly steering committee, bringing together a higher hierarchical level, arbitrates blocking or strategic points the project committee can't resolve on its own.
Risk management, a continuous exercise
Contrary to a common assumption, risk management isn't a one-off step done at the start of a project, but a continuous exercise: identify risks, assess their probability and impact, define mitigation plans, then reassess regularly as the project progresses and the context changes.
An untreated risk doesn't disappear — it becomes a problem the moment it materializes, often with an impact harder to absorb than if it had been anticipated.
A good risk register distinguishes probability of occurrence from potential impact: a low-probability, high-impact risk sometimes deserves more attention than a frequent but minor one.
Go further
Frequently asked questions
Do these notions apply in an agile context too?
Yes, with adaptations. The lifecycle repeats at the scale of each iteration, governance can be lighter and more decentralized, but the notions of the quality-cost-time triangle, stakeholders and risk remain relevant.
Which notion is most often misunderstood?
Governance is often underrated early in a career: it's perceived as bureaucracy, when in fact clear governance speeds up decision-making by avoiding informal arbitration and confusion over who has the final say.
Does the quality-cost-time triangle have variants?
Yes, some bodies of knowledge add a fourth axis (scope) and talk about 'project constraints' rather than a strict triangle. The principle stays the same: a trade-off on one axis has knock-on effects on the others.
How do you prioritize a project's risks?
Generally on two combined criteria: the probability a risk will materialize, and the impact it would have if it did. A risk that's both likely and high-impact should be treated as a priority.
Is there a specific order to learn these notions in?
The lifecycle is a good starting point since it gives the general framework. The other notions (triangle, governance, risk) can be learned in whatever order best fits your immediate professional context.
Are these basics enough to run a project on your own?
They give you the vocabulary and conceptual landmarks you need, but running a real project also takes hands-on experience and, often, support at the start — these basics are a starting point, not a complete course.
How does this foundation connect to a specific methodology like PRINCE2?
PRINCE2, the PMBOK and other bodies of knowledge all build on this same core vocabulary, then add their own specific terminology and processes on top. Knowing the fundamentals first makes it noticeably easier to map a given methodology's vocabulary onto concepts you already understand.
What exactly is scope creep?
It's the gradual accumulation of small, unformalized change requests, each seeming minor in isolation, but whose cumulative effect ends up significantly expanding the initial scope without a matching adjustment to budget or timeline.
Why does governance matter even on a small project?
Even a small project benefits from a clear answer to who decides what: without it, minor disagreements tend to stall progress while people wait for an informal green light, which often takes longer than a short, well-defined decision point would.