1. Presented by Vijaya L Uppala 09/30/2003
DSDM
Presented by
Vijaya L Uppala
09/30/2003

2. DSDM Dynamic Systems Development Method
A project delivery framework that truly serves the need of the business.

3. DSDM Projects Deliver on time To budget Don’t cut important corners
Results from practical experience

4. DSDM Describes Project management Estimating Prototyping Time boxing
Configuration management
Testing
Quality assurance
Roles and responsibilities (of both users and IT Staff)
Team structures
Tool environments
Risk management
Building for maintainability
Reuse and vendor/purchaser relationships

5. PRINCE2
It is a project management method that was specifically designed to be generic
and independent of any particular project type or development method.

6. Elements of DSDM & PRINCE2 & their Overlap.

7. Using DSDM with PRINCE2
DSDM itself includes some project management content. It was consciously designed to provide just sufficient capability to allow effective management of DSDM projects. However, it is recognized that some businesses may choose to use a PRINCE2 framework to manage all their projects, including those using DSDM.

8. Principles of DSDM Active user involvement is imperative.
DSDM teams must be empowered to make decisions.
The focus is on frequent delivery of products.
Fitness for business purpose is the essential criterion for acceptance of deliverables.
Iterative and incremental development is necessary to converge on an accurate business solution.
All changes during development are reversible.
Requirements are base lined at a high level.
Testing is integrated throughout the lifecycle.
A collaborative and co-operative approach between all stakeholders is essential.

9. Project Structure Starting
Has a major control point after an initial understanding of the project has been gained: point at which a decision to proceed must be confirmed, and the option of abandoning project must be considered
End of the Business Study (with Business Area Definition, System Architecture Definition, and Outline Prototyping Plan)
Also has an earlier, less critical, control point that is sometimes omitted:
The Feasibility Study (Products: Feasibility Report, optional Feasibility Prototype, Outline Plan)

10. Project Structure Running
A management stage may consist of a number of DSDM timeboxes. The number of stages required should be determined by balancing the amount of management control needed over the project and its risks against the potential overhead of managing stage boundaries.
A stage might be mapped:
To a phase (if all the functional model iteration is done before all the design and build iteration), or
To the development of a functional area (where the functional model iteration and the design and build iteration are done in alternation).
DSDM Implementation is either simply a part of the increment (where this is treated as a single stage) or may be treated as one or more stages in its own right.

11. Project Structure Stopping
The project review in DSDM is done in each increment
The key is tailoring the methods to do what is needed and no more, since in DSDM incremental acceptance has already taken place.
During early adoption of DSDM, the probability of and need for lessons learned information is heightened.

12. Roles & Responsibilities
In any project, someone has to take responsibility for the following:
Defining the business requirement
Providing the budget
Providing the user and development resource
Authorizing change
Defining standards and acceptance criteria
Managing the project to a successful conclusion
Signing off project deliverables
DSDM supports a project management structure in which there is a
many to many relationship between the individual and the role, and there is a direct correspondence between many of the roles they each define. It emphasizes the importance of senior management commitment throughout the life of the project.

13. Roles & Responsibilities
Project Board
The Project Board is not specifically required by DSDM, but it sits comfortably within the DSDM project framework. The Project Board consists of two roles:
Executive
Senior User

14. Roles & Responsibilities
Executive
DSDM Executive Sponsor is accountable for the project to corporate and / or program management. Throughout the project, the Executive “owns” the business case.

15. Roles & Responsibilities
Senior User
The Senior User is responsible for committing user resource to the project. DSDM warns that lack of a clearly defined user group poses a risk to the project.

16. Roles & Responsibilities
Project Manager (PM)
The Project Manager is responsible for the successful delivery of the agreed products, to the agreed standard of quality, on time and within budget, and capable of delivering the benefits stated in the PID. The Project Manager may come from IT or the user community, and reports to the Project Board.
DSDM adds a complementary emphasis on:
Empowering the project team
Protecting the project team from outside interference
Ensuring that the team can remain stable and focused throughout the project
Managing user involvement in the project and ensuring users continue to be available when needed.

17. Roles & Responsibilities
Team Manager
This individual is responsible for ensuring that the development team meets its objectives by delivering the required system.

18. Roles & Responsibilities
Project Support
An organization may establish a Project
support Office to provide administrative support to the Project Manager, either because of the volume of work or to assist in the use of particular tools in the project (for example project management or configuration management tools). This could include providing the scribe and facilitator roles required by DSDM projects.

19. Roles & Responsibilities
Project Assurance
In DSDM projects, the Project Assurance Team may be redundant because of the far closer relationship and involvement of the business and users and the increased visibility offered by frequent deliverables. DSDM projects are often carried out to a fixed budget and decisions are always based on the business benefit. The project assurance needs in DSDM projects can be effectively fulfilled by the Ambassador User and Technical Coordinator.

20. Roles & Responsibilities
Project Assurance
The Technical Coordinator is outside the core team. He or she is responsible for ensuring that the project is technically sound, meets its technical specification, and meets the agreed technical standards for the project itself and the organization as a whole.
Ambassador User and possibly the Technical Coordinator are members of the core team, they should have direct access to the board if their assurance activities tell them that the Project Manager is steering the project away from the brief it has been given by the board.
The important thing is to provide to the Project Board confidence that the project is indeed progressing well; that there are no hidden problems; and that it will deliver a product that is fit for business purpose at the agreed time.

21. Products
Most products within DSDM are specialist products. That is, they either contain information related to the system or development the project is to deliver or define the prototyping techniques and methods to be used. There are, however, some DSDM products that are either completely management products or contain project management sections (such as the outline plan and outline prototyping plan) and some DSDM quality products (such as review records and test records).

22. Products Project Initiation Document
It may contain the management aspects of the business study if the study is conducted at this time
The PID should also address any DSDM specific management issues. For instance, the following should be included in the PID:
Preliminary indication of areas within scope which may be desirable but not essential
The need for team empowerment
Facilities that the development team will need
Any safety-related or product liability issues
Define tailoring of approach for the project
Suitability Filter

23. Products Feasibility Report
This DSDM report will not be produced separately, but will be included in the Project Initiation Document.

24. Products
Business Area Definition (including Prioritized Requirements List)
This is a DSDM document that covers both specialist and management aspects.
Outline Prototyping Plan, PID, and Stage Plan
The Outline Prototyping Plan is produced in the Business Study in DSDM to define the main prototyping phases within the project
Development Risk Analysis Report
Project Review Document

25. Management and Control
The purpose is to enable each level of the project management team to:
Demonstrate to the next level up that the project is on track to a successful outcome, (that the project will deliver products that are fit for business purpose on time and within budget)
Identify early anything that may prevent this

26. Tolerance & Empowerment
Tolerance is defined as the measure of deviation that may be managed by the project manager before the project board must be consulted; that is, how far schedules can slip, budgets be overspent, or changes to scope appear before the project owners need to intervene.
DSDM acknowledges that the project team must be empowered in order to work efficiently. A project will lose momentum if every minor change to functionality, budget or schedule needs external approval. Effective teams are entrusted to make decisions within the defined level of tolerance without reference to outside authority, allowing progress to be made more quickly.
Tolerance may be set on any measurable project attribute. Common examples are cost, functionality, and time.
In DSDM projects, therefore, tolerance is on scope, rather than on time and resource (as in most traditional projects).
DSDM Feasibility and Business Studies are generally timeboxed. Scope tolerance in these phases is normally managed by limiting the depth to which the studies proceed, so that it is just sufficient to produce results that are fit for business purpose.

27. Change Management
In a DSDM project, change within the high level scope and requirements defined in the Business Study is expected. Exception reporting will only be needed where change is beyond this tolerance.

28. Quality
Quality is based on pre-determined quality criteria, formulated to ensure conformance to User Requirements (fitness for purpose) both for the project and for each product the project delivers.
Promotes the review of products against their quality criteria.
Recommends assurance activities to ensure the appropriate quality standards are being followed. DSDM requires that all reviews and assurance activities “add value” to the process and are not for documentation’s own sake (introducing unnecessary delays).
It also points out that, although the review processes for products are similar, there are probably fewer products than in traditional projects.

29. Risk The DSDM Development Risk Analysis Report
It is developed in an ongoing fashion and reported specifically at the end of the Functional Model Iteration.
Identifying relevant risks and planning how to address them is an important part of planning for each timebox in DSDM.

30. Conclusion
In a nutshell, the Dynamic System Development Method (DSDM) is a game-changing, non-proprietary agile application development project model for developing business solutions within tight timeframes. It shortens the clock-speed (and time to market) for delivery of core business benefits. DSDM is the only approach that can guarantee delivery on an exact day under tight, Internet-time deadlines. It's tool-independent – there are no tools or software packages to buy (or be hamstrung by).
DSDM is not magic. Experienced project managers see it as a systematic strategy of common sense. Few ideas in DSDM are new; best practices are synergistically built into the model. As a result, people are applying DSDM to projects in a wide range of fields, in and outside of Information Technology. Recent trends are to combine DSDM PRINCE2 or with XP (Extreme Programming), to gain the benefits of DSDM's project management framework and business focus with XP's high efficiency and high quality development practices, what we like to call Enterprise XP or EXP (a term coined by Mike Griffiths of Quadrus).