Fundementals of Project Management Theory & Practice Course Notes (Wits Plus)

Project management is both a theory-driven discipline and a practice-heavy craft: students must understand frameworks (like the triple constraint, stakeholder theory, and life-cycle models) while also being able to apply them to planning, controlling, and delivering real outcomes. These exam notes align with the expectations commonly seen in South African universities—particularly Wits—where short, specialised project management courses emphasize both concepts and “show-your-work” application. This guide is written for students studying Wits University Project Management Short & Specialised Courses Notes (Wits Plus) and is designed to support exam preparation and assignment-level competence.

Wits University Focus: Foundations of Project Management Theory & Practice (Wits Plus)

Wits-aligned project management teaching typically blends formal knowledge (process groups, methodologies, governance structures) with applied decision-making (scope control, risk responses, scheduling logic, and stakeholder communications). To do well in exams, you generally need to demonstrate that you can:

define and justify key terms; 2) explain why certain methods are used; and 3) apply those methods to a scenario.

A useful way to structure your understanding is to treat project management as a system: inputs (requirements, constraints, assumptions), tools and techniques (planning, analysis, estimation), outputs (plans, baselines, deliverables), and feedback loops (monitoring and controlling).

What Makes a “Project” Different From Work?

Many exam questions begin with the distinction between a project and operations. In operations, work is repetitive and ongoing; in projects, work is temporary, created for a specific purpose, and ends when objectives are achieved or the project is terminated.

A project typically has:

A defined start and end (even if end dates change)
A specific objective (deliverable-based or outcome-based)
A unique deliverable (something distinct from routine work)
Constraints on cost, time, scope, and quality
Cross-functional effort (multiple disciplines cooperating)

A common exam trap is to confuse “temporary” with “small.” A project can be large and still be temporary. Temporary describes the nature of work being established for a goal, not the scale.

Example (Applied)

A retail chain launches a new store in Johannesburg:

Operations: ongoing store trading, supply replenishment, daily staff rosters.
Project: building the store, setting up systems, training for go-live, launching marketing for opening day.

Even though the store will later operate indefinitely, the launch activities are a project.

The Triple Constraint and the Project Management “Trade Space”

A core theory in project management is the triple constraint—often described as:

Scope (what you will deliver)
Time (when you will deliver)
Cost (how much you will spend)

Quality is sometimes treated as a fourth dimension, because scope/time/cost choices inevitably affect quality.

Why This Matters in Exams

Examiners often ask you to explain a problem using the triple constraint, for example:

“If time is reduced, what happens to cost or scope?”
“Why is scope creep risky to budget and schedule?”

Counter-Argument / Nuance

Students sometimes oversimplify the triple constraint into “always trade scope for time.” In reality:

Sometimes scope is fixed and time slips (delays)
Sometimes time is fixed and scope is reduced (value engineering)
Sometimes cost is fixed and scope is adjusted or phasing is required
Sometimes the project uses buffering and risk response to preserve all three temporarily

You should explain that trade-offs depend on governance and contract structures, not just “logic.”

Project Life Cycle Models: Predictive vs Adaptive

A project life cycle describes how work progresses from initiation to closure. Two dominant “families” frequently appear in courses:

Predictive (Plan-Driven): heavy upfront planning; changes are controlled.
Adaptive (Agile/Iterative): planning and learning occur in cycles; changes are expected.

Some courses frame this as “traditional vs agile,” but exams often look for understanding of when each fits.

Predictive Characteristics

Clear requirements upfront
Baselines (scope, schedule, budget) are established early
Change control is formal
Suitable when work is stable and requirements are measurable

Adaptive Characteristics

Requirements evolve or are not fully known at the start
Deliveries happen in increments (sprints, iterations)
Frequent stakeholder feedback reduces uncertainty
Suitable when learning is required or customer needs change

Example Scenario (South African Context Style)

A municipal water infrastructure project:

If design standards are stable and environmental conditions are known, predictive approaches can work.
If soil conditions vary significantly and testing reveals new constraints mid-way, adaptive elements (iterative design refinement, phased execution) may reduce risk.

Governance: How Projects Get Approved, Controlled, and Closed

Governance is the “decision structure” surrounding project work. Strong governance prevents projects from becoming unmanaged “activity streams.”

Typical governance elements:

Project sponsor: authorises resources and resolves escalation issues
Project manager: responsible for day-to-day execution planning and control
Steering committee / project board: oversight, strategic decisions
PMO (Project Management Office): standards, portfolio management, reporting
Contract governance (for vendor-led work): service levels, acceptance criteria

What Examiners Like

They want you to connect governance to outcomes:

governance ensures the project remains aligned to organisational strategy;
governance creates mechanisms for change approvals;
governance defines acceptance and closure.

Stakeholders and Power-Interest Theory

Stakeholders are individuals or organisations affected by the project or able to influence it. In Wits-style short courses, stakeholder analysis is often assessed through:

identifying stakeholder groups,
classifying them based on interest and influence,
proposing engagement strategies.

A common model is Power–Interest:

High power / high interest: manage closely; keep satisfied
High power / low interest: keep informed; minimal effort
Low power / high interest: keep informed; maintain communication
Low power / low interest: monitor; provide occasional updates

Example

For a university-managed redevelopment:

Students: high interest, usually moderate influence
Facilities department: moderate interest, higher influence
External contractor: influence and direct operational power (high power)
Regulators: high power, low interest during early work (often), but can become critical later

Your engagement plan should reflect these roles.

Counter-Argument / Nuance

Not all projects have clear “high” and “low” power at all times. Power can shift:

when a procurement decision is made,
when design approvals are required,
when community concerns escalate.

Therefore, stakeholders should be re-assessed during the project.

Project Management Knowledge Areas: A Practical Map

Even if your course uses different terminology, exams often expect familiarity with widely used structure. The most recognised structure divides project management into knowledge areas such as:

Integration management
Scope management
Schedule management
Cost management
Quality management
Resource management
Communications management
Risk management
Procurement management
Stakeholder management

In practice, you rarely treat these areas independently. For instance, schedule compression affects cost, which affects quality, which impacts acceptance and stakeholder satisfaction.

Integrated Example (Mini Case)

Suppose a company wants to launch a new customer portal by 30 September.

Scope: features list A, B, C.
Schedule: compressed to 10 weeks.
Cost: must be capped because of budget constraints.
Quality: performance testing becomes risky with reduced time.
Stakeholders: customers and finance department expect reliable data.

Integration management means you identify conflicts early and make decisions—such as revising scope to ensure quality is not compromised.

Deliverables, Milestones, and Acceptance Criteria

Exams often test your ability to define deliverables clearly. A deliverable is a tangible output (document, software module, constructed element). A milestone is a significant event—often marking progress, approval, or completion of a phase.

Acceptance criteria define what “done” means. Without acceptance criteria, disputes arise.

Example (Deliverable with Criteria)

Deliverable: “Training manual”

Must cover topics: user onboarding, password resets, role-based access
Must include screenshots and version number
Must be approved by the training coordinator
Must be delivered in PDF format
Must be in line with the final user interface version released on 15 August

Because criteria are explicit, quality control and sign-off become measurable.

Planning Foundations: Baselines, Assumptions, and Constraints

A baseline is a reference plan against which performance is measured. A schedule baseline, cost baseline, and scope baseline support control.

Assumptions and constraints must be written down:

Assumptions: “Client will provide access to data by 10 June.”
Constraints: “Budget cap is R 800,000; only weekdays work can be scheduled.”

Why this matters:

If an assumption fails, you may need corrective action (replanning).
If constraints are violated, you often need formal governance approval.

A strong exam response typically:

lists assumptions/constraints,
explains how they affect the plan,
suggests a control method (e.g., change requests, monitoring).

Closing the Project: Not Just “Finishing”

Project closure includes:

final acceptance and sign-off,
documentation completion,
handing over deliverables,
contract closeout (if applicable),
post-project review and lessons learned.

Closure is where many “hidden marks” exist in exams. Students sometimes omit:

how the organisation transitions deliverables into operations,
how risks that linger are handed over,
how performance is evaluated against objectives.

Example

A software project delivers a portal:

Closing includes training the operations team,
transitioning monitoring scripts,
archiving source code repositories,
ensuring support documentation is delivered,
confirming system readiness for real customers.

Project Planning and Control in Practice: Scope, Schedule, Cost, and Risk (Applied Wits-Style Exam Skills)

The exam focus in many South African project management courses is the ability to apply planning and control tools to realistic problems. This section builds practical competence in scope management, scheduling logic, costing approaches, and risk processes—using scenario-based reasoning.

Scope Management: From Requirements to Work Packages

Scope management aims to define and control what is included in the project. Good scope management prevents “scope creep,” ensures deliverables align with requirements, and clarifies ownership and boundaries.

Scope Planning Components

Key elements frequently expected in exam answers:

Requirements: what stakeholders need and the project must satisfy
Product scope: features and functions of the deliverable
Project scope: the work required to produce the deliverable
Work Breakdown Structure (WBS): decomposition of work into manageable pieces
Scope baseline: agreed scope used for change control

WBS: Why It’s More Than a Diagram

A WBS breaks the project into work packages that can be:

assigned to teams or individuals,
estimated (time/cost),
scheduled,
monitored for progress,
audited for completeness.

A common mistake: making a WBS that only lists deliverables but not enough work packages to plan and estimate. Exams often award marks when you show a WBS that supports estimation and control.

Example WBS (Conceptual)

Project: “Build an e-library website for a university”

1. Project Management
- 1.1 Governance setup
- 1.2 Weekly reporting
1. Requirements
- 2.1 Stakeholder interviews
- 2.2 Requirements documentation
1. Design
- 3.1 Information architecture
- 3.2 UI prototypes
1. Development
- 4.1 Backend development
- 4.2 Frontend implementation
1. Testing and Training
- 5.1 Test plan
- 5.2 User training sessions
1. Go-Live
- 6.1 Deployment
- 6.2 Handover documentation

Each work package can later be mapped to cost and schedule.

Change Control: Scope Creep vs Legitimate Change

Scope creep is unmanaged growth of scope without agreed approval. Legitimate change control exists because projects learn and conditions evolve. Exams often test whether you understand the difference.

A good change process includes:

Change request submitted (what/why)
Impact assessment (scope, time, cost, quality, risk)
Review by governance
Approval/rejection
Baseline updates (if approved)
Communicate changes to stakeholders

Example (Impact Assessment)

A stakeholder requests an additional feature: “advanced search filters.”

Scope impact: + new feature module
Schedule impact: may add 5 days development + 3 days testing
Cost impact: add developer time and testing resources
Risk impact: increased complexity increases defect risk

If governance rejects or negotiates, scope baseline remains controlled.

Schedule Management: Activity Sequencing, Estimation, and Critical Path

Schedule management focuses on building a schedule that is credible, resourced, and controllable. The key exam topics usually include:

Activity definition: breaking work into tasks
Sequence: dependency logic (finish-to-start, start-to-start, etc.)
Resource estimation: who/what supports each activity
Duration estimation: how long each activity takes
Schedule development: integrating tasks into a plan
Schedule control: monitoring progress and forecasting

Dependencies: The Hidden Driver of Project Reality

Dependencies often determine whether a schedule is realistic. Common dependency types:

Finish-to-Start (FS): predecessor must finish before successor starts
Start-to-Start (SS): successor can start when predecessor starts (overlap possible)
Finish-to-Finish (FF): successor must finish when predecessor finishes
Start-to-Finish (SF): rare, usually not practical in normal planning

Critical Path (CPM Concept)

The critical path is the longest sequence of dependent activities that determines project duration. Activities on the critical path have little slack (or no float). Delays there usually delay the entire project unless mitigation actions occur.

Scenario (Reasoning Example)

If Activity B (database setup) delays, activities that depend on it (testing) delay too. If testing is on the critical path, the completion date shifts unless additional resources accelerate.

Time-Estimation Methods: Deterministic vs Probabilistic Thinking

Some courses teach:

Top-down estimates (use historical analogies quickly)
Bottom-up estimates (sum detailed work package costs/durations)
Analogous estimation (use similar past projects)
Parametric estimation (use formulas like cost per function point or cost per square meter)
Three-point estimation (probabilistic: optimistic, most likely, pessimistic)

Exams may ask you to choose which method fits given data maturity.

Three-Point Estimation (Probabilistic)

If you have:

optimistic time (a)
most likely time (m)
pessimistic time (b)

You can compute an expected duration using the PERT-style logic:

expected time ≈ (a + 4m + b) / 6

Examiners reward if you also explain:

why uncertainty exists (requirements, dependencies, resource availability),
how you manage it (buffers, risk responses).

Cost Management: Budgeting, Estimation, and Control

Cost management includes:

cost estimation
budgeting
cost control

Estimating Costs: What Goes Into “Cost”?

Cost may include:

labour (hours × rate)
materials
equipment
subcontractors
travel
contingency (for identified risk or general uncertainty)

A common exam question is: “Explain the difference between cost estimate and budget.”

Estimate: calculated expected cost (may include uncertainty)
Budget: approved spending plan that becomes a baseline

Example (Simple Arithmetic Logic)

Suppose a project has:

Labour estimate: R 500,000
Materials: R 120,000
Subcontractor: R 80,000
Total estimate before contingency: R 700,000
Contingency: say R 70,000 (10%)

Budget baseline: R 770,000

Then, cost control monitors whether actual spending plus forecasts align with the baseline.

Earned Value Management (EVM) Foundations (When Taught)

Many project management courses include basic EVM or at least the idea of measuring performance by comparing:

Planned Value (PV): what you planned to accomplish by a time
Earned Value (EV): what you actually accomplished in terms of budgeted value
Actual Cost (AC): what you spent

Then calculate:

Schedule Variance (SV) = EV − PV
Cost Variance (CV) = EV − AC

Exams may ask you to interpret results. But the best responses also note limitations:

EVM requires consistent measurement of “earned value” and careful selection of measurement criteria.

Quality Management: Preventing Rework and Protecting Acceptance

Quality management ensures the deliverable meets stated requirements and stakeholder expectations. Quality is not “luxury”—it is a risk control mechanism.

Common concepts:

Quality planning: standards and acceptance criteria
Quality assurance: processes and audits to ensure the quality plan is followed
Quality control: inspection/testing to confirm deliverable meets criteria

Example (Quality Control in Construction Style)

A building project includes:

concrete strength tests at specified intervals,
inspection of materials (certificates),
compliance checks against building codes,
snag lists near completion.

If quality control identifies issues late, rework becomes more expensive and schedule slips.

Risk Management: Identify, Analyze, Respond, Monitor

Risk management is a structured response to uncertainty. A “risk” is not the same as an “issue.”

Risk: possible future event that may affect objectives (upcoming uncertainty)
Issue: current problem already affecting the project

Risk Process Steps (Exam-Friendly)

Plan risk management: define approach and risk methodology
Identify risks: use workshops, checklists, expert judgement
Perform qualitative analysis: assess probability/impact
Perform quantitative analysis: model numerical impacts (where needed)
Plan risk responses: strategies and actions
Implement responses
Monitor and control risks

Response Strategies

Avoid: eliminate the threat
Mitigate: reduce probability or impact
Transfer: shift responsibility (insurance, contracts)
Accept: recognise risk without active response (with contingency planning)

For opportunities:

Exploit (ensure it happens),
Enhance,
Share,
Accept.

Example Risk Register (Conceptual Table)

Risk ID	Risk Description	Category	Probability	Impact	Response Strategy	Owner
R1	Client delays provision of data extracts	Scope/Requirements	Medium	High	Mitigate: data mock-ups; schedule data workshops	Data Lead
R2	Contractor material shortages	Procurement	Low	Medium	Transfer: supplier contract clauses	Procurement Manager
R3	Software defects discovered late	Quality/Technical	Medium	High	Mitigate: early test cycles; automated regression	QA Lead

Exams value risk ownership and response actions that are concrete.

Integrating Scope, Schedule, Cost, Quality, and Risk

In real projects, these systems interact. A schedule acceleration plan often increases risk or costs. Scope additions can reduce schedule slack. Quality improvements can increase costs but reduce rework.

Example (Integrated Decision)

A team is behind schedule by 2 weeks. Options:

Add more developers (cost up; risk of coordination issues rises)
Reduce scope (scope down; possibly changes stakeholder value)
Extend schedule (time up; potential penalties/contract risks)
Improve quality to prevent rework (cost up but may stabilise schedule)

A mature project manager explains trade-offs and selects actions based on constraints and governance priorities.

Communications Planning: Keeping Control Through Information

Communications management ensures stakeholders receive the right information at the right time in the right format. Poor communication leads to misunderstandings and “invisible drift.”

Common artefacts:

communication matrix (stakeholders vs information needed),
status reports,
risk reports,
meeting agendas and minutes,
decision logs.

Example (Meeting Cadence)

Weekly project team stand-up: operational progress and blockers
Bi-weekly steering committee: KPI reporting, decisions needed
Monthly sponsor review: alignment to strategic objectives

Exams can ask “why frequency matters.” High uncertainty may require more frequent updates.

Stakeholder Engagement, Procurement, and Contract Practice (Project Management in Real Organisational Contexts)

Project management theory becomes meaningful when applied to organisational realities—especially stakeholder influence and procurement/contract work. This section focuses on engagement practices, ethical and practical contracting, and the mechanics that keep projects legally and operationally stable.

Stakeholder Engagement: Communication Plans and Influence Management

A stakeholder engagement plan maps how you interact with each stakeholder group. It is closely linked to:

stakeholder analysis (power/interest),
messaging strategy (what to say),
channels (email, meetings, dashboards),
timing (when decisions affect them),
feedback loops (how issues are escalated and resolved).

Engagement Objectives

Different stakeholders need different “wins”:

Sponsor: strategic alignment, budget confidence, governance compliance
End-users: usability, functionality, training and support readiness
Regulators: compliance, documentation, audit trails
Vendors: scope clarity, payment terms, acceptance requirements

Example (Engagement Strategy for a Student-Focused Project)

Project: e-library upgrade for a university.

Students: high interest in access speed and search features
Academic staff: high interest in content categories and metadata
IT department: moderate-high influence on architecture and security
Library administrators: high interest in cataloguing workflows

Engagement plan might include:

user testing sessions each sprint,
change communication when metadata fields change,
IT security approvals early,
training workshops before go-live.

Managing Stakeholder Expectations: “Requirements” vs “Wants”

A common exam scenario is stakeholder misalignment. Requirements are explicit needs agreed for acceptance; wants are desires that may not be feasible within constraints.

A good project manager:

elicits and documents requirements,
translates wants into requirement statements,
validates feasibility,
negotiates scope trade-offs using governance.

Counter-Argument / Nuance

Sometimes stakeholders do not know what they want until they see prototypes. In such cases:

adaptive planning is useful,
iterative delivery reduces rework,
but you still need acceptance criteria and change governance to avoid endless churn.

Procurement Management: Buying vs Building

Procurement occurs when work is outsourced to external suppliers. This adds contractual complexity to project control.

Key exam topics include:

procurement planning (make-or-buy decisions),
bid evaluation criteria,
contract types (fixed price vs time and materials),
statement of work (SOW),
acceptance and performance measurement.

Make-or-Buy Logic

Projects may decide to:

build in-house (control and capability),
buy/contract (speed and specialised expertise),
hybrid (core in-house, supporting work outsourced).

Exam responses should connect make-or-buy choices to:

organisational capacity,
time constraints,
risk,
quality requirements.

Contract Types: Why Pricing Structure Matters

While exact contract classification can vary across institutions, exams commonly test basic differences:

Fixed-price (lump sum)
- Contractor bears more risk for cost overrun.
- Buyer bears risk if requirements change and scope is unclear.
Time and materials (T&M)
- Buyer bears more risk of cost overruns.
- Useful when scope is uncertain.
Cost-plus (where applicable)
- Often used for specific contexts; may include incentives.

Example (Choosing a Contract Type)

If a project requires detailed requirements known early, fixed-price can work. If requirements are evolving (e.g., R&D or iterative software with uncertain scope), T&M with strict reporting may be more appropriate.

Statement of Work (SOW) and Scope Clarity

A good SOW includes:

objectives and background,
deliverables and acceptance criteria,
schedule and milestones,
service levels (if ongoing),
roles and responsibilities,
reporting and documentation requirements,
constraints and assumptions.

Exams frequently test “what happens if SOW is vague.”

disputes,
rework,
delayed acceptance,
cost growth.

Supplier Management: Performance Monitoring

Procurement doesn’t end after awarding a contract. You monitor:

deliverable quality,
schedule performance,
compliance (health and safety, quality standards),
reporting accuracy,
change control procedures with suppliers.

Example (Performance Reporting)

Supplier provides weekly progress reports
Buyer performs monthly audits
Penalties/credits apply if service levels not met (where contract includes such clauses)

Ethical Practice and Risk in Procurement

Procurement risks include:

conflicts of interest,
bribery or improper tendering,
poor contractor capability,
collusion,
corruption.

Even short courses expect a basic understanding:

procurement must be transparent,
evaluation criteria must be pre-defined,
decisions must be documented.

Your exam responses should show “process integrity” rather than only technical procurement.

Transition and Handovers: Closing Procurement Work Properly

When vendors deliver a product/service, the project must:

validate deliverables,
ensure compliance,
obtain acceptance sign-off,
close contract obligations.

This affects project closure and post-project support readiness.

Exam Practice and Integrated Case Scenarios: Applying Theory to Solve Problems

This final section provides exam-focused synthesis: how to structure answers, how to apply frameworks to scenarios, and how to avoid common mistakes. It includes integrated case scenarios covering scope/time/cost/risk/stakeholders/procurement logic.

How to Structure High-Scoring Exam Answers

South African university exams (including Wits short-course formats) often reward structure more than memorised definitions. Use a repeatable approach:

Identify what the question asks
- Define? Explain? Apply? Compare? Recommend?
Use the right framework
- triple constraint, stakeholder power/interest, risk response strategies, change control steps, life cycle model fit.
Apply to the scenario with specifics
- reference facts in the case, not generic statements.
Justify trade-offs
- show why your recommendation works given constraints.
Propose a concrete next step
- deliverable, meeting, approval process, register update, schedule baseline action.

Common Mistakes That Lose Marks

Describing processes without explaining relevance to scenario
Giving only definitions, not application
Ignoring acceptance criteria (quality and sign-off become vague)
Failing to link costs to schedule decisions
Recommending “more work” without resource and dependency logic

Integrated Case Scenario 1: Community Health Outreach Project

Scenario:
A non-profit organisation is running a community health outreach project in Gauteng. The sponsor requests a rapid rollout by 30 September 2026. The project team has limited budget and a tight schedule. Stakeholders include local clinic managers, community leaders, and partner NGOs that will provide staff and transport. Early planning reveals that appointment scheduling for clinics is often delayed, and supplier availability for medical supplies is uncertain.

Task A: Identify key project risks and responses

Possible risks:

Clinic scheduling delays (probability: medium, impact: high)
- Response: mitigate by booking buffer capacity and establishing escalation protocols with clinic managers.
Medical supply shortages (probability: low-medium, impact: high)
- Response: transfer via supplier contracts or maintain alternative suppliers.
Staff availability challenges from partner NGOs (probability: medium, impact: medium-high)
- Response: mitigate by confirming staffing commitments earlier and building backup staffing.
Community misinformation causing low attendance (probability: medium, impact: medium)
- Response: exploit by enhancing community engagement and using tested communication channels.

You should present them in a risk register form and attach owners (e.g., Logistics Lead for supplies, Community Liaison for engagement).

Task B: Describe scope control to prevent scope creep

Scope creep might occur if clinic managers request additional screenings not planned initially.

A strong answer includes:

define scope baseline: list deliverables (e.g., number of screening sessions, types of screenings)
create acceptance criteria for sessions (what constitutes completion)
implement formal change requests: clinic requests must be assessed for schedule and cost impact
update baselines and communicate decisions

Task C: Suggest a stakeholder engagement strategy

Stakeholders:

Clinic managers: high interest, moderate-high influence
- engage closely; confirm scheduling and acceptance criteria
Community leaders: high interest, influence over attendance
- manage closely; provide updates and credible communications
Partner NGOs: operational influence over staff supply
- manage through procurement/contract-like agreements: staffing commitments and reporting cadence

Your engagement plan might include:

weekly coordination calls with clinic managers during execution weeks,
a two-week lead confirmation for NGO staff deployment,
a community briefing session before each rollout.

Integrated Case Scenario 2: University IT Upgrade and Procurement

Scenario:
A university needs to upgrade its student portal to improve performance. The IT department requests enhanced security controls. The project manager decides to contract a third-party developer because internal capacity is limited. Requirements are not fully stable at the beginning: new security needs emerge after penetration testing. The sponsor wants a stable release date and expects weekly progress reporting.

Task A: Choose life cycle approach (predictive vs adaptive)

Because requirements evolve after security testing, the project benefits from an adaptive/iterative approach:

initial predictive planning for governance, architecture baseline, and minimum viable security controls
adaptive iterations for feature development, with security testing embedded in each iteration

A good exam answer states that hybrid life cycles are common:

“predict where you can, adapt where you must.”

Task B: Explain contract strategy given evolving requirements

Because scope is uncertain:

time and materials can be appropriate, provided reporting is strict and change control exists
alternatively, fixed-price can be used for defined modules with clear acceptance criteria, while the evolving security improvements are handled via separate change orders

Your justification should mention:

how to define deliverables to reduce disputes,
how acceptance criteria and change procedures protect both parties.

Task C: Build a communications plan

Sponsor expects weekly updates:

weekly progress report (progress vs baseline, risks, decisions needed)
dashboard metrics (e.g., completed user stories, defects status, security scan outcomes)
steering committee monthly or bi-weekly for baseline changes and release approvals

Also communicate to end-users:

planned maintenance windows
user training materials timing
support readiness before go-live

Integrated Case Scenario 3: Construction-Adjacent Facility Renovation

Scenario:
A university department plans to renovate a laboratory space. The project includes renovations, procurement of equipment, and staff training for new equipment usage. Constraints:

budget is capped,
work can only happen on weekends due to teaching schedules,
quality acceptance requires compliance documents and inspections.

Task A: Use WBS to show scope definition

Your WBS should include at least:

management and governance,
design/approvals,
demolition and build tasks (scheduled around weekend access),
equipment procurement and installation,
compliance inspections,
training,
handover and closure documentation.

Explain that WBS supports:

scheduling around weekend constraints,
accurate cost estimation for each work package,
quality control (each package has checklists/acceptance).

Task B: Schedule logic with dependencies

Weekend-only access introduces dependency and resource constraints:

demolition must happen before build
electrical installation before equipment mounting
compliance inspection before commissioning
training requires equipment installed and verified

Even without numeric durations, show dependencies and why schedule realism matters.

Task C: Risk management

Key risks:

contractor access issues leading to schedule slippage,
safety compliance delays,
equipment delivery delays,
training readiness issues if equipment is not operational.

Responses:

mitigate with alternative suppliers, early booking of inspections,
transfer some procurement risk via supplier clauses,
accept with contingency only if governance allows.

Integrating It All: A Model “Top Answer” Checklist

When facing any exam case, ensure your response covers:

Scope: deliverables, WBS, acceptance criteria
Schedule: dependencies, critical path reasoning, buffers
Cost: estimate-to-budget logic, contingency use
Quality: assurance and control actions
Risk: register, probabilities/impacts, response strategies
Stakeholders: engagement plan based on power/interest
Procurement: SOW clarity, performance monitoring, acceptance sign-off
Integration: how decisions update baselines and are communicated

Examiners typically want both “what” and “why,” and at least one “how” action step.

Revision Prompts (For Exam Readiness)

Use these prompts to test yourself without notes:

Explain the difference between a risk and an issue. Provide an example of each in a project context.
Describe how scope creep impacts schedule and cost, and outline a change control procedure.
Why do dependencies matter in scheduling? Give an example of a dependency type and consequences of delay.
What is the critical path and why does it matter for schedule control?
How do stakeholder engagement strategies differ for high-power vs low-power stakeholders?
What procurement failures commonly cause project disputes, and how can SOW acceptance criteria prevent them?
Provide a brief integrated plan for a scenario: define, schedule, cost, quality, risk, communications, procurement, and closure actions.

Final Consolidation: Theory to Practice Without Losing Marks

To score well in project management theory-and-practice exams, the key is to show competence in application. Definitions are necessary, but the exam signal is clearer when you:

connect theory to decision-making,
provide structured steps,
use scenario facts,
and demonstrate an integrated view of trade-offs under constraints.

This approach reflects how real project managers operate: they don’t simply “follow a method.” They use methods as reasoning tools inside governance systems, to deliver measurable outcomes while managing uncertainty and stakeholder expectations.