AgilePM® wiki

DSDM® Process

DSDM’s process contains a number of phases, which in turn have a number of activities. In other words, the process tells you what to do and when to do that.

Process phases

These are the phases of the DSDM’s process:

These phases don’t have a sequential relationship, but one that offers a lot of flexibility to suit the project environment:

graph TD rp(Pre-Project) --> fs(Feasibility) fs --> fn(Foundations) fn --> ed(Evolutionary Development) ed --> dp(Deployment) dp --> ed dp --> fn dp -.-> fs dp --> sp(Post-Project)

Process levels

This process contains both the project management level and the project delivery level. To compare, a methodology such as PRINCE2® is only about the project management level, and a method such as XP is only about the project delivery level. Scrum is usually known to be in the delivery level, but the fact is that it covers a bit of delivery and a bit of project management layer.

Both of the mentioned levels are inside projects, while there are levels above projects: programs and portfolios. It doesn’t matter how good your project management is, your full success also depends on the quality of your program and portfolio management layers.

Process configuration

A DSDM project can have different lifecycles based on the way you configure the process.

A simple example is demonstrated below, where the initial phases are run, followed by a few iterations of development, and one deployment at the end:

graph TD rp(Pre-Project) --> fs(Feasibility) fs --> fn(Foundations) fn --> ed1(Evolutionary Development) ed1 --> ed2(Evolutionary Development) ed2 --> ed3(Evolutionary Development) ed3 --> ed4(Evolutionary Development) ed4 --> ed5(Evolutionary Development) ed5 --> dp(Deployment) dp --> sp(Post-Project)

This example is not extremely adaptive; we can be more adaptive by having more deployments because when real users use the product, the feedback will be more useful. A product that is not deployed is only used by user representatives.

graph TD rp(Pre-Project) --> fs(Feasibility) fs --> fn(Foundations) fn --> ed1(Evolutionary Development) ed1 --> ed2(Evolutionary Development) ed2 --> ed3(Evolutionary Development) ed3 --> dp1(Deployment) dp1 --> ed4(Evolutionary Development) ed4 --> ed5(Evolutionary Development) ed5 --> dp(Deployment) dp --> sp(Post-Project)

It may take more iterations before having the first deployment, but after that, there can be more frequent deployments; e.g., every five iterations.

Do you feel brave? Then you can deploy every increment:

graph TD rp(Pre-Project) --> fs(Feasibility) fs --> fn(Foundations) fn --> ed1(Evolutionary Development) ed1 --> dp1(Deployment) dp1 --> ed2(Evolutionary Development) ed2 --> dp2(Deployment) dp2 --> ed3(Evolutionary Development) ed3 --> dp3(Deployment) dp3 --> ed4(Evolutionary Development) ed4 --> dp4(Deployment) dp4 --> sp(Post-Project)

If the project is too large, you may want to revisit the Foundations phase too; e.g., once every five deployments. It means that you may make fundamental changes to your overall plans, such as your management plans or the high-level architecture.

graph TD rp(Pre-Project) --> fs(Feasibility) fs --> fn1(Foundations) fn1 --> ed1(Evolutionary Development) ed1 --> ed2(Evolutionary Development) ed2 --> ed3(Evolutionary Development) ed3 --> dp1(Deployment) dp1 --> fn2(Foundations) fn2 --> ed4(Evolutionary Development) ed4 --> ed5(Evolutionary Development) ed5 --> dp(Deployment) dp --> sp(Post-Project)

There are many possible combinations (especially when there are multiple teams), which give you a lot of flexibility in tailoring your lifecycle.

Written by Nader K. Rad

This is (and will be) a work in progress: More details will be added in the future, depending on the feedback.

This wiki is developed and managed by an accredited trainer, independent of Agile Business Consortium and APMG. While aligned with their guidelines, it’s not an official resource.