To DSDM or Not to DSDM?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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 techniques—or employed them incorrectly—failed.
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 project—only 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 technical architecture on this project was actually much more complex than on the successful project—it involved IIS, HTML, JavaScript, ASP, and SQL Server, as did the successful project—but it also involved security (SSL), credit card transaction functionality (which required integration with an external bank's payment processing system), transaction confirmations that had to be delivered to the client, and a fairly complex use of the concept of "sessions." Yet on this more complex project, the technical architecture was not "proved" up front, and therefore issues with the technology were not found until far later in the project than should have been the case.
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 originally seen a prototype of what the system would do (which was really little more than a set of graphical design concepts for one "use case" within the system, strung together using HTML and JavaScript), it was assumed by the project manager that this prototype was the design. As a result, he was reluctant to "bother the client unnecessarily" when design issues came up, preferring to allow the chief graphical designer to "guess" the requirements. This led to a number of reworks later in the project. He also held the opinion that, because the prototype appeared to do everything required, there would be little to do to the prototype to get it working for real. In fact, the prototype did very little of the server-side work and only some of the client-side work required of the "real" system, and its development into a fully working system took a great deal longer than the project manager had anticipated. This was partly due to the fact that development was not broken down into incremental iterations, that instead a "big bang" approach was taken. This approach made it difficult to develop, but also made it difficult to fully test the system (with incremental development, it's often clear that defects have been introduced in the latest iteration of coding, making it easier to locate such defects.)
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.