The DSDM Agile Project Framework (2014 Onwards)

Handbook

Products

8.1    Introduction to DSDM Products

The DSDM Agile Project Framework describes a set of products to be considered as the project proceeds. These products describe the solution itself (the main deliverable of the project) and anything created to help with the process of evolving it, and anything that is required to help with project governance and control.



Not all products are required for every project and the formality associated with each product will vary from project to project and from organisation to organisation. The formality of the products is influenced by factors such as contractual relationships, corporate standards and governance needs.



DSDM identifies two distinct types of product:

  • Evolutionary products evolve over time. They typically, but not always, span a number of project phases and may be baselined more than once during that time.

     
  • Milestone products are created in a phase and typically fulfil a specific purpose within that phase as a checkpoint or to facilitate governance processes





Figure 8a: DSDM products



The products, and where they feature in the project lifecycle, are shown in the diagram above. Orange products are business-focused, green products all contribute to the solution being created by the project and blue products cover project management/control interests. Several of the products - those marked with - may also play a part in governance processes such as approval gateways, and may be used to demonstrate compliance of the solution with corporate and regulatory standards where this is required.

8.2    The DSDM Products

8.2.1      Terms of Reference

Description



The Terms of Reference is a milestone product. It is a high-level definition of the over-arching business driver for, and top-level objectives of, the project.The primary aim of the Terms of Reference is to scope and justify the Feasibility phase. It is identified as a governance product because it may be used for purposes such as prioritisation of a project within a portfolio.

Roles and responsibilities

  Role  Rationale 
Produced By Anybody Anybody can have an idea for a project
Produced for Project Governance Authority To check alignment with strategic goals and help prioritise within a portfolio
  Business Analyst Techinical Coordinator To ensure, by reference, objectives and proposed solutions emerging during Foundations phase are appropriately aligned
Approved by Business Sponsor Person with budget for the Feasibility investigation

8.2.2 Business Case



Description



The Business Case is an evolutionary product. It provides a vision and a justification for the project from a business perspective. The business vision describes a changed business as it is expected to be, incrementally and at the end of the project. The justification for the project is typically based on an investment appraisal determining whether the value of the solution to be delivered by the project warrants the cost to produce, support and maintain it into the future, all within an acceptable level of risk.



Baselines of the Business Case are typically created first as an outline by the end of Feasibility, then as a basis for approval of development by the end of Foundations. It is formally reviewed at the end of each Project Increment in order to determine whether further work is justified.



Roles and responsilbilities

  Role  Rationale 
Produced By  Business Analyst  Skills and experience with Business Case production and working  collaboratively with the senior business and techinical roles
Produced for Project Governance Authority Approval for project to proceed and to help prioritise the project within a protfolio 
  The entire project team  Everybody involved needs to understand what is needed and why
Approved by Business Sponsor  Responsible and accountable for return on investment 

 

8.2.3      Prioritised Requirements List

Description



The Prioritised Requirement List (PRL) is an evolutionary product. It describes, at a high level, the requirements that the project needs to address and indicates their priority with respect to meeting the objectives of the project and the needs of the business. Consideration of requirements begins in Feasibility and a baseline of the PRL demarcates the scope of the project as at the end of Foundations. After that point, fur ther change will happen naturally in terms of depth, as a result of emergence of detail. Change to the breadth (adding, removing or significantly changing high-level requirements) needs to be formally controlled in order to ensure ongoing alignment with the business vision for the project and to keep control of the scope.

Roles and responsibilities

   Role   Rationale
Produced By  Business Analyst Skills and experience with eliciting and defining requirements
Produced for   The entire project team Everybody involved needs to understand the requirements
Approved By   Business Visionary Responsible for ensuring that requirements align with business vision

 

8.2.4 Solution Architecture Definition



Description



The Solution Architecture Definition is an evolutionary product. It provides a high-level design framework for the solution. It is intended to cover both business and technical aspects of the solution to a level of detail that makes the scope of the solution clear but does not constrain evolutionary development.




Roles and responsibilities

  Role Rationale
Produced by  Business Analyst  Responsible for overall design of business process and organisation change 
  Technical Coordinator  Responsible for overall design and integrity of technical aspects of solution 
Produced for Solution Development Team  Building a solution witin the framework described 
Approved by  Business Visionary  Responsible for delivering the required business change 
  Project Manager  Responsible for ensuring the products of the project are delivered 

8.2.5 Development Approach Definition



Description



The Development Approach Definition is an evolutionary product. It provides a high-level definition of the tools, techniques, customs, practices and standards that will be applied to the evolutionary development of the solution. Importantly it describes how quality of the solution will be assured. A strategy for testing and review is therefore a key part of the development approach and described in the Development Approach Definition




Roles and responsibilities

  Role  Rationale
Produced by  Technical Coordinator Responsible for defining technical standards and ensuring development best practices are applied
 Produced for Solution Development Team  Responsible for building the solution in a professional way and to the requried level of techinical quality
Approved by  Project Manager  Responsible for ensuring the products of the project are delivered



8.2.6 Delivery Plan



Description



The delivery plan is an evolutionary product. It provides a high-level schedule of Project Increments and, at least for the first/imminent Increment, Timeboxes that make up that Increment. It rarely deals with task-level detail unless there are tasks being carried out by people who are not part of the Solution Development Team or before the Solution Development Team is formed.



Roles and responsibilities

  Role  Rationale
Produced by  Project Manager Responsible for ensuring increments of the solution are delivered, predictably within agreed budget and time constraints
Produced for All project participants and stakeholders Everybody needs to understand at a high level what is happening when and who is participating 
Approved by  Business Visionary Technical Coodinator Responsible for ensuring that the incremental delivery of business value is optimal for the business as a whole  



8.2.7 Management Approach Definition



Description



The Management Approach Definition is an evolutionary product. It reflects the approach to the management of the project as a whole and considers, from a management perspective, how the project will be organised and planned, how stakeholders will be engaged in the project and how progress will be demonstrated and, if necessary, reported. The product is outlined in Feasibility and baselined at the end of Foundations and will only evolve beyond that when circumstances change or if review of the approach identifies areas for improvement.



Roles and responsibilities

  Role  Rationale 
Produced by  Project Manager  Responsible for ensuring the project is properly set up for the predictable delivery of project products.
Produced for  All project participants and Stakeholders  Everybody needs to understand at a high level how the project will be managed 
Approved by   Business Sponsor Needs to be confidnet that the project is set up right to deliver what is needed at the right time for the right price

8.2.8 Feasibility Assessment



Description



The Feasibility Assessment is a milestone product. It provides a snapshot of the evolving business, solution and management products described above as they exist at the end of the Feasibility phase. Each of the products should be mature enough to make a sensible contribution to the decision as to whether the project is likely to be feasible or not. The Feasibility Assessment may be expressed as a baselined collection of the products or as an executive summary covering the key aspects of each of them.



Roles and responsibilities

  Role  Rationale
Produced by  Project Manager  Responsible for project management and control 
Produced for   Project Governance Authority  Need to decide whether or not the project should proceed and as proposed 
Approved by Business Sponsor  The champion of the project, responsible for the return on investment 

8.2.9 Foundation Summary



Description



The Foundation Summary is a milestone product. It provides a snapshot of the evolving business, solution and management products described above as they exist at the end of the Foundations phase. Each of the products should be mature enough to make a sensible contribution to the decision as to whether the project is likely to deliver the required return on investment. The Foundation Summary may be expressed as a baselined collection of the products described above or as an executive summary covering the key aspects of each of them.

  Role  Rationale
Produced by  Project Manager  Responsible for project managment and control
Produced for  Project Governance Authority  Need to decide whether or not the project should proceed and as proposed 
Approved by  Business Sponsor  The champion of the project, responsible for the return of investment 



8.2.10 Evolving Solution



Description



The Evolving Solution is an evolutionary product. It is made up of all appropriate components of the final solution together with any intermediate deliverables necessary to explore the detail of requirements and the solution under construction. At any given time, such components may be either complete, a baseline of a partial solution (a Solution Increment), or a work in progress. They include, where valuable: models, prototypes, supporting materials and testing and review artefacts.



At the end of each Project Increment the Solution Increment is deployed into live use and becomes the Deployed Solution.




Roles and Responsibilities

  Role Rationale
Produced by  Solution Development Team Responsible for creating a solution that satisfies the requirements in the PRL 
Produced for  Business Sponsor  Responsible for the return on investment 
  Solution Participants  Users of the end-products of the project and part of the wider solution in live buinsess use. 
Approved by  Business Visionary  Responsible for ensuring the solution that is delivered is fit  for business purpose
  Technical Coordinator  Responsible for ensuring the solution that is delivered is technically fit for purpose 

8.2.11 Timebox Plan



Description



The Timebox Plan is an evolutionary product that provides depth and detail for each Timebox identified in the Delivery Plan. It elaborates on the objectives provided for that Timebox and details the deliverables of that Timebox, along with the activities to produce those deliverables and the resources to do the work. The Timebox Plan is created by the Solution Development Team and is often represented on a Team Board as work to do, in progress, and done. It is updated at least on a daily basis at the Daily Stand-ups.



Roles and responsibilities

  Role Rationale
Produced by  Solution Development Team  Responsible for self-organising to 'say what they will do'
Produced for  Solution Development Team  Responsible for self-organising and doing what they said they would do
Approved by  Project Manager Technical Manager  Jointly responsible for acknowledging that the team are properly focussed on the timely delivery of a fit-for-purpose Solution Increment 

8.2.12 Timebox Review Record



Description



The Timebox Review Record is an evolutionary product, capturing the feedback from each review that takes place during a Timebox. It describes what has been achieved up to that point together with any feedback that may influence plans moving forwards. Where appropriate, e.g. in a regulated environment, a formal auditable record of review comments from expert Business Advisors and other roles make this a governance product.



Roles and responsibilities

  Role Rationale
Produced by  Team Leader  Responsible for ensuring that the Iterative Development process is porperly focused and controlled and that all testing and review activity is properly carried out. 
Produced for  Project Governance Authority  Requires assurance that development is porperly controlled and that all testing and review activity is properly carried out. 
  Project Manager  Formally tracks progress towards delivery of the final solution 
Approved by  Business Visionary  Acknowledges that the Evolving Solution Increment continues to be fit for business purpose 
  Technical Coordinator  Acknowledges that the Evolving Solution Increment continues to be fit for technical purpose 

8.2.13 Project Review Report



Description



The Project Review Report is a milestone product. It is typically a single document that is updated, incrementally, at the end of each Project Increment by the addition of new sections pertinent to that Increment.



At the end of each Project Increment, the purpose of this product is:


 

  • To capture the feedback from the review of the delivered solution and to confirm what has been delivered and what has not

     
  • To capture learning points from the retrospective for the Increment focussed on the process, practices employed and contributing roles and responsibilities

     
  • Where appropriate to describe the business benefits that should now accrue through the proper use of the solution delivered by the project up to this point



After the final Project Increment, as part of project closure, a retrospective covering the whole project is carried out that is partially informed by the records for each Increment.

 

  Role Rationale
Produced by  Project Manager  Responsible overall for the project and the delivery of its products 
Produced for  all project participants and stakeholders and those responsible for supporting future projects (e.g. PMO)  Interested in knowing what has been achieved, the value of what has been delivered and any learning for the future. 
Approved by  Business Visionary  Responsible throughout the project for ensuring the solution is fit for business purpose 
  Technical Coordinator  Responsible throughout the project for ensuring the solution is technically fit for purpose 
  Team Leader  Responsible throughout the project for ensuring that the Iterative Development process is properly focused and controlled and that all testing and review activity is properly carried out 

8.2.14 Benefits Assessment



Description



The Benefits Assessment is a milestone product. It describes how the benefits have actually accrued, following a period of use in live operation. For projects where benefits in the Business Case are expected to accrue over a prolonged period, it is possible that a number of Benefits Assessments may be produced on a periodic basis aligned with the timeframe used for justifying the investment.




Roles and responsibilities

Role  Rationale 
Produced by  Project Manager  Responsible overall for the project and the delivery of its products 
Produced for  all project participants and stakeholders and those resposible for supporting future projects (e.g. PMO)  interested in knowing what has been achieved, the value of what has been delivered and any learning for the future. 
Approved by  Business Visionary  Responsible throughout the project for ensuring the solution is fit for business purpose 
  Technical Coordinator  Responsible throughout the project for ensuring the solution is technically fit for purpose 
  Team Leader  Responsible throughout the project for ensuring that the Iterative Development process is properly focused and controlled and that all testing and review activity is carried out 
  Role Rationale
Produced by  Business Visionary  Responsible for translation of the business vision into working practice 
  Business Analyst  Responsible, for ensuring that benefits are assessed against Business Care and business need 
Produced for  Project Governance Authority  Need to understand whether the investment in the project was justified and understand differences between predicted and accrued value 
Approved by  Business Sponsor  Responsible for the return on investment 

8.3 Summar​y

The products above are guidelines to the information needed to promote good communication within a project. They are not mandatory, and may not always be presented as documents. However, in circumstances where strong governance and/or proof of compliance with standards is important, there is real benefit to creating formal documents rather than just gaining a shared understanding (which is the normal default for DSDM). Although it may not be obvious, it is important to remember that documentation created as part of the development process and/or tied to the proactive way the project is managed, is likely to provide the most effective and robust audit trail if one is needed.



It is also critically important to remember that DSDM products are only created if and when they add value to the project and/or to the solution it creates. The most important thing is that the stakeholders and participants in the project understand what is needed and what is being delivered and that quality is assured. If documents genuinely help achieve this then create them, if not, don’t waste valuable time and effort doing so.