IT Project Management (Regent Elective) Study Notes

IT Project Management is the disciplined practice of initiating, planning, executing, monitoring, and closing technology-driven initiatives—while managing scope, schedule, cost, risk, people, and communications. In the South African university context (including Regent Business School and electives aligned with project management modules), students are often expected to demonstrate both framework knowledge (e.g., PMI/Agile concepts) and practical decision-making (e.g., how to control requirements, manage change, and handle project governance). These notes consolidate exam-relevant theory and apply it to realistic IT scenarios that mirror what you may encounter in coursework and assessments such as Unisa’s MNG 0001 (Project Management) style outcomes and related project control expectations.

Section 1: IT Project Management Foundations (Governance, Stakeholders, and Delivery Models)

IT projects differ from non-IT projects in at least four ways: (1) complexity of technical dependencies, (2) higher rates of evolving requirements, (3) heavy reliance on specialized skills and vendors, and (4) measurable uncertainty (e.g., performance, integration outcomes, cybersecurity threats). A strong understanding of project governance, stakeholder management, and delivery approaches is therefore essential for achieving predictable outcomes.

The Project Lifecycle in IT: Initiation to Closure

A widely used view of project management is the lifecycle across phases. In IT projects, these phases map to both contractual and engineering activities:

Initiation
- Business case exists (why the IT change is needed).
- Feasibility and high-level scope are confirmed.
- Stakeholder mapping begins.
- Governance structures are established (who decides, how often, and with what escalation paths).
Planning
- Detailed scope, schedule, and cost baseline are created.
- Requirements are elicited and translated into user stories/specifications.
- Risk management planning is performed early (because IT risks often compound).
- Quality standards, acceptance criteria, and testing strategy are defined.
Execution
- Development, configuration, procurement, and integration occur.
- Change control is enforced (or adapted to Agile without losing discipline).
- Communication routines operate (status reports, demos, progress tracking).
Monitoring & Controlling
- Progress is measured against baselines.
- Variance analysis (schedule/cost) and performance indicators are tracked.
- Risks are updated; mitigations are funded and executed.
Closure
- Deliverables are accepted (user sign-off, system acceptance testing results).
- Post-implementation review captures lessons learned.
- Knowledge transfer and operational handover are completed.

Exam tip: When answering theory questions, always connect a lifecycle phase to specific IT activities: initiation aligns to business case and feasibility; planning aligns to requirement baseline and test plan; execution aligns to build/configure/integrate; monitoring aligns to dashboards and change control; closure aligns to acceptance and operational handover.

Project Governance and Decision Rights (Who Decides What?)

In IT, governance structures can make or break projects. Governance is the system of authority and accountability that ensures decisions are made consistently, with appropriate oversight.

Common Governance Roles in IT Projects

Sponsor: owns the business rationale and provides executive support.
Project Manager (PM): responsible for coordination, reporting, and delivery oversight.
Product Owner / Business Owner (Agile contexts): accountable for product value and prioritized requirements.
Steering Committee / EXCO: escalates issues and approves major scope/cost changes.
IT Manager / Architecture Board: ensures technical alignment (standards, integrations, security).
Risk Owner(s): responsible for mitigation tasks for particular risks.
Change Advisory Board (CAB): reviews change requests and approves/rejects them (especially in ITIL-aligned environments).

Governance in Practice: A Concrete Example

Imagine a South African retail business implementing an online ordering portal that integrates with an existing ERP system. The governance might set:

Any change increasing integration work by more than 10% of the planned budget requires steering committee approval.
Security vulnerabilities above a defined severity level (e.g., “High”) block release acceptance.
Architecture compliance (e.g., API gateway usage) is mandatory—architecture board has veto power.

That means your PM decisions are not purely managerial; they must align to decision rights.

Stakeholder Management for IT: Power, Interest, and Influence

IT projects involve stakeholders with different objectives:

Users want usability and minimal disruption.
IT operations want stability and supportability.
Security wants risk reduction.
Finance wants cost control and value realization.
Procurement and vendors want clear contracting terms and payment schedules.
Regulators and auditors may require compliance evidence (data protection, audit trails).

A stakeholder analysis often uses power/interest grids:

High power, high interest: manage closely; co-create requirements and ensure acceptance.
High power, low interest: keep satisfied; provide high-level updates.
Low power, high interest: keep informed; involve in demos and feedback.
Low power, low interest: monitor; provide periodic communication.

Communication Tailoring

A common exam pitfall is treating communication as generic “status updates.” In IT, stakeholders need different information types:

Executives: budget burn, milestones, risk exposure, decision requests.
Developers/engineers: technical plans, interface specs, integration timelines.
Users: what changes, how to use it, training dates, test windows.
Security: threat model results, vulnerability management process, evidence of controls.

A practical routine:

Weekly PM team meeting for operational progress.
Bi-weekly product/user review for demonstrations (Agile).
Monthly steering committee for variance analysis and approvals.

Delivery Models: Waterfall, Agile, Hybrid, and “IT Realities”

Waterfall (or Predictive) Approach

Waterfall works best when requirements are stable and technology choices are known early.

Key exam points:

Strong up-front requirement documentation and baseline control.
Change requests tend to be formal and costly.
Testing and integration often happen later, increasing late discovery risks.

Agile (Iterative) Approach

Agile works best when requirements evolve or user feedback is critical.

Key exam points:

Work is delivered in increments (e.g., sprints).
Requirements change is expected; but scope control occurs via prioritization and product backlog management.
Acceptance is continuous: demos and user feedback occur regularly.

Hybrid Approaches (Common in IT)

Many IT organizations use a hybrid:

Infrastructure and security phases can be predictive (fixed standards).
Application development is iterative.
Release and deployment planning uses controlled gating.

Example: Hybrid for an IT Banking Feature

Suppose a bank introduces a new card-to-wallet transfer feature.

Security and compliance require upfront threat modeling and control design (predictive).
UI and business logic are developed in Agile iterations to refine workflow and reduce customer friction (iterative).
Integration testing with core banking services uses structured test cycles aligned to change freeze windows (controlled hybrid).

This demonstrates that “delivery model” is not an ideology—it’s a risk-optimized strategy.

Section 2: Requirements, Scope, and Quality Control in IT Projects

Requirements are the heartbeat of IT project delivery. If requirements are unclear or unstable, IT projects can drift into costly rework. Scope and quality control convert requirements into a deliverable that meets user needs and technical constraints. In exams—especially those aligned to project management outcomes in modules like Unisa MNG 0001 (Project Management) or related qualifications—markers look for structured thinking: define scope, manage change, verify acceptance, and show how quality is planned and controlled.

Requirements Engineering: From Business Need to System Specifications

Types of Requirements

Business requirements: what the organization wants to achieve (e.g., reduce processing time by 30%).
User requirements: what users must be able to do (e.g., search and filter orders).
Functional requirements: system behavior (e.g., validate payment status).
Non-functional requirements: quality attributes (performance, availability, security, usability).
Regulatory/compliance requirements: audit trails, data retention, access controls.

Elicitation Techniques Commonly Tested

Interviews (executives, managers, power users)
Workshops / JAD (Joint Application Development)
Observation / Shadowing
Document analysis (SOPs, process maps)
Prototyping and UI mock-ups
User stories for Agile (who wants what and why)

A Practical IT Example: University Enrollment System Upgrade

Assume an education provider needs to upgrade an online enrollment system to handle increased registrations during the registration period.

Possible requirements:

Functional: students can select programmes, upload documents, and receive application status updates.
Non-functional: the system must support peak loads and have secure access.
Compliance: audit logs for changes to student records; role-based access control.

The non-functional requirements must be measurable; otherwise quality acceptance becomes subjective.

Scope Definition and Scope Baseline

Scope is the sum of what the project will deliver and what it will not deliver.

Scope Components

Product scope: features and functions delivered by the IT product/system.
Project scope: the work required to deliver those features (e.g., development, testing, deployment).

Scope Statement and WBS (Work Breakdown Structure)

A strong scope statement typically includes:

Deliverables
Assumptions and constraints
High-level acceptance criteria
Out-of-scope items

Then the scope becomes actionable through a WBS, often:

organized by system components (e.g., authentication module, integration module),
organized by work streams (e.g., development, testing, training),
and mapped to a schedule and cost estimates.

Change Control: Managing the Inevitable in IT

IT projects experience “scope creep” if changes are not governed. But overly rigid change control can slow delivery and create resentment in Agile settings. The exam-friendly balanced answer: use change control, but tailor it to the development model.

Traditional Change Control (Predictive)

Steps typically include:

Log change request
Assess impact (scope, schedule, cost, risk)
Decide approve/reject/defer
Implement approved changes
Update baselines and documentation

Agile Change Control (Backlog Governance)

In Agile:

Changes are handled by adjusting the product backlog.
Impact analysis still happens, often at sprint planning level.
“Approving” changes means reprioritizing backlog items and committing capacity.

Hybrid Change Control Example

For an IT security enhancement project:

Changes affecting security controls follow CAB procedures.
Changes to UI text and minor workflow improvements go through Agile backlog updates.
This preserves both governance and agility.

Quality Management: Quality Planning, Assurance, and Control

Quality in IT is not just “testing.” It includes process quality, product quality, and conformance to standards.

Quality Planning

Quality planning answers:

What quality standards apply?
What metrics will measure quality?
What are acceptance criteria for deliverables?

Common quality dimensions:

Correctness (meets requirements)
Performance (latency, throughput)
Reliability (defects over time)
Security (vulnerability severity)
Maintainability (code structure, documentation)
Usability (user efficiency, error rate)

Quality Assurance (QA) vs Quality Control (QC)

QA: ensures processes are followed (e.g., coding standards, reviews, automated pipelines).
QC: inspects outputs (e.g., tests, defect verification, acceptance testing).

Testing Strategy (Granular but Exam-Relevant)

A robust IT testing plan often includes:

Unit testing (developer level)
Integration testing (interfaces between modules and external systems)
System testing (end-to-end behavior)
Regression testing (retest existing functionality after changes)
Performance testing (load, stress)
Security testing (vulnerability scanning, penetration tests)
User acceptance testing (UAT)

Example: Defect Severity and Exit Criteria

Suppose release acceptance criteria state:

Blocker defects: must be zero.
Critical defects: maximum 3 with documented waivers approved by product owner.
UAT pass rate: at least 95% of test cases passed without blocker issues.

If your project releases with 2 blockers, you violate acceptance criteria and governance will likely reject closure.

Acceptance Criteria and Traceability

A high-scoring exam answer typically mentions requirements traceability:

Each requirement should link to test cases.
Each test case should show pass/fail evidence.
Each deliverable should demonstrate compliance.

Traceability Matrix (Conceptual)

You can describe it even without presenting a table:

Requirement ID → Feature → Test case IDs → Evidence artifacts → Acceptance status

This is crucial for auditability and for “prove it” exam questions.

Section 3: Scheduling, Cost, Risk, and Earned Value in IT Projects

Scheduling and costing are often where students lose marks: they know the theory but fail to apply it to IT realities like dependencies, technical unknowns, vendor delays, and changing requirements. This section focuses on building a coherent set of metrics and practical control techniques. It also introduces performance measurement using Earned Value Management (EVM), which is frequently examined in project management modules across universities.

Estimating in IT: Bottom-Up, Parametric, and Expert Judgment

Estimating IT project effort is difficult because work is interdependent and uncertainty is high. Estimation methods:

Bottom-up: estimate tasks in detail and sum.
Parametric: estimate using historical parameters (e.g., function points, story points converted to effort).
Expert judgment: gather expert estimates and triangulate.

Dealing with Uncertainty

Use ranges (optimistic, most likely, pessimistic).
Add contingency for identified risks (not vague “padding”).
Distinguish between baseline estimates and forecast updates.

Time Scheduling: Critical Path and Dependencies

A schedule becomes credible when it accounts for dependencies:

Architecture sign-off may be required before development begins.
External vendor API availability impacts integration start.
Environments and test tools must be ready for testing.

Critical Path Concept

The critical path is the sequence of tasks that determines project completion time. Delays in non-critical tasks may not affect completion immediately, but delays on the critical path will.

Example: Integration Dependency

If development of a payment module ends on Day 30, but integration testing with the payment gateway starts Day 35 due to gateway environment readiness, then:

If the gateway environment slips by 7 days, you likely shift end date unless mitigation exists (e.g., simulated integration or parallel testing stubs).

Cost Management: Budget Baseline vs Forecast

Cost management in IT projects includes:

cost estimates,
budgeting (allocating funds to work packages),
monitoring and controlling costs,
evaluating variances.

Common IT Cost Drivers

Developer and analyst labor
Vendor licensing and subscriptions
Infrastructure and cloud services
Test tools, environments, and device labs
Data migration effort
Training and change management
Security compliance activities and audits

Earned Value Management (EVM): The Core Exam Metric Set

EVM integrates scope, time, and cost to measure performance. The main variables:

PV (Planned Value): the budgeted cost of work planned by a given date.
EV (Earned Value): the budgeted cost of work actually performed.
AC (Actual Cost): the actual cost incurred for the work performed.

From these, you compute:

Schedule Variance (SV) = EV − PV
Cost Variance (CV) = EV − AC
Cost Performance Index (CPI) = EV / AC
Schedule Performance Index (SPI) = EV / PV

Worked Example (Consistent Numbers)

Assume at Week 6:

PV = R 1,200,000
EV = R 1,050,000
AC = R 1,260,000

Compute:

SV = 1,050,000 − 1,200,000 = R −150,000 (behind schedule)
CV = 1,050,000 − 1,260,000 = R −210,000 (over budget)
CPI = 1,050,000 / 1,260,000 = 0.833
SPI = 1,050,000 / 1,200,000 = 0.875

Interpretation:

CPI < 1 means poor cost efficiency.
SPI < 1 means schedule inefficiency.

In exam answers, you should not only compute; you should explain likely causes and corrective actions:

EV < PV could be due to integration delays or slow requirement finalization.
AC > EV could be due to overtime, rework, or vendor changes.

Forecasting with EVM (BAC, ETC, EAC)

To predict final cost, define:

BAC = Budget at Completion (total original budget)
ETC = Estimate To Complete (remaining work)
EAC = Estimate At Completion (expected total cost)

A common simplified method:

EAC = BAC / CPI (when assuming cost performance continues)

Suppose BAC = R 6,000,000 and current CPI = 0.833:

EAC ≈ 6,000,000 / 0.833 ≈ R 7,200,000

This forecast implies significant overruns if no corrective actions improve cost efficiency.

Risk Management: Identify, Analyze, Plan Responses, Implement

Risk management is iterative and continuous in IT projects because new technical discoveries create new risks.

Risk Categories in IT

Technical risks: performance shortfalls, integration failures, unknown dependencies
Requirements risks: unclear scope, stakeholder misalignment, user adoption failure
Schedule risks: late environment setup, vendor delays, resource unavailability
Cost risks: underestimated effort, rework, licensing overruns
Security and compliance risks: vulnerabilities, data exposure, audit failures
Operational risks: deployment failures, downtime, change management gaps

Risk Analysis: Likelihood × Impact

You can use qualitative matrices (Low/Medium/High) or quantitative approaches.

A qualitative approach:

Rate likelihood (1–5)
Rate impact (1–5)
Compute risk score = likelihood × impact
Define thresholds (e.g., scores ≥ 15 require mitigation planning and monitoring)

Response Planning (Avoid, Mitigate, Transfer, Accept)

Avoid: change design to remove risk.
Mitigate: reduce likelihood or impact.
Transfer: shift risk to vendor via contract (not eliminating it).
Accept: acknowledge risk; prepare contingency.

Example: Integration Risk Mitigation

Risk: The legacy ERP API will not support required transaction volume.

Mitigate: performance testing early; implement caching; design queue-based integration.
Transfer: if feasible, vendor provides load guarantees with penalties.
Accept: only if business impact is minor and rollback plan exists.

A Risk Register with Decision Relevance

An exam-ready risk register often includes:

Risk ID
Description
Category
Likelihood, Impact, Score
Owner
Response strategy
Contingency plan
Triggers (what indicates the risk is becoming real)
Current status

You can show triggers like:

“If integration test throughput is below 500 transactions per minute by Day 45, accelerate performance mitigation.”
(If you use numeric triggers, keep them consistent in your worked examples.)

Section 4: Communication, Stakeholders, Procurement, and Team Leadership in IT Projects

IT projects are socio-technical systems. Tools, infrastructure, and code matter—but success depends heavily on leadership, team dynamics, communication discipline, and procurement governance. Many exam questions ask you to “discuss” or “evaluate” rather than compute, so you need well-structured arguments and balanced reasoning.

Communication Management: Medium, Frequency, Content, and Audience

Communication management answers:

What information needs to be communicated?
To whom?
When?
By what method?
How will accuracy be ensured?

Communication Planning Outputs

Stakeholder communication matrix (audience × information type × frequency)
Meeting cadence (weekly technical, monthly executive)
Reporting templates (status dashboard, RAID log—Risks, Assumptions, Issues, Dependencies)
Escalation paths (how decision requests are routed)

Example: Status Reporting for an IT Upgrade

Weekly status report sections:

Scope progress (percent complete by work package)
Schedule (milestones hit/missed)
Cost (budget vs actual, burn rate)
RAID updates (top risks with response actions)
Decisions needed (what the steering committee must decide)

Executives typically want:

“Are we on track?” plus “What decisions must be made now?”

Technical leads want:

integration blockers, environment availability, defect trends.

Stakeholder Engagement: Managing Expectations and Conflict

Stakeholders often conflict:

Users want more features quickly.
Security wants strict control gates.
Operations wants stability and minimal downtime.
Finance wants predictability.

A strong engagement plan includes:

expectation setting (what will be delivered in each increment),
involvement mechanisms (workshops, demos, UAT),
and transparent trade-off discussions (scope vs time vs cost).

Conflict Example: UAT vs Release Date

If UAT finds a critical usability issue:

The product owner may want the release postponed.
The sponsor may insist on release date due to business calendar (e.g., marketing campaign).

A governance-based approach:

classify issue severity,
evaluate release delay cost,
propose mitigation (hotfix plan, partial release, feature flag),
steering committee decision.

Procurement and Contract Management in IT

Procurement is critical where:

specialist development is required,
infrastructure is purchased,
or vendors supply critical components (e.g., payment gateways, cloud services, data providers).

Procurement Planning Essentials

Make-or-buy analysis
Vendor selection criteria (technical fit, security posture, delivery capability)
Contract terms (SLA, acceptance criteria, change control, payment milestones)
IP ownership and data protection clauses

Contractual Controls

Service Level Agreements (SLAs): uptime, response time
Warranty and support: defect resolution timeframes
Penalties and incentives
Audit rights (for compliance)
Acceptance testing procedures

Example: SLA with Measurable Outcomes

If a vendor provides cloud hosting, SLAs might include:

99.9% monthly uptime
breach notification within 1 hour
incident resolution target of 24 hours for critical incidents

If you mention SLA numbers in answers, ensure they remain consistent wherever referenced.

Team Leadership: Roles, Motivation, and Performance

IT teams include:

developers, testers, analysts, architects,
product owners and Scrum masters in Agile,
DevOps engineers for CI/CD,
and operations staff for release readiness.

Key leadership themes:

clarify roles and responsibilities,
remove blockers quickly,
support collaboration between business and technical stakeholders,
maintain psychological safety so issues are raised early.

Agile Team Leadership in Brief

Scrum Master focuses on process facilitation and removing impediments.
Product Owner prioritizes value; ensures backlog clarity.
Team commits to sprint goals; capacity management is essential.

Even in Agile, leadership must maintain:

quality gates,
security checks,
change governance (especially for compliance and production releases).

Managing Virtual and Cross-Functional Teams

IT projects in South African organizations may involve remote contributors and cross-functional teams (finance, HR, IT operations). Communication must:

ensure documentation is current (requirements, decisions, architectures),
provide shared tools (project management board, repository, ticketing system),
enforce meeting discipline (agendas, minutes, action items).

Section 5: Risk, Security, Change Management, and ITIL Alignment for Exam-Ready Project Control

This final section integrates advanced IT-specific governance: security and compliance, deployment and change management, and operational readiness. Many candidates can discuss project planning, but lose points when asked about real-world IT operational risks—downtime, rollback, training, and evidence for audits. These notes emphasize integrated thinking that examiners reward.

Security in IT Projects: From Risk to Controls to Evidence

Security is not an add-on. In IT delivery, security is part of requirements, design, testing, and governance.

Security Risk Lifecycle

threat identification
risk assessment (likelihood and impact)
design controls (authentication, authorization, encryption)
build controls (secure coding practices)
validate controls (security testing, review)
monitor post-release (logs, incident response)

Security Testing Types

vulnerability scanning
penetration testing
dependency checks (libraries, containers)
configuration review (cloud security posture)
SAST/DAST for code and deployed endpoints

Evidence and Compliance

Auditors often require proof:

test reports,
vulnerability closure records,
access logs,
change approvals,
and documentation of security decisions.

A strong exam answer ties:

which controls map to which requirements,
and which testing activities provide evidence.

IT Release Management and Change Management (Operational Reality)

Even a technically “working” system can fail if release is poorly managed.

Release Readiness Checklist (Exam-Friendly)

functional testing passed
regression suite passed
performance and security gates passed
migration scripts validated (if data migration exists)
rollback plan tested (even if not executed)
operational runbooks and monitoring dashboards ready
support team trained
communications plan issued (users and internal support)

Change Windows and Freeze Periods

Production systems often have freeze periods:

“Change freeze begins 48 hours before the event launch”
“No high-risk changes during peak hours”

Your project schedule must respect these. If not, the project risks forced rework and delays.

Deployment Approaches: Big Bang vs Phased Rollout

Big Bang Deployment

All users switch at once.

Pros: simpler operations alignment.
Cons: high risk; rollback may be difficult.

Phased Rollout

Roll out gradually:

to internal users first,
then to a subset of customers,
then expand.
Pros: reduced risk and faster feedback.
Cons: requires feature flags and monitoring sophistication.

Example: Feature Flags for Controlled Release

If introducing new checkout flow:

keep old flow available
route a percentage of users to new flow
monitor conversion rate, error rate, and latency
if thresholds breach, revert quickly

In exam answers, connecting feature flags to reduced risk and improved control demonstrates maturity.

ITIL Alignment: Service Management Thinking for Projects

Many organizations align IT delivery to ITIL (IT service management). While project management delivers change, service management ensures stable operations.

Core ITIL concepts relevant for exam answers:

incident management (restore service when something fails)
problem management (root cause for repeat incidents)
change management (structured process to implement changes)
configuration management (CMDB—know what exists and relationships)

Incident vs Problem vs Change (Common Exam Distinction)

Incident: something wrong right now; restore service quickly.
Problem: underlying cause of incidents.
Change: planned modification to prevent issues or add functionality.

In your project control narrative:

ensure deployment supports incident readiness (alerts, runbooks),
and that change records feed configuration management.

Managing Technical Debt and Sustainability

Not all “quality” is captured by tests. In exams, discussing sustainability shows deeper understanding.

Technical debt arises from:

rushed features,
shortcuts in architecture,
lack of documentation,
insufficient refactoring.

Consequences:

higher maintenance costs,
slower delivery cycles,
higher defect rates.

Mitigation strategies:

allocate capacity for refactoring,
enforce code review standards,
adopt automated quality checks (linting, static analysis),
maintain architectural runway.

Post-Implementation Review (PIR) and Lessons Learned

Closure is not paperwork. A strong closure includes:

compare planned vs actual outcomes,
evaluate whether objectives were achieved,
capture lessons learned,
update organizational knowledge bases.

KPIs and Benefit Realization

Project success may include:

adherence to scope, schedule, and budget,
user adoption metrics,
reduction in process time,
improved reliability,
cost savings or revenue lift.

A consistent benefit framework:

define baseline (before project),
define target (after project),
measure at agreed intervals.

Integrated Mini Case Study: End-to-End IT Project Control (Consistent Numbers)

Consider an IT project to implement an online service portal for a healthcare provider. The project has:

Total budget (BAC) = R 6,000,000
Target duration = 10 weeks
Release gates include security testing and UAT
Governance includes a steering committee monthly and CAB for security changes

Week 6 EVM Snapshot (From Section 3 Example)

At Week 6:

PV = R 1,200,000
EV = R 1,050,000
AC = R 1,260,000
So:
SV = R −150,000
CV = R −210,000
CPI = 0.833
SPI = 0.875
Forecast:
EAC ≈ R 7,200,000 (using EAC = BAC / CPI)
This indicates both schedule and cost inefficiency.

Diagnostic and Corrective Actions (Integrating Risk and Change Control)

Schedule issue diagnosis
- EV < PV suggests work planned by Week 6 wasn’t completed.
- Root cause: integration environment with authentication service was delayed by 7 days.
- Mitigation: use stubs for user flows until environment is available; parallelize UAT preparation with UI teams.
Cost issue diagnosis
- AC > EV suggests overspending.
- Root cause: overtime due to rework from changing authentication requirements late.
- Mitigation: enforce requirement traceability and freeze authentication interface contracts after architecture sign-off; route changes through CAB.
Security gate enforcement
- Identified risk: vulnerabilities in dependencies.
- Response: introduce automated dependency scanning in CI pipeline; block release for high severity issues without approved waiver.
Release management
- Use phased rollout with feature flags to reduce operational risk.
- Prepare rollback plan; test it in a staging environment.

Expected Outcome Narrative

If the corrective actions work, the project can improve:

delivery pace (increase EV growth rate),
cost efficiency (improve CPI by reducing rework),
and release stability (fewer incidents after go-live).

In an exam, the examiner expects to see:

how governance and change control are tightened,
how risks are linked to specific mitigation tasks,
and how release management supports operational readiness.

Common Exam Mistakes and How to Avoid Them

Treating requirements as only “user wants”
- Non-functional and compliance requirements must be included and tested.
Confusing QA with QC
- QA = process assurance; QC = inspecting outputs.
Doing EVM calculations but not interpreting them
- Always interpret CV/SV and recommend corrective actions.
Ignoring operational readiness
- Successful IT projects plan deployment, monitoring, rollback, and training.
Using change control without tailoring
- Agile still needs governance; predictive still needs controlled change mechanisms.

Linking to South African University Exam Context (Relevance to Regent Elective Study Expectations)

Many South African project management curricula require you to demonstrate conceptual understanding and procedural application—especially in modules that echo the learning outcomes seen in Unisa MNG 0001 (Project Management)-type assessments. The patterns you should practice for exams are:

structured, step-based answers (e.g., initiation → planning → execution → monitoring/controlling → closure),
named concepts used correctly (RAID, CAB, CPI/SPI),
and applied reasoning with consistent numbers and scenarios (EVM snapshots, acceptance criteria, governance triggers).

For Regent Business School qualification pathways that align with project management electives, exam questions typically reward:

integration of scope/schedule/cost/risk/security,
stakeholder and governance clarity,
and practical control mechanisms that reduce failure modes common in IT (integration delays, rework from unstable requirements, security gate failures, and operational disruptions).

If you want, I can also generate a Regent Elective-style exam practice pack: 10–15 exam questions (mix of short notes, computations, and scenario “discuss” prompts) with model answers that use the same consistent frameworks and, where needed, the same numeric EVM example values.