To DSDM or Not to DSDM?
- To DSDM or Not to DSDM?
- The Right Way to Do It
- Lessons Learned
E-business consultant Michelle Johnston explains some of the benefits of using DSDM (Dynamic Systems Development Method) techniques on e-business projects by describing one project that employed them and another project that didn't, and comparing the two.
Having worked on a number of e-business projects, I've seen some succeed and others that have been far from successful. In my opinion, projects that most fully employed DSDM techniques and approaches succeeded, and projects that didn't employ these techniquesor employed them incorrectlyfailed.
For example, I worked on two major projects for the same financial institution. Although the client was the same, and I worked for the same consultancy when working on both of the projects, the approaches were very different for the two projects. I believe the comparison of these two projects illustrates very well the need for DSDM techniques in e-business development. One of the projects was a great success, whereas the other project was far from successful, and caused a great deal of stress to all those who worked on it. Yet the same two companies were working together on the projectonly the project manager and client representative were different.
The Wrong Way to Do It
The biggest problems on the unsuccessful project were that the project manager knew nothing about the technologies involved (he didn't know the difference between writing a Web site and writing an e-business application), and, partly due to this ignorance, the architecture was not proved up front in the first iteration.
The client on this project was actively discouraged from having too much day-to-day involvement with the project, which led to a situation where the "design" for the system was inadequate for the needs of those attempting to develop it.
Because the client had been promised the whole system on a very tight deadline, it was impossible to deliver any part of the system on time, and hence the whole project slipped its deadlines significantly. In particular, the credit card payment aspect of the system took a long time to get working correctly, and work on this aspect of the project wasn't even started until most of the rest of the programming had been done.
Unfortunately, rather than managing the client's expectations fully, the project manager decided to reduce the amount of testing carried out before delivering the system to the client for user acceptance testing, in order to meet the deadlines. The user acceptance test carried out by the client wasn't exceptionally thorough, though it found a great number of defects. However, this meant that the system that was made "live" had never been fully tested and still contained a number of defects, some of them pretty serious.
When the system was finally delivered, it had overshot its deadlines by quite some time, and the system was of poor quality. It was also clear that major user requirements were not met by the system. For example, transaction confirmations were not subject to transaction guarantee controls because no message queuing technology was employed, and therefore didn't always reach the client from the Web site. "Losing" such confirmations of financial transactions was clearly highly embarrassing for the client and led to major rework of that part of the system.
So this project was clearly a failure.