This diagram shows the basic difference between a traditional and a dsdm approach. On a traditional Project 100% of the features and full quality are promised at the start. When problems occur, typically the deadline slips time varies and this usually increases costs. More people are assigned to work on the project, which also increases costs and often still results in time slippage as newcomers are brought up to speed. Quality is also viewed as at risk simply because testing comes at the end of the lifecycle, as does documentation, so it is often skimped. It is common and also bad practice for customers to try and fix features cost and time.

They will say I wanted all by this date with this team. This is usually impossible. And it is important to agree upfront what can be negotiated if problems occur. Agile projects Management takes the opposite approach. Early in the project typically at the end of foundations, a deadline costs and team size are agreed. The quality standard to be achieved is formally defined the requirements the prioritized and the must haves for the project are confirmed.

If problems occur, then the least important feature will be dropped. Delivery on time of a less than 100% solution is viewed as more important than late delivery of everything. It is important to stress that the least important and least valuable features are negotiable.