Why projects fail.


1. The context: information systems - a combination of hardware, ommunications and software to handle information to support business processes.

2. What is a failure?

  • the system was not delivered;
  • the delivered system does not operate as expected (required);
  • performance is suboptimal
  • the system is user hostile or rejected by users.


    3. Degrees of failure

  • minor or intermittent problems
  • totally unusable system
  • Government's latest Pensions system NIRS-2. Cost 170m, 2 years late, delivered with 1900 faults. Database contains 65m records.


    4. What sort of projects fail?

  • All types - large and small


    What can we do?


  • Look at some examples of disasters.
  • Where did the projects go wrong?
  • Try to avoid similar mistakes

    Your project will go wrong at some point!


    Try to step back and review progress critically and use this to repair the project plan. Be honest but constructive.


    Case study - PROMS.


    Performing Rights On-line Membership System


    Purpose - collecting royalties for performances of copyrighted song.

  • 16,000,000 compositions;
  • 26,000 composers in the UK;
  • 750,000 composers worldwide;
  • 40,000 live performances per year;
  • 250,000 recorded performances played per year.

    Project was to introduce a single database. started 1990. Abandonded 1992.

    11,000,000 spent. project management sued for 7,900,000.


    Problems:

    1. database design: the contractor was not given sufficient information to design the database, they guessed at the missing details and got it wrong!


    2. hardware specification - no hardware available at the time had the required performance capabilities - noone had worked this out!


    3. data quality - the existing data was in several different systems, was incomplete, had many errors and inconsistencies. The system being developed assumed that the all the data was good.


    Lessons.


  • Develop an understandable requirements document.
  • Build an accurate model or specification and analyse it.
  • Identify and monitor critical attribute.
  • Document everything - label versions with number, date, author, approval.
  • Use evolutionary delivery where appropriate, - get feedback and listen to the client.
  • Beware of the consequences of requirements change.
  • Quality is vital - review and test at every stage.
  • Ask awkward questions but constructively.
  • Plan, estimate and review every week.
  • Stand back and think - does this make sense? are we achieving our objectives?