CDT505 Chap.1 Projects, Lifecycles and Success
Projects, Lifecycles and Success
Classify the work before choosing controls
A project is temporary work directed toward a distinct result, while operations sustain a recurring service. The distinction determines whether the manager needs temporary governance, a defined finish and formal handover. The lifecycle then locates the current decision, from need and definition through planning, delivery, control and closure.
Success is tested through separate evidence for delivery efficiency, product effectiveness and stakeholder value, because meeting time and cost alone does not prove that the authorised need was solved.
Use the lifecycle as a diagnostic
A problem should be attached to the decision that admitted it.
An omitted accessibility condition begins in definition, a late approved activity belongs in delivery and control, and an accepted result with no continuing owner belongs in closure. That placement determines the evidence and authority needed next. Closure also returns lessons to later projects, so the lifecycle is not a one-way checklist.
It is a feedback structure that helps an organisation change requirements, estimates, controls and ownership after completed work reveals how its original assumptions performed.
What this chapter covers
- 01
Projects against continuing operations
- 02
Need, definition, planning, delivery, control and closure
- 03
Temporary governance and operational handover
- 04
Time, cost and scope baselines
- 05
Efficiency, effectiveness and stakeholder value
- 06
Benefits ownership after closure
Worked example · free
Separate launch success from service success
- 2Classify project and operation boundaries.
- 2Separate efficiency from effectiveness.
- 2Name the evidence and owner needed after handover.
Key terms
- Project
- A temporary effort undertaken to create a distinct product, service or result.
- Operation
- Continuing work that sustains a recurring organisational process or service.
- Lifecycle
- The decision phases through which a project is defined, planned, delivered, controlled and closed.
- Baseline
- An approved reference for scope, schedule or cost against which performance is compared.
- Benefits Owner
- The role accountable for tracking and sustaining intended value after project delivery.
Projects, Lifecycles and Success FAQ
How should a lifecycle case be answered under time pressure?
Classify the work, locate the unresolved lifecycle decision, name the success criterion and cite the evidence before recommending action. Then identify who has authority and who owns the result after handover. This short chain prevents a schedule symptom from hiding an earlier definition failure or a later operational responsibility.
How is a project different from an operation?
A project is temporary and produces a distinct result under a defined governance arrangement. An operation repeats or sustains a service. Implementing a new booking system can be a project, while running that booking service after handover is an operation with continuing performance targets.
Does finishing on time mean a project succeeded?
It proves one part of delivery efficiency, not the whole outcome. A balanced judgement also tests cost and scope, whether the result solves the authorised need, whether stakeholders adopt it and whether benefits continue after the temporary project team has closed.
Why does closure feed back into planning?
Closure captures acceptance, unresolved obligations, performance evidence and lessons. Those findings improve later definitions and estimates. Without a feedback route, the organisation can repeat the same planning assumptions even when completed work has shown that they were weak or incomplete.
Assessment move
Begin with three familiar examples: launching a service, operating that service and redesigning it. For each, state whether the work is a project, an operation or a transition, and justify the answer with temporary duration, uniqueness, closure and continuing ownership. Draw the six lifecycle decisions from need through closure. Place one failure at each stage and write the control that would have prevented or detected it.
This forces you to distinguish a missing requirement from a late approved activity and an incomplete handover. Next, take a short success case and create a four-column scorecard for schedule, cost, product effectiveness and stakeholder value. Write the evidence that belongs in each column before deciding whether the project succeeded. If two criteria conflict, identify whose criterion controls and why.
Finish by writing a closure paragraph that names acceptance, open obligations, operational ownership, a benefits review and one lesson that should change the next project definition. Revise the chapter by speaking the project-operation boundary aloud in one sentence. Then cover the lifecycle diagram and reproduce it from memory, including the feedback from closure to definition.
Use the practice cards to check whether you name the stage before proposing the remedy. On a second attempt, change one fact so the correct stage changes; for example, turn an omitted accessibility requirement into an approved feature that was delivered late. This comparison prevents memorised labels and builds the diagnostic habit the later planning chapters assume.
Working through Projects, Lifecycles and Success in CDT505? Sia is AskSia’s AI Project Management tutor — ask any CDT505 Projects, Lifecycles and Success question and get a clear, step-by-step explanation grounded in how CDT505 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
