To DSDM or Not to DSDM?

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.

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.