INFO6007 Chap.1 What Makes an IT Project — and Why They Fail
What Makes an IT Project — and Why They Fail
A project is temporary work that creates a unique outcome under objectives and constraints. Programs coordinate related projects, while portfolios select and balance initiatives for strategic value. This chapter develops Project, program and portfolio, Temporary and unique work, Objectives and constraints, Triple constraint, IT complexity, Stakeholder success, Knowledge areas and process groups, Failure diagnosis.
Each idea is framed as a management decision: what evidence is needed, who owns the decision, which baseline or service outcome changes, and how the result is communicated.
Classify the work first, then connect technical delivery to governance, stakeholders, adoption, benefits and the interacting knowledge areas. The method is deliberately connective.
Scope choices affect dependencies and estimates; resource choices affect schedule and cost; governance choices affect escalation and benefit ownership; service choices affect operating value. A strong answer names those links rather than reproducing an isolated framework.
Technology quality alone cannot rescue unclear sponsorship, uncontrolled requirements or an outcome that users do not adopt.
The chapter uses direction checks, boundary cases and original scenarios to make those errors visible. Where a supplied figure is reproduced third-party material, the guide rebuilds it on new dimensions.
Where an answer is independently computed from a published table, it is labelled AskSia-authored rather than attributed to the University.
For assessment, start with a one-sentence definition, apply it to the stated facts, explain the consequence for objectives or constraints, and finish with the controlled action. Quantitative work must show the formula, substituted values, result, direction and management meaning.
Qualitative work must identify the decision owner and the evidence that would change the recommendation.
Study this chapter through retrieval. Rebuild the central artefact from a blank page, test it against a changed assumption, then check it against one neighbouring plan or practice.
That routine prepares for explanations, comparisons, scenarios and calculations without inventing a past-paper format or per-question mark scheme.
What this chapter covers
- 01
Project, program and portfolio
- 02
Temporary and unique work
- 03
Objectives and constraints
- 04
Triple constraint
- 05
IT complexity
- 06
Stakeholder success
- 07
Knowledge areas and process groups
- 08
Failure diagnosis
Free worked application: What Makes an IT Project — and Why They Fail
- FrameIdentify the objective, decision owner and evidence available at the decision point.
- MethodApply the chapter rule and keep assumptions, units and direction words explicit.
- IntegrateTrace effects into at least one connected plan, baseline, stakeholder or service outcome.
- ActState the recommendation and the change, control or communication action that follows.
- VerifyCheck the result against the chapter trap and explain why the conclusion is reproducible.
Key terms
- Project, program and portfolio
- A chapter concept used to make the relevant scope, flow, responsibility, measure or outcome explicit. Interpret it in the scenario rather than from its label alone.
- Temporary and unique work
- A chapter concept used to connect evidence to a controlled project or service decision. Interpret it in the scenario rather than from its label alone.
- Objectives and constraints
- A chapter concept used to make the relevant scope, flow, responsibility, measure or outcome explicit. Interpret it in the scenario rather than from its label alone.
- Triple constraint
- A chapter concept used to connect evidence to a controlled project or service decision. Interpret it in the scenario rather than from its label alone.
- IT complexity
- A chapter concept used to make the relevant scope, flow, responsibility, measure or outcome explicit. Interpret it in the scenario rather than from its label alone.
- Stakeholder success
- A chapter concept used to connect evidence to a controlled project or service decision. Interpret it in the scenario rather than from its label alone.
What Makes an IT Project — and Why They Fail FAQ
How is a project different from operations?
A project is temporary and creates a unique outcome; operations sustain recurring activity. A one-off change to operations may itself be a project.
What is the main decision rule for What Makes an IT Project — and Why They Fail?
Classify the work first, then connect technical delivery to governance, stakeholders, adoption, benefits and the interacting knowledge areas.
What is the most common trap in What Makes an IT Project — and Why They Fail?
Technology quality alone cannot rescue unclear sponsorship, uncontrolled requirements or an outcome that users do not adopt.
How should I structure a written answer on What Makes an IT Project — and Why They Fail?
Define the concept, apply it to specific facts, explain the effect on an objective or constraint, identify the decision owner, and state the next controlled action.
Are the worked scenarios for What Makes an IT Project — and Why They Fail official answers?
No. They are AskSia-authored learning examples derived independently from the concepts and stated inputs. They are not official questions, marking schemes or university solutions.
Exam move
Begin with the chapter map: Project, program and portfolio, Temporary and unique work, Objectives and constraints, Triple constraint, IT complexity, Stakeholder success, Knowledge areas and process groups, Failure diagnosis. Write the purpose of each item in your own words and connect it to a decision, an artefact and an owner. Then rebuild the worked application without looking at the answer.
Use this governing rule: Classify the work first, then connect technical delivery to governance, stakeholders, adoption, benefits and the interacting knowledge areas. Create two variations by changing one assumption, dependency, rating, probability, duration or stakeholder priority. Explain what changes and what remains stable. Keep an error ledger headed direction, boundary, authority, precision and integration.
The chapter's highest-risk mistake is: Technology quality alone cannot rescue unclear sponsorship, uncontrolled requirements or an outcome that users do not adopt. For quantitative work, write symbols and units before arithmetic, keep intermediate precision visible and translate the result into under/over, ahead/behind, faster/cheaper or selected/not selected as appropriate.
For qualitative work, write claim, scenario evidence, causal reasoning and controlled action. Finish by checking one neighbouring plan or practice. Review operational assessment details on Canvas; this learning chapter does not invent dates, a viva rubric, past-paper questions or a per-question university mark scheme.
Working through What Makes an IT Project — and Why They Fail in INFO6007? Sia is AskSia’s AI Project Management tutor — ask any INFO6007 What Makes an IT Project — and Why They 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.
