Chapter 8: Product

Previous chapter: 7 Roles and responsibilities

8  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

8a_-_dsdm_products__pg54_ 1.png

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 

Business Analyst Technical Coordinator

To check alignment with strategic goals and help prioritise within a portfolio

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 responsibilities


Role Rationale 
Produced By Business Analyst Skills and experience with Business Case production and working  collaboratively with the senior business and technical roles
Produced for Project Governance Authority Approval for project to proceed and to help prioritise the project within a portfolio 

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, further 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 within 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 required level of technical 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 Coordinator 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 confident 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 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 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 business 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 properly focused and controlled and that all testing and review activity is properly carried out. 

Produced for Project Governance Authority Requires assurance that development is properly 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 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 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 Summary

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.

Next chapter: 9 Workshops