Selecting the Initial Development Approach
The initial choice of development approach gets made at the point where a project knows least about itself, which is an awkward fact most guidance walks past. Somebody has to say how the work will run before anybody has done any of it. The useful response is to decide quickly, on the two things that are already knowable, and to write the decision down as a hypothesis with a reason against it.
What makes the choice harder than it needs to be is that people are usually choosing a label. Agile is not a selection. Two-week increments with something demonstrable at the end, and a product owner who can decide without going away for a fortnight, is a selection. So is a stage-gated structure with a frozen scope baseline and change control at the boundaries. The label summarises a shape, and the shape is what everybody has to live with.
Two properties give you a first answer
How well the requirements are understood is the first. Not whether they are written down, which is a much weaker test, but whether the people who will use the thing can describe what they need precisely enough that building it will not surprise them. Requirements set by an external standard, a regulation or an existing interface are usually well understood. Requirements about how somebody will work differently once a new system arrives usually are not, however confidently they were stated in a workshop.
How fast usable feedback can arrive is the second. Iterative work only repays its overhead if something comes back from each cycle that changes what happens next. A team that can put a working increment in front of a real user every fortnight has a fast loop. A team whose output cannot be judged until a six-week test campaign has run has a slow one, and running two-week iterations against a six-week loop produces ceremony without learning.
Put the two together and a first answer falls out. Well understood with slow feedback points at predictive. Poorly understood with fast feedback points at adaptive. Well understood with fast feedback can go either way and usually turns on the constraints below. Poorly understood with slow feedback is the uncomfortable case, and the honest answer there is generally to spend some money shortening the feedback loop before committing to anything at all.
Three constraints can overrule it
Section 3.4.1 of the PMBOK® Guide Eighth Edition puts the initial selection at the front of the tailoring work, and what makes it a selection rather than a conclusion is that three constraints sit outside the nature of the work and can override what the work would otherwise indicate.
The funding and contracting model comes first. A fixed-price contract with a defined scope and payment against milestones does not support an evolving backlog, whatever the work is like, and a team that runs one anyway acquires a commercial dispute on top of a delivery problem. The approach has to be payable. Where the work genuinely needs to evolve and the contract will not carry it, the conversation is a commercial one, and it happens before mobilisation or it does not happen.
What the delivery organisation can actually do comes second. An approach nobody in the organisation has run before is a risk in its own right, and it competes for attention with the risks inside the work. A first adaptive delivery in an organisation with no product owner role, no way of releasing anything between quarterly windows and a finance process that funds projects annually will spend most of its energy on the organisation and very little on the product.
Evidence requirements come third. Regulated, safety-critical and contractually audited work has to produce a defined trail, and while that does not force a predictive approach, it constrains how loosely the front end can be run. An adaptive stream produces that evidence perfectly well when the evidence is designed into the increments from the start. Reaching the end and finding that nobody recorded why a decision was taken in March is the failure mode.
One programme, two answers
A defence contractor was starting an integration programme for a secure communications fit: a rack of equipment interfacing to an existing platform, plus a new operator console. The instinct in the room was predictive, on the grounds that defence work is predictive.
The two properties gave a different answer for each half. The integration requirements came from a published interface standard and a specification that had existed for two years, so they were as well understood as requirements get. Feedback was slow, because anything built had to go through a test campaign on a shared rig with a queue in front of it. Predictive, plainly.
The console was the reverse. What the operator needed was understood in general terms and not in the detail that decides whether a console works, because the existing one had been in service eleven years and the people using it could describe their workarounds far better than their requirements. Feedback was fast: a foam-board mock-up in front of three operators produces an answer in an afternoon.
So the programme ran the integration predictively and the console in six-week increments with operator trials at the end of each. The contract was milestone-based, so the console increments were packaged into three payable milestones, not eighteen, which cost some flexibility and kept the commercial model intact. The selection went into the project record in about half a page: the two properties, the constraint, and one line naming what would change it, which was a console design stabilising early enough to fold into the predictive stream.
For a PMP® candidate, the reading that helps is that the approach follows the work, and a description usually contains what you need to decide. Stable requirements and a long test cycle describe predictive conditions whatever the organisation calls itself, and a team that cannot say what good looks like until it sees something describes adaptive conditions. Look for how well the requirements are known and how fast feedback arrives, before reaching for a methodology name. A structured PMP exam preparation course works on delivery approach mainly through situations where the label and the conditions disagree.
The whole exercise should take an hour. Write two sentences, one about the requirements and one about the feedback loop, test the answer against the contract and against what the organisation can actually run, then record the choice, the reason and the signal that would change it in half a page. Anything longer is a proposal for a decision nobody has taken, and anything shorter gets forgotten by the people who have to live with it.
Interested in going further?
An approach chosen on instinct and never written down is one nobody can revisit when the work turns out differently from the assumption. Omega's PMP® Exam Preparation works through selection decisions where the conditions and the organisational constraints point different ways.
Selecting an initial development approach is the first step of the tailoring work set out in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A064: Choosing Predictive, Agile or Hybrid for a Real Project
A080: Tailoring the Life Cycle and Development Approach
A065: Choose the Approach Around the Deliverable
A089: Project Diagnostics: When Your Delivery Approach Is Not Working
A066: How Project Characteristics Shape the Delivery Approach
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
