Systems Development Life Cycle (SDLC) for PMs — Study Material (UNISA / CUT / UCT-Style)

Systems Development Life Cycle (SDLC) is the structured approach used to plan, build, test, deploy, and improve information systems. For Project Managers (PMs), SDLC is not just a technical “delivery method”—it becomes the backbone for scope control, risk management, schedule estimation, stakeholder alignment, and governance. This guide is written for PMs who need SDLC knowledge for South African university modules such as UNISA MNS/IST/IT Project Management–type courses (often covered under names like IT Project Management, Software Project Management, and related modules), and for learners who want exam-ready clarity consistent with the style of CUT and other South African universities.

SDLC Foundations for Project Managers (UNISA-style): What to Know for Exams

SDLC is a framework that defines the life of a software or system project from conception through retirement. In practice, SDLC “stages” provide a common language for everyone involved: PMs, business analysts, developers, testers, security, architects, DevOps, procurement, and auditors. For PMs, the value is that SDLC stages map directly to deliverables, gates, controls, and measurable outcomes.

SDLC vs. SDLC “Models”: One Concept, Multiple Ways of Working

A common exam trap is mixing up SDLC (the general lifecycle idea) with a specific SDLC model (the structure of work across time). The lifecycle concept is universal; the model determines how the work flows.

Common SDLC models include:

• Waterfall: sequential phases (requirements → design → build → test → deploy)
• V-Model: like Waterfall but emphasises verification/validation alignment
• Incremental/Iterative: build in portions with repeated cycles
• Prototyping: build a preliminary version early to reduce uncertainty
• Spiral: risk-driven iterations
• Agile (Scrum/Kanban): iterative development with continuous delivery and frequent feedback
• DevOps / Continuous Delivery: extends lifecycle into operations with automated pipelines

As a PM, your job is to choose (or recommend) the model that fits the project’s constraints: regulatory risk, system criticality, stakeholder availability, delivery timeline, team maturity, and technology complexity.

SDLC Stages: The “Exam Answer” Set

Many South African exam questions ask you to list and briefly explain SDLC phases. A practical baseline lifecycle set you should be able to recall and expand on is:

1. Initiation / Planning
2. Requirements Analysis
3. Design
4. Development / Implementation
5. Testing / Verification
6. Deployment / Release
7. Operations / Maintenance
8. Retirement / Replacement (sometimes included in advanced answers)

The key is not memorising words—it’s knowing what deliverables and decisions occur at each stage and what PM controls apply.

PM Responsibilities Across the SDLC

A PM’s responsibilities shift by lifecycle stage. In exam responses, it helps to connect SDLC to the PM knowledge areas. For SDLC, the most testable PM linkages are:

• Scope & Requirements Control
  Requirements analysis defines the scope baseline. PMs must establish change control, traceability, and stakeholder sign-offs.

• Schedule & Milestone Management
  Each SDLC phase contains outputs that become inputs for the next phase. PMs must plan dependencies and manage critical paths.

• Risk Management
  Requirements ambiguity and late design changes create high risk early. Agile reduces some risks via early feedback, but can increase risk if governance is weak.

• Quality Management
  Testing, acceptance criteria, and quality gates ensure the product meets “fit for purpose”.

• Communication & Stakeholder Management
  SDLC stage gates create predictable moments to align stakeholders.

Lifecycle Deliverables: What PMs Should Expect

While specific deliverables vary by organisation and SDLC model, PMs typically manage artefacts such as:

• Project charter / business case
• Project management plan (scope, schedule, quality, risk, communications)
• User requirements specification or product backlog
• System design specification (high-level architecture and detailed design)
• Work breakdown structure (WBS) and development plan
• Test plan, test cases, and evidence of test results
• Release plan, deployment scripts, and training materials
• Operations handbook / support documentation
• Maintenance plan and end-of-life strategy

A strong exam answer includes the phrase “deliverables and gate decisions”. SDLC is a chain of decisions, not just a list of activities.

Common Exam Scenario: A PM Joining Mid-Project

Consider a scenario used in many IT project management exams: A PM is appointed after the “requirements phase” ended, but stakeholders complain that the solution “doesn’t match what we asked for.” As a PM, how do you respond using SDLC logic?

• Review the requirements baseline and how it was approved.
• Check traceability from requirements to design to tests.
• Confirm whether change control was followed.
• Determine whether the project used:
  • Waterfall-style phase gates (where sign-off should have prevented ambiguity), or
  • Agile-style iterative backlog evolution (where misalignment may result from unclear story acceptance criteria).
• Identify whether the root cause is:
  • missing stakeholder discovery,
  • unclear acceptance criteria,
  • inadequate business analysis,
  • weak governance,
  • or poor communication.

This demonstrates that SDLC is governance-friendly, and PMs can diagnose issues systematically.

SDLC for PMs in South Africa: Governance and Institutional Context

South African public and semi-public institutions (and many private firms) often face governance requirements: procurement rules, audit trails, security standards, and formal acceptance processes. SDLC helps structure those governance needs by ensuring:

• documented approvals,
• audit-ready artefacts,
• controlled changes,
• and evidence of verification and validation.

In modules where you might see references to IT governance, systems analysis, or project management (common in UNISA and CUT curriculum structures), SDLC typically becomes the “delivery governance mechanism.” Your exam answers should show SDLC is compatible with formal compliance requirements.

SDLC Phase-by-Phase: PM Planning, Requirements, Design, Build, Test, and Release

This section breaks SDLC into phase-level activities and shows what PMs must plan and control at each step. The focus is on how to manage work (not just what engineers do).

1) Initiation / Planning: From Business Need to Project Governance

Core Activities

In initiation and planning, the PM establishes why the project exists and how it will be managed. Typical activities include:

• developing the business case (benefits, costs, feasibility)
• defining high-level scope and objectives
• identifying stakeholders and governance structures
• selecting a delivery approach (Waterfall, Agile, hybrid)
• planning budget, schedule, and resource strategy
• setting up risk management processes
• planning quality approach (standards, acceptance criteria, evidence collection)
• deciding communication channels and reporting cadence

PM Artefacts to Mention in Exams

If you want marks, mention artefacts that show governance maturity:

• Project charter
• Stakeholder register
• Risk register (initial)
• High-level schedule / milestone plan
• Project management plan

Decision Gate Example

A common SDLC gate question is: “What decision is made at the end of initiation?” For many organisations, the gate is whether to proceed to detailed requirements based on a sufficiently justified project.

PM exam phrasing that scores:

“The initiation phase results in a decision to proceed, supported by a business case, charter, and initial risks—enabling structured requirements work.”

2) Requirements Analysis: The Scope Foundation and Change-Control Trigger

Requirements are where projects succeed or fail. A PM must treat requirements as a living asset—especially under Agile—but still control change so that scope doesn’t become uncontrolled.

Requirements Types You Should Know

• Business requirements: why the organisation needs the system (improve efficiency, reduce errors)
• User requirements: what users need (screen needs, workflows, reporting outputs)
• Functional requirements: system behaviour (e.g., “system shall calculate tax”)
• Non-functional requirements (NFRs): qualities like performance, security, availability, usability

Non-functional requirements are exam gold because they’re often misunderstood until late. Examples:

• Performance: “The system shall return dashboard results within 2 seconds for 95% of requests.”
• Security: “All user actions must be logged; passwords must be hashed using an industry-standard algorithm.”
• Availability: “System uptime must be 99.5% during business hours.”

Traceability: The PM Weapon Against Scope Drift

A strong exam answer includes traceability: mapping requirements to design elements to tests and acceptance criteria.

PMs manage traceability via:

• requirement IDs (or user story IDs)
• design document references
• test case IDs and results
• sign-off records

If a stakeholder later says “this isn’t what we asked for,” traceability can show whether:

• they misunderstood,
• requirements changed,
• or acceptance criteria weren’t enforced.

Change Control in Requirements

PMs should implement a controlled process for changes. In Waterfall, this is often formal change requests. In Agile, changes appear as backlog refinement and prioritisation adjustments.

But the control goal is the same:

• protect baseline scope,
• estimate impact (time/cost),
• agree acceptance criteria,
• approve and update plans.

Case Example: Attendance System Misaligned Requirements

Imagine an institution deploying an attendance system for classes. During requirements, only functional features were captured (e.g., “mark attendance” and “generate reports”). Non-functional requirements were not detailed. After deployment, the system becomes unusable during peak times (lectures end at the same time). The root problem is missing performance requirements.

A PM lesson:

• validate NFRs early,
• include performance tests in test planning,
• and ensure the architecture supports expected load.

This shows that requirements analysis is not “writing documents”—it’s ensuring correct constraints for design and testing.

3) Design: Translating Requirements into Buildable Solutions

Design answers: How will the system meet the requirements? For PMs, design is about making choices, managing interfaces, and approving architecture.

Design Outputs PMs Should Recognise

• High-level architecture (components, data stores, integration points)
• Detailed design (data models, APIs, workflows)
• UI/UX design (wireframes, user journeys)
• Security design (authN/authZ model, logging, threat controls)
• Data design (schemas, migration strategy)
• Interface design for integrations (e.g., with student information systems)

Design Review and Approvals

A design phase often includes reviews and sign-off by stakeholders. PMs should ensure:

• design meets requirements (functional and non-functional)
• risks are identified (e.g., complexity of integrations)
• dependencies are tracked (e.g., external vendor API availability)
• development effort is estimated based on design clarity

Counter-Argument to “Design Should Be Done Once”

A typical debate: “Design should be final before build.” In agile contexts, design evolves. The PM exam-ready balanced answer is:

• In regulated/high-risk projects, freeze key architecture decisions early.
• In discovery-heavy contexts, design can iterate, but architecture must remain coherent and acceptance criteria must be controlled.

This prevents a false extreme: either rigid design-only thinking or unstructured coding.

4) Development / Implementation: Planning Work Packages and Controlling Progress

Development converts design into working increments. PMs manage:

• task assignment and team capacity
• coding standards and engineering practices
• environment management (dev/test/staging/prod)
• integration strategy
• defect management and sprint/iteration cadence (for Agile)

Environments Matter for PMs

A PM should ensure that:

• a test environment exists and resembles production
• deployment scripts are versioned
• configuration management is controlled
• rollback plans are defined (especially for production releases)

Progress Measurement: More Than “Lines of Code”

Measures of progress include:

• completed features meeting acceptance criteria
• integrated components
• automated test coverage improvements
• reduction in defect backlog

Exams may ask: “How do you track progress in SDLC?” A high-quality answer links progress to evidence and not just activity.

5) Testing / Verification: Ensuring Quality and Evidence for Acceptance

Testing is where SDLC becomes measurable. PMs should understand test levels and what evidence is needed to accept the system.

Test Levels

• Unit testing: component correctness
• Integration testing: interfaces between components
• System testing: whole system meets requirements
• User Acceptance Testing (UAT): business validation
• Regression testing: ensure new changes didn’t break old features
• Performance testing: confirm NFR performance
• Security testing: vulnerability discovery and compliance

PM Role in Test Planning

PMs ensure:

• test plans exist and have schedules
• test environments are stable
• entry and exit criteria are defined
• defect severity levels and triage processes exist
• evidence is stored for audits

Defect Management Example

A robust defect process includes:

• severity (e.g., Critical, High, Medium, Low)
• priority (based on business impact)
• assignment ownership
• target resolution dates
• retest cycle and closure rules

A PM should also manage stakeholder expectations: not all defects can be fixed before release. That decision must be governance-based (risk tolerance and acceptance thresholds).

6) Deployment / Release: Operational Readiness and Change Adoption

Deployment is more than pushing code; it’s operational and user adoption.

Release Activities PMs Must Manage

• deployment plan (schedule, freeze windows, rollback)
• migration plan for data (if relevant)
• training for users and support teams
• communications (what changes, when, how to get help)
• monitoring setup (logs, alerts, dashboards)
• hypercare period (extra support after release)

Rollback and Business Continuity

A PM should plan for:

• rollback conditions (what triggers reverting)
• data integrity protection
• contingency communications
• readiness of support staff

Exam Scenario: “We went live on Friday and nothing works”

If a release failed, SDLC governance should show:

• whether testing evidence existed,
• whether release criteria were met,
• whether monitoring was in place,
• and whether the PM approved release despite risks.

A good exam response focuses on learning and improving the governance process, not blame.

7) Operations / Maintenance and Continuous Improvement

After deployment, the system enters operations. PMs may become involved in:

• incident management coordination
• change requests and enhancements
• continuous improvement through metrics
• security patching and compliance updates

Even in maintenance, SDLC principles hold: changes should be analysed, designed, tested, deployed, and accepted—though possibly with lighter governance depending on risk.

Retirement / Replacement

Eventually, systems are replaced. A PM should consider:

• data retention and legal requirements
• migration plan and cutover
• decommissioning activities
• user transition and training
• archiving and audit evidence

SDLC Models (Waterfall, Agile, Spiral, DevOps) for PMs: Choosing the Right Approach and Justifying It

This section teaches PMs how to compare SDLC models, when to use which, and how to justify choices in exam answers. South African university exams often reward structured comparisons, pros/cons analysis, and the ability to apply theory to a scenario.

Waterfall SDLC: Sequential Phases with Strong Gate Governance

How It Works

Waterfall progresses through phases sequentially:

1. requirements
2. design
3. development
4. testing
5. deployment
6. maintenance

A key concept is that each phase produces outputs used by the next phase.

When Waterfall Fits

Waterfall tends to fit when:

• requirements are stable and well understood
• stakeholders are available for sign-off
• regulatory or contractual constraints require formal documentation
• scope changes are expensive or heavily controlled
• the project has a clear end-state

Risks and Drawbacks

Waterfall risks include:

• delayed discovery of misunderstanding until late testing
• higher cost of change once design/build has started
• difficulty accommodating feedback

PM Exam Justification

A strong justification statement:

• “Use Waterfall when the organisation needs formal phase gates, clear sign-offs, and when requirements uncertainty is low.”

V-Model: Testing Aligned with Requirements and Design

The V-Model is a variation of Waterfall that aligns testing activities with development stages:

• requirements verification corresponds to acceptance testing
• design verification corresponds to system testing/integration testing
• component verification corresponds to unit testing

For PMs, V-Model’s key value is traceability between:

• requirements,
• design,
• and test evidence.

In exams, if you discuss V-Model, connect it to:

• quality assurance,
• risk control,
• and audit-ready traceability.

Agile SDLC (Scrum/Kanban): Iterative Delivery and Feedback Loops

Core Agile Principles Relevant to PMs

Agile is not “coding quickly.” It’s an adaptive approach emphasising:

• iterative delivery,
• frequent stakeholder feedback,
• and prioritisation based on value.

Scrum typically uses roles and ceremonies:

• Product Owner
• Scrum Master
• Development Team
• Sprint planning
• daily stand-ups
• sprint reviews
• retrospectives
• backlog refinement

Agile Work Products

Instead of classic documents, agile often relies on:

• Product Backlog
• Sprint Backlog
• User Stories with acceptance criteria
• Increment (potentially releasable)

PM Responsibilities in Agile

PMs in Agile still handle governance but with different mechanics:

• Manage scope through prioritisation, not fixed detailed plans
• Control risk through frequent delivery
• Ensure quality gates via definition of done and test automation
• Maintain communication cadence with stakeholders

Exam Scenario: Stakeholders Keep Changing Their Minds

Agile can help because you can adapt via backlog prioritisation. But it can also fail if:

• the Product Owner doesn’t have authority,
• acceptance criteria are weak,
• sprint goals are unclear,
• or leadership confuses agile speed with agile clarity.

A balanced exam answer states:

• “Agile reduces risk of misunderstanding by delivering increments, but governance is still required for acceptance and scope management.”

Spiral SDLC: Risk-Driven Iterations

Spiral is often used in contexts where risk is central, such as large enterprise systems or high-risk environments. Each iteration addresses:

• objectives and alternatives
• identification and resolution of risks
• development and verification
• planning next iteration

For PMs, Spiral’s strength is that risk management is built into the lifecycle, not added as a separate activity.

A typical exam justification:

• “Choose Spiral when you have significant uncertainty and you need structured risk reduction before full commitment.”

DevOps / Continuous Delivery: Extending SDLC into Operations

DevOps is not a replacement for SDLC; it extends the lifecycle into deployment automation, monitoring, and continuous improvement.

Key DevOps practices include:

• CI/CD pipelines
• infrastructure as code
• automated testing
• monitoring and incident response loops

For PMs, DevOps matters because it:

• shortens feedback cycles,
• improves release reliability,
• and makes operational readiness part of delivery.

Exam Comparison: Waterfall vs DevOps

• Waterfall: phase gates; fewer releases; changes are controlled but later feedback
• DevOps: continuous delivery; small increments; stronger emphasis on automation and reliability

A good exam answer does not claim one is always better. It argues based on:

• organisational maturity,
• compliance requirements,
• and team capability.

Hybrid Approaches: Most Real Projects Use a Mix

Many organisations use a hybrid:

• Waterfall for requirements and governance
• Agile for development iterations
• DevOps for deployment automation

For PM exams, hybrid arguments should include:

• what remains “phase-gated” (e.g., architecture approval)
• what becomes iterative (e.g., backlog delivery)
• how governance still ensures compliance and traceability

SDLC Governance for PMs: Risk, Quality Gates, Traceability, Stakeholders, and Exam-Ready Frameworks

This section focuses on the PM “control layer” that ties SDLC phases into effective project management. In exams, high-scoring answers often show you can govern: not only describe stages, but explain how to ensure correctness, manage risk, and handle change.

SDLC Quality Management: Defining “Done” and Evidence for Acceptance

Quality Gates Across the Lifecycle

Quality gates vary by model, but PMs should be able to describe typical gates:

• Requirements gate: sign-off that requirements and acceptance criteria are complete enough
• Design gate: architecture approval and alignment with NFRs
• Build gate: code review and integration readiness
• Test gate: test evidence and exit criteria met
• Release gate: go-live checklist completed; monitoring and rollback planned
• Acceptance gate: UAT sign-off and warranty/hand-over acknowledgement

The exam-friendly idea is: “Each phase ends with a decision supported by evidence.”

Definition of Done (DoD) in Agile

In Scrum, DoD ensures quality consistency. A PM should mention that DoD might include:

• story implemented
• unit tests passing
• integration tests passing
• documentation updated
• code reviewed
• meets acceptance criteria

DoD creates quality predictability without needing heavy stage-gate documents.

Traceability and Auditability: Making SDLC Defensible

Traceability is one of the most consistent exam-mark themes in IT project management.

What Traceability Links Together

• business requirements → functional requirements → design components
• functional requirements → test cases → test results
• user stories → acceptance criteria → UAT evidence

Why It Matters to PMs

Traceability helps:

• prevent scope drift
• respond to disputes (“did we deliver the requirement?”)
• support audits and compliance
• reduce regression risk by understanding dependencies

Risk Management Embedded in SDLC

SDLC phases create predictable risk patterns:

• Early risks: unclear requirements, weak stakeholder alignment, feasibility gaps
• Middle risks: design complexity, integration failures, technical debt
• Late risks: testing defects, performance shortfalls, deployment problems

Risk Register Practices PMs Must Mention

A strong risk practice includes:

• risk probability and impact scoring
• risk owners
• mitigation and contingency plans
• monitoring triggers

In SDLC, risk mitigation should be scheduled into the lifecycle. For example:

• if performance is a risk, schedule performance testing early enough to fix architecture issues
• if integration is a risk, test integration in increments, not only at the end

Stakeholder Management: How SDLC Creates Communication Cadence

SDLC provides built-in stakeholder communication moments:

• requirements workshops and sign-offs
• design reviews
• sprint reviews/demos
• UAT sessions
• training and release communications
• maintenance feedback loops

For PMs, the key is to identify stakeholders by influence and interest, and then align communication with SDLC gates.

Example Stakeholder Set (Generic but Exam-Relevant)

• executives: business case and governance approvals
• business owners: requirement priorities and acceptance
• end users: usability testing and UAT
• IT operations: deployment readiness and monitoring
• security: security requirements and validation
• compliance/audit: evidence and traceability

Your exam answer should show you understand that different stakeholders need different information at different times.

Change Management: Handling Scope Creep without Killing Delivery

Change management is one of the hardest PM challenges in SDLC. Projects fail when change is either:

• ignored (leading to misalignment), or
• uncontrolled (leading to scope creep and cost overruns).

Change Control in Waterfall

Waterfall often uses:

• change request forms
• impact analysis (schedule, cost, risk, quality)
• approvals by a change control board (CCB) or governance committee

Change Management in Agile

Agile typically uses:

• backlog grooming and prioritisation
• estimation updates (e.g., story points or sizing)
• negotiation with stakeholders on what to defer or trade off

Exam-Ready “Trade-off” Explanation

A strong exam answer states:

• adding scope usually increases schedule or reduces quality or requires additional resources.
• PMs must make trade-offs explicit and obtain agreement.

Documentation vs Working Software: Finding the Balance

A classic debate appears in exam questions:

• “Agile doesn’t need documentation.”

The correct balanced response is:

• documentation is not the goal; useful evidence and alignment are the goal.
• the level of documentation depends on risk, compliance, and team needs.

For PMs, you can state:

• high-risk areas (security architecture, critical integrations) require stronger documentation
• user-facing and acceptance materials are needed for sign-off
• test evidence is needed for defensibility

This avoids simplistic answers and shows maturity.

Mini Case Study for Governance: E-Learning Platform SDLC Failure and Recovery

Imagine an e-learning platform being delivered to a South African educational institution. The project was started with Waterfall assumptions, but stakeholders changed requirements frequently after prototypes were shown. The release date slipped, and UAT found major mismatches in course content workflow and reporting.

A PM recovery plan using SDLC governance might include:

1. Re-baseline requirements through workshops and structured sign-offs
2. Traceability mapping: connect each requirement to design and test cases
3. Define acceptance criteria at story/requirement level
4. Introduce incremental UAT earlier (not only at the end)
5. Add quality gates: design review for workflow correctness, performance targets, and security checks
6. Manage changes via controlled backlog: for example, treat new requirements as “change items” with impact analysis
7. Update schedule with realistic sequencing of dependent features

The lesson: SDLC governance prevents chaos by turning stakeholder feedback into controlled changes, supported by evidence.

SDLC Exam Techniques for PMs: How to Answer UNISA/CUT-Style Questions with High Marks

This section focuses on exam strategy, common question types, and how to craft strong answers. It is designed for learners studying for IT Project Management and related modules where SDLC is a frequent topic in assessments.

What Questions Commonly Ask About SDLC

Typical exam prompts include:

• “Discuss the phases of SDLC.”
• “Compare Waterfall and Agile SDLC.”
• “Explain SDLC with respect to project management.”
• “Describe SDLC deliverables and quality gates.”
• “How does a PM manage risk across SDLC?”
• “What is traceability and why is it important?”
• “Which SDLC model is suitable for this scenario and why?”

Understanding the question’s command word is critical:

• Discuss: give explanation + implications
• Compare: include similarities and differences + justification
• Explain: cause/effect and process
• Describe: organised facts and key steps
• Evaluate: pros/cons + recommendations

SDLC “Mark-Scoring” Answer Structure

A reliable structure for exam answers:

1. Define SDLC (1–2 sentences)
2. List phases (with deliverables)
3. Explain PM role in each phase (controls and evidence)
4. Add model comparison if asked (Waterfall vs Agile etc.)
5. Use a mini scenario (application to a project)
6. Conclude with a governance/quality emphasis

This structure yields coherence and demonstrates understanding instead of rote memorisation.

Example Exam Answer: “Discuss SDLC Phases and PM Responsibilities”

A high-quality answer should cover:

• Initiation: business case, charter, governance
• Requirements: elicitation, stakeholder alignment, NFR definition
• Design: architecture decisions, security and interface design
• Build: implement based on design, manage environments and integration
• Testing: test levels, evidence and exit criteria
• Deployment: release plan, training, rollback readiness
• Operations: monitoring, maintenance, continuous improvement
• Retirement: data retention and replacement planning

To score, include PM-specific control words:

• baseline
• change control
• evidence
• acceptance criteria
• risk register
• quality gates

Example Exam Answer: “Waterfall vs Agile — Which Is Better?”

If asked “which is better,” examiners usually expect you to say:

• it depends on requirements stability, risk, compliance, and stakeholder readiness.

A strong comparison table conceptually looks like:

• Waterfall: sequential, phase gates, later feedback
• Agile: iterative, early feedback, backlog-based scope control

Then conclude with a scenario:

• stable requirements → Waterfall
• changing requirements / high uncertainty → Agile
• high risk → Spiral or risk-driven hybrid
• frequent releases and automation maturity → DevOps/continuous delivery

Quantitative Reasoning in SDLC (How to Show It Without Over-Specifying)

Some exams include questions where you must do basic planning logic—like estimating schedule impact of change.

Even without a full numerical dataset, you can demonstrate reasoning:

• Changes introduced after design cause rework across build/test and extend testing window.
• Early discovery (e.g., during requirements or sprint reviews) reduces rework cost.
• NFR gaps often lead to performance/security failures late, increasing defect resolution time.

If you use numbers, they must be consistent across the answer. Many learners lose marks by changing figures between paragraphs. A safe strategy is to avoid new numbers unless the question provides them.

Common Mistakes That Cost Marks

Avoid:

• listing phases only (without deliverables or PM controls)
• confusing SDLC models (e.g., saying Agile is sequential)
• ignoring non-functional requirements
• failing to mention quality gates and evidence
• failing to connect SDLC to risk and change management
• giving vague answers like “PMs manage everything” without specifying how

A top answer is explicit and structured.

Memory Aids That Still Sound Professional

You can use mnemonic-style thinking, but your final exam answer must remain academic. One practical memory sequence for PMs:

• Plan → Specify → Design → Build → Test → Deploy → Operate → Improve/Retire

Even if the model is Agile, you can still map activities to these outcomes:

• planning and prioritisation,
• specifying needs via stories/backlog,
• design decisions (including architecture),
• building increments,
• testing with evidence,
• deploying frequently,
• operating and monitoring,
• iterating and retiring.

Consolidated SDLC Cheat Sheets for PMs (Quick Reference for Revision)

This final revision section is designed to help you review efficiently without repeating earlier text verbatim. Use it for last-minute exam prep.

SDLC Phases + Typical PM Deliverables (Reference List)

SDLC Phase	PM Focus	Typical Deliverables / Evidence
Initiation / Planning	governance, business case, approach selection	charter, business case, risk register (initial), milestone plan
Requirements Analysis	scope baseline, stakeholder alignment, NFRs	requirements spec or backlog, acceptance criteria, stakeholder sign-offs
Design	architecture, interface, security, feasibility	architecture/design documents, data model, security design, design reviews
Development / Implementation	task control, integration, environment management	implemented increments, integration builds, code reviews
Testing / Verification	quality evidence, exit criteria	test plan, test cases, defect reports, performance/security evidence
Deployment / Release	operational readiness, cutover, rollback	release plan, migration plan, training materials, monitoring setup
Operations / Maintenance	incident coordination, enhancements, governance	support docs, maintenance backlog, change approvals
Retirement / Replacement	end-of-life governance	decommission plan, data retention/archiving evidence, transition support

SDLC Governance Checklist for PMs

Before approving key gates, ensure:

• Requirements: acceptance criteria are measurable; NFRs are defined
• Design: architecture supports NFRs; integration points are clarified
• Build: environments are prepared; deployment scripts exist
• Test: test evidence exists; regression/performance/security are included
• Release: rollback plan exists; monitoring and hypercare are planned
• Acceptance: stakeholders have signed off; handover documentation is complete
• Change: new requests go through impact analysis and governance

SDLC Model Selection Heuristics (How to Justify in Exams)

Choose based on:

• Requirements stability: stable → Waterfall; uncertain → Agile/Spiral
• Regulatory/compliance: high compliance → structured gates (Waterfall/V-model) or hybrid with strict evidence
• Risk profile: high technical risk → Spiral or risk-driven iterations
• Delivery cadence needs: frequent releases → Agile + DevOps
• Team maturity: DevOps and Agile require strong automation and collaboration norms

Conclusion: SDLC as a PM Governance and Delivery System

For Project Managers, SDLC is best understood as an integrated governance and delivery system. It structures how work moves from business need to reliable operations, and it gives PMs the tools to control scope, manage risk, assure quality, and create an evidence trail that supports acceptance and audit requirements. Whether your project uses Waterfall, Agile, Spiral, or DevOps, the PM exam-ready core remains consistent: each SDLC phase creates deliverables, supports decisions via gates, and provides traceable evidence that the delivered system meets stakeholder needs.