AgilePM Foundation · Domain 6 of 10

AgilePM Foundation Domain 6: Project lifecycle framework

The AgilePM lifecycle from pre-project through feasibility, foundations, development and deployment to post-project benefits, how increments flow through it, and how to configure it for a given project.

Exam weight estimate
Not published
Official syllabus topics
3
Estimated questions estimate
~5
Suggested study time estimate
3–4 hrs

About 13 min read Reviewed October 2026

Overview

Project lifecycle framework is where AgilePM's project layer becomes concrete. The lifecycle runs from Pre-Project, which checks that the right project is being started, through Feasibility, which decides whether the idea is worth pursuing, and Foundations, which builds enough understanding of scope, solution and approach to start delivery safely. Development then builds the solution iteratively, in AgilePM v3 through Scrum Sprints, and Deployment releases an increment into live business use. After deployment, benefits are assessed to judge whether the intended value is being realised.

The lifecycle is iterative, not a waterfall. Development and Deployment repeat for each increment, and the project can return to Foundations if the next increment needs fresh thinking. The area also covers configuration: the lifecycle is adjusted to the project's size, risk and context, for example by combining Feasibility and Foundations on a small, well-understood project.

How it's tested

Most questions name an activity or output and ask which phase it belongs to, or describe a phase and ask for its purpose. Others test the iterative flow, such as what happens after an increment is deployed, or how to configure the lifecycle for a small or low-risk project. Neighbouring phases are the usual distractors.

  • Which phase

    An activity or decision is described and you choose the phase in which it normally happens.

  • Purpose of a phase

    You choose the statement that matches why a phase exists, separating close neighbours such as Feasibility and Foundations.

  • Flow and configuration

    You identify where the project goes next after a deployment, or how to adapt the lifecycle to a given context.

Reasoning it through

A question says the team has confirmed the project is worth pursuing and must now agree the high-level prioritised requirements, solution architecture and delivery plan before building. Feasibility is tempting because it also comes early, but its question, whether to proceed at all, is already answered. Establishing enough scope, architecture and approach to start development is the purpose of Foundations, so that is the answer.

Syllabus topics 3

Official syllabus topics from the APMG International outline, in outline order.

6.1 The AgilePM project lifecycle and types of incrementThe iterative lifecycle and how increments of the solution move through it.
What it means
The lifecycle is Pre-Project, Feasibility, Foundations, Development, Deployment and a post-project benefits assessment. An increment is a usable part of the solution delivered as a step toward the whole, so a project may pass through Development and Deployment several times.
What to understand
Two kinds of increment are easy to mix up: a Scrum Increment, the Done, usable output of each Sprint, and a deployed increment, which is released into live business use and may combine the work of several Sprints. Only a deployed increment starts delivering business value in operations.
How it shows up
A question asks what happens after an increment is deployed, or whether every Sprint's output must go live; the answer depends on the type of increment.
Common confusion
Assuming every Sprint Increment is deployed to the business, or that the project deploys only once at the end.
6.2 Purpose and key work in each phase from pre-project to post-deploymentWhy each phase exists and what it produces.
What it means
Pre-Project makes sure only the right projects start, with clear objectives. Feasibility takes a first look at whether the project is likely to be feasible and worth pursuing. Foundations establishes the high-level scope, prioritised requirements, solution architecture, approach and plan. Development builds and tests the solution iteratively. Deployment assembles, reviews and releases an increment. Post-deployment benefits assessment checks whether expected benefits are realised.
What to understand
Early phases are short and aim for 'enough' understanding, not completeness. The business case is outlined in Feasibility and firmed up in Foundations, and benefits are assessed after deployment because many only appear once the solution is in use.
How it shows up
An activity is described, such as confirming architecture or assessing realised benefits, and you choose its phase.
Common confusion
Swapping Feasibility (should we proceed) and Foundations (how will we deliver, in enough detail to start).
6.3 How lifecycles can be configured for different contextsAdapting phases, increments and team structure to the project.
What it means
The lifecycle is a framework to configure, not a fixed sequence. Phases can be shortened or combined, for example Feasibility and Foundations together on a small or low-risk project; the number of increments varies; and v3 adds guidance for projects with several delivery teams.
What to understand
Configuration is driven by size, risk, complexity and the organisation's context. Removing a phase's purpose is not configuration: even a combined early phase must still answer whether to proceed and lay firm foundations.
How it shows up
A project's context is described and you choose a sensible configuration, such as combining early phases or planning several increments.
Common confusion
Thinking configuration means skipping Foundations entirely to start building sooner.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • Pre-Project

    Pre-Project makes sure only the right projects are started, and that they are set up with clear objectives that fit the organisation's strategy.

    Remember
    It precedes Feasibility and is about starting the right project, not designing it.
    Tested as
    Which-phase questions about initiating or approving an idea.
    Trap
    Confusing it with Feasibility's investigation of viability.

  • Feasibility

    Feasibility is a short phase that gives a first view of whether the project is likely to be feasible technically and worth pursuing from a business perspective.

    Remember
    It answers 'should we proceed', with just enough investigation to decide.
    Tested as
    The most common neighbouring-phase distractor.
    Trap
    Expecting detailed architecture or plans in Feasibility.

  • Foundations

    Foundations builds enough understanding of scope, prioritised requirements, solution architecture, development approach and delivery plan to start building safely.

    Remember
    Enough design up front, not complete design, in line with build incrementally from firm foundations.
    Tested as
    Which-phase questions about architecture, prioritised requirements and plans.
    Trap
    Thinking every requirement is detailed here.

  • Development

    Development builds and tests the solution iteratively and incrementally; in AgilePM v3 delivery teams use Scrum Sprints within this phase.

    Remember
    Detail emerges here, through cycles of build and feedback.
    Tested as
    Questions on where Scrum fits in the lifecycle.
    Trap
    Thinking Scrum replaces the whole lifecycle.

  • Deployment

    Deployment assembles, reviews and releases an increment into live business use, including preparing the business to use it.

    Remember
    After deployment the project may return to Development or Foundations for the next increment, or close.
    Tested as
    Flow questions about what happens next.
    Trap
    Thinking deployment happens only once, at the end of the project.

  • Post-project benefits assessment

    After deployment, the business assesses whether the expected benefits are being realised, since many benefits appear only after the solution has been in use for some time.

    Remember
    Benefits are judged after deployment, not at the last Sprint Review.
    Tested as
    Questions on when benefits are assessed.
    Trap
    Assuming benefits are confirmed at project closure.

  • Sprint Increment vs. deployed increment

    Each Sprint produces a Done, usable Increment, while a deployed increment is the set of work actually released into business use, which may combine several Sprints.

    Remember
    Usable is not the same as deployed.
    Tested as
    Questions on increments and deployment frequency.
    Trap
    Assuming every Sprint's output goes live.

  • Iterative lifecycle flow

    Development and Deployment repeat for each increment, and the project may return to Foundations when a later increment needs its own groundwork.

    Remember
    The arrows loop back; the lifecycle is not a waterfall.
    Tested as
    Flow and sequence questions.
    Trap
    Choosing a strictly sequential answer.

  • Combining Feasibility and Foundations

    For a small or well-understood project, the two early phases can be run together, provided both purposes are still achieved.

    Remember
    Combine phases, do not drop their purpose.
    Tested as
    Configuration questions.
    Trap
    Skipping early phases entirely to start development.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Pre-Project vs. Feasibility vs. Foundations

ConceptMeaningKey differenceCommon trap
Pre-Project Make sure the right project is started Strategic fit and clear objectives Expecting investigation of technical viability here
Feasibility First view of whether the project is worth pursuing Answers 'should we proceed' Expecting architecture and delivery plans here
Foundations Enough scope, architecture, approach and plan to start Answers 'how will we deliver' Detailing every requirement up front

Development vs. Deployment vs. post-project benefits assessment

ConceptMeaningKey differenceCommon trap
Development Build and test the solution iteratively in Sprints Creates usable increments Thinking work is released to the business here
Deployment Release an increment into live business use Value starts flowing to the business Thinking it happens only at the end
Post-project benefits assessment Check whether expected benefits are realised Happens after the solution has been in use Doing it at the final Sprint Review

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Architecture in Feasibility

    What candidates pick
    Agree the solution architecture and delivery plan during Feasibility.
    Why it looks right
    Feasibility is early and involves technical investigation.
    Why it's wrong
    Feasibility only gives a first view of viability; architecture and the delivery plan are established in Foundations.

    Clue to watch for The activity is about how the solution will be built and delivered.

  2. Complete requirements in Foundations

    What candidates pick
    Detail every requirement in Foundations so development has no surprises.
    Why it looks right
    'Foundations' sounds like a complete specification.
    Why it's wrong
    Foundations sets high-level, prioritised requirements; detail emerges during Development.

    Clue to watch for Words such as 'all', 'every' or 'full detail' before development.

  3. Benefits at closure

    What candidates pick
    Confirm all benefits at the last Sprint Review before the project closes.
    Why it looks right
    Closure feels like the natural point to measure success.
    Why it's wrong
    Many benefits appear only after the solution has been used for a while, so they are assessed after deployment.

    Clue to watch for A question about when benefits are measured.

  4. Single big-bang deployment

    What candidates pick
    Finish all development, then deploy the complete solution once.
    Why it looks right
    It mirrors familiar project plans.
    Why it's wrong
    AgilePM builds and deploys incrementally, so Development and Deployment repeat and value arrives earlier.

    Clue to watch for A question about the lifecycle's flow after the first deployment.

  5. Configure by skipping Foundations

    What candidates pick
    Skip Foundations on a small project to start building immediately.
    Why it looks right
    It sounds lean and agile.
    Why it's wrong
    Configuration may combine or shorten early phases, but their purpose, firm foundations, must still be achieved.

    Clue to watch for A small or simple project in a configuration question.

  6. Every Sprint goes live

    What candidates pick
    Each Sprint's Increment must be deployed to the business.
    Why it looks right
    Scrum Increments must be usable.
    Why it's wrong
    Usable is not the same as deployed; a deployed increment may combine several Sprints, depending on business readiness.

    Clue to watch for The scenario mentions business readiness or release timing.

Answer framework

Use these steps when a question asks about a lifecycle phase, the flow between phases or configuring the lifecycle.

  1. Identify the question behind the activity: is it whether to start, whether to proceed, how to deliver, building, releasing, or checking benefits.
  2. Map that question to Pre-Project, Feasibility, Foundations, Development, Deployment or the post-project benefits assessment.
  3. Check the level of detail expected: early phases seek just enough understanding to decide or to start safely, so reject options demanding complete detail before development.
  4. For flow questions, remember Development and Deployment repeat per increment and the project may return to Foundations for later increments.
  5. For configuration, adapt phases and increments to size, risk and context, but keep every phase's purpose achieved even when phases are combined.

Practice question

A project has been confirmed as worth pursuing. The team now needs to agree the high-level prioritised requirements, the solution architecture and the approach to delivery so that development can start safely. In which AgilePM lifecycle phase does this work belong?

Want more like this? The AgilePM Foundation practice test has questions for every domain.

Checklist

0 of 11

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Draw the lifecycle from memory, with the loop-back arrows, until you can do it in under a minute. Under each phase write one question it answers: should we start, should we proceed, how will we deliver, build it, release it, did it deliver the benefits. That single line per phase resolves most which-phase questions.

Spend extra time on Feasibility versus Foundations, the highest-yield distinction in this area. Write five activities, such as an outline business case, architecture definition and a delivery plan, and sort them into the two phases.

The commonly underestimated topics are the flow and increments. Practise explaining what happens after the first deployment and why a Sprint Increment is not automatically released. Then think through configuration for two contrasting projects: a small internal change and a large multi-team programme of work.

Afterwards, study planning and control, which plans across these phases, and risk management, which uses the Project Approach Questionnaire early in the lifecycle. Finish with a practice set of which-phase questions under time pressure, since they reward fast recall.

FAQ

What are the AgilePM lifecycle phases?

Pre-Project, Feasibility, Foundations, Development, Deployment and a post-project benefits assessment. Development and Deployment repeat for each increment.

What is the difference between Feasibility and Foundations?

Feasibility asks whether the project is likely to be feasible and worth pursuing. Foundations establishes enough scope, architecture, approach and planning to start building safely.

Is the AgilePM lifecycle a waterfall?

No. It is iterative and incremental: increments are built and deployed in cycles, and the project can return to Foundations for later increments.

Where does Scrum fit into the lifecycle?

In AgilePM v3, delivery teams use Scrum Sprints to build the solution during Development. The surrounding phases are part of the AgilePM project layer.

Can phases be skipped on a small project?

Phases can be shortened or combined, such as Feasibility with Foundations, but their purposes still have to be achieved. Skipping firm foundations is not valid configuration.

When are benefits assessed?

After deployment, because many benefits only become measurable once the solution has been in business use for a while.

Other Project Management certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 6 knowledge

You have covered each lifecycle phase, how increments flow and how to configure the lifecycle. Check that you can place activities in the right phase, especially Feasibility versus Foundations.

Take the AgilePM Foundation practice test Check your AgilePM Foundation readiness

Keep going