IT00077 – Introduction to IT Project Management Exam Notes (UJ College of Business & Economics)

These exam notes provide a structured, practical guide to IT00077: Introduction to IT Project Management with emphasis on core project management concepts, IT-specific delivery issues, and the kinds of questions commonly asked in entry-level modules. The notes are written for a South African university context—aligned with expectations at the University of Johannesburg (UJ), College of Business & Economics—and include frameworks, checklists, and worked examples designed for revision.

1. Foundations of IT Project Management: Scope, Stakeholders, and Project Life Cycles (UJ Lens)

Why IT Project Management Is Different

IT projects differ from many traditional construction or manufacturing projects because their outputs are often intangible, progress can be harder to measure, and the work is frequently knowledge-driven. In practice, this means IT project managers must manage not only time, cost, and resources, but also:

• Requirements volatility (needs change as users learn what is possible)
• Technology uncertainty (dependencies, compatibility, and integration risks)
• Knowledge and communication complexity (teams often span business + technical roles)
• Quality and usability expectations (defects and user dissatisfaction are costly even if “on schedule”)

A useful exam framing is: IT project management is project management, but with IT-specific levers such as architecture, testing, data, security, and change control.

Core Project Concepts and Definitions

Most exam questions test whether you can differentiate key terms:

• Project: A temporary endeavour with a defined start and end, created to deliver a unique product/service/result.
• Programme: A group of related projects managed in a coordinated way to achieve outcomes.
• Project portfolio: A set of projects grouped to align with strategic objectives.
• PMO (Project Management Office): A governance and support function that improves delivery consistency (policies, templates, assurance).

It is also common for exams to ask you to interpret terms such as:

• Deliverables (tangible outputs like a system release, training material, migration plan)
• Milestones (major progress points like “requirements sign-off” or “go-live”)
• Constraints (time, cost, scope, quality, regulatory requirements)
• Assumptions and dependencies (factors you believe are true or rely on external teams)

Stakeholders: The People Behind the Requirements

An IT project manager must identify stakeholders and understand their influence. Typical stakeholders include:

• Sponsor (funding authority, strategic alignment, escalation)
• Project manager (delivery accountability)
• Business owner/product owner (defines business value and acceptance criteria)
• End users (provide usability and operational input; validate functionality)
• Developers/engineers (deliver technical solutions)
• QA/testing team (verify quality and readiness)
• Security and compliance (risk controls, regulatory adherence)
• Operations/Support team (post go-live stability and process readiness)

A frequent exam theme is the difference between stakeholder management and communication management:

• Stakeholder management is about engagement, expectations, power/interest analysis, and buy-in.
• Communication management is about information flow (what, to whom, when, and how).

Stakeholder Power/Interest and Engagement Strategies

In many project management courses at South African universities, students learn the power–interest grid. A simplified version:

1. High power, high interest: Manage closely; frequent engagement.
2. High power, low interest: Keep satisfied; communicate periodically.
3. Low power, high interest: Keep informed; involve in reviews.
4. Low power, low interest: Monitor; minimal effort.

IT example: In an e-commerce system project, the security team may be high power (can block go-live) and high interest (deep involvement in design). End users may have low power but high interest (they determine usability acceptance). The sponsor has high power but sometimes lower interest in details—so communication should focus on decisions and risk status rather than technical tasks.

The IT Project Life Cycle: From Idea to Closure

A typical IT project life cycle includes:

1. Initiation: Business case, feasibility, identification of stakeholders.
2. Planning: Detailed scope, schedule, cost, risk, communication, quality.
3. Execution/Delivery: Build, configure, test, train, and prepare deployment.
4. Monitoring & Controlling: Track progress, manage changes, correct deviations.
5. Closing: Final acceptance, benefits review, lessons learned.

Predictive vs Iterative Life Cycles (Waterfall vs Agile)

Even introductory modules often require basic comparison:

• Predictive (Waterfall/phase-gated):

  • Heavy upfront planning
  • Useful when requirements are stable and technology risks are low
  • Changes are expensive; strong governance needed

• Iterative/Agile (Scrum/Kanban style):

  • Work delivered in increments
  • Better when requirements evolve or discovery is needed
  • Requires ongoing stakeholder availability and strong product ownership

Exam-style argument: If an organisation is launching a new internal reporting tool but business requirements are still evolving, an iterative approach helps by delivering early value and learning quickly. If the tool must integrate with a regulated system with strict technical constraints and fixed interface definitions, a predictive structure may be safer—or hybridized (predictive architecture + iterative development).

Governance and Control: Preventing “Chaos Delivery”

IT projects fail often not because teams are incapable, but because governance is weak. Common governance controls include:

• Stage gates (approval to proceed to the next phase)
• Change control (formal process for scope and requirements changes)
• Risk management (regular risk reviews)
• Quality assurance (defined standards and acceptance criteria)
• Status reporting (schedule/cost/risk updates)

A concrete exam example is the difference between:

• Change requests (planned process) vs
• “Uncontrolled changes” (typical source of scope creep)

Scope creep happens when additional features are added without adjusting time/budget/technical approach. A key response is to document the impact and seek explicit approval from the sponsor or product owner.

Summary: What Examiners Look For

For IT00077-style questions, students are usually expected to:

• Define core project terms accurately
• Identify stakeholder roles and typical engagement methods
• Explain the life cycle and describe differences between predictive and iterative approaches
• Use governance concepts (change control, stage gates, risk controls) to show how projects stay on track

2. Planning an IT Project: Scope, Work Breakdown, Schedule, Budget, Quality, and Risk

Scope Management: Requirements, Deliverables, and Acceptance

Scope is more than “what we will build.” In IT project management it includes:

• Product scope: Features and functions (what the system does)
• Project scope: Work required to deliver the product (what we must do)
• Requirements: Business and technical needs that guide design and testing

A critical concept for exams is scope baseline, which includes approved:

• Scope statement
• Work Breakdown Structure (WBS)
• Schedule and cost baselines (often integrated with scope)

Writing a Scope Statement (What It Must Include)

A strong scope statement typically addresses:

• Project objectives and success criteria
• In-scope and out-of-scope items
• Key deliverables and assumptions
• High-level constraints (regulatory, architecture, platform limitations)
• Acceptance criteria (how the sponsor/product owner will approve completion)

IT example: For a university learning management system integration:

• In scope: API integration, user authentication mapping, reporting dashboard
• Out of scope: redesign of the core LMS UI, replacing the LMS platform itself
• Acceptance criteria: successful API calls for defined endpoints, agreed test cases pass, and security checks approved

Work Breakdown Structure (WBS): Turning Scope into Manageable Work

A WBS breaks down deliverables into smaller work packages. A common approach is:

1. Identify major deliverables (e.g., “Requirements,” “Design,” “Build,” “Test,” “Training,” “Deployment”).
2. Decompose deliverables into tasks.
3. Define work packages that are small enough to estimate duration and cost.

A typical WBS element might include:

• “Define functional requirements”
• “Create data migration mapping”
• “Develop payment integration”
• “Execute integration testing”
• “Prepare user training materials”

WBS and Estimation: Why It Matters

Without a WBS, schedule estimation becomes vague. Many exam questions ask you to explain why decomposition helps:

• It improves estimation accuracy
• It clarifies ownership
• It enables tracking progress at task level
• It supports change control by linking changes to affected tasks

Scheduling: Dependencies and Realistic Timelines

Schedules are not just lists of tasks. They incorporate:

• Dependencies (A must happen before B)
• Critical path (sequence of tasks that determines project duration)
• Buffers (time reserve to manage uncertainty)

Common dependency types:

• Finish-to-start: Task B can start after A finishes
• Start-to-start: Task B can start once A starts
• Finish-to-finish: Task B must finish when A finishes

IT example:

• You may need to complete “environment setup” before “developer builds” can begin.
• You may need to complete “security testing plan” before “penetration testing” can proceed.

Schedule Example (Exam-Friendly Numbers)

Consider a simplified plan for a small IT rollout:

• Requirements & design: 3 weeks
• Build: 4 weeks
• Testing: 2 weeks
• Deployment preparation: 1 week
• Training: 1 week

If testing can begin halfway through build (iterative approach), the schedule differs. For predictive approach, it might be sequential:

• Total duration = 3 + 4 + 2 + 1 + 1 = 11 weeks

For iterative approach, testing begins after 2 weeks of build, so:

• Requirements & design: weeks 1–3
• Build: weeks 4–7
• Testing starts at week 6 and runs 2 weeks: weeks 6–7
• Deployment prep starts after testing begins: weeks 6–7 (or after testing completion depending on risk)
• Training occurs after final release

In exam questions, you may be asked to reason why the approach changes risk, feedback speed, and schedule predictability.

Budgeting an IT Project: Cost Categories and Cost Drivers

IT project budgets often include:

• Labour costs: developers, analysts, testers, PM
• Software licences and cloud services
• Hardware and infrastructure (if required)
• Testing tools and environments
• Training and change management
• Contingency reserve for risk

Cost Estimation Methods (Intro Level)

Common methods you may need to mention:

• Analogous estimation: use similar past projects
• Parametric estimation: estimate based on measurable parameters (e.g., function points, number of users)
• Bottom-up estimation: sum estimates for work packages (more accurate when WBS is detailed)

IT00077 exam logic: If you are early in the project and requirements aren’t fully defined, analogous or parametric estimates may be safer than bottom-up guesses. As WBS becomes refined, bottom-up becomes better.

Quality Management: Standards, Assurance, and Testing Strategy

Quality in IT is not “polish at the end.” It includes:

• Quality planning: define what quality means for deliverables
• Quality assurance (QA): process to prevent defects
• Quality control (QC): testing and verification to detect defects

A basic IT testing taxonomy:

• Unit testing: developer verifies individual components
• Integration testing: validate interactions between components/services
• System testing: evaluate the whole system against requirements
• Acceptance testing (UAT): business validates against acceptance criteria

Quality Metrics Often Mentioned

Depending on your module depth, you may see metrics such as:

• Defect density (defects per unit size)
• Test pass rate for planned test cases
• Severity levels (critical/high/medium/low)
• Test coverage (percentage of requirements mapped to test cases)

Exam question pattern: If asked “How do you ensure quality?” you should include both process (QA) and verification (testing), plus traceability between requirements, design, and tests.

Risk Management: Identify, Assess, Respond, Monitor

Risk management is central to project planning. A standard cycle:

1. Identify risks (technical, schedule, cost, organisational)
2. Qualitatively assess (probability vs impact)
3. Plan responses
4. Monitor and review

Risk Register: What It Contains

A risk register usually includes:

• Risk description
• Category (technical, schedule, cost, compliance, stakeholder)
• Probability and impact rating
• Owner (who manages it)
• Response strategy (avoid, mitigate, transfer, accept)
• Contingency plan (what you do if it occurs)

Concrete Risk Examples for IT Projects

• Requirements risk: stakeholders change requirements late
  • Response: involve users early, implement change control, use prototypes
• Technical risk: integration fails due to API mismatch
  • Response: early API tests, define interface contracts, create mock services
• Security risk: vulnerabilities found late in testing
  • Response: security-by-design, vulnerability scanning early, secure coding standards
• Resource risk: key developer leaves mid-sprint/phase
  • Response: cross-training, documentation, backup resources

Quality and Risk Interactions (Why It’s Not a Separate Topic)

Examiners like integrated thinking. For example:

• Poor scope definition increases risk of rework, which increases cost and threatens schedule.
• Testing too late increases defect escape (defects found after release), which increases operational disruption.
• Inadequate risk response plans lead to “surprise emergencies.”

Planning Outputs: The Deliverables of Good Planning

By the end of planning, an IT project usually has:

• Scope baseline
• Schedule baseline
• Cost baseline (budget and cost estimates)
• Quality plan (standards and acceptance)
• Risk register and risk response plan
• Communication plan
• Stakeholder engagement plan
• Requirements traceability approach (especially important in systems projects)

3. Execution and Monitoring in IT Projects: Communication, Change Control, Procurement, Agile Delivery, and Metrics

Execution: Coordinating Teams Toward Deliverables

Execution in IT projects includes performing the work defined in the plan:

• Build/configure components
• Develop documentation
• Conduct testing and defect resolution
• Deliver training
• Prepare for deployment and cutover
• Manage stakeholder engagement activities

The project manager’s role is partly operational (coordinating delivery) and partly leadership:

• remove blockers
• manage escalations
• ensure that decisions align with goals and governance

Communication Management: Making Information Actionable

Communication management covers what information is needed, by whom, and when. Common communication artefacts include:

• Project charter summary (high-level objectives and sponsor approval)
• Status reports (progress, accomplishments, risks, changes)
• Issue logs (what is happening right now that needs action)
• Meeting minutes and action items
• Dashboards (visual schedule/risk/cost indicators)

Weekly Status Report Example (Typical Structure)

A good status report often includes:

• Progress against milestones
• Completed tasks since last report
• Planned tasks for next period
• Top risks (and status changes)
• Budget status (spend vs plan)
• Decisions required and deadlines

Exam approach: If asked to design a communications plan, you should include:

• Audience (sponsor, users, technical team)
• Frequency (daily stand-up, weekly steering committee, monthly compliance report)
• Channel (email, meeting, dashboard)
• Content (status, decisions, risks, approvals)

Monitoring & Controlling: Tracking Performance and Taking Corrective Action

Monitoring involves collecting data and measuring it against baselines. Controlling involves acting when deviations occur.

Common monitoring targets:

• Schedule variance (are we behind/ahead?)
• Cost performance (are we over budget?)
• Scope compliance (are changes approved and tracked?)
• Quality performance (defects, test pass rates)
• Risk status (are key risks increasing or decreasing?)

Earned Value (EVM) at Intro Level

Even in introductory courses, students may be expected to know EVM basics:

• Planned Value (PV): cost planned for work scheduled
• Earned Value (EV): budgeted value of completed work
• Actual Cost (AC): actual cost incurred for completed work

From these:

• Schedule Variance (SV) = EV – PV
• Cost Variance (CV) = EV – AC

You might be asked to interpret positive/negative results:

• SV > 0: ahead of schedule
• SV < 0: behind schedule
• CV > 0: under budget (for completed work)
• CV < 0: over budget

Example:

• PV = R200,000, EV = R180,000, AC = R210,000
• SV = 180,000 – 200,000 = -R20,000 (behind schedule)
• CV = 180,000 – 210,000 = -R30,000 (over budget)

Change Control: Managing Scope Creep and Keeping Approval Clear

Change control ensures that changes to scope, requirements, or deliverables go through defined procedures.

A standard change control process:

1. Change request submitted (what changed + why + impact)
2. Impact analysis (schedule, cost, quality, risk)
3. Decision/approval by authority (sponsor/product owner/change board)
4. Update baselines and plans if approved
5. Communicate changes and update traceability documents
6. Implement change and verify acceptance

What to Include in a Change Request (Exam Checklist)

• Description of change
• Reason (business need, defect correction, regulatory requirement)
• Affected requirements/deliverables
• Estimated impact (time/cost/technical)
• Priority and urgency
• Proposed implementation plan

Why this matters: In IT projects, uncontrolled changes cause hidden rework, delayed testing, and integration problems. A formal process reduces chaos.

Issue Management vs Risk Management (Important Distinction)

• Risk: potential future event (not happened yet)
• Issue: current problem affecting progress

Exam questions sometimes test that you can respond differently:

• For risks: plan response before it happens
• For issues: resolve promptly with corrective actions

Procurement and Vendor Management (IT Reality)

Many IT projects rely on:

• software vendors,
• cloud providers,
• system integrators,
• consultants,
• hardware suppliers.

Vendor management includes:

• procurement planning
• vendor selection criteria
• contract management
• performance monitoring
• acceptance criteria and warranties

Procurement Types

Intro modules typically cover:

• Make or buy decision
• Request for proposal (RFP), request for quotation (RFQ)
• Evaluation criteria (price, capability, security, support)

IT example:
A university might buy a learning analytics platform. The procurement process must ensure:

• data privacy controls
• integration compatibility (APIs, identity management)
• support response times
• training and documentation

Agile Delivery in Execution: Sprints, Backlogs, and Working Software

Agile methods emphasize iterative delivery and feedback. Execution concepts include:

• Product backlog: prioritized list of features and requirements
• Sprint backlog: selected items for the current iteration
• Sprint planning: decide what to deliver in the sprint
• Daily stand-up: coordinate daily progress and blockers
• Sprint review: demonstrate working increment to stakeholders
• Sprint retrospective: improve team process

Metrics in Agile (Common Exam Mentions)

• Burndown charts (remaining work vs time)
• Velocity (historical throughput, used for planning)
• Defect trend
• Sprint goal attainment

Exam caution: Velocity is not “product quality.” It predicts capacity. Quality metrics must still be managed through testing and acceptance.

Monitoring in Agile: Handling Change Without Losing Control

Agile does not mean “no control.” It means control is adapted:

• Change can be incorporated via backlog refinement and prioritization.
• Scope changes are handled by adjusting backlog items, not by silent extra work.
• Governance remains through acceptance criteria, product ownership, and sprint goals.

Worked Scenario: Managing a Late Security Requirement

Imagine an IT project in week 5 of build. A compliance review identifies a new requirement: multi-factor authentication (MFA) for user access.

A good project response includes:

1. Submit a change request referencing compliance deadline.
2. Identify impacted components: authentication service, user UI flows, configuration scripts, testing scenarios.
3. Estimate impact:
   • additional development: 2 weeks
   • testing expansion: 1 week
   • possible infrastructure updates: additional 1 week for environment readiness (if required)
4. Decide:
   • sponsor accepts schedule impact
   • or adjust scope by deferring lower-priority features to later sprints
5. Update backlog and schedule baseline accordingly.
6. Communicate to stakeholders clearly.

This scenario demonstrates both execution and change control.

4. IT Project Management Tools and Techniques: Requirements, Documentation, Estimation, Risk Workshops, and Quality Traceability

Requirements Engineering for IT Projects

Requirements are the foundation of design, development, testing, and acceptance. Intro IT project management exams often assess whether you can describe requirement types and how they are managed.

Types of Requirements

• Business requirements: what the business needs to achieve (outcomes)
• User requirements: needs of specific user groups (tasks, workflows)
• Functional requirements: system behaviours (inputs → outputs)
• Non-functional requirements (NFRs): quality attributes (performance, security, usability, availability)
• Technical requirements: constraints related to architecture and interfaces

Exam emphasis: NFRs are often where IT projects fail if ignored. For instance, “the system must respond within 2 seconds” influences architecture and testing.

Requirements Traceability Matrix (RTM)

A traceability approach links:

• business requirements → functional requirements → design components → test cases → defects and acceptance results.

A simplified RTM row might look like:

• Requirement ID: FR-12 (user can reset password)
• Acceptance criteria: reset email sent within 10 seconds; tokens expire in 30 minutes
• Test cases: TC-34, TC-35
• Defects: none/recorded with severity

Why traceability matters:

• It supports impact analysis for changes.
• It reduces the risk of missed requirements.
• It demonstrates completeness for audits and acceptance.

Documentation That Often Appears in Exams

While IT projects are dynamic, there are documentation artefacts you should know:

• Project charter: purpose, objectives, sponsor authority
• Project management plan: how work will be executed and controlled
• Requirements specification: what must be delivered
• WBS and schedule: task breakdown and timeline
• Risk register: identified risks and response plans
• Quality plan: standards and testing approach
• Communication plan: who gets what information
• Change log: history of approvals and modifications
• Lessons learned report: closure output

An examiner might ask: “Which documents are updated when scope changes?” The expected response involves the scope baseline, change log, schedule/cost baselines, and traceability mapping.

Estimation Techniques in More Detail: Practical IT Estimation

Estimation in IT projects is difficult because software effort depends on complexity, dependencies, and team maturity.

Common practical drivers:

• integration complexity (number of external systems)
• data migration complexity (volume and data quality)
• security complexity (controls, testing requirements)
• requirement clarity (ambiguity causes rework)
• environment readiness (dev/test/prod parity)

A common exam scenario: if your estimates are wrong early, your baseline might become unrealistic. A good response includes:

• refine requirements early,
• use risk-based contingency,
• include buffers and explicit assumptions.

Risk Workshops and Probability/Impact Assessment

Risk identification can be enhanced by workshops. Techniques include:

• brainstorming with cross-functional team (dev + QA + business + operations)
• affinity diagrams (group risks by themes)
• interview-based discovery (especially for stakeholder-specific risks)

Probability and Impact Rating

A typical qualitative scale:

• Probability: Low (1), Medium (2), High (3)
• Impact: Low (1), Medium (2), High (3)

Then compute risk score:

• Risk score = probability × impact

Example:

• Risk “late stakeholder sign-off”: probability 3, impact 2 → score 6
• Risk “cloud provider outage”: probability 2, impact 3 → score 6
  Both are equally significant by score, so they require attention.

Risk Response Strategies (Avoid/Mitigate/Transfer/Accept)

Exams often expect you to describe each:

• Avoid: remove cause; redesign approach
• Mitigate: reduce probability or impact
• Transfer: shift risk to another party (insurance, vendor contract)
• Accept: acknowledge and manage with contingency plan

IT example:

• Avoid: if integration risk is extremely high, you may defer risky integration or replace with a simpler interface.
• Mitigate: build mocks and run contract tests early.
• Transfer: contract includes service level agreement (SLA) with vendor for uptime.
• Accept: if probability is low and cost to mitigate is too high, accept with contingency.

Quality Traceability and Test Design

A quality traceability approach means tests should be derived from requirements. For functional requirements, test design includes:

• happy path (expected correct behaviour)
• edge cases (boundary values)
• negative tests (invalid inputs)
• security tests (authorisation/access control)
• performance tests for NFRs (response time, throughput)

Example:
Functional requirement: “User cannot access admin dashboard without admin role.”
Test cases:

• Role-based access returns admin dashboard for admin
• Non-admin gets access denied
• Attempted direct URL access is blocked
• Audit log records access attempts

Non-functional requirement: “Admin dashboard loads within 2 seconds for 95% of requests.”
Test cases:

• performance test with realistic load
• verify response times and error rates

Lessons Learned: Turning Past Mistakes into Better Delivery

Lessons learned should cover:

• what went wrong and why
• what worked and should be repeated
• actions for the next project (process changes, training, better estimation practices)

A strong lessons learned entry should be:

• specific (not “communication was bad”)
• linked to a risk/issue root cause
• include corrective actions

5. Exam-Ready Practice: Answering IT00077 Questions Using Models, Checklists, and South African University Style Expectations (UJ College of Business & Economics)

How IT00077-Style Questions Are Typically Structured

While the exact exam format can differ by year, intro modules often include:

• short conceptual questions (define and differentiate)
• scenario questions (apply processes to a case)
• “choose the best option” multiple choice style
• structured responses (describe steps in sequence, justify decisions)

A high-scoring strategy is to:

1. Identify what concept the question targets (scope, risk, quality, change, stakeholders).
2. Provide a clear definition or framework.
3. Apply it to the scenario.
4. Conclude with an expected outcome or justification.

Quick-Reference Concept Checklist (Memorise for Short Questions)

Key Definitions (Must Be Crisp)

• Project: temporary, unique deliverable
• Stakeholder: person/group affecting or affected by project
• Scope creep: uncontrolled expansion of scope without time/cost adjustment
• Risk vs Issue: potential future vs current problem
• Quality assurance vs quality control: process prevention vs testing detection

Key Planning Outputs

• scope baseline, schedule baseline, cost baseline
• communication plan, quality plan, risk register

Key Monitoring/Control Activities

• track against baselines
• manage changes through change control
• update risk status and handle issues

Scenario Practice 1: Requirements Ambiguity Late in Development

Scenario: A team begins building after a brief requirements workshop. In week 6, users report that the system’s “reporting” does not match their expectation. The product owner requests new graphs and revised calculations.

What your answer should include:

1. Recognise this as requirements ambiguity and a likely scope and stakeholder expectation issue.
2. Use change control:
   • submit change request
   • perform impact analysis (schedule/cost/testing effort)
3. Use traceability:
   • map new needs to requirement IDs (or create new ones)
4. Quality and schedule response:
   • decide whether changes go into next increments/sprints or require timeline adjustment
   • prioritise based on business value and compliance constraints

Why this scores: It shows you understand that agile can accept change, but acceptance still requires formal handling (backlog updates, impact analysis, revised acceptance criteria).

Scenario Practice 2: Budget Overrun Caused by Infrastructure Delays

Scenario: Procurement for cloud services and environment provisioning takes longer than expected. Developers cannot start integration tests as planned. Actual costs increase due to idle time and additional contractor hours.

Answer structure:

1. Identify the root cause as a schedule risk that became an issue (environment readiness not available).
2. Monitor:
   • assess schedule variance and cost variance (if your course uses EVM logic)
3. Control:
   • adjust schedule dependencies
   • implement mitigation (use temporary mock environments, adjust test plan, re-sequence tasks)
4. Prevent recurrence:
   • improve procurement lead-time estimation
   • require environment readiness milestones earlier
   • update risk register for next project phase

Key exam phrase: “Update baselines if changes are approved; otherwise keep tracking deviations and manage corrective actions.”

Scenario Practice 3: Vendor Contract and Quality Acceptance

Scenario: A vendor delivers a security scanning tool, but results are inconsistent. The vendor claims “tool settings vary,” while internal QA claims acceptance criteria are not met.

Expected answer elements:

• Mention contract and acceptance criteria:
  • verify that acceptance tests reflect agreed settings and security requirements
• Quality approach:
  • QA (process to validate scanning standards)
  • QC (testing to validate outcomes)
• Governance:
  • issue log for inconsistencies
  • change control if configuration changes require baseline updates
• If unresolved:
  • escalation to sponsor/change board
  • potentially apply contractual remedies (service credits, replacement, additional support)

Why it matters: IT project management includes vendor management and acceptance discipline—not only internal development.

Scenario Practice 4: Choosing Predictive vs Agile for an IT System

Scenario: A municipality wants a system integration with stable APIs but evolving user workflows. The sponsor wants early benefits.

Answer:

1. Explain constraints:
   • stable integration interfaces favour predictive control
   • evolving workflows favour iterative delivery
2. Propose a hybrid approach:
   • predictive architecture and interface contracts
   • iterative development and user workflow increments
3. Link to quality and risk:
   • define acceptance criteria per increment
   • maintain traceability for requirements and tests
4. Stakeholder engagement:
   • require active product owner/user involvement during sprint reviews

Scoring justification: You show you can make a reasoned selection based on uncertainty, risk, and stakeholder availability—not just repeating textbook definitions.

Model Answers Using Structure (Use This Template in the Exam)

When asked “Discuss” or “Explain,” a robust structure is:

1. Definition/Framework (1–2 sentences)
2. Key Components (bullet list or short subpoints)
3. Apply to Scenario (tie to the case)
4. Outcome/Recommendation (what you would do next and why)

For example, in a scope question:

• Define scope
• Explain scope baseline and change control
• Apply to a case of new requirements arriving late
• Recommend formal change request and impact analysis

Common Mistakes That Lower Marks

• Confusing risk with issue
• Explaining Agile as “no documentation” (Agile still requires documentation relevant to acceptance and traceability)
• Only listing processes without applying them to the scenario
• Ignoring non-functional requirements (security/performance)
• Failing to mention baselines when asked about control and deviations
• Not addressing stakeholder expectations (e.g., sponsor approval, user acceptance)

South African University Exam Style: Clarity and Relevance

In South African university marking, clarity and relevance matter. Therefore:

• Use specific terms: scope baseline, risk register, change request, acceptance testing (UAT).
• Avoid generic phrases without consequences.
• Where possible, use an example mapping requirement → test → acceptance.

Worked Mini-Calculations (If Your Exam Includes Numbers)

Even if IT00077 is concept-heavy, you may get simple calculations.

Example: Risk Score

If probability scale is Low=1, Medium=2, High=3 and impact is Low=1, Medium=2, High=3:

• Risk: “User feedback delayed”
  • Probability = High (3)
  • Impact = Medium (2)
  • Risk score = 3 × 2 = 6

Then interpret:

• Score 6 means high priority within your qualitative grid—assign an owner and plan mitigation.

Example: Basic Schedule Reasoning

If task B depends on task A finishing:

• If A is delayed by 2 days, B’s start shifts by 2 days unless there is an overlap strategy or a parallel activity is possible.
• A good answer states dependency logic and mitigation options (mocks, partial testing, resequencing).

Final Revision Notes: The 10 “Must Know” Themes

1. Project vs programme vs portfolio
2. Predictive vs iterative delivery (and why both can be appropriate)
3. Stakeholder roles and engagement
4. Scope statement and scope baseline
5. WBS decomposition and why it improves estimates
6. Scheduling logic: dependencies and realistic sequencing
7. Budget categories and estimation methods
8. Quality assurance vs quality control; testing layers and UAT
9. Risk management lifecycle and risk response strategies
10. Change control discipline and difference between risk and issue

Quick Study Plan (One-Week Revision Approach)

If you have a short revision period, a balanced schedule is:

• Day 1: Foundations, stakeholders, project life cycle, governance
• Day 2: Scope and requirements; WBS basics; acceptance criteria
• Day 3: Scheduling and budget; estimations and dependencies
• Day 4: Quality management and test strategy; traceability
• Day 5: Risk management; risk register; response planning
• Day 6: Execution and monitoring; communication; change control
• Day 7: Practice scenarios; answer framework template; review common mistakes

Consistent Exam Takeaway

To succeed in IT00077: Introduction to IT Project Management at the University of Johannesburg (UJ), College of Business & Economics, focus on the “exam trifecta”: structured frameworks, correct terminology, and scenario application. When writing answers, always connect concepts to deliverables, governance decisions, and measurable outcomes—because in IT projects, quality and acceptance are as important as schedule and budget.