IT Unconsciousness

In the July edition of CACM, there is an article with a glowing title: “Managerial IT Unconsciousness”. It is a report on “software failure”, but with a distinct flavor; it is presented from an “IT” perspective. Although, it is still another report on how the lack of software engineering practices does hurt business, it does not mention the term software engineering at all.

The article presents three cases: a) Sydney Water a public company that lost around 61 million dollars, b) RMIT a educational institution who budget 12, 6 million for an academic management system spent 47, 3 and had to re-launch the project and c) One.Tel a company that went bankrupt with problems with its billing system. The amounts are in Australian dollars.

Out of the article I selected three statements from the stakeholders of these systems: a) from RMIT: “The project reports that came through to me and then went on to the council showed that the project was on time, on budget, and meeting its milestones. We all thought that this project was actually OK”, b) from Sydney Water: “There was a belief in Sydney Waters that IT projects of this nature and complexity would inevitably go over budget and be delayed”, and c) from One.Tel “Why bother with petty concerns like faulty billing systems – when you can be thinking about global communications”. Citations pointers are available in the references of the CACM article.

Avison, Gregor and Wilson believe that three common themes/causes emerge from the study: a) “Complexity of application system software”, b) “Poor IT governance”, and c) “Relatively inexperienced and/or powerless IT staff lacking clout among corporate decision makers”. The article concludes stating:

“Management may be seduced by the abstract nature
of software,the ubiquity of PCs on every desktop,
and the availability of genericapplications into
thinking that IT doesn’t matter. ...
Software is flexible,
and IS specialists can develop systems to support
almost any business application. By they are complex
and need rigorous design, carefulconstruction, and
exhaustive testing to ensure they actually do what
they are intended to do. Management must
understand, track, review,and control their progress,
particularly their impact on the rest of the organization.”

In the article there is no mention to the field of software engineering nor to requirements engineering. CMM is mentioned in the comparison table in the article as IT maturity, and as: “CMM Level 1-2” or “CMM Level 1”. I did not know about the 1,5 grade in the CMM scale! Anyhow, this is not the central point. The central point is that in 2006 we still see reports of the type of the failures that have long been reported.

In a previous note, we recall of the LAS case and the lessons learned and published to the community. The last two sentences of the quotation above show that the authors believe that software must implement their requirements and that one has to manage software using a requirements baseline (requirements management is a pre-condition to CMM level 2).

Yes, technology transfer is hard (read about it here and here)!

We need to keep pushing, but sometimes it is a little bit frustrating.

After all, what have we learned?