2. A
number of problems (4 in total) could have had a major impact upon the tight delivery deadlines. What were these
problems? How did the project team use DSDM to help overcome these problems?
Answer :
According case-study, these problems are :
- The diverse range of stakeholders presented major challenges.Not only were there 12 of them, drawn from both the public and the private sector, but they had very different ways of working and perceptions of risk.
- The project was impacted by a major office move and complete change of team by one of the key project stakeholders around the time the system was due to go live.
- Resistance to the ‘iterative’ and ‘appropriate level of rigour’ approach of DSDM for the project had to be overcome.
- The requirements for a major part of the system were more complex than first thought and were changing as part of the review of the regulations.
With problem 2, the project team follow DSDM Atern principles 6 "Develop Iteratively" to help them to cope with changing requirements and personnel.Change is inevitable, It's allows for change and harnesses its benefits. Within the constraints of time and cost, change is actively encouraged in order to evolve the most appropriate solution. Atern uses iteration and constant review to make sure that what is being developed is what the business really needs.
The project team need to deliver the project on time however DSDM presented cultural difficulties for one of the key stakeholders, The project team intergrate DSDM Atern into an existing Prince2 Environment in order to help them to quickly establish or enable their own agile capability and overcome resistance to the ‘iterative’ and ‘appropriate level of rigour’ approach of DSDM for the project.
And final problem, The project team realised that the only sensible time for this to go live was 1st September, at the time only 3 months away. So with DSDM Atern principles 1 "Focus on the business need", it's help them to overriding project goal, which is to deliver what the business needs it to deliver, when it needs to be delivered by using MoSCoW prioritisation. Using this techniques it became clear that this functionality was a ‘should have’ rather than ‘must have’ for delivery and so was re-scheduled for the following year.