Get Started. It's Free
or sign up with your email address
Agile Programme Management (AgilePgM®) study guide mind map by Mind Map: Agile Programme Management (AgilePgM®) study guide mind map

1. Current DSDM® Consortium products family

1.1. DSDM® Consortium products history in a nutshell

1.1.1. positioning AgilePgM® in comparision to other Agile approaches

2. AgilePgM® Governance Levels (3)

2.1. Business Strategy Team

2.1.1. 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

2.2. Programme Board

2.2.1. 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

2.3. Capability Teams

2.3.1. Responsibilities As defined by the project / activity

2.4. Portfolio Management Office

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

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

2.5. Programme Strategy Office

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

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

2.6. Project Strategy Office

2.6.1. Also helps to implement consistent best practice across large projects

2.6.2. Assists the project in planning, reporting and administration

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

3. 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 -

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

4. AgilePgM® Principles (5)

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

4.1.1. Program will have an overall vision

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

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

4.1.4. Business Case must be established

4.1.5. All projects must be aligned with programme's Business Case

4.1.6. Maintain continuous business sponsorship and commitment

4.1.7. Review points within the programme

4.1.8. Frequent review and validation of the programme

4.2. 2. Benefits are realised incrementally and as early as possible

4.2.1. Incremental enablement of delivered capabilities Which leads to realisation of programme benefits

4.2.2. Business can benefit early from the outcomes

4.2.3. Programme team can learn from experience and adapt

4.2.4. Include feedback from earlier deliveries

4.2.5. Prioritise benefits ASAP So benefits can be deliered in incremental way ASAP

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

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

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

4.3. 3. Governance focuses on creating a coherent capability

4.3.1. Programme will be executed as a series of projects

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

4.3.3. 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

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

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

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

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

4.4.1. In Agile environments decisions has to be made quickly and effectively

4.4.2. Empower project team members

4.4.3. 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

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

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

4.5.1. Through the programme, iterative techniques and practices can be used

4.5.2. 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

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

5. AgilePgM® Philosophy (1)

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

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

5.3. Programme will:

5.3.1. Constantly be aligned to business strategy, mission, vision

5.3.2. Adapt to emerging changes in the business environment

5.3.3. Deliver projects outputs incrementally, realising benefits ASAP

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

5.3.5. Provide and establish governance model that empowers the most appropriate people

5.3.6. Provide iterative environments

5.3.7. Ensure active and on-going involvement of stakeholders

5.4. "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

6. 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!)

6.1. Questions / issues / errors? What do you think about my work? Your comments are highly appreciated. Feel free to visit my website:






6.1.6. miroslaw_dabrowski

7. AgilePgM® Official publications

7.1. Agile Programme Management Handbook


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

8. AgilePgM® Lifecycle (1) with Phases (6)

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

8.2. Lifecycle is both iterative and incremental

8.2.1. Increment is called "tranche"

8.3. Programme Feasibility and Programme Foundations are sequential phases

8.4. 1. Pre-Programme

8.4.1. 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)

8.4.2. Do not not into details

8.4.3. Justify the programme is needed and worth investigation further

8.5. 2. Programme Feasibility

8.5.1. 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

8.5.2. As short as possible

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

8.6. 3. Programme Foundations

8.6.1. 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

8.6.2. Establish firm foundations for the programme

8.6.3. Ensure that the programme will realise sufficient business benefits

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

8.6.5. Do not plan all tranches

8.6.6. 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

8.7. 4. Capability Evolution

8.7.1. 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

8.7.2. Contains 2 main processes Capability Enablement Benefits Realisation

8.8. 5. Tranche Review

8.8.1. 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

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

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

8.9. 6. Programme Close

8.9.1. 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

8.10. Benefits Management

8.10.1. Starts when capabilities have been enabled

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

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

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

10. AgilePgM® Products / Artifacts (20)

10.1. The types of Products

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

10.1.2. Milestone products Created in a phase and typically fulfill a specific purpose

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

10.2. Legend

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

10.2.2. Orange Business focused products

10.2.3. Blue Programme management focused products

10.2.4. Green Outputs / Capabilities / Benefits focused products

10.2.5. Violet Benefits management focused products

10.3. Vision Statement

10.3.1. Define clearly and concisely the desired future state of the organisation

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

10.3.3. Captures the intended state of the organisation following the transformation programme

10.3.4. Expresses the desired future state of the organization

10.3.5. Aligned to business strategy

10.3.6. Needs to be agreed with the Business Strategy Team

10.3.7. Relatively short and easily understood

10.3.8. 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)

10.4. Business Case

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

10.4.2. Provides justification that the programme is worthwhile

10.4.3. Responsiblities Owned by: Agreed by: Compiled and Updated by: Contributions from:

10.5. Business Architecture Model (BAM)

10.5.1. Describes the desired future structure of the organization

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

10.5.3. 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

10.6. Programme Plan

10.6.1. 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

10.6.2. 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

10.7. Tranche Plan

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

10.7.2. Produced for each incremental step in the programme

10.7.3. Produced immediately prior to the commencement of the tranche

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

10.8. Tranche Review Record

10.8.1. 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

10.8.2. Produced at the end of a tranche

10.8.3. An output of the Tranche Review

10.9. Programme Control Pack

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

10.9.2. Programme Risk Log

10.9.3. Programme Issues Log

10.9.4. Communication Log

10.9.5. High-Level Project Status

10.9.6. Benefits Assessment

10.10. Stakeholder Engagement Strategy

10.10.1. Defines approach to be taken towards all groups of stakeholders

10.10.2. Includes internal and external stakeholders

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

10.11. Communication Plan

10.11.1. Aimed predominantly at the communication requirements for a given tranche

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

10.12. Governance Strategy

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

10.13. Capabilities

10.14. Benefits

10.15. Prioritised Benefits Definition

10.15.1. Defines benefits predicted to emerge from the change

10.15.2. Defines how benefits realisation will be measured

10.15.3. Can be decomposed into sub-benefits

10.15.4. Benefits should be prioritised using MoSCoW rules

10.16. Programme / Tranche Approach Questionalire (PTAQ)

10.16.1. Original product of DSDM

10.16.2. Provides set of questions to be asked when conducting agile programme

10.16.3. Helps assess how Tranches should be applied in specific environment

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

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

10.16.6. Helps to understand how the critical success factors are addressed

11. AgilePgM® Roles (10)

11.1. Legend

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

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

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

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

11.3. An individual or group can take more than one role

11.4. Programme Management Team (PMT)

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

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

11.4.3. Roles are supported in administrative affairs by the Programme Support Office

11.4.4. 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

11.4.5. 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®)

11.4.6. 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

11.4.7. 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®)

11.5. Capability Delivery Team (CDT)

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

11.5.2. Programme Technical Architect (PTA) Responsibilities Agreeing and ultimately controlling the programmes architectures 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

11.5.3. 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

11.5.4. 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

11.5.5. 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

11.6. Supporting Roles

11.6.1. Deals with: assistance and guidance to the programme

11.6.2. Works on ad hoc basis throughout the programme lifecycle

11.6.3. 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

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

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

12. Interactive AgilePgM® Glossary

12.1. Interactive AgilePgM® Glossary

13. Portfolios, Programmes & Projects

13.1. DSDM AgilePgM framework in context

13.2. Relationship between Programme and Projects

13.3. Example programme with three tranches

14. AgilePgM® Planning

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

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

14.1.2. Experience from executing plans will change the future plans

14.2. Planning needs to

14.2.1. Be iterative and incremental

14.2.2. Set the vision for the long term

14.2.3. Divide delivery into increments to realise benefits as early as possible

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

14.2.5. Plan the immediate future in some detail

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

14.2.7. Review and update plans based on experience of delivery

14.2.8. Review and update plans based on the current business landscape

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

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

14.4. MoSCoW Prioritisation