THE CASE
The paper, named above by Wastell (1996), uses a case study from the ACME Company, who used SSADM, with questionable results, as an implement for change within there IS structure. Wastell delivers a cautionary tale, and highlights some potential problems with adopting a formal methodology.
The company decided to adopt SSADM as it was the most widely used methodology in the UK at the time. They were frustrated with their I.T. system and the lead time in developing new software.
'An internal study had indicated that 80% of the IS effort was devoted to maintaining the company's legacy systems.' (Wastell, D. 1996. P.26)
Sensibly, the company decided to undertake a pilot scheme; a new 'parcel-tracking' system was chosen for this purpose. New staff were recruited, an experienced SSADM analyst was chosen to head the project and additional analysts and programmers were also added to the team. Internal staff members were subjected to a two week intensive training course in the said methodology.
Here our story begins. With all the skills in place and a clear outline, and deadline, surely our team could not fail. Several teething problems occurred. In house staff displayed a lack of confidence with the technique (DFD ERD etc), which is hardly surprising. And it was felt that too many staff were focusing on the aesthetics of the diagrams (again hardly surprising).
For some, SSADM had become a place: a place for the inexperienced to hide behind. Imagine being a relatively new member of staff; for example, a graduate in your first job. In this scenario we imagine the graduate taking comfort in the fact that he followed the methodology down to a tee in a completely abecedarian manner; he's thinking 'no one can fault my work no one.' Wastell goes on to point out that SSADM requires a good amount of user involvement/ feedback. But in our little story things got a little out of hand. For those who wanted, SSADM became a friend - a friend with the gift of the gab. This friend could be dumped on a user's desk and replaced social skills. Meanwhile, the project continues.
People were becoming "disenchanted", and they were "dismayed" with the speed of the project's progression. Management suggested streamlining the process wherever possible. Whereupon the IS staff jumped to the defense of their new found friend.
They insisted "SSADM represented a new culture of quality; that in the past people just jumped in and started coding as soon as possible' (Watell, D 1996. p.27)
The project was delivered approximately 6 months late. In a review of the project ensued. The review highlighted the rigid bureaucratic structure of the methodology; and suggested extracting the "high value aspects" of the methodology only. Ultimately, ACME decided to abandon in-house development using SSADM and outsource systems development.
Wastell goes on to draw on the work by others, and suggests that structured methodologies can hinder creativity and engagement with the proposed system, moving to a psychological approach; outlining other's work again in this field. For example, see
Nice words or words of the day:
'milieu'; settings surrounding environment.
" a priori" - Proceeding from a known or assumed cause to a necessarily related effect; deductive.
"Vicissitudes": regular change or succession of one thing to another; as the vicissitudes of day and night
