Assess Project Needs and Choose a Development Approach

Introduction

This lesson opens Task 2.1 of the Process domain of the July 2026 PMP Examination Content Outline (ECO). The Process domain carries 41% of the scored questions, and Task 2.1, "Develop an integrated project management plan and plan project delivery", is where the project's shape is decided. Its first enablers are the subject of this lesson: assess project needs, complexity and magnitude to recommend a development approach (predictive, adaptive/agile or hybrid); gather critical information requirements such as sustainability; and recommend a project execution strategy such as contracting, finance or resourcing. Tailoring runs through all of them.

PMI states that about 40% of the exam items relate to predictive approaches and 60% to adaptive/agile or hybrid approaches, and that these approaches appear in every domain. You therefore cannot pass by knowing only one of them. The exam repeatedly asks: given this project, which approach, which tailoring, and which first action is best?

After this lesson you will be able to assess a project's needs, complexity and magnitude, compare predictive, agile and hybrid approaches, recommend an approach with a justification, define critical information requirements, choose an execution strategy, and tailor processes and artefacts.

Learning objectives

• Assess project needs, complexity and magnitude with structured criteria.
• Distinguish the life cycles and development approaches: predictive, iterative, incremental, agile and hybrid.
• Recommend the approach that fits the project and justify it.
• Identify critical information requirements, including sustainability and regulatory inputs.
• Recommend a project execution strategy (contracting, financing, resourcing).
• Tailor the approach and the artefacts to the project and to the organisation.

1. Assessing needs, complexity and magnitude

Before choosing how to work, understand what is being asked. Three lenses help.

Needs. What problem or opportunity does the project address, what benefits are expected, and what do the stakeholders consider success? Needs come from the business case, the charter, the sponsor, users and regulators. A need can be stable ("migrate 40 branch offices to a new telephone system") or emerging ("find out which features customers will actually pay for").

Complexity. Complexity comes from the number and interaction of elements, not just their size. Typical sources:

• Human behaviour: many stakeholders with conflicting interests, cultural differences, politics.
• System behaviour: dependencies between components, feedback and emergent effects.
• Ambiguity: unclear requirements, new technology, unknown solution.
• Technical uncertainty: unproven design, integration with legacy systems.

Magnitude. Size of the budget, number of people, duration, number of locations, level of risk and regulatory exposure.

A simple way to use these lenses is a scoring table filled out with the sponsor and the team.

No score is an automatic answer; the result is a discussion that leads to a recommendation.

Example: assessing two projects at the same company

Nordhaven Logistics has two projects. Project A replaces the fire-suppression system in a warehouse: fixed scope set by a safety regulator, a fixed budget of EUR 1.8 million, a contractor, a 7-month schedule, and no value until the system is certified. Project B builds a mobile app for drivers to report delays: the company is not sure which features drivers will use, the business wants to test in two depots, and early releases would already save time. Project A scores strongly "predictive": stable requirements, regulation, one release. Project B scores strongly "agile": uncertain requirements, frequent feedback from drivers, incremental value. Using one approach for both would hurt one of them.

2. Life cycles and approaches

The ECO uses these terms; know the differences.

The agile mindset in brief

The Agile Manifesto values individuals and interactions, working software (working product), customer collaboration and responding to change, while still recognising the value of the items on the right. Servant leadership, empowered teams, transparency, inspection and adaptation, and delivering value early are the principles behind frameworks such as Scrum, Kanban, XP and SAFe. You need to understand Scrum's roles (product owner, Scrum Master, developers), events (sprint, planning, daily, review, retrospective) and artefacts (product backlog, sprint backlog, increment), and Kanban's visualisation of work and limits on work in progress.

Hybrid is not a mix of confusion

Hybrid choices are deliberate. Common patterns:

• Predictive frame, agile delivery. A fixed funding envelope, milestones and governance, while the product team works in sprints on a prioritised backlog.
• Different approaches for different parts. Hardware with a fixed lead time follows a predictive plan; software on top is built iteratively.
• Agile discovery, then predictive build. Prototypes and iterations define the requirement, then a stable build phase follows.
• Predictive first, agile after. Implementation of a solution in stages, followed by continuous improvement in a flow-based team.

The best answer on the exam usually explains the reason for the combination in terms of the project's needs.

3. Recommending an approach

The ECO uses the verb "recommend": the project manager analyses and recommends; decision makers (sponsor, steering committee, PMO) decide, within the organisation's policies. A good recommendation:

1. States the assessed needs, complexity and magnitude.
2. Lists options and compares them against the criteria.
3. Identifies risks of each option and how they would be handled.
4. Considers organisational constraints: policies, contracts, regulators, skills, tools, culture.
5. Includes a plan to tailor, with a way to review if conditions change.

Factors that can override an otherwise good fit include a contract that requires fixed scope, a regulator that requires a formal documented process, or a team with no agile experience. These do not make agile impossible, but they influence the form: for example, a fixed-price contract can be run with an agile team if the contract fixes the capacity and time-box and allows scope to be reprioritised.

Worked example: choosing an approach

Statement. Alder Insurance wants a customer self-service portal. The business has a firm launch date at the start of the next financial year (10 months) and a capped budget of EUR 2.4 million. Product managers have a list of 60 wishes but admit that only about 15 will matter to customers. Two regulations require specific data-protection controls with documented evidence. Developers have two years of Scrum experience. The sponsor asks you for a recommendation.

Reasoning, step by step.

1. Needs. The main need is a working portal at launch that customers use. Value arrives incrementally: a basic login and policy view already has value.
2. Complexity. Scope is uncertain (15 of 60 wishes matter), integration with core systems is known, user behaviour is unknown. Medium-high ambiguity.
3. Magnitude. EUR 2.4 million, 10 months, moderate team size.
4. Constraints. Fixed date and cap on budget; data-protection controls need documented evidence.
5. Options. (a) Fully predictive: lock all 60 wishes, risk building features no one uses and late feedback. (b) Fully agile with no frame: freedom, but the date and budget cap with unknown scope, and no evidence for regulators. (c) Hybrid: a governance frame with the budget, date, release milestones and a compliance work-stream with documented controls; delivery in two-week sprints on a prioritised backlog with customer feedback, scope flexing to meet the date.
6. Recommendation. Hybrid (c). Fix time and cost, vary scope by priority, produce compliance evidence as part of the definition of done, and report progress by release burn-up and milestone.

Why the others are weaker. Predictive locks the wrong scope. Pure agile ignores the compliance and governance obligations. A hybrid that is not designed (some documents, some sprints) would confuse the team.

4. Critical information requirements, including sustainability

The ECO adds to the first enabler the idea of gathering critical information requirements: the information you must have, early, to plan well. Examples:

• Legal and regulatory constraints, industry standards, contract terms.
• Organisational policies, templates, tools and historical data (organisational process assets) and enterprise environmental factors.
• Security and privacy requirements.
• Sustainability requirements: environmental impact (energy, emissions, materials, waste), social impact, and reporting required by the organisation or by regulation.
• Availability and cost of resources, location and time-zone constraints.
• Dependencies on other projects, programmes and operations.
• The decision rights and the people who must approve.

Sustainability is treated as an input to planning, not as a separate course topic. In a scenario it may appear as a requirement that the new data centre meets an energy-efficiency target, that suppliers report their emissions, or that packaging reduces waste. The project manager captures it as a requirement or constraint, assesses its impact on cost, schedule, scope and risk, and plans how it will be measured.

Example: sustainability as a planning input

A retailer builds a new distribution centre. The sustainability policy requires 30% lower energy use than the current site and reporting of embedded carbon in materials. The project manager records these as requirements, asks suppliers to provide emissions data in tenders, adds a measurement activity to the quality plan, and includes a cost line for energy-efficient equipment (about 4% more than the baseline option, offset by lower operating costs). The business case is updated to show the whole-life cost.

5. Project execution strategy

The second enabler is to recommend a project execution strategy, such as contracting, finance, and resourcing. The strategy answers how the work will be delivered and funded.

The strategy has to be consistent with the approach. An agile project funded as one large fixed scope, or a predictive project resourced with a team that shares time on five other products, creates conflict from the start.

Example: matching strategy to approach

For the Alder portal, the execution strategy is: a stable internal team of 9 plus 3 specialists from a vendor under a capacity-based contract renewed every three months; funding released per quarterly release with a stage review; a pilot with 2,000 customers before the national launch; a contingency of 10% held by the sponsor. This supports the hybrid approach: money flows as value is delivered, and the vendor is not locked into a scope that is likely to change.

6. Tailoring

Tailoring means adapting the approach, governance, processes and artefacts to the project's context, the organisation, and the stakeholders. The goal is the lightest process that still delivers the value and meets obligations.

Tailor by considering:

• Project size, risk and criticality: a small internal change does not need the same documents as a large regulated programme.
• Stakeholder needs and expectations.
• Organisation standards: required templates, gates, tools, quality criteria.
• Team skills, location and experience.
• Development approach and life cycle.

What to tailor: the processes that are used, the level of detail in plans, the length of iterations, the review gates, the metrics, the reports and the tools. What not to tailor: legal and regulatory obligations, ethics, and the organisation's mandatory governance (unless the governance body agrees to an exception).

Tailoring is a decision made with the team and key stakeholders, recorded in the plan, and reviewed. A retrospective or a phase review is a natural time to adjust.

Example: tailoring after a review

On the Alder project, the first retrospective shows that the weekly 40-slide steering report takes a day to produce and is not read. The project manager, with the sponsor and the PMO, replaces it by a one-page dashboard (release burn-up, top five risks, decisions needed, budget variance) and a monthly 45-minute review. Mandatory PMO fields stay. The change is documented in the communication plan.

7. Comparing approaches by plan element

Knowing how the approaches handle the main elements helps with scenario questions.

8. Common pitfalls and exam tips

Pitfalls

• Choosing the approach from habit or from what is fashionable, not from assessment.
• Treating agile as "no planning" or "no documentation".
• Treating hybrid as permission to take the worst of both.
• Ignoring regulators, contracts or governance when recommending agile.
• Setting the strategy (contract, funding) in conflict with the approach.
• Forgetting that sustainability and security can be critical inputs.
• Tailoring away something that is mandatory.
• Deciding alone instead of recommending and obtaining agreement.

Exam tips

• In "which approach" questions, find the clues: stable vs uncertain requirements, regulation, customer availability, delivery of early value.
• The best answer usually starts with assessing needs, complexity and magnitude before recommending.
• When both a predictive and an agile element are present (fixed date and uncertain scope), hybrid is often right.
• Tailor to the context; do not impose a method.
• Recommend and obtain agreement; the sponsor or governance body decides.
• Match contract and funding to the approach (agile and a rigid fixed-scope contract are a warning sign).
• When a team with no agile experience is asked to go agile, the best action includes coaching, a pilot, and support from leaders.

9. Mini case study

Situation. Marlow Energy asks you to lead a project to install smart meters for 120,000 customers within 18 months. The meter hardware and the installation procedure are regulated and fixed. The customer app and the data platform that read the meters are new, with unclear requirements and strong pressure from the marketing department to try ideas quickly. The regulator requires monthly progress evidence. Installers are subcontractors paid per installation. The CFO wants a fixed budget of EUR 36 million. The team of platform developers has used Scrum for three years. Sustainability policy requires that old meters are recycled and reported.

Question. What do you recommend?

Model solution.

1. Assess. Two parts with different profiles: installation (stable, regulated, repeatable, contract-based) and platform/app (uncertain, benefits from feedback, incremental value).
2. Recommend a hybrid approach. A predictive plan for hardware procurement, installation waves by region, regulatory milestones and contracts. An agile product team for the platform and the app, with a backlog prioritised by the product owner and releases aligned to the installation waves.
3. Critical information. Regulator requirements and evidence format; recycling requirements and the supplier data to report; data-protection rules for meter readings; installer capacity by region.
4. Execution strategy. Fixed-price unit contracts for installation; capacity-based contract for platform development; funding released per installation wave and per platform release; a contingency reserve held by the sponsor, and a management reserve at programme level.
5. Tailor. Monthly regulator report produced from the same data as the programme dashboard; the app team keeps its Scrum events; a joint planning event before each wave aligns both streams; recycling evidence is part of the installation "done" criteria.
6. Governance. Steering committee reviews at wave boundaries; escalation thresholds for cost and schedule agreed with the CFO; recommendations documented and approved by the sponsor.
7. Review. After wave 1, hold a joint retrospective and adjust the integration and the report.

Why not fully agile or fully predictive. Fully predictive freezes the app requirements too early; fully agile ignores regulation, fixed contracts and the CFO's cap on the installation stream.

Key terms

• Predictive approach: plan-driven delivery with detailed up-front planning and formal change control.
• Adaptive / agile approach: iterative and incremental delivery that responds to feedback and change.
• Hybrid approach: a deliberate combination of predictive and agile elements.
• Iterative / incremental: refining through cycles / delivering in usable pieces.
• Complexity: difficulty caused by interacting elements, human behaviour, ambiguity and uncertainty.
• Critical information requirement: information needed early to plan well (regulatory, security, sustainability and others).
• Execution strategy: the way the project will be delivered, contracted, funded and resourced.
• Tailoring: adapting processes, governance and artefacts to the context.
• Minimum viable product (MVP): the smallest release that delivers value and learning.

Summary checklist

• I assess needs, complexity and magnitude with explicit criteria before recommending an approach.
• I can explain predictive, iterative, incremental, agile and hybrid approaches and when each fits.
• I recommend an approach with its justification, and the sponsor or governance body decides.
• I capture critical information requirements, including regulatory, security and sustainability inputs.
• I recommend a project execution strategy (contracting, finance, resourcing) consistent with the approach.
• I tailor processes and artefacts to the context without removing mandatory obligations.
• I review the approach when conditions change.

Official sources

• PMI, PMP Examination Content Outline (July 2026), Process domain, Task 2.1: https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf (opens in a new tab)
• PMI, New PMP exam (approaches across domains, 40% predictive and 60% agile or hybrid): https://www.pmi.org/certifications/project-management-pmp/new-exam (opens in a new tab)