## Introduction to The DSDM Agile Project Framework

DSDM (Dynamic Systems Development Method) is a comprehensive agile project delivery framework that provides a robust approach to managing, planning, and controlling agile projects. It focuses on delivering business value quickly and effectively, ensuring projects are delivered on time and on budget, and that the solution is fit for purpose. DSDM is a framework, not just a methodology, meaning it provides a structure that can be adapted to various project contexts.

## DSDM Philosophy and Principles

The DSDM Philosophy states: "The best way to deliver value is to deliver frequently and incrementally, in a collaborative, self-organising team, with a focus on business needs."

This philosophy is supported by 8 Principles that guide all DSDM projects:

• Focus on the Business Need: Every decision must align with business objectives.
• Deliver on Time: Punctual delivery is a key measure of success.
• Collaborate: Active user involvement and close cooperation are essential.
• Never Compromise Quality: Quality is a prerequisite, not a variable.
• Build Incrementally from Firm Foundations: Start with a clear understanding and evolve the solution.
• Develop Iteratively: Embrace change and refine solutions through repeated cycles.
• Communicate Continuously and Clearly: Effective communication is vital for success.
• Demonstrate Control: Maintain transparency and control throughout the project.

## The DSDM Lifecycle

The DSDM framework defines a structured, yet agile, lifecycle with 6 phases:

• Pre-Project: Ensures projects are set up correctly.
• Feasibility: Establishes if the project is viable from a business and technical perspective.
• Foundations: Defines the 'what' and 'how' of the solution at a high level.
• Evolutionary Development: Iteratively develops the solution, delivering increments.
• Deployment: Releases the tested increment into operational use.
• Post-Project: Reviews the project's success and benefits realisation.

## Key DSDM Techniques and Roles

MoSCoW Prioritisation is a core technique used to prioritise requirements into:

• Must Have: Non-negotiable requirements.
• Should Have: Important, but not critical, can be deferred.
• Could Have: Desirable, but less critical, easily dropped.
• Won't Have: Requirements agreed not to be delivered in this increment.

Timeboxing is another fundamental technique, fixing time and cost while allowing the scope (specifically 'Could Have' and 'Should Have' requirements) to vary to meet deadlines. Other techniques include Facilitated Workshops, Modelling, and Prototyping.

Key DSDM roles include the Business Sponsor (funding, strategic direction), Project Manager (overall project management), Business Ambassador (represents business needs in the team), Technical Coordinator (technical architecture), and Solution Developer (builds the solution).

## AgilePM Philosophy: DSDM's Core

AgilePM is built upon the Dynamic Systems Development Method (DSDM), a proven agile framework. Its philosophy centers on delivering business value quickly and continuously. Unlike traditional approaches, DSDM aims for fixed time and fixed cost projects, achieving this by allowing scope to flex. This ensures early and frequent delivery of working solutions, fostering a collaborative environment where stakeholders are actively involved throughout the project lifecycle. A core tenet is the no blame culture, promoting learning and adaptation.

## The 8 Principles of AgilePM

These principles guide all AgilePM projects:

• Focus on the Business Need: Every effort must contribute to a clear business objective.
• Deliver on Time and to Budget: Project control is paramount; timeboxes and budgets are fixed.
• Collaborate: Active involvement and shared ownership among all stakeholders.
• Never Compromise Quality: Quality is defined and agreed upon early and is non-negotiable.
• Build Incrementally from Firm Foundations: Start with a solid understanding, then evolve the solution.
• Develop Iteratively: Embrace change and refine solutions through repeated cycles.
• Communicate Continuously and Clearly: Open and honest communication is vital for shared understanding.
• Demonstrate Control: Maintain visibility and manage the project proactively.

## Project Variables: Fixed Time, Fixed Cost, Variable Scope

A fundamental difference in AgilePM is its approach to project variables. Traditional projects often fix scope and allow time/cost to vary, leading to potential overruns. AgilePM, conversely, fixes time and cost, treating them as constraints. To achieve this, scope becomes the variable. This is managed through effective prioritization using techniques like MoSCoW (Must Have, Should Have, Could Have, Won't Have this time).

Quality is considered a fixed, non-negotiable element. By prioritizing requirements, the most critical features (Must Haves) are always delivered, ensuring a minimum viable product within the agreed timeframe and budget, while less critical features (Should/Could Haves) can be deferred or dropped if necessary. This approach guarantees a working solution on time and within budget, delivering maximum possible business value.

## DSDM Roles and Responsibilities

DSDM (Dynamic Systems Development Method), upon which AgilePM is based, defines a comprehensive set of roles designed to ensure effective collaboration, clear accountability, and successful project delivery. These roles are typically categorised into three levels:

• Business Roles: Focus on the 'what' and 'why' – ensuring the project delivers real business value.
• Management Roles: Focus on the 'how' – managing the project process and environment.
• Technical Roles: Focus on the 'build' – creating and testing the solution.

Key Business Roles

• Business Sponsor: The ultimate authority for the project, accountable for its business case, ROI, and ensuring adequate funding and resources. They empower the Business Visionary.
• Business Visionary: Defines the project's overall vision, high-level scope, and requirements. They represent the business user community at a strategic level and ensure the solution aligns with business needs.
• Business Ambassador: Represents specific business areas or user groups. They provide detailed business requirements, actively participate in workshops and reviews, and are empowered to make decisions on behalf of their users.
• Business Advisor: Provides specialist input (e.g., legal, security, marketing) as required, typically not a full-time role.

Key Management Roles

• Project Manager (PM): Facilitates the project, manages the process, risks, and budget. The PM focuses on the project lifecycle and ensures effective communication and collaboration across all stakeholders.
• Team Leader: Leads the Solution Development Team (SDT), facilitates daily stand-ups, removes impediments, and mentors team members. They ensure the team adheres to DSDM principles and practices.

Key Technical Roles

• Technical Coordinator (TC): Ensures the technical quality, consistency, and architectural integrity of the solution. They define technical standards and mentor technical team members.
• Solution Developer: Designs, builds, and tests parts of the solution, collaborating closely within the SDT to deliver increments.
• Solution Tester: Tests the solution to ensure quality and adherence to requirements, working with developers and business representatives.

Supporting Roles

Supporting roles like the Workshop Facilitator, DSDM Coach, and DSDM Trainer provide specialist assistance to ensure efficient working practices and DSDM adoption. All DSDM roles emphasise empowerment, collaboration, and continuous communication to deliver value incrementally.

## The DSDM Process

The DSDM Process provides a robust, iterative, and incremental framework for agile project management, emphasizing the delivery of business value quickly and frequently. It's structured around a lifecycle designed to ensure controlled and successful project delivery, integrating principles like active user involvement and frequent delivery.

## DSDM Process Lifecycle Phases

The DSDM Process comprises six distinct, yet often overlapping, phases:

• Pre-Project: This initial phase ensures that only well-conceived and viable projects are started. It focuses on identifying the project's business need, strategic fit, and securing initial funding and commitment.
• Feasibility: Here, the project's overall viability is assessed from both business and technical perspectives. It answers whether the project is possible and desirable, establishing a high-level business case and understanding key risks.
• Foundations: This phase establishes the 'what' and 'how' of the solution at a high level. It involves defining the scope, high-level requirements, architectural outline, and the project approach, including team structure and initial plan.
• Evolutionary Development: This is the core iterative and incremental phase where the solution is built. It involves cycles of Explore, Refine, and Consolidate. Requirements are refined, the solution is developed, tested, and reviewed, continuously moving towards a deployable increment.
• Deployment: In this phase, a tested and approved increment of the solution is released into the operational environment. It includes activities like user training, data migration, and formal handover to operational teams.
• Post-Project: This final phase ensures that the business benefits defined in the business case are realized. It involves reviewing the project's success against objectives, identifying lessons learned, and ensuring ongoing support and maintenance for the delivered solution.

## Key Techniques within the Process

• Timeboxing: A core DSDM technique where work is fixed into short, fixed-duration periods (timeboxes). Scope is variable and managed using prioritisation.
• MoSCoW Prioritisation: Used extensively within timeboxes and across the project to prioritize requirements and tasks. It categorizes items as Must have, Should have, Could have, and Won't have (this time), ensuring focus on critical features.
• Active User Involvement: DSDM stresses continuous and active engagement from business users throughout the project lifecycle, particularly during Evolutionary Development, to ensure the solution meets real business needs.

## DSDM Products Overview

AgilePM (based on DSDM) projects create a set of defined products (deliverables) throughout their lifecycle. These products provide structure, maintain control, and ensure alignment with business objectives. They are categorised into Feasibility, Foundations, Evolutionary, Deployment, and Post-Project products.

A key DSDM concept is that products evolve over time, starting with high-level definitions and becoming more detailed as the project progresses. This iterative refinement supports continuous feedback and adaptation.

## Key Feasibility & Foundations Products

• Terms of Reference (ToR): Defines the scope and objectives for the Feasibility phase. It ensures everyone understands what needs to be assessed.
• Business Case: Justifies the project from a business perspective, outlining the expected benefits, costs, and risks. It's a living document, reviewed and updated throughout the project.
• Prioritised Requirements List (PRL): A high-level list of all requirements, prioritised using MoSCoW (Must Have, Should Have, Could Have, Won't Have). This ensures focus on critical features.
• Solution Architecture Definition (SAD): Describes the high-level technical architecture and design of the solution, ensuring it is fit for purpose, scalable, and maintainable.
• Management Approach Definition (MAD): Outlines how the project will be managed, including roles, responsibilities, reporting structures, and project controls.
• Development Approach Definition (DAD): Specifies the technical tools, techniques, environments, and standards to be used during development.

## Key Evolutionary & Deployment Products

• Evolving Solution: This is the incremental, iterative development of the actual business solution. It includes prototypes, increments, and the final deliverable, continually refined based on feedback from stakeholders.
• Deployment Plan: Details the strategy and activities required to release the Evolving Solution into the live environment, including training, data migration, and ongoing support arrangements.
• Deployed Solution: The final, tested, and accepted business solution that has been successfully released into the operational environment, ready for use.

## Key Post-Project Product

• Benefits Realisation Report: Created post-project closure, this report confirms whether the expected business benefits outlined in the Business Case have actually been achieved over time. It validates the project's ultimate success and value delivery.

## MoSCoW Prioritisation

MoSCoW is a widely used prioritisation technique in AgilePM, crucial for managing scope within fixed time and cost projects. It categorises requirements to ensure the most important features are delivered first, aligning with the principle of delivering value early.

• Must Have: These are non-negotiable requirements, absolutely essential for the solution to be viable and acceptable. Without a Must Have, the project cannot be considered a success. They should be kept to a minimum to allow flexibility.
• Should Have: Important requirements that add significant value but are not critical for viability. Omitting them would be painful, but the solution would still be functional. These are often delivered after all Must Haves.
• Could Have: Desirable requirements that are nice to have if time and resources permit. They offer additional benefits but are the first to be dropped under pressure, providing the primary buffer for timebox delivery.
• Won't Have (this time): Requirements agreed to be excluded from the current delivery increment. This manages expectations and prevents future misunderstandings, while allowing for potential inclusion in later increments or projects.

Prioritisation is a collaborative effort involving business and technical stakeholders, and the relative importance of items can evolve as understanding grows and circumstances change.

## Timeboxing

Timeboxing is a core AgilePM technique involving a fixed period of time (a 'timebox') during which a team works to deliver an agreed set of outcomes. It has a non-negotiable fixed end date and fixed resources (the stable team).

The primary variable within an AgilePM timebox is scope, which is managed using MoSCoW prioritisation. This ensures that the most important features are delivered by the deadline, even if some lower-priority items need to be deferred.

Timeboxes drive focus, manage risk by forcing frequent delivery of working solutions, and provide regular opportunities for feedback and adaptation. They prevent projects from overrunning by making scope the adjustable element, not the deadline.

## MoSCoW and Timeboxing in Practice

These two techniques work hand-in-hand to deliver value within constraints. Within a timebox, the team commits to delivering all Must Haves. They then aim to deliver as many Should Haves as possible, followed by Could Haves if time permits. Won't Haves are explicitly excluded from the current timebox.

If a Must Have cannot be delivered, it triggers a serious re-evaluation of the project or timebox, as the viability of the solution is at stake. However, the flexibility to descope Should Haves and Could Haves is crucial for meeting the fixed deadline and delivering a viable, acceptable solution, embodying the AgilePM principle of 'fix time and cost, flex scope'.

## Planning and Control in AgilePM

AgilePM operates on a fixed time, fixed cost, variable scope model, making effective planning and control fundamental for project success. The central mechanism for achieving this is timeboxing.

## Timeboxing: The Core Mechanism

A Timebox is a fixed, short period of time (typically 2-4 weeks) within which a specific set of objectives must be met. It has a defined start and end date, and its scope is managed using MoSCoW prioritisation. This ensures that the most critical requirements (Must Have) are delivered first, followed by Should Have, Could Have, and finally Won't Have this time if scope needs to be adjusted. This flexibility in scope is key to delivering within fixed time and cost.

Each Timebox follows a structured cycle:

• Kick-off: The team agrees on the Timebox objectives and initial tasks.
• Daily Stand-ups: Short, daily meetings for the team to report progress, highlight impediments, and re-plan their work for the day.
• Review: At the end of the Timebox, the team demonstrates the working solution to stakeholders and gathers feedback.
• Close-out: Formal completion of the Timebox, including updating progress and capturing lessons learned.

## Levels of Planning

Planning in AgilePM occurs at multiple levels, providing increasing detail as the project progresses:

• Project Level: The Project Plan provides a high-level overview, outlining the project's phases (e.g., Feasibility, Foundations, Exploration, Deployment) and overall timeline.
• Phase Level: The Foundations Phase establishes the project's baseline, defining the detailed scope, solutions, and delivery approach. The Exploration Phase involves iterative development within Timeboxes.
• Timebox Level: Detailed planning for each individual Timebox, breaking down features into specific tasks for the team.
• Daily Level: Individual team members plan their daily activities, often discussed during Daily Stand-ups.

## Monitoring and Control Mechanisms

Control in AgilePM is continuous, collaborative, and adaptive:

• Daily Stand-ups: Essential for real-time progress monitoring, identifying and resolving issues, and fostering team collaboration.
• Timebox Reviews: Provide regular opportunities for stakeholders to inspect the delivered increments and provide feedback, ensuring alignment with business needs.
• Risk Management: Risks are continuously identified, assessed, and managed throughout the project lifecycle, with responses planned proactively.
• Configuration Management: Ensures that all project products (e.g., code, documentation, test scripts) are version-controlled and managed effectively.
• Estimation: Often uses relative estimation (e.g., Story Points) rather than absolute time, and velocity (the team's historical average work completion rate) to forecast future delivery. The Project Manager and Team Leader facilitate these processes, empowering the team to self-organise while maintaining project alignment.

## Key DSDM Practices

AgilePM, built on the DSDM (Dynamic Systems Development Method) framework, employs several key practices to ensure successful, iterative delivery of business value. These practices promote collaboration, continuous improvement, and effective management of scope and time, forming the backbone of an AgilePM project.

Iterative Development

This core practice involves breaking down the project into smaller, manageable increments or iterations. Each iteration delivers a working, tested piece of the solution, allowing for early feedback and continuous refinement. This approach reduces risk, enables flexibility, and ensures the solution evolves to meet changing business needs effectively.

Timeboxing

Timeboxing is fundamental to DSDM. It involves fixing a period of time (a "timebox") for a specific activity or set of activities, with the objective of delivering the best possible solution within that timeframe. Resources and deadlines are fixed, while scope is variable and prioritised. This practice drives focus, prevents projects from overrunning, and ensures that something usable is always delivered by the deadline.

MoSCoW Prioritisation

This technique is used to prioritise requirements and deliverables effectively, ensuring that the most important items are delivered first. It categorises items into:

• Must Have: Non-negotiable requirements essential for the solution to be viable.
• Should Have: Important requirements that add significant value but are not critical for immediate delivery.
• Could Have: Desirable requirements that would improve the solution but are less important.
• Won't Have (for now): Requirements agreed not to be delivered in the current increment, to be revisited later.

MoSCoW ensures focus on critical items and manages expectations regarding scope.

Facilitated Workshops

These are structured, collaborative sessions involving key stakeholders and team members. They are highly effective for rapid information gathering, decision-making, and conflict resolution. Workshops promote shared understanding, build consensus, and accelerate progress compared to traditional serial meetings.

Modelling and Prototyping

Modelling involves creating visual representations (diagrams, flowcharts) of processes, data, or system components to aid understanding and communication among stakeholders. Prototyping involves building early, experimental versions of the solution to test ideas, gather user feedback, and validate requirements quickly. Both practices help to reduce ambiguity, confirm feasibility, and ensure the solution meets user needs before significant investment.

Daily Stand-ups and Retrospectives

Daily Stand-ups (or Daily Scrums) are short, timeboxed meetings where the team synchronises activities, shares progress, and identifies any impediments. They foster transparency and collaboration. Retrospectives are regular team meetings held at the end of an iteration or phase to review how the process went, identify what worked well, what didn't, and agree on improvements for future iterations. These practices drive continuous improvement within the team and project.