UCT IT Project Management Course Notes (UCT IS Department): MGT/ITPM Concepts for Exam Success

IT project management at university level is a blend of planning discipline, technical understanding, stakeholder communication, and governance. This set of study notes focuses on the way the UCT IS (Information Systems) Department typically frames IT project management—through processes, roles, risk thinking, requirements clarity, and measurable delivery. These notes are designed to support exam preparation for students studying IT Project Management–type modules (often cross-listed with strategy, systems analysis, software delivery, and governance topics) and for those preparing for related assessments at South African universities.

1) UCT IS Department IT Project Management Foundations: Scope, Stakeholders, Governance, and Value

Why “project management” matters in an IT department context

In IT project environments, “projects” are not only about building software or configuring systems. At the UCT IS department level, the emphasis is usually on ensuring that the project:

Delivers business value, not only outputs.
Manages constraints (time, cost, scope, quality, and risk).
Aligns with governance structures (approval gates, roles, accountability).
Supports adoption through change management and stakeholder engagement.

A common exam trap is to treat project management as purely technical. A stronger approach treats IT delivery as a socio-technical system: people, process, information, and technology interact.

Project lifecycle: from initiation to closure (and why closure is not optional)

A standard lifecycle model often used in university teaching (and in UCT-style IS governance framing) includes:

Initiation: define the problem/opportunity, identify stakeholders, do initial feasibility.
Planning: scope, schedule, budget, quality plan, risk plan, communication plan.
Execution: deliver work, manage teams, procure resources, coordinate vendors.
Monitoring & controlling: track performance, manage risks, handle changes.
Closure: lessons learned, formal acceptance, handover and benefits review planning.

Closure is frequently underemphasised by students, but it is typically assessed: exams may ask about what constitutes “project completion,” how acceptance works, and how organisations capture learning to improve future delivery.

Concrete example: university registration system upgrade

Imagine an IT project at a university: upgrading a registration system before semester start.

Initiation identifies the problem: registration delays create student complaints and operational strain.
Planning defines scope: integration with fee management, timetable data, authentication.
Execution includes configuration and migration testing.
Monitoring & controlling tracks milestones: “data migration rehearsal completed,” “role-based access tested.”
Closure includes formal acceptance by the Registrar’s office and a lessons-learned document.

If closure is weak, the project may be technically “done,” but operational adoption fails, producing downstream incidents and reputational damage—precisely the sort of “value” reasoning that IS departments stress.

The project governance lens: accountability, decision rights, and approvals

In South African university and organisational contexts, IT project governance is a major theme because it affects:

Who approves scope changes
How budgets are controlled
What happens when delivery slips
How stakeholder conflicts are resolved

Even if your module title is “IT Project Management,” the questions often implicitly test governance concepts:

Steering committees
Project manager authority
Business owner accountability
Change control boards
Stage-gate approvals

Decision rights and roles: a practical mapping

You can map governance roles into a simple structure used in many project contexts:

Project Sponsor / Executive: owns the business case; authorises investment.
Project Manager (PM): manages delivery and coordinates the team.
Product Owner / Business Owner: defines priorities and accepts deliverables.
Scrum Master / Delivery Lead (if Agile): facilitates delivery process.
Technical lead / Architecture: ensures solutions align with standards.
Stakeholders: users, operations, compliance, finance, security.

In exams, it is common to see questions like: “Who approves the change and why?” The best answer links decision rights to the role’s responsibility for value, risk, and feasibility.

Stakeholder analysis: identifying power, interest, and communication needs

Stakeholders include anyone impacted by the project or who can influence outcomes. A typical stakeholder analysis framework categorises stakeholders by:

Power (can influence resources/decisions)
Interest (degree of concern about outcomes)

Communication planning per stakeholder group

Once stakeholders are mapped, communication must be tailored:

High power + high interest: frequent engagement, detailed reporting.
High power + low interest: periodic updates, ensure alignment.
Low power + high interest: involve in feedback sessions, training, pilots.
Low power + low interest: minimal updates, maintain awareness.

Exam-style scenario: a payroll integration project.

Finance has high power (approves budgets, compliance).
End users (staff) have high interest (accuracy affects pay).
The internal IT security team may have high power due to approval authority.

A strong answer explains that communication is not “one-size-fits-all”—it is structured to reduce resistance and avoid surprise escalations.

Value and the business case: connecting IT outputs to outcomes

UCT IS teaching frequently aligns delivery with value logic. You can think in two layers:

Outputs: what the project produces (e.g., a working integration service).
Outcomes: what improves (e.g., reduced payroll errors, faster processing, improved compliance reporting).

Business case components to memorise

Often assessed elements include:

Problem statement and current-state pain
Proposed solution and benefits
Costs (capex/opex where relevant)
Risks and assumptions
Timeline and key milestones
Benefit measurement approach

Common quantitative examination pattern: compute whether benefits outweigh costs over a time horizon (even if numbers are hypothetical). When a question provides cost and benefit values, show calculation steps.

2) Requirements, Scope, Planning, and Change Control in UCT-Style IT Project Management

Requirements management: from vague needs to testable scope

IT projects fail frequently due to requirements ambiguity. Exams may test:

Elicitation techniques
Documentation formats
Traceability between requirements and deliverables
Managing scope changes

A requirements mindset treats requirements as:

Functional: what the system must do (features).
Non-functional: performance, security, availability, usability, compliance.
Constraints: deadlines, regulatory rules, technical standards.
Acceptance criteria: how success will be validated.

Example: “improve student access” vs “enable secure timetable self-service”

“Improve student access” is vague. A better requirement is:

Functional: students can log in and view timetable sessions for enrolled modules.
Non-functional: page loads under 2 seconds for 95% of requests during peak time.
Security: role-based access; enforce MFA.
Acceptance: after completion, UAT users complete tasks successfully, and performance testing meets thresholds.

In exam answers, converting broad statements into structured requirements earns marks because it demonstrates professional discipline rather than generic theory.

Scope definition and the work breakdown structure (WBS)

Scope describes the boundaries of what the project will and will not include. A major planning tool is the Work Breakdown Structure (WBS).

WBS: how to think about it

A WBS breaks down work into manageable components. For example, for a “student timetable integration” project:

Project management
Business analysis
Solution design
Development
Integration and testing
Deployment and training
Operations handover and support

Within each level, tasks become more detailed until they can be scheduled and assigned.

Exam scenario: “Explain why WBS helps control scope.” A strong response links WBS to:

Better estimation
Easier progress tracking
Reduced ambiguity
Change impact analysis (what is affected when scope changes)

Planning: schedule, cost, quality, and risk as linked systems

In typical university IT project management courses, planning is assessed not just as separate documents but as an integrated system. If:

you add scope without adjusting time,
you underestimate risk,
you ignore quality constraints,
then schedule and cost estimates become unreliable.

Schedule fundamentals: milestones and critical thinking

Common scheduling elements:

Milestones: significant points (e.g., “UAT complete,” “Go-live approved”).
Dependencies: Task B cannot start until Task A finishes.
Critical path: longest sequence affecting project completion.
Buffer time: protection against uncertainty.

Even when your module doesn’t heavily emphasise CPM diagrams, exams often ask:

How to reduce schedule risk?
How to handle slippage?
How to communicate timeline changes?

Estimation: from analogous estimates to bottom-up reasoning

Exam questions may require you to interpret estimation methods. Typical methods include:

Analogous estimation: use past similar projects.
Parametric estimation: model effort based on measurable parameters.
Bottom-up estimation: sum detailed tasks.

Counter-argument students often miss

Bottom-up estimation is not always “best.” It requires:

good clarity of tasks,
stable requirements,
time to plan.

If a project is early and requirements are unstable, bottom-up estimates might be misleading. In such cases, analogous or parametric estimation can be more realistic, but must be explicitly labelled with assumptions and confidence levels.

Quality planning: preventing defects rather than detecting them late

Quality in IT includes:

Product quality (correctness, usability, security)
Process quality (how development and testing are managed)
Service quality (availability, performance, support)

In UCT IS framing, quality management tends to connect to:

test planning,
acceptance criteria,
traceability,
change control.

Example: quality gates for an integration release

A realistic quality plan for an integration project may include:

Code review and security checks before merging
Unit testing coverage targets
Integration testing with representative data
Performance testing under load scenarios
User acceptance testing (UAT) with business sign-off
Deployment readiness checklist

If a question asks what should happen before go-live, the answer should emphasise not only “testing,” but readiness (backup plans, monitoring setup, rollback strategy, training, and approval).

Change control: managing scope creep and protecting delivery

Change is inevitable in IT projects. The issue is uncontrolled change. Change control ensures changes are:

identified,
assessed for impact (time, cost, quality, risk),
approved by the correct authority,
implemented with updated documentation.

Step-by-step change control process (exam-ready)

A robust change control process can be described as:

Change request submitted (what is changing and why)
Impact assessment (scope, cost, schedule, risks)
Decision by change authority (steering committee, sponsor, product owner—depending on governance)
Update baselines (schedule, cost estimates, requirements documents)
Implement and verify (testing, documentation update)
Communicate decision and outcomes

Exam tip: if asked “what happens when change is rejected,” show that you still:

document the reason,
manage stakeholder expectations,
consider alternative solutions.

Baselines: scope, schedule, and cost as “reference points”

Baselines provide control. If you only talk about plans without baselines, your answers may feel incomplete.

A baseline usually refers to:

approved scope statement,
approved schedule,
approved cost estimate/budget.

When change occurs, baselines may be updated—but only via governance and approval.

3) Agile vs Waterfall Delivery, Risk Management, and Monitoring/Controlling

Delivery approaches: Waterfall, iterative, and Agile (and when each fits)

Universities often teach multiple approaches. The goal is not to memorise slogans but to choose an approach aligned with:

requirement stability,
stakeholder involvement capacity,
risk tolerance,
time constraints,
organisational governance.

Waterfall (predictive) model characteristics

Waterfall is suitable when:

requirements are stable,
scope is well understood,
compliance or procurement requires upfront definition,
delivery can be planned in sequences with less need for frequent reprioritisation.

Risks include:

difficulty adapting late changes,
late discovery of misunderstandings,
longer time to feedback.

Agile model characteristics

Agile fits when:

requirements evolve,
frequent feedback is feasible,
you want to deliver value in increments,
you can maintain active stakeholder/product ownership.

Common risks:

scope can become unstable without strong prioritisation,
teams may overestimate their ability to “always move fast,”
governance may conflict with agile if approvals require rigid documentation.

Exam-ready contrast: answering “Which is better?”

A high-scoring answer explains that the “best” approach depends on context. If asked which approach reduces risk, you can argue:

Waterfall reduces risk through upfront clarity and structured approvals.
Agile reduces risk through early delivery of increments and feedback loops.

A strong exam response links the argument to project characteristics like uncertainty level and stakeholder availability.

Monitoring and controlling: how you detect deviation early

Monitoring & controlling includes:

tracking progress against baseline or sprint goals,
managing schedule/cost performance,
handling deviations and corrective actions.

Students sometimes describe monitoring as “reporting.” In exams, reporting without action is weak. A better answer includes:

metrics,
variance analysis,
corrective actions,
escalation process.

Metrics commonly referenced in project management

Depending on the course, you may see:

milestone completion status
defect trends / quality metrics
burn-down/burn-up (in Agile)
effort vs planned (cost control)
risk register updates (risk control)

Risk management: identifying, analysing, responding, and reviewing

Risk management is a core theme in IT project management. A structured risk register usually includes:

risk description
probability and impact
risk owner
response strategy
trigger conditions
status/updates

Risk identification techniques

Examples include:

expert interviews
checklists (based on historical issues)
brainstorming sessions with team and stakeholders
reviewing assumptions and constraints

Risk analysis: probability-impact logic

Many exams expect you to reason about risk priority, often using a matrix approach:

High probability + high impact risks are addressed first.
Medium risks may get mitigation planning.
Low risks are monitored.

Response strategies

Typical strategies:

Avoid: change plan to eliminate risk.
Mitigate: reduce probability or impact.
Transfer: outsource/insurance/contractual shifting (often to vendors).
Accept: acknowledge risk and plan for contingencies.

A strong answer also explains the “when.” For example, transfer may be feasible for certain vendor-delivery risks but not for stakeholder adoption risks (which you must mitigate through training and communication).

Example case study: migration project risks

Consider an IT project migrating a legacy system to a new platform.
Key risks might include:

data migration errors (high impact)
unclear mapping rules from legacy data fields (high probability early)
vendor delivery delays (medium probability)
performance degradation due to unoptimised queries (medium-high impact)
insufficient business testing time (high probability if UAT is under-scheduled)

A mitigation plan could specify:

data validation scripts,
mapping workshops with business owners,
phased migration rehearsals,
performance testing with realistic load,
UAT schedule protected from overtime constraints.

An exam might ask: “Which risk response is best and why?” Your answer should connect probability-impact reasoning to response selection.

Controlling changes in Agile: still need governance

Agile doesn’t eliminate change; it changes how it is controlled. Even in iterative development:

requirements still evolve,
priorities must be managed,
acceptance criteria remains essential,
releases must be governed.

Practical Agile monitoring/control techniques

Backlog refinement: clarify and break down stories.
Sprint review: confirm delivered increment meets business needs.
Retrospective: address process improvements.
Definition of Done (DoD): ensures quality thresholds.

Important counterpoint: If the organisation’s governance requires heavy documentation for compliance, agile teams may have to adapt by producing the required evidence at the right times (e.g., compliance-oriented checklists tied to DoD).

Escalation and issue management

Where risk leads to “possible problems,” issues are “problems happening now.” Issue management is a control function:

log the issue,
assess impact,
propose resolution options,
assign an owner,
track closure.

In exams, questions often ask how to handle a critical issue that threatens deadlines. The best response includes:

immediate containment,
stakeholder communication,
corrective action plan,
update schedule/budget baseline if needed.

4) IT Project Management Tools, Documentation, Reporting, and Exam-Ready Templates

The importance of documentation that actually supports decisions

Documentation in IT project management is often misunderstood. The goal is not “more documents,” but decision-quality documentation. UCT IS teaching approaches generally value:

clarity of scope and requirements,
traceability of decisions,
evidence of governance compliance,
audit-friendly records for change and acceptance.

The trick in exams is to connect documents to purpose:

A plan is for execution and coordination.
A log is for traceability and learning.
A report is for monitoring and decision-making.

Core documents and what they contain

Even if the module name is “IT Project Management,” questions often expect familiarity with typical deliverables.

Example set of planning and control documents

Project charter: purpose, high-level scope, stakeholders, authority.
Project management plan: how work will be executed and controlled.
Scope statement: detailed deliverables and boundaries.
Requirements specification (or user stories with acceptance criteria).
WBS / scope breakdown.
Schedule baseline: milestones and timelines.
Cost baseline / budget: estimates and resource assumptions.
Risk register: risk probability/impact, responses, owners.
Quality plan: standards, verification/validation approach.
Communication plan: cadence, channels, reporting structure.
Change control plan: how changes are requested and approved.
Test plan and UAT plan.
Go-live checklist / deployment plan.
Lessons learned report for closure.

A common exam question: “Explain the difference between a risk register and an issue log.” Answer: risk is potential future event; issue is current problem. Risk register evolves continuously; issue log tracks active resolution work.

Templates you should be able to describe (conceptually)

Even without writing formal templates, describing structures earns marks.

Risk register template fields

Risk ID
Risk description
Category (technical, schedule, stakeholder, vendor, security, compliance)
Probability (e.g., low/medium/high)
Impact (e.g., low/medium/high)
Risk score (if used: P x I)
Risk owner
Response (avoid/mitigate/transfer/accept)
Triggers
Contingency plan
Status and update date

Communication matrix fields

Stakeholder group
Information needed
Purpose (status, decision request, escalation)
Format (report, meeting, dashboard)
Frequency (weekly sprint review, monthly steering committee)
Owner (PM, sponsor, technical lead)

Reporting: from status to decision reporting

A status report can include:

what was done,
what is planned,
variances,
risks and issues,
decisions needed.

A decision report emphasises:

options,
recommended action,
cost/schedule impacts,
urgency.

Exam example: weekly report to a steering committee

If asked “What should be included in a weekly update?” your answer should include:

milestone progress,
risks/issues requiring decisions,
change requests needing approval,
budget status (if requested),
next-week priorities.

If your update is only narrative, graders may consider it incomplete. The exam expects structured reporting linked to governance.

Earned Value Management (EVM): understand the concept even if not heavy on calculation

Some project management curricula introduce EVM. If present in your module context, you should be able to interpret:

Planned Value (PV): budgeted work scheduled
Earned Value (EV): budgeted work performed
Actual Cost (AC): actual cost for work performed
Variances: Cost Variance (CV = EV − AC), Schedule Variance (SV = EV − PV)

Even if the exam does not ask for detailed calculations, conceptual understanding matters.

Example interpretation without heavy math

If EV < PV: you are behind schedule.
If EV < AC: you overspent relative to work completed.

Counterpoint

EVM requires measurable progress. If your organisation cannot quantify “earned value” (for example, if deliverables are subjective), EVM becomes less meaningful, and you should propose alternative measures.

Tools in practice: project tracking, collaboration, and documentation systems

Exams may mention tool categories:

work tracking (Jira-like systems)
document management (SharePoint-like repositories)
communication (email, scheduled meetings, chat platforms)
test management systems
version control (Git-like repositories)

The exam is usually not about brand names, but about using tools to:

maintain single source of truth,
trace changes,
enforce workflow,
improve visibility.

Documentation and traceability: tying requirements to tests

A critical exam concept is traceability:

requirement → design → development → tests → acceptance evidence

This prevents “we built it but it doesn’t meet the need.” If a question asks why traceability matters, link it to:

defect reduction,
faster impact analysis on changes,
compliance evidence,
easier acceptance sign-off.

5) UCT IS Department-Linked Exam Preparation: Answering Common Questions, Applying Frameworks to Scenarios, and Building a Study Plan

How UCT-style IT project management exams typically assess knowledge

Even across different modules, IT project management exam patterns in South African universities frequently assess:

understanding of process steps (initiation, planning, execution, control, closure)
applying frameworks to scenarios (choose approach, define stakeholders, manage risk)
interpreting documentation roles (what goes in which plan)
reasoning about change control and governance
linking requirements to quality/acceptance

Students often memorise definitions but lose marks by failing to apply them to a scenario. The key is to combine:

correct terminology,
logical structure,
explicit “why.”

Scenario-based question strategy: a repeatable approach

When facing a scenario, structure your answer:

Identify the project context (type, uncertainty level, stakeholders involved).
Select relevant framework (Agile vs Waterfall choice, stakeholder analysis, risk approach).
State actions in a logical sequence.
Include governance considerations (who approves, who owns).
Provide measurable outputs (milestones, acceptance criteria, evidence).
Address risks of your approach (counter-arguments).

This approach helps you remain coherent even under time pressure.

Mapping common exam prompts to content you should include

Prompt: “Explain change control and its importance”

A strong answer includes:

definition of change control,
why scope creep is dangerous,
step-by-step process (request → impact assessment → approval → baseline updates → implementation/verification → communication),
link to governance and decision rights.

Prompt: “Compare Agile and Waterfall for an IT system”

A high-scoring answer includes:

criteria for selection (stability of requirements, stakeholder access, compliance needs),
where Agile delivers value early,
where Waterfall helps with upfront clarity,
risks and limitations for both,
recommended approach given a scenario.

Prompt: “Identify stakeholders and propose communication plan”

A top answer includes:

stakeholder identification with categories,
power/interest mapping,
tailored communication cadence and formats,
inclusion of decision requests and escalation paths.

Prompt: “Create a risk register for a migration project”

A strong answer includes:

multiple risk types (technical, schedule, vendor, data, security, stakeholder adoption),
probability and impact ratings,
risk owner suggestions,
mitigation strategy,
triggers and contingency plan.

Building a study plan aligned to exam outcomes

A study plan should reflect how marks are earned: not by rereading notes, but by practising scenario reasoning and producing structured answers.

Week-by-week approach (example for a 4-week revision cycle)

Week 1: Foundations and governance

Revise project lifecycle, stakeholder analysis, value/biz case.
Practise writing a project charter outline and a stakeholder communication matrix.

Week 2: Requirements, scope, WBS, planning

Revise requirements types (functional/non-functional), acceptance criteria.
Practise converting vague needs into testable scope statements.
Practise WBS breakdown for 1–2 mini scenarios.

Week 3: Delivery approaches, risk, monitoring/controlling

Practise Agile vs Waterfall decision making using scenarios.
Create risk registers and propose response strategies.
Practise writing a monitoring/control section that includes corrective actions.

Week 4: Documentation and exam simulation

Practise structured answers: change control, quality plan, acceptance evidence.
Do timed mock questions focusing on scenario application.
Review mistakes and produce “error logs” (what you missed and why).

Example exam answer structures (high-scoring formats)

Structure A: “Choose an approach and justify”

Project context: requirements stability, stakeholder availability, deadlines.
Choose approach: Agile or Waterfall (or hybrid).
Justify with 3–5 reasons.
Identify governance needs and how you’ll manage them.
Risks and mitigations of your choice.
Deliverables and acceptance evidence.

Structure B: “Risk register task”

Provide 8–12 risks with varied categories.
For each risk:
- probability and impact,
- owner,
- response strategy,
- triggers,
- contingency.
Prioritise top 3 risks and explain why.

Structure C: “Change control explanation”

Definition and problem (scope creep).
Step-by-step process.
Decision makers and decision rights.
Baseline updates.
Communication and verification.

Counter-arguments: how to earn marks for “critical thinking”

Examiners often reward answers that acknowledge trade-offs. Examples of counter-arguments you can include:

Against pure Agile: “Agile requires active product ownership; if stakeholders are unavailable, the project can stall or decisions can be delayed.”
Against pure Waterfall: “Upfront definition may fail if requirements are uncertain; late discovery can cause expensive rework.”
Against weak governance: “Without approval gates, uncontrolled change can invalidate schedules and budgets.”

You don’t need to write long debates. You need to demonstrate reasoning quality: show you understand limitations and mitigation.

Connecting to “UCT IS Department” expectations through terminology

To align with typical IS department framing, use terminology that shows you understand both:

project management mechanics (baselines, risk registers, WBS, acceptance criteria),
information systems delivery realities (requirements traceability, stakeholder adoption, security/compliance, data quality).

In other words: your answer should sound like an IT project manager who understands software delivery, not only a person who knows generic project management vocabulary.

Exam-time checklist: what to include in every answer

Use a mental checklist:

Did I name the correct stakeholders/roles?
Did I mention a process step sequence?
Did I link actions to “why” and to value/quality?
Did I include governance/decision rights for changes or escalations?
Did I propose measurable deliverables (milestones, acceptance criteria, test evidence)?
Did I consider at least one risk/limitation of my proposal?

South African university context: course alignment and what students should expect

Students in South Africa often take IT management topics in modules that align with project management, systems development, enterprise systems, and IT governance. While exact module codes and titles differ by institution and year, the knowledge assessed tends to overlap strongly:

requirements and systems delivery
project planning and control
risk management
delivery approach selection
stakeholder communication and governance

This document is structured so that a student who studies UCT-aligned IS project management concepts can answer:

short conceptual questions (definitions and comparisons),
scenario-based questions (stakeholder, risk, change control),
applied tasks (create a risk register, propose communication, define acceptance evidence).

Summary: What to master for UCT IS Department IT Project Management exams

Mastering IT project management for UCT IS-aligned assessments means mastering more than the “waterfall vs agile” debate. You need to demonstrate disciplined thinking about scope and requirements, governance and decision rights, quality and acceptance, risk and change control, and monitoring/control with corrective action. With consistent practice of scenario-based answering—especially stakeholder, risk register, and change control responses—students can convert conceptual knowledge into exam marks reliably.