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.
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.
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.
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?