How to choose a project life cycle

“So, do you work in waterfall or are you agile?” It opens almost every kickoff meeting, and it is the wrong question. Life cycles are not two camps or five rival schools: they are points on a single scale, and what decides where you stand is how firm your requirements are and when the business needs to receive value.

Choosing well is not a matter of methodological fashion. The life cycle determines how you will handle change, how often you will face your stakeholders, and how you will control risk for months. Getting it wrong is expensive.

The five, one line each

• Predictive (waterfall). Scope, time and cost are set upfront. One deliverable at the end, and change tightly controlled.
• Iterative. Repeats cycles over the same product to understand what to build. Its question is what.
• Incremental. Delivers successive functional pieces, each one usable. Its question is when.
• Adaptive (agile). Requirements are elaborated continuously in short cycles, with stakeholders involved throughout.
• Hybrid. Different fronts of the same project, each with its own approach.

The pair most often confused sits in the middle. Iterative and incremental are not synonyms. Iterative polishes the solution: prototype, test, adjust, and only then build. Incremental already knows what to build and ships it in pieces that work from day one. One is about getting it right; the other is about getting there early.

Two questions and you are most of the way there

The full tree fits in three questions, but the first two do most of the work:

1. Are the requirements defined, and will they hold? If the honest answer is yes — usually because a regulation or a contract imposes them — you are on the predictive side.
2. Does the business get something usable before the end? If not, predictive. If yes, incremental.

When the first answer is no, the question becomes whether stakeholders are genuinely available for continuous feedback. If they are, adaptive. If they are not and what is missing is understanding the product itself, iterative.

You can walk that tree in the life cycle selector that comes with this module: three questions and it hands back the answer with the reasoning written out, ready to paste into a meeting record. The tool is in Spanish for now.

Why the real answer is usually “hybrid”

A case that repeats across Colombian banking. A project to modernize the corporate digital channel has two fronts under one budget:

• The regulatory engine. Tax reporting, audit, record purging. The law requires the logic to be fully defined, documented and legally validated before any deployment. An open backlog here is not innovation: it is a regulator’s finding waiting to happen.
• The user experience. Portal and app for approving corporate payroll. Nobody yet knows what the screen should look like; it gets discovered through prototypes, and the requirements that matter are about performance and security. Freezing scope six months ahead here guarantees shipping something nobody wants any more.

Same project, two natures. Forcing a single approach breaks one of the two sides every time. That is why the right answer is hybrid: predictive on the regulatory front, adaptive on the product one.

And here is the subtle part: a hybrid does not fail at its ends, it fails at the seam. What must be written down from day one is where one front stops and the other starts, and how the two integrate. That boundary is the real deliverable of the decision.

Before the life cycle comes the authorization

None of this matters if the project does not formally exist. The project charter is what authorizes it and gives the project manager the authority to apply organizational resources. It is the point of no return: once approved, the company commits money and people.

Its eleven elements boil down to four questions somebody will eventually ask: what are we achieving and how is it measured, where does the project stop, who decides it was done right, and what authority does the manager actually have. If the charter is vague on any of these, the project will argue about it for its entire life.

Alongside the charter sits stakeholder management, which is not a mailing list: identify, engage and monitor are three distinct, continuous activities. A stakeholder who was not identified early does not disappear; they show up at the end, when change is expensive.

Requirements are the raw material of scope

The PMBOK sorts them into five categories, and using the right one avoids half of all acceptance disputes:

Non-functional requirements are the ones most often forgotten and the most expensive to miss: security, performance, availability, retention. Nobody complains about an ugly screen the way they complain about a slow system or a record that could not be audited.

Before entering the baseline, every requirement must be unambiguous, measurable, traceable, consistent and accepted. “The system must be fast” fails all five.

The WBS: deliverables, not tasks

The work breakdown structure decomposes total scope into progressively smaller pieces down to the work package, the level at which work can be estimated, scheduled and controlled.

One misunderstanding is worth killing: in a WBS, “work” means the deliverables, not the activities. A WBS is not a schedule or a task list — it is the map of what will exist when the project ends. Tasks come afterwards, and they come from it.

And the rule that governs all of scope: the project includes all the work required, and only the work required. The first half keeps things from being missing; the second keeps the project from growing on its own.

A note on the edition

This guide uses the life cycle classification from the sixth edition of the PMBOK, still the clearest reference for processes and process groups. The seventh edition, published in 2021, shifted the approach from processes to principles and performance domains, and much of the detail on development approaches moved to the agile practice guide. The five life cycles are the same; what changed is where they are explained. If you are citing the standard in a formal document, check which edition holds the text you quote.

PMBOK is a registered mark of the Project Management Institute, Inc. This material is educational and is neither sponsored nor endorsed by PMI.

The takeaway

If only one idea survives: a life cycle is not chosen out of conviction, it is deduced from your requirements and your deliveries. And when a project has one front the regulator forces you to freeze and another the user has to discover, the mature answer is not picking a camp — it is drawing the line between them.

The previous module, on how a project is born and what a business case needs to get approved, is in How a project is born: from idea to approved budget.