INFO6007 Chap.1 What Makes an IT Project and Why Projects Fail
What Makes an IT Project and Why Projects Fail
This chapter defines a project as temporary work producing a unique outcome and separates project delivery from ongoing operations. It broadens success beyond time and budget to include usable quality, stakeholder value, adoption and benefits. The failure clinic traces visible symptoms back to unclear objectives, unstable scope, unrealistic estimates, weak engagement, fragmented governance and late risk decisions.
IT projects combine technical dependencies with organisational change, so a launch can satisfy a specification while failing the people or operations meant to use it. Success criteria therefore need declared measures, evidence and owners before delivery begins. The chapter distinguishes a visible symptom from the upstream decision that produced it and shows how recovery options create their own trade offs.
Cutting scope, adding people or overlapping work can protect one objective while increasing another exposure. A strong diagnosis names the affected stakeholder, objective and authority, then updates the proper baseline instead of blaming one team.
This approach also creates useful lessons: identify the earliest point where different evidence or governance could have changed the outcome, and preserve that reasoning for future work.
What this chapter covers
- 01
Projects compared with operations
- 02
Scope, time and cost trade offs
- 03
Quality, value and adoption
- 04
Success criteria and benefits
- 05
Common IT failure patterns
- 06
Cause based recovery decisions
- 07
Trace each visible failure symptom to a decision, assumption, dependency or governance mechanism before recommending a corrective action
- 08
Separate delivery outputs from operational outcomes and measurable benefits when judging whether an information technology project succeeded
- 09
Test whether sponsorship, authority, information and escalation thresholds could have exposed the problem early enough to change the result
- 10
Use post-project review evidence to improve estimation, governance and delivery practice rather than allocate blame with hindsight
- 11
State an intervention owner, decision trigger and expected effect so a recovery recommendation can be evaluated rather than merely asserted
- 12
Judge recovery choices against benefit, feasibility, urgency and the remaining authority of the temporary project
Worked example · free
Diagnose a delayed municipal platform
- +1Separate the six week delay from its upstream causes.
- +1Identify missing success measures and unstable scope.
- +1Assign one integration owner and validate the minimum release.
- +1Rebaseline schedule and cost through authority.
- +1State the revised acceptance evidence.
Key terms
- Project
- Temporary work undertaken to create a unique product, service or result.
- Operations
- Ongoing repetitive work that sustains an organisational capability or service.
- Success criteria
- Measurable conditions used to judge whether delivery and intended outcomes are acceptable.
What Makes an IT Project and Why Projects Fail FAQ
Why can an on time project still fail?
Time and budget show delivery performance, but the product may still be unusable, insecure, rejected by stakeholders or unable to produce the intended benefits. Success needs agreed outcome and acceptance evidence.
What usually causes IT project failure?
The taught patterns include unclear objectives, unstable scope, unrealistic estimates, weak stakeholder engagement, fragmented governance, unmanaged dependencies and risks discovered after decisions become expensive to reverse.
How should I structure a failure diagnosis?
Start with the visible symptom, identify the missing or weak decision, name the affected stakeholder and objective, then recommend a corrective control and a revised success test.
Exam move
Build revision around decisions rather than a list of definitions. Separate a project from operations: a project is temporary and unique, while operations sustain recurring capability. Draw the scope, time and cost triangle, but put value, quality and stakeholder acceptance in its centre so efficient delivery is not mistaken for genuine success. For every case, write success criteria before diagnosing failure.
Useful criteria name the outcome, measure, threshold, evidence source and person authorised to accept it. Then practise a five-part failure chain: visible symptom, missing or weak decision, affected stakeholder and objective, corrective control, and revised success test. If a rollout is late, do not stop at schedule pressure.
Ask whether objectives were unclear, scope changed without authority, dependencies were hidden, estimates ignored uncertainty, users were consulted too late or governance failed to assign integration ownership. Make every recovery recommendation explicit about trade-offs. Freezing scope may protect the date but reduce value. Adding people may increase coordination effort. Overlapping activities may create rework.
A complete answer states which option is recommended, who decides, which baseline changes and what evidence is reviewed next. Use one original IT scenario throughout the week and rewrite the diagnosis from the perspectives of sponsor, user, project manager and operations. That reveals why stakeholders can disagree about success without any side being irrational.
Finish by checking that your explanation does not blame a person for a system decision they did not control. On the notes sheet, keep the project definition, success dimensions and diagnosis chain as compact prompts. The aim is to recognise a pattern in a new case, locate the missing control and give a recovery decision that preserves transparency across scope, schedule, cost, quality, risk, adoption and benefits.
Working through What Makes an IT Project and Why Projects Fail in INFO6007? Sia is AskSia’s AI Project Management tutor — ask any INFO6007 What Makes an IT Project and Why Projects Fail question and get a clear, step-by-step explanation grounded in how INFO6007 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.