Tailoring the Life Cycle and Development Approach
Two decisions get taken at the same moment and then discussed as though they were one. The life cycle is the shape of the project: what phases it has, where the boundaries fall, and what each phase exists to settle. The development approach is how the thing being built actually gets produced inside those phases, whether once at the end, in planned increments, or iteratively with feedback shaping what comes next. Running the two together is why so many projects describe themselves as hybrid and cannot say what the hybrid consists of.
Most real hybrids are a predictive life cycle with adaptive development inside one or two of its phases, and that combination is not a fudge. A stage-gated structure exists because somebody has to commit money and accept risk at defined points. Iterative development exists because the solution is not knowable in advance. Both things can be true of the same project, and on a good many projects they are.
Putting the gates where the decisions are
Tailoring the life cycle means settling how many phases there are, where the boundaries sit, and what each boundary decides. The structure most organisations supply by default is four or five phases at roughly even intervals, which is a calendar rather than a structure.
A gate earns its place when a genuine decision exists at that point, and three tests sort them quickly. Is money being committed here that could still be withheld? Is there a point of no return, a tooling order, a supplier commitment, a migration nobody can reverse? Is information arriving here that the organisation does not hold before it, so that the decision is better taken now than earlier?
A boundary passing none of those is a review. Reviews are useful, and calling one a gate creates an approval that people wait for. The opposite case is worse: a project with a real point of no return and no gate at it is one where nobody gets asked the question while the answer can still be no.
One project, more than one approach
Section 3.3.1 of the PMBOK® Guide Eighth Edition treats the selection of life cycle and development approach as a tailoring decision taken against the conditions of the work, and the practical consequence is that the decision belongs to the workstream rather than to the project as a whole.
A programme replacing a depot's warehouse management system has infrastructure work where the requirements are known and the sequence is fixed; configuration work where the business rules emerge from conversations with people who have never had to articulate them; a data migration whose difficulty is unknown until somebody profiles the data; and third-party integrations paced by other organisations' release calendars. One approach across all four makes three of them uncomfortable. Predictive infrastructure, adaptive configuration, a time-boxed investigation for the migration and a milestone-driven integration track are four honest answers to four different questions.
Delivery cadence is a separate dial again. A project can develop iteratively and still release once, which is normal where the receiving organisation can absorb only one change. It can develop predictively and release in tranches. How the work gets done and how often something reaches a user are different decisions, and letting one imply the other is where a lot of hybrid designs come apart.
Then there is the revisiting. Whatever gets chosen at the start is a hypothesis, and it is worth writing down what would show it to be wrong: a predictive stream running at three changes a week, an adaptive stream producing two successive iterations with nothing a user can see, a fixed date that has quietly stopped being fixed. Naming the signal in advance is what turns a change of approach into a decision instead of an admission.
Four stages and a two-week rhythm
A software company was implementing its platform for a client whose procurement required a four-stage contract structure with payment at each stage boundary. The delivery team's instinct was to call the work agile and treat the stages as reporting points, which would have come apart at the first payment application.
The tailoring took the stages seriously and moved two of them. The standard structure put its boundaries at even quarters. The client's real decisions were a go or no-go on the data migration approach, which landed at week seven, and a commitment to a custom integration carrying a two-year support obligation, which landed at week nineteen. Both boundaries were moved to those points, and the contract schedule was amended once before work started, at a cost of a fortnight of commercial time.
Inside the middle stage, running from week seven to week nineteen, the work went in two-week increments with a demonstration at the end of each. The demonstration doubled as the client's progress evidence, which removed a written report nobody had wanted to write. The first and last stages stayed predictive, because an environment build and a cutover are sequences.
For a PMP® candidate, keeping the two decisions apart is the thing worth carrying into any situation about delivery approach. A stage-gated project whose team runs iterations is not describing a contradiction, and a team that wants to drop a gate is usually raising the question of whether a real decision sits at it. Settle the phase structure and the way the work is produced as two questions, not one, before deciding what a situation calls for. Practising that on projects where the two genuinely differ is the work a structured PMP exam preparation course sets out to make routine.
Go through the plan gate by gate, asking what decision is taken at each one and who takes it. Gates with no answer become reviews, which clears an approval queue at no cost. Then take the phase holding the most unknowns and ask whether the work inside it is being produced in a way that lets those unknowns resolve, because a phase full of discovery running to a fixed detailed plan is the commonest reason a sound life cycle still produces a late project.
Interested in going further?
Separating the shape of a project from the way its work is produced is what makes a hybrid design explainable to a sponsor who is paying for it. Omega's PMP® Exam Preparation works through delivery decisions where those two have to be settled independently.
The tailoring material covering life cycle and development approach selection is in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A084: Selecting the Initial Development Approach
A064: Choosing Predictive, Agile or Hybrid for a Real Project
A066: How Project Characteristics Shape the Delivery Approach
A065: Choose the Approach Around the Deliverable
A089: Project Diagnostics: When Your Delivery Approach Is Not Working
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
