UNISA INF3705 Project Management in IT Exam Notes: Scope, Schedule, Risk & Agile Delivery

UNISA INF3705 (Project Management in IT) exam questions typically test your ability to plan and manage IT projects from initiation through closure. The exam commonly blends core project management frameworks (scope, schedule, cost, quality, risk) with practical IT-focused delivery thinking (requirements, dependencies, change control, governance, and Agile/iterative delivery). These study notes focus on what you must know, how to apply it in exam-style scenarios, and how to structure answers clearly.

1. INF3705 Foundations: Project Life Cycle, Governance, and IT Project Roles

Project management in IT is not only about “planning a timeline.” In INF3705, you’re expected to understand how projects are justified, governed, resourced, monitored, and controlled, especially when requirements change, stakeholders conflict, or technology introduces uncertainty.

1.1 What is a Project vs an Operation (and why exams care)

A project is temporary and produces a unique outcome (e.g., a new system, a migration, a software release). An operation is ongoing and produces repetitive outputs (e.g., running a helpdesk, maintaining servers).

In exam answers, always highlight three distinctions:

Temporariness: projects have a defined start and end; operations continue.
Uniqueness: projects deliver something new or different (new features, new architecture, new process).
Constraints: projects are bounded by scope, time, cost, and quality targets.

IT example:

Operation: “Maintain the current ticketing system (patching and user support).”
Project: “Replace the ticketing system with a new platform and migrate historical tickets by 30 November.”

If the question asks “Explain why project management is needed in IT,” you can connect to the reality that software/IT delivery contains uncertainty and change—two characteristics that make a project management approach essential.

1.2 Project life cycle models (predictive vs iterative) in INF3705

INF3705 commonly expects you to recognize life cycle stages and understand that projects can follow different approaches:

Predictive (waterfall-like) life cycle

Requirements and design are established early
Execution follows after approval of documents
Change control is stricter
Works best when requirements are stable

Typical stages:

Initiation
Requirements / analysis
Design
Implementation
Testing
Deployment
Closure

Iterative / incremental life cycle (Agile-like)

Deliver in increments (sprints, iterations, milestones)
Frequent feedback from users and stakeholders
Requirements can evolve with learning
Works better when you can’t fully define requirements upfront

Typical stages:

Vision / backlog framing
Planning for iteration
Build & test increments
Review with stakeholders
Adapt (refine backlog, adjust plan)
Release and closure

Mixed (hybrid) approach

Many IT projects use hybrid patterns:

Predictive for high-level governance and budgets
Iterative for software development execution

Exam-ready phrasing: “INF3705 accepts that both predictive and iterative life cycles exist; selection depends on requirement stability, risk profile, and stakeholder feedback needs.”

1.3 Initiation: business case, problem statement, and feasibility

Initiation is where you define why the project exists. In IT, a weak initiation leads to schedule overruns, scope creep, and stakeholder dissatisfaction.

Key outputs typically include:

Business case: financial and strategic justification
Problem statement: what is wrong and what must change
Project objectives: measurable targets
Project scope (high-level): what’s included/excluded
High-level timeline and budget estimate
Stakeholder register (who is involved/affected)

Example scenario: starting a clinic management system project

A university health clinic complains about manual appointment bookings. A project is initiated to implement an online booking system integrated with existing user credentials.

A strong business case includes:

Reduction in appointment scheduling time
Reduced errors in bookings
Improved reporting for management
Better user experience for staff and patients

1.4 Stakeholders and roles (who does what)

In INF3705, stakeholder management is frequently tested because IT projects involve many parties: customers, users, IT teams, vendors, governance committees, security specialists, and auditors.

Common roles you must be able to describe:

Sponsor / Project Sponsor: provides funding, escalates issues, ensures alignment with strategy
Project Manager: plans, coordinates, monitors and controls
Product Owner / Business Owner (Agile): represents the business perspective; prioritizes value
Project Team: analysts, developers, testers, DevOps, UX, data engineers
Stakeholders: anyone impacted (end users, management, support teams)
Steering Committee: governance, approves major changes, monitors outcomes
Vendor / Supplier (if applicable): delivers contracted components

Exam tip: In stakeholder questions, mention both interest and influence, and then propose actions:

high influence + high interest → manage closely, communicate frequently
high influence + low interest → keep satisfied, occasional updates
low influence + high interest → keep informed
low influence + low interest → monitor with minimal effort

1.5 Governance: approvals, reporting cadence, and change control

Governance ensures the project delivers value and stays within constraints.

Typical governance mechanisms in IT projects:

Stage gates (approval checkpoints)
Steering committee meetings at fixed intervals
Risk review and status reporting
Change control board (CCB) for scope/time/cost changes
Quality assurance reviews
Security and compliance sign-offs

Why change control matters (especially in IT)

IT projects often experience “small” changes that become major:

“Just one more report”
“We need roles and permissions”
“The database schema must be different”

Without formal change control, scope expands and the plan collapses.

A good change control answer should include:

Request (log change with description and impact)
Assessment (scope, cost, time, risk, quality)
Approval/Reject (by CCB or sponsor within authority limits)
Implementation (update backlog, update baseline plans)
Communication (inform stakeholders of decision and effects)

1.6 Deliverables and acceptance: Definition of Done

In IT projects, acceptance criteria are often ambiguous. INF3705 expects you to emphasize that deliverables must be measurable.

A robust deliverable includes:

Acceptance criteria (what “done” means)
Testing evidence (unit/integration/UAT results)
Documentation (user manual, technical docs)
Handover to operations/support

Example: UAT acceptance criteria for an e-learning portal

Users can log in using existing university credentials
Course pages render correctly on mobile and desktop
Progress tracking updates after completing a module
Security tests show no critical vulnerabilities

“Done” should not only mean “deployed,” but “accepted and usable.”

1.7 Summary of Section 1: the mindset tested in INF3705

In the exam, scorers often look for:

Clear understanding of project vs operation
Ability to match life cycle approaches to uncertainty
Strong initiation outputs (business case, objectives, scope)
Stakeholder clarity (who influences decisions)
Governance and change control logic
Deliverables defined via acceptance criteria

That foundation supports everything in later sections: planning, risk, schedule, cost, quality, and delivery.

2. Project Planning Mastery: Scope, WBS, Scheduling, Estimation, and Baseline Control

Planning is the practical heart of INF3705. Many marks are earned by structuring answers with correct terminology and showing how planning connects to control. This section builds the core mechanics: scope definition, WBS breakdown, estimation, scheduling, and baselines.

2.1 Scope management: requirements, deliverables, and boundaries

Scope management prevents “scope creep,” the silent killer of schedules.

Scope definition components

Product scope: features and functions of the IT deliverable
Project scope: work required to produce the product deliverable

In IT, scope is often described using:

user stories or use cases
functional requirements (what the system must do)
non-functional requirements (performance, security, usability)
constraints (technology choices, compliance rules)

Example: scope for an online procurement system

Product scope may include:

Request creation and approval workflows
Budget category selection
Vendor list integration
Audit logs

Project scope includes:

Configure workflow engine
Develop UI and approval module
Build database migration scripts
Conduct integration testing and UAT
Deploy to production with rollback plan

2.2 Work Breakdown Structure (WBS): turning scope into manageable work

The WBS is a hierarchical decomposition of the project scope into work packages.

Exam-friendly WBS method

Start with final deliverable (e.g., “Procurement system build and deploy”)
Break into major components (e.g., “Workflow,” “UI,” “Database,” “Testing”)
Break further into work packages that can be assigned and estimated

A good WBS has work packages that are:

clear
small enough for estimation
testable/monitorable

Example WBS (illustrative)

1. Procurement System Delivery
- 1.1 Workflow Module
  - 1.1.1 Define approval rules
  - 1.1.2 Configure workflow engine
- 1.2 User Interface
  - 1.2.1 Build request form
  - 1.2.2 Build approval dashboard
- 1.3 Data & Integration
  - 1.3.1 Database schema design
  - 1.3.2 Integrate vendor directory
- 1.4 Testing & Deployment
  - 1.4.1 Integration testing
  - 1.4.2 UAT support
  - 1.4.3 Deployment and rollback

2.3 Estimation in IT projects: effort, duration, and uncertainty

INF3705 typically expects you to understand estimation approaches conceptually:

Analogous estimation: use past similar projects
Parametric estimation: use statistical relationships (e.g., function points, story points)
Bottom-up estimation: sum estimates of detailed work packages
Three-point estimation (if used in course): consider optimistic/likely/pessimistic scenarios

Effort vs duration distinction (common exam trap)

Effort is person-time (e.g., 120 person-hours)
Duration is calendar time (e.g., 10 working days)

If 2 developers each work 60 hours, effort = 120 person-hours, but duration depends on parallelism and scheduling.

2.4 Developing the schedule: dependencies and critical thinking

A schedule is more than a list of tasks; it includes:

sequencing
dependencies
constraints
milestones

Dependency types you should recognize

Finish-to-Start (FS): Task B starts after Task A finishes (most common)
Start-to-Start (SS): Task B can start after Task A starts
Finish-to-Finish (FF): Task B can finish when Task A finishes
Start-to-Finish (SF): rarer; usually not used in simple exams

Example dependency chain

Requirements sign-off (finish) → UI design (start)
UI design (finish) → front-end development (start)
Database schema (finish) → integration coding (start)
Integration coding (finish) → integration testing (start)

2.5 Milestones and baseline plans

A baseline is an approved plan against which performance is measured.

Common baselines:

Scope baseline (what is included)
Schedule baseline (target dates)
Cost baseline (budget allocation)
Performance baseline (for earned value if used)

Milestone design

Milestones are useful for governance:

“Requirements approved”
“Database migration complete”
“UAT passed”
“Go-live achieved”

In exam scenario questions, you can justify why milestones matter:

they reduce uncertainty through checkpoints
they help stakeholders align on progress
they reduce risk of late discovery

2.6 Resource planning: staffing and capacity constraints

Resource planning includes:

team roles needed (developers, testers, security analysts)
availability (vacations, other projects)
skills match (a “tester” may need specific domain knowledge)
capacity and scheduling conflicts

Example: capacity conflict scenario

A project schedule assumes a full-time developer on Module A for six weeks. Midway, the developer is needed for a production incident and is unavailable for 10 working days.

In your answer, you should:

identify the impact: reduced throughput, increased duration risk
propose mitigation: reallocate resources, reduce scope of Module A temporarily, adjust timeline with sponsor approval
emphasize change control if baseline dates must shift

2.7 Scheduling techniques (how to express them correctly)

Even if the exam does not require deep math, you must demonstrate conceptual competence.

Critical Path (CPM concept)

The critical path is the longest sequence of dependent tasks determining project duration.

To earn marks:

explain that tasks on the critical path have float ≈ zero
changes to critical path tasks directly change project end date

Float (slack)

Float = how long a task can slip without delaying the project end date
Non-critical tasks may slip within float

In IT projects, float protects against minor delays, but delays accumulate risk—especially with integrated software modules.

2.8 Linking planning to monitoring and control

A plan is useful only if it can be controlled. Planning outputs feed monitoring:

WBS dictionary: defines each work package
schedule: planned start/finish
cost estimates: budgets per work package
risk register: assigned to tasks where relevant

When deviations occur:

detect variance (schedule/cost/scope)
analyze root cause
decide corrective action (and possibly preventive action)
update plan through change control

2.9 Planning example: designing an answer framework

Consider an exam prompt:

“A university plans to develop a new student portal. Requirements are partially defined and integration with identity management is required. Explain how you would plan and create a schedule.”

A strong INF3705 answer should include:

initiation outputs (business case, objectives)
scope breakdown (WBS)
estimation method: bottom-up for work packages; analogous for uncertain pieces
identify dependencies (identity integration first, or parallel development where safe)
include milestones (requirements sign-off, architecture approval, integration complete, UAT pass)
define baseline and change control governance

Even without numbers, the structure shows planning maturity.

2.10 Summary of Section 2

To perform well in INF3705 planning questions:

manage scope precisely
build a WBS that supports estimating and tracking
distinguish effort vs duration
model dependencies and identify milestones
set baselines and describe how changes are controlled
address resources and capacity constraints

This planning foundation becomes the input for cost control, risk management, quality assurance, and delivery monitoring later in the course.

3. Cost, Quality, and Risk Management in IT Projects (INF3705 Application)

IT projects fail not only because of poor schedules. INF3705 strongly tests your ability to manage cost, quality, and risk in a coherent way that supports project outcomes.

3.1 Cost management: from estimating to controlling spend

Cost management aims to deliver within an approved budget while responding to change.

Core cost concepts

Cost estimation: determine expected costs for work packages
Budgeting: aggregate estimates into a cost baseline
Cost control: monitor actual vs planned spending; forecast outcomes

Typical cost categories in IT projects

While exams vary, you can generally organize costs as:

labour (internal staff)
software licensing and subscriptions
hardware and infrastructure (servers, cloud services)
external vendors/contractors
training and documentation
contingency reserves

Contingency and reserves (conceptual clarity)

Contingency reserve: for known-unknowns (risks that are identified)
Management reserve: for unknown-unknowns or unplanned needs within governance limits

In exam scenarios, if a risk occurs (e.g., vendor delays), a good answer should explain using contingency if allowed and escalating if reserve is insufficient.

3.2 Quality management: quality planning, assurance, and control

Quality in IT includes:

functional correctness (features work)
performance (response time, throughput)
security and reliability
usability and maintainability

INF3705 often expects you to differentiate:

Quality planning: define standards and processes (e.g., coding standards, test strategy)
Quality assurance (QA): process-oriented; ensure activities follow standards
Quality control (QC): product-oriented; inspect/test outputs to confirm quality

Example: quality standards for a web application

Response time: page load under 2 seconds for standard queries
Security: no critical vulnerabilities after SAST + dependency checks
Accessibility: meet baseline accessibility guidelines
Reliability: crash rate below an agreed threshold in testing

3.3 Quality metrics and test evidence

In answers, describe quality evidence, not only intent.

Examples:

Unit tests for core business logic
Integration tests for API and database interactions
Security tests: penetration testing or vulnerability scanning
User acceptance testing (UAT) sign-off
Defect tracking and resolution metrics

Defect severity categories (common exam vocabulary)

Critical: production-blocking, security risk
Major: functionality impaired but workaround exists
Minor: cosmetic issues
Trivial: small formatting issues

If the exam gives a scenario, use it:

If critical defects appear late, quality control and change control interplay becomes important: you may need to extend testing or cut lower-value scope.

3.4 Risk management: identifying, analyzing, responding, and monitoring

Risk management is where you demonstrate structured thinking.

Key risk management steps

Identify risks (brainstorm + document assumptions)
Analyze risks (probability and impact)
Plan responses (avoid, mitigate, transfer, accept)
Monitor and control (trigger monitoring, review status)

3.5 Risk identification in IT (sources of risk)

In IT, common risk categories include:

Technical risk: unknown integration complexity, performance limitations
Requirements risk: unclear scope, changing user needs
Schedule risk: dependencies not ready (e.g., identity service availability)
Vendor risk: third-party delay or contract constraints
Security/compliance risk: regulatory requirements not met
Team risk: skills gaps, turnover, underestimated effort
Operational risk: deployment and rollback not tested

3.6 Risk analysis: qualitative vs quantitative

If the exam expects methods:

Qualitative: categorize likelihood and impact (Low/Med/High)
Quantitative: estimate numeric outcomes (e.g., expected time, expected cost), sometimes using probability models

In most INF3705 exam tasks, a qualitative risk matrix is enough if clearly explained.

Risk matrix concept

Likelihood on one axis (e.g., Low/Medium/High)
Impact on another axis (e.g., Low/Medium/High)
Determine overall risk priority

3.7 Risk response planning: choose response types deliberately

You must link response types to risk characteristics.

Avoid

Eliminate the threat by changing the plan.

Example: if identity integration is too uncertain, defer it and build a mock identity layer early.

Mitigate

Reduce likelihood and/or impact.

Example: perform early integration tests; prototype API calls; add buffer time for integration.

Transfer

Shift impact to a third party.

Example: use a managed service provider with SLA; insure specific components.

Accept

Acknowledge the risk and have contingency if it happens.

Example: accept low probability “minor UI inconsistency” and plan no special effort.

3.8 Example risk register (structured and exam-usable)

A risk register row in an exam scenario should include:

Risk ID
Risk description
Category (technical, schedule, vendor, security, etc.)
Probability (L/M/H)
Impact (L/M/H)
Priority
Owner (who monitors it)
Response strategy
Trigger/early warning
Contingency action

Illustrative mini-register (not numeric claims beyond L/M/H)

Risk	Category	Likelihood	Impact	Priority	Response	Trigger
Identity service integration delays	Technical/Schedule	High	High	High	Mitigate: early prototype + daily integration checks	API errors persist for 1 week
Requirements change after UAT	Requirements	Medium	High	High	Mitigate: backlog refinement + change control	Stakeholders reject UAT sign-off
Vendor infrastructure goes out of SLA	Vendor	Low	High	Medium	Transfer: SLA + penalties; Mitigate: monitoring	Latency exceeds agreed threshold
Security vulnerability found late	Security/Quality	Medium	High	High	Avoid/Mitigate: SAST + dependency scanning; allocate pen-test window	Critical findings during pre-UAT scan

3.9 How risk management connects to schedule and cost

INF3705 exams often reward integration:

Risk response activities add tasks to the schedule (mitigation costs time)
Contingency reserves link to budget planning

If you propose mitigation like “do early integration testing,” you should also mention:

schedule impact: additional work earlier but reduces late integration failure risk
cost impact: additional testing effort but potentially avoids major rework

3.10 Combining quality and risk: failure modes in IT

Quality issues are often risks realized. For example:

A security vulnerability is a realized risk.
Poor test coverage is a risk factor: it increases likelihood that defects will escape.

A sophisticated answer should show:

quality planning reduces risk likelihood (e.g., continuous testing reduces defect escape)
quality control reduces impact by catching issues early

3.11 Practical exam scenario: responding to an integration risk

Scenario:

A project depends on an external identity management API.
Midway, integration test failures appear and the vendor says fixes may take 3 weeks.
The project end date is under pressure.

A strong response should include:

Assess impact: tasks downstream on critical path are delayed.
Update risk assessment: integration failures now become higher likelihood and impact.
Choose response:
- Mitigate: stub/mock identity, proceed with UI/workflows using mock data
- Transfer: check SLA and escalation route with vendor
Update schedule: re-sequence tasks where possible, adjust milestones
Communicate: sponsor and steering committee with options (tradeoffs)
Control scope: defer low-priority features until integration stabilizes
Protect quality: ensure stubs reflect real API contracts and data models

3.12 Summary of Section 3

High-scoring INF3705 answers for cost, quality, and risk will:

show structured cost management logic (estimate → budget → control)
distinguish QA vs QC and connect to measurable standards
manage risk using register structure, risk matrix logic, and deliberate response strategies
integrate risk responses into schedule and budget decisions

These principles create coherence across the rest of the course: managing change, executing delivery, and controlling progress.

4. Agile, Iterative Delivery, and Change Management for IT Projects

Many INF3705 exam candidates struggle because they treat Agile as “no planning.” In reality, Agile requires planning—just not all planning happens at the start, and governance must adapt while still controlling scope, cost, and quality.

4.1 Agile fundamentals: value, feedback, and incremental delivery

Agile delivery is built on:

iterative development
customer feedback
prioritization of value
continuous improvement

In an exam, you should connect Agile to uncertainty:

When requirements are unclear, iterative learning reduces risk.
When stakeholders need frequent review, Agile accelerates validation.

4.2 Key Agile concepts: backlog, sprint, and roles

Product backlog

A prioritized list of work items (features, improvements, fixes).

Backlog refinement improves clarity:

define acceptance criteria
ensure dependencies are understood
estimate effort (often relative estimation methods)

Sprint / iteration

A time-boxed cycle to deliver potentially shippable increments.

Within a sprint:

team commits to a planned set of backlog items
changes may occur, but scope control is managed via agreed Agile rules (and re-planning if necessary)

Roles

Product Owner: prioritizes work and represents business value
Scrum Master (if Scrum context): supports process and removes impediments
Developers: deliver increment

Even if the course uses broader Agile language, these concepts remain useful.

4.3 Planning in Agile: iteration planning vs release planning

Agile planning typically has two layers:

Release planning (longer horizon)
- decide what outcomes to target
- set a roadmap of features/milestones
Iteration planning (near horizon)
- choose backlog items for the next sprint
- plan tasks at work-package level within sprint

Exam answer tip

If asked: “Explain how you would plan in Agile,” avoid only describing sprint ceremonies. Include:

backlog prioritization
estimation/selection for the sprint
dependencies identification
definition of done and quality standards

4.4 Change management in Agile: embracing change without losing control

Change is inevitable in IT. Agile “welcomes change,” but control is still necessary.

How control works in Agile:

backlog is the controlled mechanism
product owner manages priority tradeoffs
scope changes usually affect what goes into future sprints rather than silently changing sprint commitments (unless allowed by the team)

Example: change request mid-sprint

A stakeholder asks to add a “download report in PDF format” after sprint start.

A good Agile response should include:

assess if it fits within current sprint goals
if not, defer to backlog and re-prioritize
evaluate cost and effort tradeoffs
communicate clearly the impact on timeline/value

4.5 Monitoring Agile progress: burndown, velocity (conceptual), and quality gates

INF3705 may ask how to track progress without confusing “activity” with “value.”

Common Agile progress signals:

Burn-down chart: remaining work over time
Velocity (relative): historical throughput used for forecasting (not a commitment)
Increment quality: passing tests, meeting acceptance criteria
Stakeholder feedback: UAT results, review outcomes

In exam answers, caution against gaming metrics:

velocity may fluctuate due to changing scope complexity
burn-down can be inaccurate if estimates were poor or if work definitions are unclear

4.6 Hybrid governance: aligning Agile execution with stage gates

Many universities and corporate environments require governance similar to predictive methods (approvals, audits, funding milestones). In that case, hybrid governance is used.

An exam-ready approach:

Keep stage gates for funding and compliance
Execute iterative increments under each stage
Use quality assurance checkpoints aligned with governance needs

4.7 Case study: Agile delivery of a student portal (South African university context)

Imagine a student portal project for a South African institution:

Features include course registration interfaces, academic calendar display, and a support ticket integration.
Requirements start partial; student feedback is critical.

A plausible Agile plan:

Release 1: registration UI + calendar pages + basic identity login
Release 2: course update notifications + improved support integration
Release 3: analytics dashboards and advanced search

How risk is handled in Agile

Early integration with identity management to validate access
Iterative testing to reduce late defect spikes
Frequent stakeholder demos to confirm value

How change is managed

New student requests enter backlog
Product owner prioritizes based on value and effort
If a request conflicts with sprint goals, it moves to future sprints

4.8 Linking Agile to cost and schedule control

Agile schedules can be forecasted but controlled through:

capacity-based planning (team capacity per sprint)
release planning with adjusted scope
burn-down and velocity-based forecasting (conceptual)
continuous re-prioritization if risks arise

Cost control:

effort estimates per backlog item
track spend per sprint or per component
manage vendor costs and licensing with planned increments

4.9 Counter-arguments: when Agile might fail (and what to say in exams)

Examiners often appreciate critical thinking. Common reasons Agile can struggle:

Unstable stakeholders / unclear product owner authority
- result: constant reprioritization, endless rework
Insufficient technical architecture
- result: inability to scale; quality collapses
No quality automation
- result: defects accumulate; UAT becomes a bottleneck
Misuse of Agile ceremonies
- result: bureaucracy replaces flexibility

A high-quality exam answer acknowledges these and provides mitigation:

empower product owner, establish backlog governance
define architectural runway / technical spikes
implement CI/CD and automated tests
ensure definition of done includes quality criteria

4.10 Summary of Section 4

To score strongly on Agile and change management questions:

explain Agile value and incremental learning
describe backlog, sprint planning, and roles
show how change is controlled through backlog prioritization
describe progress monitoring using quality-focused evidence
connect Agile execution to governance and stage gates
address risks and reasons Agile can fail, plus mitigation strategies

This section builds delivery intelligence for the final parts of INF3705, where you must demonstrate monitoring, control, and closure discipline.

5. Monitoring & Controlling Projects, Communication, and Exam-Ready Answer Templates (Including Closure)

The last INF3705 exam phase is about what happens after planning: monitoring performance, controlling deviations, managing communications, and closing responsibly. This section provides structured techniques and practical answer templates for scenario questions.

5.1 Monitoring & controlling: detecting variance early

Monitoring means tracking:

scope progress (completed deliverables)
schedule progress (milestone status)
cost progress (spend vs budget)
quality evidence (test results, defect trends)
risk status (risk likelihood/impact changes)

Controlling means:

correcting deviations (schedule recovery, scope reprioritization)
updating baselines if change is approved
implementing preventive actions

INF3705 expects you to understand that monitoring without control is not enough; control requires decision-making and change governance.

5.2 Performance measurement: how to discuss progress without advanced math

Even if earned value calculations are not heavily required, you should show understanding of:

comparing planned vs actual
forecasting based on current trends
using objective evidence

A strong exam answer uses language like:

“Based on milestone achievement and defect leakage rates…”
“Schedule variance indicates critical path impact…”
“Quality gates passed/failed based on acceptance criteria…”

Example: milestone tracking language

“Requirements sign-off completed on 12 May as planned.”
“UAT is currently slipping because integration defects are delaying test readiness.”
“A re-baselining request will be submitted if vendor fixes do not stabilize within the agreed window.”

Notice the structure: facts first, then impact, then response.

5.3 Earned value (EVM) concepts—what to know if tested

If the course includes EVM, you should know the basic vocabulary:

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

From these, indicators:

schedule performance: EV vs PV
cost performance: EV vs AC

Even if numeric calculation is minimal, examiners like correct terms and how they are interpreted.

5.4 Communications management: stakeholder communication design

IT projects have information complexity. A communications plan reduces confusion and prevents late escalation.

A communications plan includes:

audience (who needs what)
channels (email, reports, meetings, dashboards)
cadence (weekly status, monthly steering committee)
escalation triggers (e.g., critical risk materializes)
ownership (who produces updates)

Example communication cadence

Weekly team stand-up: sprint blockers and progress
Weekly project status report to sponsor: milestone, risks, issues
Steering committee monthly: decisions, budget approvals, major changes
Ad hoc for incidents: security or production incidents with immediate escalation

5.5 Issue management: differentiate issues from risks

Risk: a potential event that may happen in the future
Issue: an event that has happened or is happening now

In exams, if asked to “manage uncertainties,” you should show:

risks are tracked with mitigation plans and triggers
issues require immediate action and often require approval for changes

Example

Risk: “Vendor integration delays may occur.”
Issue: “Vendor API endpoint is currently unavailable, causing integration test failures.”

For issue management, include:

log issue
analyze impact (scope, schedule, cost, quality)
decide action and assign owner
communicate and track resolution

5.6 Corrective vs preventive actions

This distinction is subtle but important.

Corrective action: fix something that already went wrong
Preventive action: avoid recurrence by improving process or addressing root cause

Exam example:

Corrective: re-run tests and fix defects after UAT failure
Preventive: improve automated testing coverage to reduce future regression

5.7 Change control: from request to approved baseline update

Change control is one of the most testable topics because it integrates scope/schedule/cost/risk governance.

A complete exam answer usually includes:

how changes are logged
impact assessment process
decision-making authority (sponsor/CCB)
documentation and baseline updates
communication of decisions and impacts

Impact assessment elements (what to say)

scope: what feature changes?
schedule: which milestones slip?
cost: effort and budget impact
quality: test requirements and defect risk
risk: new risks introduced or old ones reduced
compliance: regulatory/security implications

5.8 Procurement and vendor management (often present in IT project scenarios)

In IT projects, vendors deliver modules, hosting, or support services.

Vendor management in INF3705 answers often includes:

contract requirements and SLAs
escalation paths
acceptance criteria for vendor deliverables
integration and testing responsibility boundaries

Example vendor escalation

If the vendor misses SLA:

check contract penalties or remediation options
request corrective action plan
escalate to steering committee if critical path is impacted

5.9 Closure: what “done” means at the end of an IT project

Project closure includes both administrative and technical activities.

Closure outputs include:

final deliverables acceptance
handover documentation to operations/support
lessons learned and post-project review
contract closure (if vendors used)
final project report and archive of project documents

Lessons learned categories

what worked (processes, collaboration practices)
what did not work (planning gaps, underestimated dependencies)
improvement recommendations (standards, templates, training)

In exams, closure questions reward “professional completeness,” not just “we finished development.”

5.10 Exam-ready answer templates (copy structures)

Below are structures you can use to write high-scoring responses quickly.

Template A: “Plan a project” scenario answer

Initiation: business case, objectives, high-level scope
Scope breakdown: WBS and deliverables list
Estimation: estimation approach, effort/duration distinction
Scheduling: dependencies, milestones, critical path concept
Resources: capacity, role assignments
Quality plan: QA/QC, acceptance criteria, test strategy
Risk plan: risk register, matrix, responses
Baseline and control: change control process, reporting cadence

Template B: “Manage risk” scenario answer

Identify: risk description and category
Analyze: likelihood/impact and prioritization
Response: avoid/mitigate/transfer/accept
Implementation: add mitigation tasks to plan
Triggers: early warning indicators
Monitor: update risk register and report in status meetings

Template C: “Handle change request” scenario answer

Log change request and describe it precisely
Assess impact: scope/schedule/cost/quality/risk/compliance
Decide: approve/reject/defer (authority-based)
Update baselines or backlog accordingly
Communicate decision and update stakeholders
Track and confirm implemented change meets acceptance criteria

5.11 Full scenario walkthrough: integrating everything into one coherent plan

Consider this comprehensive exam scenario:

“A university has initiated an IT project to deliver a new student portal. Requirements are partially defined. Integration with an identity management system is required. Midway, UAT reveals critical defects and the sponsor asks whether scope should be reduced to meet the deadline.”

A strong answer draws on all previous sections:

Identify current status
- UAT is failing due to critical defects
- integration readiness and quality gates are not met
Classify problems as issues
- critical defects found now are issues, not only risks
Quality control actions
- pause non-critical work to focus on critical defect remediation
- ensure testing evidence is captured (defect logs, reproduction steps)
- verify that acceptance criteria for UAT items are met
Risk updates
- the “critical defects late” risk materialized
- re-assess likelihood/impact for further issues
Change control and scope management
- propose scope reduction strategy: defer low-value backlog items
- update backlog priorities with product owner
- ensure decisions are documented and communicated
Schedule and critical path
- determine which tasks/milestones are now critical
- consider resequencing tasks or re-baselining if necessary
Cost and contingency
- assess whether remediation costs fit within budget
- use contingency reserve if approved for risk materialization
Communication
- report to sponsor and steering committee with options:
  - reduce scope to meet deadline
  - extend timeline to achieve full scope quality
  - combine both (small scope cut + timeline buffer)
Lessons learned
- after stabilization, conduct root cause analysis:
  - test strategy gaps
  - unclear acceptance criteria
  - integration mismatch
- apply preventive actions for future releases

This answer style demonstrates control maturity and shows you can connect governance, quality, risk, and change decisions.

5.12 Summary of Section 5

High-scoring INF3705 exam work on monitoring/controlling and closure should include:

explicit monitoring of scope/schedule/cost/quality/risk
issue vs risk differentiation
corrective vs preventive actions
structured change control steps and impact assessment
communications plan cadence and escalation thinking
closure deliverables and lessons learned
reusable exam templates showing coherent logic

Final Consolidation: What to Know for UNISA INF3705 Exam Success

UNISA INF3705 Project Management in IT exam success requires more than remembering definitions. You must demonstrate the ability to apply project management concepts to IT delivery realities: evolving requirements, integration dependencies, quality gates, and risk materialization. Across the exam, the strongest answers tend to share a pattern:

Define the project and scope clearly (initiation, WBS)
Plan schedule and resources with dependencies and milestones
Budget and control costs using baselines and contingency logic
Assure quality through QA/QC and acceptance criteria
Manage risk with a structured register and deliberate responses
Deliver iteratively (Agile/hybrid) with governance-aligned planning
Monitor and control using clear variance interpretation, issue management, and change control
Close professionally with acceptance, handover, and lessons learned

Use the templates and scenario logic above to craft structured, exam-ready responses that match how INF3705 questions are typically marked: correctness of terminology, coherence of reasoning, and practical control actions tied to IT project constraints.