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
2.1.1.1. Overall strategy, direction and goals of the business
2.1.1.2. Agreement and review of Business Case for programme with respect the Business Strategy
2.1.1.3. Prioritisation of the programme against other initiatives
2.1.1.4. Approval of programme vision
2.2. Programme Board
2.2.1. Responsibilities
2.2.1.1. Approval of Prioritised Benefits
2.2.1.2. Agreement of Programme and Tranche Plans
2.2.1.3. Agreement of project high-level requirements / scope with respect to the programme's Business Case
2.2.1.4. 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
2.3.1.1. 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
2.4.2.1. 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
2.5.2.1. 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
2.6.3.1. 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 - www.dsdm.org
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
4.1.2.1. 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
4.2.1.1. 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
4.2.5.1. 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
4.2.7.1. 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
4.3.2.1. Yet agile projects has to incorporate changes from programme
4.3.3. Projects must be aligned with programme vision
4.3.3.1. Projects (and other initiatives) must be constantly synchronised to ensure that they can deliver a capability that is coherent across the organisation
4.3.3.2. 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
4.4.3.1. Decisions regarding overall goal and vision has to be mage by Programme
4.4.3.2. 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
4.5.2.1. 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
5.3.4.1. right-engineering (no under-engineering or over-engineering)
5.3.4.2. 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: www.miroslawdabrowski.com
6.1.1. http://www.miroslawdabrowski.com
6.1.2. http://www.linkedin.com/in/miroslawdabrowski
6.1.3. https://www.google.com/+MiroslawDabrowski
6.1.4. https://play.spotify.com/user/miroslawdabrowski/
6.1.5. https://twitter.com/mirodabrowski
6.1.6. miroslaw_dabrowski
7. AgilePgM® Official publications
7.1. Agile Programme Management Handbook
7.1.1. http://dsdm.org/product/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
8.4.1.1. Describe business transformation
8.4.1.2. Identify Business Programme Owner (PBO) and Busines Change Owners (BCOs)
8.4.1.3. Derive a programme from the existing portfolio within the organisation
8.4.1.4. Confirm alignment of programme vision with business strategy, vision, misson etc.
8.4.1.5. Scope, Plan, Resource Programme Feasibility phase (not the whole programme)
8.4.1.6. Check if programme is worth pursuing to Programme Feasibility phase
8.4.1.7. Determining the initial key roles
8.4.1.7.1. Business Programme Owner (BPO)
8.4.1.7.2. 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
8.5.1.1. Confirm programme is consistient with business strategy and potentially achievable
8.5.1.2. Refine outline vision of programme
8.5.1.3. Outline high-level benefits of business transformation
8.5.1.4. Produce initial outline costs for the programme
8.5.1.5. Confirm programme structure
8.5.1.6. Develop outline plan for Programme Foundations
8.5.1.7. Develop outline governance strategy
8.5.1.8. 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
8.6.1.1. Baseline programme vision
8.6.1.2. Create initial Business Architecture Model
8.6.1.3. Define initial Roadmap for realising vision
8.6.1.4. Define and prioritise the high-level benefits and capabilities
8.6.1.5. Confirm the Business Case for the programme
8.6.1.6. Establish governance model that is Agile
8.6.1.7. Develop Programme Plan
8.6.1.8. Describe, assess and manage risk
8.6.1.9. Identify and categorise key stakeholders
8.6.1.10. Plan initial tranche(s)
8.6.1.11. Obtain approval to proceed to first tranche
8.6.1.12. 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)
8.6.6.1. Identify and plan the projects and initiatives to build the capabilities
8.6.6.1.1. Projects may be sequential or much often overlapping
8.6.6.1.2. Plan only high-level scope of each project in alignment to programme Business Case
8.6.6.1.3. Determine projects inter-dependencies
8.6.6.1.4. Set outline budget
8.6.6.1.5. Set outline start and end dates
8.6.6.2. Identify and plan the activities required to build and enable the capabilities
8.7. 4. Capability Evolution
8.7.1. Objectives
8.7.1.1. Plan, initiate and execute projects to deliver the capabilities
8.7.1.1.1. a.k.a. Sprints / Timeboxes on the programme level
8.7.1.2. Iteratively and incrementally enable consistent subsets of capabilities into the live organization
8.7.1.2.1. a.k.a. Deployments on the programme level
8.7.1.3. Deliver capabilities as soon as posible through projects with delivering outputs regularly and often
8.7.1.4. Run projects within tranches (tranches can be overlapping)
8.7.1.5. Measure the benefits being released through the capabilities
8.7.2. Contains 2 main processes
8.7.2.1. Capability Enablement
8.7.2.2. Benefits Realisation
8.8. 5. Tranche Review
8.8.1. Objectives
8.8.1.1. Confirm the sufficient capability has been delivered for the tranche
8.8.1.1.1. a.k.a. Review on programme tranche level
8.8.1.2. Plan next tranche in sufficient detail
8.8.1.3. Review the programme and update plans and other Programme Foundations products as necessary based on experiences from the current tranche
8.8.1.4. Review lessons learnt
8.8.1.4.1. 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
8.9.1.1. Confirm that sufficient capability has been delivered
8.9.1.2. Close the programme
8.9.1.3. Gather lessons learnt for the future initiatives
8.9.1.3.1. a.k.a. Retrospective on programme level
8.9.1.4. 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
10.1.1.1. Initial produced in outline in a specific phase
10.1.1.2. Continued to evolve, becoming more detailed as the programme progresses
10.1.2. Milestone products
10.1.2.1. Created in a phase and typically fulfill a specific purpose
10.1.3. Foundation products
10.1.3.1. Fundamental drivers of the programme
10.1.3.2. Normally baselined during the Programme Foundations
10.1.3.3. Set the basis of all programme activity
10.2. Legend
10.2.1. Icon
10.2.1.1. 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
10.2.2.1. Business focused products
10.2.3. Blue
10.2.3.1. Programme management focused products
10.2.4. Green
10.2.4.1. Outputs / Capabilities / Benefits focused products
10.2.5. Violet
10.2.5.1. 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
10.3.8.1. Owned by:
10.3.8.1.1. Business Programme Owner (BPO)
10.3.8.2. Agreed by:
10.3.8.2.1. Business Strategy Team (outside the AgilePgM)
10.3.8.3. Compiled and Updated by:
10.3.8.3.1. Business Programme Owner (BPO) and peers
10.3.8.4. Contributions from:
10.3.8.4.1. 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
10.4.3.1. Owned by:
10.4.3.2. Agreed by:
10.4.3.3. Compiled and Updated by:
10.4.3.4. 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):
10.5.3.1. Processes
10.5.3.1.1. Processes and business models of operations and functions
10.5.3.1.2. Operational costs and performance levels, KPIs
10.5.3.2. Organisational structure
10.5.3.2.1. Organisation structure, staffing levels, roles and skills
10.5.3.2.2. Culture, style, supply chain
10.5.3.3. Technology
10.5.3.3.1. Technology, IT systems, tools, equipment, machinery
10.5.3.3.2. Buildings and accommodation, infrastructure
10.5.3.4. Information
10.5.3.4.1. Information and data required for future business operations and performance measurement
10.5.3.4.2. Current State, Intermediate Future States, Final Future State
10.6. Programme Plan
10.6.1. Roadmap
10.6.1.1. Describes the incremental steps (tram to realise the vision of the programme
10.6.1.2. Forms part of the Programme Plan
10.6.1.3. Describes a schedule of tranches for the incremental enablement of consistent capabilities
10.6.2. Benefits Realisation Plan
10.6.2.1. 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
10.7.1.1. 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
11.1.1.1. Business intrest roles representing the business view
11.1.1.2. Typically taken by business personnel
11.1.2. Blue
11.1.2.1. Management intrest roles representing the management / leadership view
11.1.2.2. Managing or facilitating the management/leadership aspects of the programme
11.1.3. Green
11.1.3.1. Technical intrest roles representing the technical view
11.1.3.2. 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
11.4.4.1. Strong communication skills
11.4.4.2. Confidence and trust in their teams, giving them real empowerment
11.4.4.3. Clarity of vision and ability to share it with others
11.4.4.4. Determination to achieve the vision
11.4.4.5. Strong focus on priorities
11.4.4.6. Respect for everyone involved in the programme
11.4.4.7. Ability to inspire and motivate
11.4.4.8. Positive attitude at all times and an innate ability to be diplomatic
11.4.4.9. Passion and pride in what they do
11.4.4.10. Lateral thinking and the ability to find innovative ideas
11.4.4.11. Ability to focus on developing people
11.4.4.12. Willingness to take calculates risks
11.4.5. Business Programme Owner (BPO)
11.4.5.1. Programme Champion
11.4.5.2. The most senior programme-level business role
11.4.5.3. Responsibilities
11.4.5.3.1. Overall strategic programme direction
11.4.5.3.2. Continuous and ongoing commitment to the programme
11.4.5.3.3. Provision of funds
11.4.5.3.4. Ensuring the programme vision and goals are aligned with organisational / business strategy
11.4.5.3.5. Managing the interface to key stakeholders
11.4.5.3.6. Ensuring efficient, effective and rapid decision-making process
11.4.5.3.7. Responding rapidly to escalate issues
11.4.5.4. Mappings to other roles in other methods ...
11.4.5.4.1. Managing Successful Programmes (MSP®)
11.4.6. Programme Manager (PgM)
11.4.6.1. Responsibilities
11.4.6.1.1. Incremental and iterative programme design and planning
11.4.6.1.2. Monitoring the programme progress agains it's design and plan
11.4.6.1.3. Ensuring project outputs are appropriate (meeting the programme vision with ability to deliver benefits)
11.4.6.1.4. Managing risks and issues
11.4.6.1.5. Creating autonomous projects environment
11.4.6.1.6. Managing project interdependencies and inter-projects conflicts
11.4.6.1.7. Managing and communicating with all stakeholders
11.4.6.1.8. Working together with Stakeholder Engagement Coordinator ensuring clear and continuous communication
11.4.6.1.9. Incremental and iterative programme design and planning
11.4.7. Business Change Owners (BCOs)
11.4.7.1. Realising benefits that the new programme capabilities will provide
11.4.7.2. Implementing change in the business area
11.4.7.3. Senior member of a specific business area
11.4.7.4. Responsibilities
11.4.7.4.1. Defining benefits for their area of responsibility
11.4.7.4.2. Ensuring projects are aligned to the programme vision
11.4.7.4.3. Creating and monitoring the plan for benefits realisation
11.4.7.4.4. Reacting to business change
11.4.7.4.5. Leading change in their business area
11.4.7.4.6. Managing stakeholders within their area of business
11.4.7.4.7. Ensuring efficient, effective and rapid decision-making process
11.4.7.4.8. Responding rapidly to escalate issues
11.4.7.5. Characterisics
11.4.7.5.1. Incremental approach
11.4.7.5.2. Constant review benefits against current business
11.4.7.5.3. Instils empowernmanet and commitment
11.4.7.5.4. Strong communication of the programme vision
11.4.7.5.5. Gentle steering of project teams towards the progremme vision
11.4.7.6. May be supported by
11.4.7.6.1. Programme Change Architect
11.4.7.6.2. Stakeholder Engagement Cooridnator
11.4.7.6.3. Change Agents
11.4.7.7. Mappings to other roles in other methods ...
11.4.7.7.1. Managing Successful Programmes (MSP®)
11.5. Capability Delivery Team (CDT)
11.5.1. Deals with:
11.5.1.1. delivery of the products/outputs
11.5.1.2. business architectural design and consistency
11.5.1.3. technical design and consistency
11.5.1.4. stakeholder engagement and commitment
11.5.2. Programme Technical Architect (PTA)
11.5.2.1. Responsibilities
11.5.2.1.1. Agreeing and ultimately controlling the programmes architectures
11.5.2.1.2. Agreeing technical environments
11.5.2.1.3. Advising and coordinating each project's technical activities
11.5.2.1.4. Identifying and owning programme-level architectural and other technical risks
11.5.2.1.5. Ensuring compliance with appropriate norms, standards, technical best practices
11.5.2.1.6. Resolving design / technical differences between project members across projects
11.5.2.1.7. 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)
11.5.3.1. Responsibilities
11.5.3.1.1. Creating the Business Architecture Model (BAM)
11.5.3.1.2. Advising and guiding on business architecture
11.5.3.1.3. Monitoring the achievement of the Business Architecture Model (BAM)
11.5.3.1.4. Identifying and owning programme-level business architecture risk
11.5.3.1.5. Resolving differences between project teams with respect to business architecture as defined in the Business Architecture Model (BAM)
11.5.3.1.6. 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)
11.5.4.1. Onward-facing and inward-looking
11.5.4.2. The key purpose of outward stakeholder engagement Sis to ensure that stakeholders remain informed about, engaged with, and positive towards programme
11.5.4.2.1. 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
11.5.4.3. Stakeholder Engagement Coordinator has two aspects:
11.5.4.3.1. Engagement and communication outward from the programme to stakeholders
11.5.4.3.2. Engagement of stakeholders into the programme and internal communication within the programme
11.5.4.4. Agile programme will generally require more business resource to be involved in the programme than using more traditional techniques
11.5.4.4.1. 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
11.5.4.5. Responsibilities
11.5.4.5.1. Creating and maintaining the Stakeholder Engagement Strategy
11.5.4.5.2. Ensuring active, ongoing engagement with all stakeholders
11.5.4.5.3. Creating and maintaining the Tranche Communication Plan
11.5.4.5.4. Identifying and owning programme-level stakeholder engagement activities
11.5.4.5.5. Ensuring all outward communications are aligned to programme vision
11.5.4.5.6. Facilitating and ensuring effective communication between teams and stakeholders within the programme
11.5.5. Project Teams (PTs)
11.5.5.1. Responsibilities
11.5.5.1.1. not defined in AgilePgM™
11.5.5.1.2. 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:
11.6.1.1. assistance and guidance to the programme
11.6.2. Works on ad hoc basis throughout the programme lifecycle
11.6.3. Change Agents (CAs)
11.6.3.1. Responsibilities
11.6.3.1.1. Change management specialist input
11.6.3.1.2. Assisting Business Change Owners (BCOs)
11.6.3.1.3. Implementing business processes to realise the benefits of new capabilities
11.6.3.1.4. Implementing organisational changes required to realise the benefits of new capabilities
11.6.4. Specialists (Ss)
11.6.4.1. Responsibilities
11.6.4.1.1. Consulting input
11.6.4.1.2. Advising and guiding the programme stakeholders / decision-makers
11.6.5. Programme Support Office (PSO)
11.6.5.1. Responsibilities
11.6.5.1.1. not defined in AgilePgM™
11.6.5.1.2. 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