MS Project Workshop for Wits Specialised PM Course Notes (Wits Plus)

This guide consolidates practical Microsoft Project (MS Project) workshop knowledge tailored to the Wits University Project Management Short & Specialised Courses Notes (Wits Plus) collection. It is written in an exam- and assignment-ready style, linking core MS Project techniques to the typical thinking, planning, and reporting expected in Wits specialised PM modules. You’ll learn how to build, calibrate, and defend project schedules—complete with resource planning, critical path analysis, baselines, and progress reporting—using realistic scenarios aligned with university coursework.

MS Project Workshop Essentials for Wits Specialised PM: Building Schedules That Survive Assessment

A recurring challenge in project management education is that students can create “a schedule,” but struggle to create a schedule that communicates control. In a Wits-style specialised PM context, marking often rewards the ability to: (1) structure work logically, (2) estimate durations credibly, (3) sequence activities correctly, (4) handle resources and constraints responsibly, and (5) produce reports that match project governance expectations. MS Project is the tool that makes these ideas concrete.

Understanding the MS Project Model (Activities, Links, Calendars)

MS Project is not just a Gantt chart generator. It is a model with rules. Your plan will behave differently depending on whether you use activity links, logic-driven scheduling, and correct calendars.

Start with three foundational concepts:

Activities (tasks) are work items—planned units with durations and sometimes costs.
Links (dependencies) define sequencing logic—finish-to-start (FS), start-to-start (SS), etc.
Calendars define working time rules—what counts as “a working day” and when.

A schedule that “looks right” but uses inconsistent assumptions can fail in exam questions. For example, if you link tasks in a way that implies working days while your calendar has different working patterns, the dates will shift. In graded assessments, those shifts can be interpreted as poor planning discipline.

Example: Scheduling a Procurement Cycle

Consider a project for a department at a South African university to procure learning materials and set up training sessions. You might create activities like:

Draft procurement specification (5 working days)
Source quotations (10 working days)
Evaluate suppliers (3 working days)
Place order (2 working days)
Deliver materials (15 working days)

If you mistakenly set the calendar to work weekends, delivery may appear earlier. Conversely, if your calendar excludes public holidays but your durations were estimated assuming those holidays exist, you may underestimate the timeline.

Defining Project Start and Working Time

Your Project Information settings determine the baseline of the entire schedule. For Wits-related coursework, you’re often expected to apply disciplined scheduling assumptions rather than default settings.

Use the typical approach:

Choose project start date (e.g., Monday morning in a realistic timeframe).
Set the default calendar to match the organisation context.
Add any non-working days relevant to the schedule period (public holidays, shutdown periods, exam weeks if the scenario calls for it).
Use consistent time units: MS Project usually works with minutes/hours/days based on settings.

Scenario: University Shutdown Week

Suppose your project runs across a period that includes a university shutdown where no work can happen. If you fail to mark that period as non-working, MS Project will allocate work and produce an overly optimistic duration. In exam answers, you can be asked to “identify scheduling errors” or “explain why the finish date is earlier than expected.” Calendar discipline prevents that.

Creating Activities: Task Types, Durations, and Constraints

When you build tasks in MS Project, you choose how they behave. The key task distinctions are:

Fixed Duration: the task’s duration remains constant; dates move based on logic.
Fixed Work: the task’s work stays constant; duration may vary if resources change.
Fixed Units: the resource units stay constant; work and duration can vary.

Your course context often expects you to recognise that task durations are not always “true time” if resource allocations change.

Durations: Working vs Elapsed Time

MS Project can show tasks as working duration by default (i.e., days that count only working time). This matters for exam-style questions where you might need to interpret whether “7 days” means calendar days or working days. If a scenario says “materials delivery takes 7 calendar days regardless of work schedule,” that suggests elapsed time.

Task Structure: Summary Tasks and Work Packages

MS Project allows summary tasks (groupings) that reflect hierarchical work breakdown. In university planning tasks, summary tasks often align with the idea of work packages under a WBS.

A typical Wits PM approach emphasises:

Summary tasks for phases (e.g., Planning, Procurement, Implementation)
Subtasks for deliverables (e.g., supplier evaluation, training preparation)
No “lumped activities” that hide logic or accountability

A schedule with only a few huge tasks can be challenged in grading because it lacks planning detail needed for monitoring and resource control.

Task Sequencing: Dependencies and Logical Links

Dependencies are the engine of schedule reasoning. The most commonly used link type is:

Finish-to-Start (FS): a successor cannot start until predecessor finishes.

Other types exist:

Start-to-Start (SS): successors can start after predecessors start.
Finish-to-Finish (FF): successors can finish when predecessors finish.
Start-to-Finish (SF): rare in practice; may be used in special cases.

In assessment contexts, you may be asked why a successor task is delayed in the schedule. Typically, the answer is: because the dependency is wrong (FS vs SS), or because a constraint is overriding scheduling logic.

Constraints: When to Use Them (and When Not To)

Constraints can “lock” dates and override MS Project’s scheduling model. Common constraints include:

As Soon As Possible (ASAP) (usually recommended for flexible planning)
As Late As Possible (ALAP) (for certain delay-sensitive setups)
Must Start On / Must Finish On (locks a date)
Finish No Later Than / Start No Earlier Than (semi-flexible)

A typical marking expectation: use constraints sparingly and justify them. If everything is set to “Must Start On” dates, the schedule becomes manual rather than logic-driven. That can be considered weak project control practice.

Counter-Argument: Constraints Can Be Necessary

Students sometimes argue that constraints should always be avoided. The nuanced approach is:

Avoid constraints when you can rely on logic and calendars.
Use constraints when there is an external rule that truly fixes time (e.g., a venue booking, a regulatory deadline, a fixed delivery window).

The assessment strength is not “never use constraints,” but “use them only when there is a credible external time reason.”

MS Project Workshop for Wits Specialised PM: Resource Planning, Critical Path, and Baselines That Support Governance

Once your schedule has logic, the next workshop-level skill is building a plan that includes resources and produces a timeline you can defend. Many learners focus on the Gantt chart but neglect the analysis layers that demonstrate control: critical path, baseline comparison, and resource levelling.

Resource Types and Resource Assignment

In MS Project, resources can include:

Work resources (people, teams)
Material resources (items with costs and usage)
Cost resources (no work; costs incurred)

For a Wits-aligned specialised PM scenario (e.g., project implementation for a university initiative), the most common are work resources: project manager, project coordinator, trainer, procurement officer.

Building a Simple Resource Pool

Create a resource list with realistic names and unit allocations. For example:

PM (Project Manager)
BA (Business Analyst)
Procurement Officer
Trainer
Admin Assistant

When you assign a resource to a task, MS Project calculates scheduling based on work, duration, and units. If you allocate 100% to one person and later allocate two people, you’re changing the units. That will affect duration if the task type is fixed work.

Work, Duration, and Units: The Core Scheduling Equation

MS Project’s underlying logic can be summarised:

Work = duration × units (conceptually)
If you set work as fixed, adding units reduces duration.
If duration is fixed and units are changed, work changes.

This is where many exam questions can detect misunderstanding. Suppose you add resources expecting “no change to timeline,” but task type is fixed work. MS Project will reduce duration automatically. If the question expects schedule stability, your task type assumptions must match.

Critical Path Fundamentals (And Why It Matters in Exams)

The critical path is the longest sequence of dependent activities that determines the project’s minimum completion date. Activities on the critical path have zero slack/float in a typical deterministic schedule.

In assessments, critical path questions often ask:

Which activities delay the project if they slip?
What is the critical path duration?
What is the effect of changing a task duration?

Practical Steps to Identify Critical Path

Use MS Project view tools to show critical tasks (commonly through network analysis or Gantt formatting).
Examine Total Slack for tasks.
Confirm dependencies are correctly set (critical path can change with links or constraints).

Case Example: Training Programme Rollout

Imagine a programme with these logical activities:

Develop training content (5 days)
Create timetable (3 days)
Book venue (2 days, dependent on timetable)
Train facilitators (4 days, dependent on content)
Deliver training sessions (10 days, dependent on facilitators)
Collect feedback and close-out (3 days, dependent on deliveries)

If “Book venue” is linked as FS to “Create timetable,” then any delay in “Create timetable” pushes “Book venue,” and ultimately “Deliver training sessions.” If you accidentally link “Book venue” as SS, the schedule may appear shorter or may allow venue booking before timetable finalisation—an unrealistic plan.

Float, Slack, and Risk Interpretation

Slack (float) indicates how much an activity can slip without delaying the project finish date. In governance contexts, slack helps prioritise monitoring: critical tasks require more frequent review, while non-critical tasks can be monitored but not always escalated immediately.

However, an exam answer should reflect the nuance:

A task with positive slack is not necessarily “low risk.”
Risk can convert slack into a schedule delay if other tasks slip concurrently.
Stakeholder expectations might require earlier delivery even if float exists.

Baselines: The Contract of Planned vs Actual

A baseline is the snapshot of planned schedule performance used for variance tracking. In professional environments, baseline comparison is a governance tool: it demonstrates planned commitments vs realised progress.

In MS Project:

Set a baseline (e.g., Baseline 0 or Baseline 1).
Later compare actual dates/durations to baseline.

In coursework, baseline questions may ask:

What is the difference between baseline and current schedule?
How do you interpret variance?
Why might you update the baseline (or not)?

Baseline Updating Discipline

Good practice in project control: only update baselines after formal change approvals. Students sometimes update baseline repeatedly without justification, undermining governance interpretation. In an exam scenario, you can be penalised if you describe baseline replacement as routine rather than controlled.

Example: Procurement Delay Variance

Suppose your baseline planned “Source quotations” to take 10 working days and finish on 15 May. In reality, it took 13 working days due to supplier response times and finished on 18 May. MS Project can show variance in:

Planned finish vs Actual finish
Planned duration vs Actual duration
Schedule impact on successors (dependent tasks)

Your analysis should then link variance to upstream causes: perhaps procurement officer capacity was insufficient, or constraints were misapplied, or assumptions about supplier turnaround were wrong.

Resource Levelling: When the Plan Breaks Under Capacity

After resource assignment, you may encounter overallocation: two tasks demand the same limited resource simultaneously. Resource levelling attempts to resolve overallocation by delaying tasks or adjusting timing based on rules.

In MS Project resource levelling settings, key choices include:

Whether tasks can be split
Whether to respect deadlines and constraints
Leveling order (how MS Project chooses tasks to delay)

Exam-Level Reasoning: Levelling Trade-offs

A strong answer typically includes trade-offs:

Pros: reduces overallocation, creates feasible schedules for resource capacity.
Cons: can change critical path and extend project duration; might violate logic if not done carefully.

A counter-argument students sometimes ignore: levelling can mask poor planning. If you continually level by pushing tasks later without addressing capacity constraints in reality, you’re simulating feasibility rather than improving underlying assumptions.

Practical Workshop Workflow: From Blank Project to Controlled Plan

A disciplined workflow aligns with what assessors look for:

Set project start date and calendar rules.
Create WBS-like task structure with summary tasks.
Enter durations as working durations consistent with task type.
Apply dependencies to reflect real sequencing.
Check critical path and schedule logic.
Build a resource pool and assign resources to tasks.
Resolve overallocation using resource levelling where required.
Set a baseline after schedule acceptance.
Enter progress and actuals during execution and update variance reporting.

This workflow creates a narrative of control: plan → feasibility → baseline → execution monitoring.

Wits Specialised PM Focus: Progress Tracking, Variance Analysis, and Reporting with MS Project for University Assessments

Scheduling is only half the exam journey. The other half is showing you can track progress, explain variances, and communicate results in credible report formats. In university specialised PM courses, marks often reflect reporting clarity: you don’t only compute variance—you interpret it and connect it to management actions.

Setting Up Tracking: Status Date, Actual Dates, and Percent Complete

Progress tracking in MS Project usually revolves around a few mechanisms:

Status date: the “as of” point for progress calculations.
Actual start/finish for tasks begun/completed.
Actual duration or remaining work.
Percent complete (with caution depending on task settings).

A common exam pitfall is over-reliance on percent complete without proper actuals. If percent complete is updated but actual start dates remain unchanged, downstream variance may not accurately reflect reality.

Worked Example: Updating a Partially Completed Task

Consider “Develop training content” with:

Baseline duration: 5 days
Planned finish: 12 June
As of status date (e.g., 10 June), content is 60% complete

A credible progress update would involve:

Set actual start (if it began).
Update remaining duration or remaining work.
Confirm MS Project recalculates successor schedules appropriately.

If your scenario states “the content team is blocked for 2 days waiting for approval,” then you should reflect that by adjusting remaining work/duration and ensure logic propagation occurs.

Earned Schedule and Variance Thinking

Even when not explicitly named, exam questions often test your understanding of variance types:

Schedule variance (planned vs actual timing)
Duration variance (planned vs actual duration)
Resource variance (overallocation/underallocation effects)
Scope/sequence variance (e.g., successor work started prematurely or late)

In MS Project reporting, you can examine:

Variance columns (where available)
Current start/finish vs baseline start/finish
Total slack changes over time

A strong interpretation addresses causes and effects. For example:

If schedule slips: identify upstream dependency failures.
If schedule remains stable despite delays: identify slack utilisation.
If schedule improves: check if assumptions were changed (e.g., resource added) and whether baseline stays valid.

Reporting Views for Workshop-Grade Submissions

Assessors often expect students to use structured views. In MS Project, typical workshop outputs include:

Gantt chart with baseline overlay
Network diagram for logic checking
Task usage for progress by resource
Resource sheet and assignment tables
Reports (like task variance or critical path listing)

Example: Gantt Chart with Baseline

A baseline overlay helps interpret variance visually:

Baseline bars show planned timeline.
Current bars show updated schedule.
Variance is visible in the shift between bars.

In exam writing, you can reference specific tasks and describe how the variance affects delivery dates.

Creating a Management Narrative from MS Project Data

The numbers must be translated into management actions. In Wits specialised PM tasks, you might be required to write a short management summary alongside technical outputs.

Here is a management narrative pattern that fits many assignments:

What changed? (e.g., “Procurement quotations took 3 additional working days”)
Where did it occur? (task name and phase)
Why did it change? (resource capacity issue, external delay, assumption error)
What is the impact? (finish date change, which tasks became critical)
What will you do? (resource reallocation, revised dependency logic, change control)

This structure is both “technical” and “management-ready.”

Typical Exam Scenarios: Identify the Mistake

University workshop exams frequently contain “faulty schedule” scenarios. You may be asked to identify errors such as:

Missing dependencies causing unrealistic early starts
Incorrect constraints locking dates
Overallocation not resolved but assumed feasible
Progress updates inconsistent with actual durations
Baseline not set after schedule acceptance

Counter-Example: Why “Must Start On” Can Break Logic

Suppose “Deliver training sessions” is set to “Must Start On” a fixed date even though “Train facilitators” is delayed. MS Project may show the training starting anyway (depending on constraint settings), creating inconsistency. A strong answer says: this is not schedule control; constraints override logic. The fix is to use realistic dependency links and flexible constraint types unless an external fixed date truly exists.

Weekly Update Exercise: Turning a Plan into a Living Schedule

A practical workshop exercise (often used in PM courses) is the weekly schedule update. A typical workflow:

Adjust status date.
Update actual start/finish for completed tasks.
Update progress (actual duration or remaining work) for in-progress tasks.
Check re-computed schedule and critical path.
Review variances vs baseline.
Summarise in a management update note.

This exercise builds exam competence: it shows you can move from planning to control.

Cluster Focus: Wits University MS Project Workshop Outputs for Integrated PM Assignments (Planning, Control, and Communication)

This section consolidates MS Project workshop skills into deliverables—what you would actually submit for a specialised PM coursework task in a Wits-style environment. While the tool features are universal, assessments often reward the combination of correct technical settings and disciplined communication.

Workshop Deliverable 1: A Defensible Project Schedule (Baseline-Ready)

Your schedule submission should demonstrate:

WBS-like structure with summary tasks
Correct dependency logic
Realistic durations and correct task type settings
Calendars and working-time assumptions aligned to scenario constraints
Critical path identification and explanation

Example Deliverable Structure

A common submission format:

Baseline 0: after schedule logic and resources are set
Current schedule: after progress updates
Critical path listing: tasks with zero total slack
Assumptions list: calendar assumptions, task type assumptions, resource availability

In your written commentary, you don’t need to write essays. But you must show you understand why the schedule is the way it is.

Workshop Deliverable 2: Resource Plan and Feasibility Report

Students often lose marks by having a schedule but no evidence of feasibility. A feasibility report can include:

Resource list and roles
Overallocation checks (and resolution via levelling if appropriate)
Summary of changes after levelling (e.g., critical path changed; project duration increased)
Any explicit trade-offs (e.g., tasks split to reduce overallocation)

Example Feasibility Commentary

If levelling increases the project finish date by 4 working days, your report should say:

Which tasks moved
Whether those tasks were critical
Whether the change is acceptable or needs change control

This is the difference between “making MS Project produce a schedule” and “managing a schedule.”

Workshop Deliverable 3: Variance Analysis and Corrective Actions

A credible variance analysis includes:

Baseline planned dates
Current dates
Variance (difference in days)
Root cause interpretation
Corrective plan

Example Corrective Action Plan

If “Source quotations” is behind baseline by 3 working days:

Short-term corrective action:
- Reallocate Admin Assistant support to procurement documentation
- Tighten supplier follow-up schedule
Medium-term action:
- Consider dual-source strategy earlier in future phases
Governance action:
- Log schedule risk; evaluate whether to update baseline via approved change request

In exam terms, the evaluator wants to see that you connect variance to decisions.

Workshop Deliverable 4: Reporting Quality (Clarity Under Time Pressure)

In time-limited tests, students often produce technical tables that are unreadable. A Wits PM assessment typically values clarity:

Use consistent task naming (verbs + deliverables: “Draft specification,” “Evaluate suppliers”)
Avoid inconsistent units (“5d” in one place and “40h” in another unless required)
Provide a short narrative summary with bullet points
Ensure screenshots or exported tables correspond to stated findings

Alignment with Wits Specialised PM Course Practices

Wits specialised PM course assessments commonly test:

Planning logic and schedule realism
Understanding of dependencies, constraints, and calendars
Ability to use resources responsibly
Ability to track progress and interpret variance
Ability to communicate results in project terms

MS Project is the mechanism through which those competencies are demonstrated.

Practical MS Project Workshop Templates and Scenarios (Study-Ready Exercises, Common Errors, and “How to Answer” Logic)

This section provides exam-style practice structures: scenarios, task sets, and the kind of logic you should apply when solving MS Project questions. These are designed to mirror how workshop content is evaluated: through building, interpreting, and troubleshooting.

Exercise 1: Build a Logic-Driven Schedule and Explain the Critical Path

Scenario: A university department runs a “Policy to Practice” workshop project.

Tasks (working days):

Confirm workshop scope (3)
Draft agenda (4) depends on 1
Identify guest speakers (5) depends on 2
Book venue (2) depends on 2
Prepare workshop materials (6) depends on 3
Run workshop event (1) depends on 4 and 5
Post-event evaluation (2) depends on 6

What you should do in MS Project:

Create tasks with durations.
Set dependencies:
- 2 FS 1
- 3 FS 2
- 4 FS 2
- 5 FS 3
- 6 FS 4 and 5 (two predecessors)
- 7 FS 6
Use network view or critical path formatting to identify critical tasks.

Expected logic outcome:

The critical path likely includes 1 → 2 → 3 → 5 → 6 (depending on overlaps with task 4).
“Book venue” may have slack if it completes before workshop start is dictated by materials preparation.

How to answer in an exam:

Name tasks on the critical path.
State how many working days the critical path totals (sum durations).
Explain what happens if “Prepare workshop materials” increases by 2 days.

Insight: Probing Dependency Sensitivity

If materials preparation slips by 2 days, task 6 cannot start until both venue booking (task 4) and materials (task 5) are complete. If task 4 finishes earlier, task 6 remains constrained by task 5. The project finish slips by exactly those 2 days (in a simplified model without other constraints or resource adjustments).

Exercise 2: Resource Assignment and Levelling Decision

Scenario: The same project has two teams: a project coordinator and a materials assistant. Their availability is limited to 100% each. Your MS Project schedule includes overallocation.

Resources:

Project Coordinator (100% capacity)
Materials Assistant (100% capacity)

Assign resources:

Confirm scope: Project Coordinator
Draft agenda: Project Coordinator
Identify guest speakers: Project Coordinator
Prepare workshop materials: Materials Assistant
Post-event evaluation: Project Coordinator

If you schedule tasks so that Project Coordinator is assigned to multiple tasks simultaneously (e.g., confirm scope, draft agenda, and identify speakers all overlap), MS Project will show overallocation.

Workshop technique:

Use resource levelling with a clear rule:
- Respect dependencies (don’t break logical order).
- Choose whether tasks can be split (splitting can reduce levelling delays but may reduce feasibility).
- Keep deadlines if external dates exist.

Exam answer expectation:

Explain whether levelling increases project duration and why.
Identify which tasks move due to levelling.
Confirm critical path changes or remains stable.

Exercise 3: Progress Update and Variance Interpretation

Scenario: The project is halfway through. Status date is mid-way through tasks 2 and 3.

Assume:

Task 2 (Draft agenda) is 50% complete and is on track.
Task 3 (Identify guest speakers) started late due to slower responses and is now behind schedule by 2 working days.
Task 5 depends on task 3, so it is also affected.

How to update in MS Project:

Set status date.
Update actual start for task 3 (if applicable).
Update remaining duration for tasks 2 and 3.
Confirm MS Project recalculates task 5 and task 6 dates.

Answer structure:

Provide planned vs current finish dates for affected tasks.
State the chain reaction:
- task 3 slip → task 5 slip → task 6 slip → project finish slip
Mention critical path change if “Book venue” becomes non-critical and “Identify guest speakers” (or “Prepare materials”) becomes the new critical driver.

Exercise 4: Common Mistakes Checklist (What Examiners Look For)

Use this as a self-audit before submitting MS Project work:

Missing predecessor links: successor tasks start too early.
Incorrect dependency type: FS used where SS should apply.
Overuse of “Must Start On” constraints: schedule stops behaving logically.
Calendar mismatch: durations treated as working days but should be elapsed (or vice versa).
Resource overallocation ignored: schedule assumes capacity without checking feasibility.
Baseline set too early: baseline captures incomplete logic or pre-levelling chaos.
Progress updates inconsistent: percent complete changes without actual start/duration/remaining work alignment.
No variance interpretation: reporting numbers without explaining management implications.

A strong exam answer tends to explicitly address at least two issues and propose corrected settings and reasoning.

Exercise 5: Reporting with Baseline Comparisons

Scenario: After execution, you need a compact report for stakeholders.

Include:

A Gantt view showing baseline vs current timeline.
A table of key milestone tasks with variance in days.
A short written summary:
- biggest driver of delay or success
- whether critical path shifted
- recommended corrective actions

Milestone Table Template (Example)

Milestone Task	Baseline Finish (Working Days)	Current Finish	Variance (Days)	Interpretation
Book venue	2	2	0	On track
Prepare workshop materials	6	8	+2	Resource or response delay
Run workshop event	1	1	0	Adjusted dependencies; still tied to materials
Post-event evaluation	2	2	0	Depends on event completion

When constructing such a table, ensure all figures are consistent with your MS Project timeline updates. If your current schedule shifts the workshop event date, post-event evaluation will also shift because of dependencies.

Exercise 6: Network Diagram Interpretation for Logic Validation

Some workshop exams require logic validation using network diagrams.

Key interpretation skills:

Identify convergence points (tasks with multiple predecessors).
Identify diverging paths (tasks that feed multiple successors).
Detect “orphan tasks” without predecessors or successors (unless intentionally independent).
Check for unintended cycles (not typical in student models but can occur with incorrect linking).

In your exam answer, you can say something like:

“Task 6 has two predecessors; therefore its start depends on both the venue and materials. The critical path runs through the predecessor that finishes later.”

Even if you don’t compute every path length, this explanation demonstrates correct conceptual understanding.

Summary Checklist: MS Project Workshop Skills for Wits Specialised PM Exams

Use this as a final revision tool.

Schedule Creation and Control

Project start date and calendars correctly configured
Task structure uses summary tasks and realistic work packages
Durations match scenario assumptions (working vs elapsed time)
Dependencies reflect true execution logic
Constraints used sparingly and justified

Analysis and Feasibility

Critical path identified and explained
Slack/float interpreted for monitoring priorities
Resource assignments created with correct capacity assumptions
Overallocation handled (with levelling choices justified)

Progress Tracking and Reporting

Status date set and actuals updated responsibly
Progress updates reflect actual duration/remaining work
Baseline compared with current schedule for variance
Written interpretation links causes to impacts and corrective actions
Reports are readable: consistent task names, clear milestone tables, coherent narrative

Exam-Ready Mindset

Prefer logic-driven scheduling over manual locking
Defend every “why” with schedule evidence (critical path, dependencies, baseline variance)
Translate MS Project outputs into management decisions

Closing Note: Mastery Is Showing Control, Not Just Making Dates

MS Project workshop competence in a Wits Specialised PM context means your schedule must behave like a controlled plan: logic-driven, calendar-consistent, resource-feasible, baseline-reconciled, and progress-tracked with credible variance interpretation. When those elements align, you don’t just produce a Gantt chart—you produce a schedule that can be defended under exam scrutiny and withstand real project governance questions.