Online Mind Mapping and Brainstorming

Create your own awesome maps

Online Mind Mapping and Brainstorming

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account? Log In

Agile Programme Management (AgilePgM®) study guide mind map by Mind Map: Agile Programme Management
(AgilePgM®) study guide mind
5.0 stars - 16 reviews range from 0 to 5

Agile Programme Management (AgilePgM®) study guide mind map

DSDM®, Atern®, AgilePM® are registered trade marks of Dynamic Systems Development Method Limited in the United Kingdom and other countries. AgilePgM™ is a trade mark of Dynamic Systems Development Method Limited in the United Kingdom and other countries. Trademarks are properties of the holders, who are not affiliated with mind map author.

Current DSDM® Consortium products family

DSDM® Consortium products history in a nutshell

positioning AgilePgM® in comparision to other Agile approaches

AgilePgM® Governance Levels (3)

Business Strategy Team

Responsibilities, Overall strategy, direction and goals of the business, Agreement and review of Business Case for programme with respect the Business Strategy, Prioritisation of the programme against other initiatives, Approval of programme vision

Programme Board

Responsibilities, Approval of Prioritised Benefits, Agreement of Programme and Tranche Plans, Agreement of project high-level requirements / scope with respect to the programme's Business Case, Agreement and control of resourcing and budgets Technical consistency across the programme Communication consistency across the programme

Capability Teams

Responsibilities, As defined by the project / activity

Portfolio Management Office

A portfolio management office is the team responsible for the management of initiatives within the organisation

Responsibilities, Prioritisation of programmes and other projects in line with agreed business priorities

Programme Strategy Office

Assists the programme in planning, reporting and administration. Also helps to implement consistent best practice across the programme

Responsibilities, Provides a support function and does not have management responsibilities over the programme

Project Strategy Office

Also helps to implement consistent best practice across large projects

Assists the project in planning, reporting and administration

Responsibilities, Provides a support function and does not have management responsibilities over the project(s)

AgilePgM® - an iterative, incremental, adaptive agile programme management method and framework from UK for general (not industry specific e.g. IT or Engineering) agile programme management. AgilePgM™ is closely aligned with methods AgilePM®, dedicated to generic agile project management and DSDM®, dedicated to agile project management of software development projects. Same as AgilePM®, AgilePgM® was created by DSDM® Consortium -

AgilePgM™ first version (v1.0) was published in 09.2014.

AgilePgM® Principles (5)

1. Programme goals are clearly and continuously aligned to Business Strategy

Program will have an overall vision

Vision is based on business strategy at the time of definition, Vision should be updated throgh the programme

Programme team members must understand the business strategy, priorities and needs

Business Case must be established

All projects must be aligned with programme's Business Case

Maintain continuous business sponsorship and commitment

Review points within the programme

Frequent review and validation of the programme

2. Benefits are realised incrementally and as early as possible

Incremental enablement of delivered capabilities, Which leads to realisation of programme benefits

Business can benefit early from the outcomes

Programme team can learn from experience and adapt

Include feedback from earlier deliveries

Prioritise benefits ASAP, So benefits can be deliered in incremental way ASAP

Prioritise the capabilities that can deliver the benefits to reflect the benefits prioritisation

Plan in detail only relative short term capabilities, Planning will need review and update after each capability enablement

Understand that some benefits will add more value to the business when compared with the costs of delivering the benefits

3. Governance focuses on creating a coherent capability

Programme will be executed as a series of projects

In Agile environment projects are allowed to be carried out autonomously, with minimal intervention, Yet agile projects has to incorporate changes from programme

Projects must be aligned with programme vision, Projects (and other initiatives) must be constantly synchronised to ensure that they can deliver a capability that is coherent across the organisation, Projects are reviewed continaully to ensure their alignment with programme vision

High level requirements (HLR) e.g. Objectives and Themes of each project are aligned with programme vision

Project teams have to be empowered to deliver the outputs satisfying high level requirements

Project outputs are converted to capabilities that ultimately lead to benefits realisation

4. Decision-making powers are delegated to the lowest possible level

In Agile environments decisions has to be made quickly and effectively

Empower project team members

Decisions can be made at the lowest possible level, Decisions regarding overall goal and vision has to be mage by Programme, Decisions hot regarding high level requirements must be made at the lowest possible level of the relevant project

Programme governance needs to be clearly defined early in the programme and effectively communicated clearly to all stakeholders

5. Agile programmes are iterative and have the ability to contain both Agile (at least 1) and non-Agile projects

Through the programme, iterative techniques and practices can be used

Some of the projects within the programme may be run using non Agile techniques, Team has to understand how the different types of projects can be executed successfully within the programme

Programme is planning and enabling benefits iteratively and incrementally by means of a series of projects and that the projects are seen as autonomous

AgilePgM® Philosophy (1)

"An agile programme delivers what is required when it is required - no more, no less"

Programme management is concerned with the optimal resourcing of multiple related projects.

Programme will:

Constantly be aligned to business strategy, mission, vision

Adapt to emerging changes in the business environment

Deliver projects outputs incrementally, realising benefits ASAP

Do only enough to fulfil the vision, right-engineering (no under-engineering or over-engineering), no gold plating

Provide and establish governance model that empowers the most appropriate people

Provide iterative environments

Ensure active and on-going involvement of stakeholders

"Project management is like juggling three balls – time, cost and quality. Program management is like a troupe of circus performers standing in a circle, each juggling-three balls and swapping balls from time to time." G. Reiss

This freeware, non-commercial mind map (aligned with the newest version of AgilePgM®) was carefully hand crafted with passion and love for learning and constant improvement as well for promotion the AgilePgM™ method and as a learning tool for candidates wanting to gain AgilePgM™ qualification. (please share, like and give feedback - your feedback and comments are my main motivation for further elaboration. THX!)

Questions / issues / errors? What do you think about my work? Your comments are highly appreciated. Please don't hesitate to contact me for :-) Mirosław Dąbrowski, Poland/Warsaw.


AgilePgM® Official publications

Agile Programme Management Handbook

The most important, key position on AgilePgM™ preparing for Foundation and Practitioner exams

AgilePgM® Lifecycle (1) with Phases (6)

a.k.a. DSDM Agile Programme Framework (AgilePgM)

Lifecycle is both iterative and incremental

Increment is called "tranche"

Programme Feasibility and Programme Foundations are sequential phases

1. Pre-Programme

Objectives, Describe business transformation, Identify Business Programme Owner (PBO) and Busines Change Owners (BCOs), Derive a programme from the existing portfolio within the organisation, Confirm alignment of programme vision with business strategy, vision, misson etc., Scope, Plan, Resource Programme Feasibility phase (not the whole programme), Check if programme is worth pursuing to Programme Feasibility phase, Determining the initial key roles, Business Programme Owner (BPO), Business Change Owner (BCO)

Do not not into details

Justify the programme is needed and worth investigation further

2. Programme Feasibility

Objectives, Confirm programme is consistient with business strategy and potentially achievable, Refine outline vision of programme, Outline high-level benefits of business transformation, Produce initial outline costs for the programme, Confirm programme structure, Develop outline plan for Programme Foundations, Develop outline governance strategy, Assess organisation readiness for use of Agile techniques on the programme

As short as possible

Justify the programme's inclusion in the organisation's portfolio of initiatives

3. Programme Foundations

Objectives, Baseline programme vision, Create initial Business Architecture Model, Define initial Roadmap for realising vision, Define and prioritise the high-level benefits and capabilities, Confirm the Business Case for the programme, Establish governance model that is Agile, Develop Programme Plan, Describe, assess and manage risk, Identify and categorise key stakeholders, Plan initial tranche(s), Obtain approval to proceed to first tranche, Gain funding for at least the first tranche

Establish firm foundations for the programme

Ensure that the programme will realise sufficient business benefits

Address key areas of vision, design and architecture, governance, culture and communication

Do not plan all tranches

One of the main goals of Programme Foundations is to plan first tranche (of projects), Identify and plan the projects and initiatives to build the capabilities, Projects may be sequential or much often overlapping, Plan only high-level scope of each project in alignment to programme Business Case, Determine projects inter-dependencies, Set outline budget, Set outline start and end dates, Identify and plan the activities required to build and enable the capabilities

4. Capability Evolution

Objectives, Plan, initiate and execute projects to deliver the capabilities, a.k.a. Sprints / Timeboxes on the programme level, Iteratively and incrementally enable consistent subsets of capabilities into the live organization, a.k.a. Deployments on the programme level, Deliver capabilities as soon as posible through projects with delivering outputs regularly and often, Run projects within tranches (tranches can be overlapping), Measure the benefits being released through the capabilities

Contains 2 main processes, Capability Enablement, Benefits Realisation

5. Tranche Review

Objectives, Confirm the sufficient capability has been delivered for the tranche, a.k.a. Review on programme tranche level, Plan next tranche in sufficient detail, Review the programme and update plans and other Programme Foundations products as necessary based on experiences from the current tranche, Review lessons learnt, a.k.a. Retrospective on programme tranche level

Update BAM after tranche review to incorporate newest changes and lessons learnt

Update governance structure and / or processes after tranche review to incorporate newest changes and lessons learnt

6. Programme Close

Objectives, Confirm that sufficient capability has been delivered, Close the programme, Gather lessons learnt for the future initiatives, a.k.a. Retrospective on programme level, Review the programme against its vision and Business Case

Benefits Management

Starts when capabilities have been enabled

An iterative and incremental on-going process that starts early in the programme where benefits definition commences

AgilePgM® method consists of: 1 Philosophy, 5 Principles, 10 Roles, 6 Phases, 3 Governance Levels, 20 Products (a.k.a. documentation).

Download: AgilePgM® Project Phases vs Products (documentation) vs Roles vs Reponsibilites Matrix (PDF)

AgilePgM® Products / Artifacts (20)

The types of Products

Evolutionary products, Initial produced in outline in a specific phase, Continued to evolve, becoming more detailed as the programme progresses

Milestone products, Created in a phase and typically fulfill a specific purpose

Foundation products, Fundamental drivers of the programme, Normally baselined during the Programme Foundations, Set the basis of all programme activity


Icon, This means that selected products are Gateway Products, which can be used for Yes / No decision if project should be continued

Orange, Business focused products

Blue, Programme management focused products

Green, Outputs / Capabilities / Benefits focused products

Violet, Benefits management focused products

Vision Statement

Define clearly and concisely the desired future state of the organisation

Used to validate all decisions, plans, activities and communcations carried out during the programme

Captures the intended state of the organisation following the transformation programme

Expresses the desired future state of the organization

Aligned to business strategy

Needs to be agreed with the Business Strategy Team

Relatively short and easily understood

Responsiblities, Owned by:, Business Programme Owner (BPO), Agreed by:, Business Strategy Team (outside the AgilePgM), Compiled and Updated by:, Business Programme Owner (BPO) and peers, Contributions from:, Programme Team, Business Change Owners (BCOs)

Business Case

Compares the benefits to result from the programme with the risks and costs of realizing the benefits

Provides justification that the programme is worthwhile

Responsiblities, Owned by:, Agreed by:, Compiled and Updated by:, Contributions from:

Business Architecture Model (BAM)

Describes the desired future structure of the organization

Describe in outline the potential incremental step changes that could lead to the final structure

The BAM will normally cover (a.k.a. POTI model):, Processes, Processes and business models of operations and functions, Operational costs and performance levels, KPIs, Organisational structure, Organisation structure, staffing levels, roles and skills, Culture, style, supply chain, Technology, Technology, IT systems, tools, equipment, machinery, Buildings and accommodation, infrastructure, Information, Information and data required for future business operations and performance measurement, Current State, Intermediate Future States, Final Future State

Programme Plan

Roadmap, Describes the incremental steps (tram to realise the vision of the programme, Forms part of the Programme Plan, Describes a schedule of tranches for the incremental enablement of consistent capabilities

Benefits Realisation Plan, Describes how the benefits identified within the Prioritised Benefits Definition will accrue as capabilities are enabled Describes how benefits will be measured Forms part of the Programme Plan

Tranche Plan

Defines the MoSCoW-prioritised capabilities, projects and costs for the tranche, Not define the projects in detail

Produced for each incremental step in the programme

Produced immediately prior to the commencement of the tranche

Defines the Timeboxes for the projects as subsequent projects and activities may be dependent on their completion

Tranche Review Record

Describe what has been achieved during the tranche and is used as a foundation for future tranche plans and to update the overall Programme Plan

Produced at the end of a tranche

An output of the Tranche Review

Programme Control Pack

Programme Control Pack comprises reports, documents and logs related to the ongoing status of the programme

Programme Risk Log

Programme Issues Log

Communication Log

High-Level Project Status

Benefits Assessment

Stakeholder Engagement Strategy

Defines approach to be taken towards all groups of stakeholders

Includes internal and external stakeholders

Stakeholder Engagement Strategy should be is reviewed and updated often, but at least during Tranche Review

Communication Plan

Aimed predominantly at the communication requirements for a given tranche

Each plan will identify how and when key events will be communicated to stakeholders

Governance Strategy

Documents the way in which governance will be carried out on the programme



Prioritised Benefits Definition

Defines benefits predicted to emerge from the change

Defines how benefits realisation will be measured

Can be decomposed into sub-benefits

Benefits should be prioritised using MoSCoW rules

Programme / Tranche Approach Questionalire (PTAQ)

Original product of DSDM

Provides set of questions to be asked when conducting agile programme

Helps assess how Tranches should be applied in specific environment

Helps explore characteristics of the project and organization in context how AgilePgM should be applied

Helps identify potential areas of risk that should be considered and addressed moving forwards

Helps to understand how the critical success factors are addressed

AgilePgM® Roles (10)


Orange, Business intrest roles representing the business view, Typically taken by business personnel

Blue, Management intrest roles representing the management / leadership view, Managing or facilitating the management/leadership aspects of the programme

Green, Technical intrest roles representing the technical view, Contributing to technical consistency, design or development

Roles can comprise one or more individuals and sometimes a group of individuals

An individual or group can take more than one role

Programme Management Team (PMT)

Programme Management Team comprises of roles that for the most part are involved both in business strategy and programme management

Roles are accountable for oversight and must direct and strategically guide the transition of the organisation towards its new future state

Roles are supported in administrative affairs by the Programme Support Office

Agile Programme Management Team (PMT) characteristics, Strong communication skills, Confidence and trust in their teams, giving them real empowerment, Clarity of vision and ability to share it with others, Determination to achieve the vision, Strong focus on priorities, Respect for everyone involved in the programme, Ability to inspire and motivate, Positive attitude at all times and an innate ability to be diplomatic, Passion and pride in what they do, Lateral thinking and the ability to find innovative ideas, Ability to focus on developing people, Willingness to take calculates risks

Business Programme Owner (BPO), Programme Champion, The most senior programme-level business role, Responsibilities, Overall strategic programme direction, Continuous and ongoing commitment to the programme, Provision of funds, Ensuring the programme vision and goals are aligned with organisational / business strategy, Managing the interface to key stakeholders, Ensuring efficient, effective and rapid decision-making process, Responding rapidly to escalate issues, Mappings to other roles in other methods ..., Managing Successful Programmes (MSP®), Senior Responsible Owner (SRO)

Programme Manager (PgM), Responsibilities, Incremental and iterative programme design and planning, Monitoring the programme progress agains it's design and plan, Ensuring project outputs are appropriate (meeting the programme vision with ability to deliver benefits), Managing risks and issues, Creating autonomous projects environment, Managing project interdependencies and inter-projects conflicts, Managing and communicating with all stakeholders, Working together with Stakeholder Engagement Coordinator ensuring clear and continuous communication, Incremental and iterative programme design and planning

Business Change Owners (BCOs), Realising benefits that the new programme capabilities will provide, Implementing change in the business area, Senior member of a specific business area, Responsibilities, Defining benefits for their area of responsibility, Ensuring projects are aligned to the programme vision, Creating and monitoring the plan for benefits realisation, Reacting to business change, Leading change in their business area, Managing stakeholders within their area of business, Ensuring efficient, effective and rapid decision-making process, Responding rapidly to escalate issues, Characterisics, Incremental approach, Constant review benefits against current business, Instils empowernmanet and commitment, Strong communication of the programme vision, Gentle steering of project teams towards the progremme vision, May be supported by, Programme Change Architect, Stakeholder Engagement Cooridnator, Change Agents, Mappings to other roles in other methods ..., Managing Successful Programmes (MSP®), Business Change Manager (BCM)

Capability Delivery Team (CDT)

Deals with:, delivery of the products/outputs, business architectural design and consistency, technical design and consistency, stakeholder engagement and commitment

Programme Technical Architect (PTA), Responsibilities, Agreeing and ultimately controlling the programmes architectures, Architecture owner, Agreeing technical environments, Advising and coordinating each project's technical activities, Identifying and owning programme-level architectural and other technical risks, Ensuring compliance with appropriate norms, standards, technical best practices, Resolving design / technical differences between project members across projects, Facilitating and ensuring communication between teams on the coherence of the developing capabilities and so avoiding technical inconsistencies

Programme Change Architect (PCO), Responsibilities, Creating the Business Architecture Model (BAM), Advising and guiding on business architecture, Monitoring the achievement of the Business Architecture Model (BAM), Identifying and owning programme-level business architecture risk, Resolving differences between project teams with respect to business architecture as defined in the Business Architecture Model (BAM), Facilitating and ensuring communication between project teams on the coherence of the changes to achieve the new business architecture

Stakeholder Engagement Coordinator (SEC), Onward-facing and inward-looking, The key purpose of outward stakeholder engagement Sis to ensure that stakeholders remain informed about, engaged with, and positive towards programme, This becomes important when a tranche is about to start as all stakeholders to be involved in the tranche need to be aware that they are required, ready to participate and committed to their part of it, Stakeholder Engagement Coordinator has two aspects:, Engagement and communication outward from the programme to stakeholders, Engagement of stakeholders into the programme and internal communication within the programme, Agile programme will generally require more business resource to be involved in the programme than using more traditional techniques, This is one of the reason why stakeholder engagement is so important to the success of the programme that a separate role is defined in AgilePgM, Responsibilities, Creating and maintaining the Stakeholder Engagement Strategy, Ensuring active, ongoing engagement with all stakeholders, Creating and maintaining the Tranche Communication Plan, Identifying and owning programme-level stakeholder engagement activities, Ensuring all outward communications are aligned to programme vision, Facilitating and ensuring effective communication between teams and stakeholders within the programme

Project Teams (PTs), Responsibilities, not defined in AgilePgM™, In general responsible for successful project delivery for start to the finish in alignment to the programme vision

Supporting Roles

Deals with:, assistance and guidance to the programme

Works on ad hoc basis throughout the programme lifecycle

Change Agents (CAs), Responsibilities, Change management specialist input, Assisting Business Change Owners (BCOs), Implementing business processes to realise the benefits of new capabilities, Implementing organisational changes required to realise the benefits of new capabilities

Specialists (Ss), Responsibilities, Consulting input, Advising and guiding the programme stakeholders / decision-makers

Programme Support Office (PSO), Responsibilities, not defined in AgilePgM™, Assistance

Interactive AgilePgM® Glossary

Interactive AgilePgM® Glossary

Portfolios, Programmes & Projects

DSDM AgilePgM framework in context

Relationship between Programme and Projects

Example programme with three tranches

AgilePgM® Planning

There are two important concepts to confer when planning for Agile programmes:

Change is inevitable and plans must be able to deal with change

Experience from executing plans will change the future plans

Planning needs to

Be iterative and incremental

Set the vision for the long term

Divide delivery into increments to realise benefits as early as possible

Prioritise delivery based on the relative value of benefits and on interdependencies

Plan the immediate future in some detail

Plan the mid and long term in outline, knowing that it will change

Review and update plans based on experience of delivery

Review and update plans based on the current business landscape

Overlapping tranches to ensure that benefits can be realised as soon as possible

This implies that the capabilities within each of the overlapping tranches are not interdependant

MoSCoW Prioritisation