Magazine article Management Services

Information Systems Project Management: The Price of Failure

Magazine article Management Services

Information Systems Project Management: The Price of Failure

Article excerpt

In traditional software projects self-deception is a prominent characteristic of system failure. In other words, understanding what the customer wants is crucial to any successful system development project. Put simply, everyone's efforts are wasted if the product produced is not what the customer needs.

Research indicates, for projects that fail, there is a tendency to jump to the implementation phase as quickly as possible and put through a Return On Investment (ROI) validation. This is due to project sponsors and information technology management believing that due diligence and planning represent unwarranted delays and wanting to see concrete progress as soon as possible. Over the next few years, organisations will increasingly implement a pre-launch phase, designed to shape the loosely stated ideas of project sponsors into a clear articulation of the real business problem and a comprehensive definition of the project's objectives, cost/benefits, and agreed-upon roles and responsibilities.

The pre-launch phase should include the production of a project-based, service-level agreement which includes the business justification, an outline for the overall approach, rough-cut resource estimates (skills/personnel, cash), a summary of risks and the approach to managing risk.

Ewusi-Mensan and Przasnyski, from the College of Business Administration at Loyola Management University in Los Angeles, observed that few organisations seem to learn from their mistakes. They discovered that sixty per cent of organisations surveyed in the United States had terminated more than one project for the same reasons. Perhaps more disturbing is that seventy per cent of these organisations failed to keep any records of their failed projects. Research carried out in 1984 by Professor Albert Lederer of Oakland University in the US highlights a number of key symptoms in the failure to deliver information technology systems.

In the authors' experience such symptoms are characteristic of projects with centralised structures and a vertical chain of command - where business and technology are moving twice as fast as information systems developments. Add to this the actuality that some managers are afraid to grapple with the great unknown that information technology represents - and it is not too difficult to appreciate why projects fail. When a project goes wrong it's all too easy to hide behind the old "information technology strategy wasn't aligned with the business" excuse. True, this can be a problem but it is rarely the only reason as Lederer has pointed out. Table 1 opposite draws on Lederer's work to summarise some of the symptoms associated with the delivery of a poor information system.

Since Table 1 highlights a number of interesting and important factors, it is worth examining the items listed in more detail.

1 Frequent Requests for Changes by users

The undermining and failure of many projects is associated with development scope creep. Project managers need to rigorously monitor requests for changes. Each request should be logged (who, what, when, why and what is affected) and assessed for impact on time and cost. It is important to remember who the sponsor is and what his objectives are - managers should check with the sponsor first before changing anything significant. It is perhaps worth pointing out that the complexity of change increases as:

* the number of parallel baselines to be supported increases;

* the number and geographical distribution of development teams expand;

* the volume of code increases;

* the number of change requests rises;

* the source of change increases the urgency increases;

These factors lead to a range of additional problems, including:

* problems in propagating changes across baselines;

* high communication overhead;

* uneven levels of skill against development teams; and

* loss of control and visibility into the change cycle. …

Search by... Author
Show... All Results Primary Sources Peer-reviewed

Oops!

An unknown error has occurred. Please click the button below to reload the page. If the problem persists, please try again in a little while.