Microsoft Project 1 & 2 (Boston Course) Study Material — MNG0001 / CSE / Project Management Short Course Notes (Boston City Campus)

Microsoft Project 1 & 2 for the Boston City Campus Project Management Short Course & Certification Notes is designed to help learners move from basic scheduling to professional project planning, baseline control, resource management, and reporting—using Microsoft Project (commonly referred to as MS Project) as the main tool. In the Boston-style progression, you typically start with task structure, durations, dependencies, and calendars, and you later advance into assignments, tracking progress, critical path, baselines, and performance reporting. These exam notes emphasize practical exam-ready steps, common pitfalls, and realistic scenarios you’re likely to see in South African university and short-course assessments such as MNG 0001, CNS (Computer Science/Systems-style) modules, and related Project Management outcomes at UNISA and other campuses.

1) Microsoft Project Fundamentals (Boston Project 1): Scheduling Logic, Calendars, and Task Structure

Microsoft Project “Project 1” is where you build the model correctly. Marks in assessments often depend less on fancy charts and more on whether your schedule logic is sound: tasks are defined properly, dependencies are correct, durations match expectations, and calendars are consistent. In exam settings for modules like MNG 0001 (management/project foundations) and similar first-level project planning outcomes, the examiner frequently evaluates whether your schedule reflects realistic work patterns and logical sequencing.

1.1 Core MS Project Concepts You Must Know for Exams

Before clicking menus, you must understand the fundamental entities inside MS Project:

• Tasks: work items that have a name, duration, and sometimes a resource assignment and cost.
• Duration: how long a task takes (e.g., 2d, 3w). In MS Project, the unit of duration affects scheduling.
• Dependencies (Predecessors/Successors): the relationships that control sequencing.
• Calendars:
  • Project Calendar: defines the working time for the whole project.
  • Resource Calendars: define working time for each resource.
  • Task constraints: can force scheduling behaviour in relation to dates.
• Critical Path: path of tasks determining project finish date based on dependencies and durations.
• Gantt chart: visual timeline used in many assignments.

Exams usually test understanding implicitly by requiring that your project finish date updates correctly when you change durations or relationships.

1.2 Create a New Project Correctly (Start Date, Calendar, and Working Time)

A frequent exam scenario is: “Create a project schedule for a short construction/IT rollout with working days Monday to Friday, and start on a specified date.” The most common way learners lose marks is starting on the correct date but using the wrong calendar or default assumptions.

A typical Boston-style approach is:

1. Open MS Project.
2. Choose Blank Project.
3. Set the Project Start Date:
   • Use the date given in the question (example below uses a coherent timeline).
4. Confirm the calendar:
   • Usually Mon–Fri are working days.
   • Weekends are non-working unless specified.

Example Case (IT Training Rollout)

Suppose the scenario for an exam task is:

• Start date: 15 July 2026
• Working days: Monday–Friday
• Weekend: off

If you fail to set the calendar, MS Project may schedule tasks into weekends, shifting dates. That leads to incorrect critical path and incorrect expected finish date.

1.3 Task Types: Summary Tasks, Regular Tasks, and Milestones

MS Project supports different task forms:

• Summary task: a container grouping several tasks (e.g., “Planning Phase”).
• Regular task: a schedulable activity with a duration.
• Milestone: a task with 0 duration used to mark significant completion points (e.g., “Requirement sign-off”).

In exam notes, you should be able to justify why summary tasks exist: they provide hierarchical structure and make reporting easier. Milestones are vital for baseline comparisons later in Project 2.

Exam-Friendly Structure Example

A typical two-phase schedule might look like:

• 1.0 Planning Phase (summary)
  • 1.1 Gather requirements (duration 5d)
  • 1.2 Review requirements & sign-off (milestone)
• 2.0 Implementation Phase (summary)
  • 2.1 Configure environment (duration 6d)
  • 2.2 Testing (duration 4d)
  • 2.3 Go-live (milestone)

MS Project will roll up dates of summary tasks automatically based on their children.

1.4 Durations and Units: Avoiding “2 days becomes 2 weeks” Mistakes

MS Project interprets duration fields with unit suffixes or defaults. In exam instructions, durations are often given like “5d” or “2w”. Ensure:

• If task duration is 5 working days, use 5d (or confirm MS Project is using working-day logic).
• If duration is stated as 2 weeks, use 2w.

What happens if you enter 5 instead of 5d?

If the exam question expects “5 days” but you enter “5” and MS Project interprets it as “5 hours” or “5 weeks” (depending on settings), your schedule is wrong. Your Gantt chart and critical path will not match the expected answer.

1.5 Dependencies: Relationship Types and How They Affect the Schedule

In MS Project, common predecessor relationships include:

• Finish-to-Start (FS): Task B starts when Task A finishes.
• Start-to-Start (SS): Task B starts when Task A starts.
• Finish-to-Finish (FF): Task B finishes when Task A finishes.
• Start-to-Finish (SF): rare in real life and generally not used in basic courses.

Most university project scheduling assignments teach FS first and expect you to use it correctly.

Lag and Lead

Dependencies may include lag (delay) or lead (overlap). Boston assessments often include at least one example of lag:

• “Testing can start 2 days after configuration is complete”
  → FS with Lag = 2d.

If you omit lag, tasks may start too early and push the finish date earlier than expected (or break logic).

1.6 Task Constraints: When and Why They Matter in Project 1

Task constraints tell MS Project how to schedule a task relative to a date. In Project 1, you should not overuse constraints—use them only when a scenario demands “must not start before” or “start on a fixed date.”

Common constraint types in MS Project include:

• As Soon As Possible (ASAP): default scheduling behaviour.
• Must Start On: forces the task to start on a specified date.
• Start No Earlier Than: task can’t start before a date.
• Finish No Later Than: finish cannot exceed a date (more common in Project 2 tracking and risk control).

In exams, constraints are often used to test whether you understand “fixed milestone dates” or “resource availability windows.”

1.7 Practical Mini-Assignment (Exam-Style) Build Steps

Below is an end-to-end exercise style that mirrors what you might submit in an MS Project 1 assessment.

Exercise: “Boston Course Planning for a Short Delivery Project”

Given:

• Start date: 15 July 2026
• Calendar: Mon–Fri
• Tasks:
  1. Gather requirements — 5d
  2. Draft project plan — 4d, depends on Gather requirements (FS)
  3. Review plan — 2d, depends on Draft project plan (FS)
  4. Sign-off milestone — 0d, depends on Review plan (FS)

Steps:

1. Enter tasks in the Gantt table.
2. Enter durations using d units.
3. Add predecessors:
   • Draft project plan predecessor: Gather requirements (FS)
   • Review plan predecessor: Draft project plan (FS)
   • Sign-off milestone predecessor: Review plan (FS)
4. Ensure milestone has duration 0d.
5. Confirm the schedule finish date aligns with expected timeline.

How graders typically check logic

• Predecessor links exist (numbers in the predecessor column).
• Durations and milestone duration are correct.
• The schedule dates reflect working days only.
• Summary tasks roll up correctly (if created).

2) Microsoft Project 2 (Boston Project 2): Resources, Baselines, Progress Tracking, and Reporting

If Project 1 is about building the schedule “correctly,” Project 2 is about managing it “credibly.” In assessments, Project 2 questions often include resource assignment, cost/resource availability assumptions, baseline setting, and then tracking progress to produce performance metrics and reports. This is where South African short-course learners often struggle because they can create a schedule but cannot demonstrate controlled project management.

2.1 Resources in MS Project: Types and Assignment Basics

A resource can be a person (work resource), equipment, material, or cost-only resource.

• Work resource: has a capacity and typically a “rate” and “units” assignment.
• Material resource: quantity-based, costs are consumed.
• Cost resource: a fixed cost (no work).

In Project 2 for beginner/intermediate courses, you typically work with work resources.

Resource Assignment Mechanics

When assigning a resource to a task in MS Project, you decide:

• Units (availability during task period):
  • 100% means full-time capacity (e.g., 1 person working full time).
  • 50% means half-time effort (e.g., another concurrent assignment could share capacity).
• Work and duration relationships:
  • Work = Units × Duration (in simplified terms for understanding).
  • If duration is fixed and units change, work changes accordingly.

Exams may ask: “Assign Resource A at 50% units. How does it affect task duration or work?”

2.2 Resource Sheet Setup: Capacity and Rates

While every exam differs, a consistent Project 2 expectation is:

1. Enter resources in Resource Sheet.
2. For work resources:
   • Set Standard Rate (hourly/day rate depending on configuration).
   • Define max capacity if asked (sometimes default is acceptable).

Example Resource Set

Suppose an exam scenario uses two team members:

• Team Member: Thandi — standard rate R 350 per day
• Team Member: Sipho — standard rate R 400 per day

In MS Project, the “per day vs per hour” depends on units. If your course uses day-based durations (common in project planning exercises), the rates should align with day calendars. For consistency, keep it day-based throughout the question.

Why this matters: if the question later asks for total estimated cost, you must have consistent rate units and consistent assignments.

2.3 A Complete Consistent Scenario (Schedule + Resources + Costs)

To make your exam answers coherent, you need internal arithmetic consistency. Consider the following scenario used for practice and alignment:

Scenario: “Boston Course Delivery Project (Project 1 & 2 Integration)”

• Project start date: 15 July 2026
• Working days: Mon–Fri
• Tasks:
  1. Gather requirements — 5d
  2. Draft project plan — 4d, after Gather requirements (FS)
  3. Review plan — 2d, after Draft project plan (FS)
  4. Testing — 3d, after Review plan (FS) with 2 people at different units
  5. Go-live milestone — 0d, after Testing (FS)

Resource plan:

• Gather requirements: Thandi at 100%
• Draft project plan: Thandi at 100%
• Review plan: Sipho at 100%
• Testing: Thandi 50% and Sipho 50% (both assigned)

Rates:

• Thandi: R 350 per day
• Sipho: R 400 per day

Compute planned costs (simple cost model for exam practice):

• Gather requirements cost = 5d × R350 = R 1,750
• Draft project plan cost = 4d × R350 = R 1,400
• Review plan cost = 2d × R400 = R 800
• Testing cost:
  • Testing duration = 3d
  • Thandi assigned at 50% units → cost = 3d × 0.5 × R350 = 3 × 175 = R 525
  • Sipho assigned at 50% units → cost = 3d × 0.5 × R400 = 3 × 200 = R 600
  • Total testing cost = R525 + R600 = R 1,125

Total planned cost = 1,750 + 1,400 + 800 + 1,125 = R 5,075

In MS Project, costs can also include assignment costs, overtime rules, and calendar adjustments. But for exam notes, the above is a clear “expected answer” approach if the course question uses a straightforward model.

2.4 Resource Constraints and Over-Allocation Warnings

A common Project 2 exam trap is ignoring resource over-allocation.

• If a person is assigned to multiple tasks that overlap beyond their capacity, MS Project flags overallocated resources (depends on the scheduling mode and resource leveling).
• For example, if Thandi is 100% on one task during the same time she is 100% on another, you create double-booking in the model.

What learners should do in exam responses:

• Identify over-allocations using Resource Usage or the Gantt Chart with resource indicators.
• Decide whether tasks should be rescheduled (resource leveling) or units reduced.

If an exam question explicitly says “Do not level resources; keep dates,” then you should not click automatic leveling; instead, you report that the resource is overallocated or note it in assumptions.

2.5 Baselines: The Foundation of Performance Tracking

A baseline in MS Project is the approved plan for comparison against actuals. In Project 2, you typically do:

1. Set a baseline at a particular time (often right after schedule creation).
2. Track actual progress (percent complete, actual start/finish).
3. Compare “Baseline vs Actual” using reports and variance fields.

Why baseline marks matter

Without baseline, performance reporting is meaningless—variance cannot be computed. Many exam questions ask you to produce “variance for finish date” or “variance for cost,” which depends on baseline data.

2.6 Tracking Progress: Percent Complete vs Actual Dates

MS Project offers multiple ways to track progress:

• % Complete
• Actual Start / Actual Finish
• Remaining duration
• Update task (actual vs planned)

Common Best Practice (Course-Expected)

In teaching contexts, the usual recommendation is:

• If you know task completion percentage but not actual dates, use % Complete.
• If you know actual start/finish, enter them.
• Avoid mixing methods incorrectly unless the question instructs it.

Example Tracking Exercise

Assume “Draft project plan” (planned duration 4d) started as planned but is only 50% complete after 2 days. In tracking mode:

• Set % Complete = 50%
• Keep other dates consistent with scenario.

If you instead change duration or actual finish without reason, the schedule may recalculate incorrectly and variance may not match expected marks.

2.7 Variance Reporting and Interpretation

Once baseline is set and progress is tracked, MS Project can show:

• Start variance
• Finish variance
• Duration variance
• Cost variance (if costs are enabled and tracked)

In exam submission, it’s not enough to display numbers. You must interpret what variances mean:

• Positive variance often implies delays (actual finish later than baseline).
• Negative variance implies finishing earlier than planned.
• Cost variance depends on whether actual costs are recorded and whether remaining work is re-estimated.

A key exam skill is aligning the narrative explanation with the numbers you show:

• “Testing is behind baseline by 1 day due to underperformance / resource constraints” should match finish variance.

2.8 Reporting: Views, Tables, and Exportable Outputs

Many Boston course assignments require you to submit a report with evidence (screenshots or exported tables). MS Project lets you tailor views and tables.

Common required components in reports

• Gantt chart with critical tasks highlighted
• Task table showing IDs, names, start, finish, duration, predecessors
• Resource usage showing who is assigned
• Variance tables for baseline comparisons

In exams, it helps to use:

• Clear formatting
• Correct columns requested by the question
• Consistent baseline identifiers

Example Report Checklist (Exam-Style)

A typical submission might require:

• Baseline set (confirm baseline fields)
• Gantt chart showing tasks and critical path
• A table listing tasks with baseline start/finish and actual start/finish
• Resource cost summary (Total cost, variance if asked)

If the question asks for “top 5 tasks by cost,” your table must be sorted correctly (and cost values must match your resource-rate model).

3) Critical Path, Float, Constraints, and Risk Scenarios (What Examiners Actually Test)

In Project Management assessments at South African institutions and short courses, the “math” is usually the schedule logic rather than advanced probabilistic risk modeling. For MS Project 1 & 2, you’re expected to understand critical path, float/total slack, and how constraints and dependencies influence schedule outcome. This section focuses on exam-grade logic explanations and realistic scenarios that reveal whether your schedule is coherent.

3.1 Critical Path: Identifying It and Using It in Decisions

The critical path in MS Project is a chain of tasks that determines the earliest finish date. Tasks on the critical path typically have:

• Total slack (float) = 0
• Any change to duration affects project completion (unless constraints/buffer logic exists)

In MS Project:

• You can display critical tasks using a view setting like “critical tasks” or fields that show slack.

How exam questions phrase critical path

• “Which tasks are critical?”
• “If Task X increases by 2 days, when does the project finish?”
• “Explain why Task Y is not critical.”

Your explanation must link to dependency logic and float.

3.2 Total Slack (Float) and Why It Matters

Total slack is the amount of time a task can be delayed without delaying the project finish date.

• If total slack is 3 days, a delay up to 3 days does not affect finish date.
• If total slack is 0 days, delay affects finish date.

Exams often test interpretive reasoning rather than calculation:

• Learner sees slack but doesn’t interpret.

3.3 Dependency Structure Drives Slack

Slack comes from:

• Alternative paths
• Flexibility in predecessor/successor relationships
• Whether tasks are constrained

In a coherent schedule:

• If you accidentally break a dependency chain (e.g., forget predecessor), slack might become “incorrectly large,” giving false conclusions.

Therefore, when a question asks for critical path, always ensure predecessors/relationships are properly assigned first.

3.4 Constraints vs Dependencies (Common Confusion)

Many learners confuse:

• Dependencies: define “logic” (what comes after what)
• Constraints: define “date restrictions” (what MS Project must do even if logic allows earlier/later)

In Project 1, the default constraint often is ASAP. If you change a task constraint to “Must Start On,” you can create criticality even if dependency logic wouldn’t require it.

Exam scenario: Fixed go-live date

Suppose a question says:

• “Go-live must be on 29 July 2026” (a fixed date)
  If the go-live milestone must be on that date, you may enforce a constraint or adjust predecessors/durations so that the milestone lands on the date.

If you force a constraint incorrectly, other tasks may shift, or MS Project may show red flags. Your job is to match the scenario’s expectation.

3.5 Resource Effects on the Critical Path (Project 2 Insight)

In Project 2, critical path can change if:

• Resource leveling is enabled
• Scheduling mode changes (automatic vs manual)
• Over-allocation causes rescheduling

Even if dependencies are correct, resource constraints can shift task dates.

Boston course interpretation expectation

• In a basic exam, critical path is usually dependency-driven.
• In an advanced exam scenario, resource leveling may be implied.

Your approach:

• If the question says “Use default scheduling; do not level,” you should keep the critical path as determined by dependencies.
• If it says “Resolve over-allocations,” then critical path may change due to leveling.

3.6 Risk Scenarios You Should Practice (with Clear Expected Logic)

Scenario A: Testing delayed by 2 days

Assume:

• “Testing” planned duration is 3d and is on the critical path.
  If Testing becomes 5d, the project finish date should move later by 2 working days (assuming dependencies remain FS and nothing else changes).

Scenario B: Draft project plan slips but has float

Suppose:

• “Draft project plan” has total slack 2 days.
  If Draft slips by 1 day, project finish may remain unchanged.
  If it slips by 3 days, it should delay finish date by 1 day.

These are interpretive tests—students must connect slack to finish date behaviour.

Scenario C: A constraint forces early start

If “Review plan” is set to “Must Start On” a date earlier than dependency allows, MS Project may violate dependency logic or adjust other tasks, creating unexpected variance.

Your exam answer should emphasize:

• Correct use of dependencies
• Use constraints only when the scenario requires fixed dates

3.7 Mini-Case Study: Coherent Schedule Narrative for Marks

Examiners often give marks for the story you provide alongside MS Project fields.

Example narrative (aligned with a hypothetical Boston project):

• “Gather requirements and draft plan complete on schedule, review plan starts immediately due to FS dependency. Testing remains critical because it has zero total slack; therefore any increase in Testing duration affects go-live.”

This narrative must be consistent with what MS Project shows:

• critical tasks highlighted
• slack fields showing expected values

Even if exact slack numbers are not required, the “criticality reasoning” is.

4) Advanced Schedule Management in Project 2: Baseline Changes, What-If Analysis, and Exam-Grade Updates

Project 2 in Boston-style courses often includes “what-if” questions and baseline change policies. In real project management (and in university marking schemes), you cannot simply edit the plan and call it done—you must understand baseline control: what can be changed, how to compare versions, and how to interpret updated schedules.

4.1 Baseline Policies: When to Set Baseline and Whether to Rerun It

Typically, baseline is set after initial planning. Then updates should be tracked rather than overwritten.

In exams, you might be asked:

• “Set baseline at current schedule.”
• “Change some durations and view variance vs baseline.”
• “Reset baseline” (less common) or “create a new baseline.”

Because exam instructions are explicit, your answer must follow the phrasing:

• If they say “Set baseline now,” do it now.
• If they say “Do not reset baseline,” track actuals and show variance.

4.2 What-if Scenarios: Changing Durations and Understanding Recalc

MS Project recalculates automatically when you change durations, dependencies, or constraints. For exam practice:

1. Record baseline first.
2. Modify one element (e.g., testing duration increases from 3d to 5d).
3. Observe changes in:
   • project finish date
   • critical path tasks
   • slack values (total slack)
   • variance fields if tracked

Example: Testing duration increases

Using the earlier scenario:

• Testing planned: 3d
• Change: Testing becomes 5d

If Testing is on critical path, expected finish date shifts later by 2 working days. In a consistent calendar from start date 15 July 2026, you can map the sequence days.

Even if your exam does not ask you to compute exact dates, the direction and reasoning must be correct.

4.3 Entering Actual Progress Correctly: Preventing “Fake Perfect” or “Fake Delay”

Learners sometimes create unrealistic tracking:

• Setting % complete but also changing remaining duration inconsistently.
• Entering actual start/finish but forgetting to update remaining work.

A credible approach:

• Update one primary tracking method.
• Keep internal logic consistent:
  • If percent complete is 50% and workdays are aligned, actual dates should reflect that.

4.4 Baseline vs Updated Schedule: Exam Fields That Matter

In MS Project, baseline variance can appear in multiple columns:

• Baseline Start
• Baseline Finish
• Actual Start / Actual Finish
• Variance Start/Finish
• Cost baseline fields and cost variance fields (if cost tracking is enabled)

In exam submissions, instructors often specify:

• “Show Baseline vs Actual Finish variance for each task.”
• “Show which tasks have the largest negative variance.”

To score well, ensure:

• the table includes exactly the required columns
• baseline is set and referenced correctly
• formatting highlights variance values

4.5 Updating Costs: What Happens When Progress Changes Work

When tasks progress, costs depend on:

• Assignment costs
• Remaining work
• Whether MS Project is set to calculate actual costs based on earned work

In a simplified exam model:

• If a task is 50% complete, actual cost may represent 50% of work performed.
• If you mark percent complete but do not enable/enter actual work/cost, cost variance may not calculate as expected.

Because course materials differ, focus on:

• Using the course’s expected tracking approach
• Avoiding contradictions (e.g., showing a task 100% complete but leaving it scheduled as if it’s still long)

4.6 Risk and Mitigation Logging (Lightweight but Exam-Relevant)

Project 2 exams sometimes include a short risk mitigation element:

• identify which tasks are at risk based on critical path and slack
• propose mitigations (resource changes, resequencing, buffer)

You may not need formal risk registers, but you should link mitigation to schedule logic.

Example mitigation statements:

• “Increase testing effort by assigning additional capacity or increasing units.”
• “Reduce review cycle time by overlapping activities if allowed (SS relationship) or improving dependency logic.”

However, any mitigation must be consistent with MS Project logic:

• If you propose overlap, you must change dependencies accordingly (FS to SS or adjust lag/lead).

4.7 Worked Case Study: “Reroute the Schedule” without Breaking Logic

Consider an exam question:

• After baseline, testing is behind schedule.
• You’re instructed to resequence so that “Review plan” outputs can support part of testing earlier.

A valid schedule adjustment:

• Convert Testing dependency from “after Review plan” (FS) to “start after Review plan starts” (SS) with a lag representing when review becomes usable.

But be careful:

• If the exam expects testing to begin only after sign-off, you should not change to SS. The scenario rules constrain what you can do.

This is why exam accuracy matters:

• Your solution must reflect the scenario’s constraints, not only your intuition.

4.8 Deliverable Quality: How to Present MS Project Evidence for Marks

Even if the schedule is correct, weak presentation can lose marks. For Boston-style assessments, common presentation expectations include:

• Correct view for the report (Gantt chart for scheduling, resource usage for assignments)
• Tables showing required fields
• Baseline fields included
• Screenshots labelled consistently (if required)

A good rule:

• Make sure every number you claim in explanation appears in MS Project columns or report outputs.

5) Full Exam Preparation Toolkit for Boston Course (Microsoft Project 1 & 2): Templates, Typical Marking Criteria, and Practice Scenarios

This final section is an exam toolkit tailored to Boston City Campus Project Management short-course style expectations and common South African university assessment behaviours (including introductory management/project planning modules often structured as “MNG 0001”-type outcomes and allied project planning components at UNISA and similar institutions). It consolidates what usually earns marks: correct scheduling logic, correct MS Project configuration, correct resource assignment, baseline tracking, and clear reporting.

5.1 Typical Marking Criteria: What Examiners Reward

Across MS Project 1 & 2 assessments, marks generally align to these categories:

1. Data entry accuracy
   • Task names
   • Durations with correct units
   • Predecessors and dependency types
2. Schedule logic correctness
   • Proper FS links
   • Correct milestone handling (0 duration)
   • Correct calendar working days
3. Resource correctness (Project 2)
   • Assign the right people to the right tasks
   • Correct units (100% vs 50%)
   • Rates consistent with task durations
4. Baseline and tracking
   • Baseline set at correct time
   • Actual progress recorded properly
   • Variances displayed correctly
5. Reporting clarity
   • Correct views/tables
   • Requested columns only (or at least all required columns)
   • Evidence supports narrative

5.2 MS Project “Exam Moves” You Should Memorize

These are practical actions that directly translate into marks.

Move 1: Always verify working time settings

• Set project start date.
• Confirm weekend handling.
• If the question says “Mon–Fri only,” enforce it.

Move 2: Use milestones for sign-off and go-live

• Milestones have 0 duration.
• Dependencies to milestones should be set using predecessors.

Move 3: Build dependency chain intentionally

• Use FS for sequential workflows.
• Add lag/lead if explicitly provided in the question.

Move 4: Set baseline before you start “what-if”

• Baseline is your reference.
• If the question asks for variance, baseline must exist.

Move 5: Use consistent tracking method

• Choose % complete or actual dates as the primary update method based on question requirements.
• Ensure you don’t create conflicting actual fields.

5.3 Practice Scenario Pack (3 Scenarios that Combine Project 1 & 2)

Below are three exam-ready practice scenarios. You can simulate them in MS Project to build speed and accuracy.

Scenario Pack 1: “Management Planning and Go-Live”

This is the consistent resource/cost model introduced earlier, used here as a full package.

• Start date: 15 July 2026
• Working days: Mon–Fri
• Tasks:
  1. Gather requirements — 5d
  2. Draft project plan — 4d, predecessor: Task 1 (FS)
  3. Review plan — 2d, predecessor: Task 2 (FS)
  4. Testing — 3d, predecessor: Task 3 (FS)
  5. Go-live milestone — 0d, predecessor: Task 4 (FS)
• Resources:
  • Gather requirements: Thandi 100% at R 350/day
  • Draft project plan: Thandi 100% at R 350/day
  • Review plan: Sipho 100% at R 400/day
  • Testing: Thandi 50% and Sipho 50% at rates above

Expected total planned cost: R 5,075
Expected logic: if FS chain is correct, Testing begins after Review completes; Go-live follows Testing.

Project 2 tracking add-on (common exam step):

• After baseline, set Testing to 50% complete halfway through its planned period.
• Show schedule variance and resource cost impact if your course enables earned work/cost tracking.

Exam marking expectation:

• Baseline exists
• Variance table populated
• Resource assignment units match exactly

Scenario Pack 2: “Infrastructure Upgrade with Lag”

• Start date: 15 July 2026 (same to maintain practice consistency)
• Working days: Mon–Fri
• Tasks:
  1. Prepare hardware — 4d
  2. Install components — 6d, FS after Task 1
  3. Configure system — 5d, FS after Task 2 with Lag = 1d
  4. Perform integration testing — 3d, FS after Task 3
  5. System acceptance milestone — 0d, FS after Task 4
• Resources:
  • Thandi (R 350/day): Task 1 and Task 2 at 100%
  • Sipho (R 400/day): Task 3 and Task 4 at 100%

Key marking focus:

• Lag on configuration is correctly entered.
• Milestone is 0 duration.
• Dependencies are correct.

Scenario Pack 3: “Fixed-Date Constraint and Critical Path Explanation”

• Start date: 15 July 2026
• Working days: Mon–Fri
• Tasks:
  1. Requirements workshop — 3d
  2. Process documentation — 4d, FS after Task 1
  3. Review & approval — 2d, FS after Task 2
  4. Go-live milestone — 0d, must occur on 29 July 2026 (fixed date)
• Resources:
  • Thandi: Task 1 and Task 2 (100%)
  • Sipho: Task 3 (100%)

Exam tasks:

1. Build schedule with FS dependencies.
2. Apply constraint to Go-live milestone to land on 29 July 2026.
3. Identify which tasks become critical due to the forced date.

Marking expectation:

• Your logic explains criticality changes caused by fixed date constraint.
• You do not simply change durations without explaining why the milestone still lands on 29 July 2026.

5.4 Common Errors That Cause Mark Loss (Avoid These)

A strong exam guide must explicitly list errors students make.

Error 1: Wrong units for duration

• Entering “5” instead of “5d”
• Confusing days vs weeks

Impact: schedule dates shift.

Error 2: Missing predecessors

• Tasks start at default times
• Schedule becomes artificially short

Impact: critical path detection becomes meaningless.

Error 3: Incorrect milestone duration

• Milestone not set to 0 duration

Impact: finish dates and variance are wrong.

Error 4: Over-allocation ignored (Project 2)

• Resource assigned at 100% to overlapping tasks without leveling logic
• Not reporting over-allocation

Impact: schedule may violate resource feasibility.

Error 5: Baseline not set

• Variance fields blank or incorrect

Impact: you cannot show baseline vs actual, losing major marks.

Error 6: Inconsistent tracking entries

• % complete changed without aligning actuals
• Actual dates set but % complete left inconsistent

Impact: variance and cost calculations become inconsistent.

5.5 Strategy for Time Management during the Exam

A practical approach:

1. First 20% of time: read scenario carefully and list:
   • tasks
   • durations
   • dependencies
   • milestones
   • start date and calendar rules
2. Next 40%: build Project 1 schedule logic:
   • enter tasks, durations, predecessors
   • create summary tasks if requested
   • confirm schedule updates correctly
3. Next 25%: build Project 2 elements:
   • assign resources and units
   • verify costs and resource usage
   • set baseline at required time
4. Final 15%: tracking and reporting:
   • apply progress updates exactly as question states
   • show variance and produce requested outputs

This plan is consistent with typical Boston course marking: accuracy first, then advanced tracking/reporting.

5.6 Mapping to South African University Course Language (UNISA/CUT-style Outcomes)

In South Africa, students commonly encounter course outcomes that align with project scheduling, planning, and monitoring. While not all learners take the exact same “Microsoft Project 1 & 2,” the exam expectations are frequently shared across:

• UNISA project management and management-related modules (often focusing on planning, scheduling, monitoring, and control)
• Technical/IT modules (including CNS-labelled learning components) that emphasize resource planning and workflow sequencing
• Campus short courses at Boston City Campus (Project Management short-course notes)

Therefore, exam answers should reflect:

• planning structure (tasks, dependencies, calendars)
• monitoring controls (baselines, tracking progress)
• communication outputs (reports, tables, evidence)

Your MS Project outputs effectively act as the “assessment proof” for those outcomes.

5.7 Final “Must-Know” Checklist (Use as Last-Minute Revision)

Before submitting any MS Project 1 & 2 exam tasks, confirm:

• Project start date is correct (15 July 2026 in practice scenarios)
• Calendar uses Mon–Fri working days as required
• All tasks have correct durations with working-day units (e.g., 5d, 4d, 2d, 3d)
• Summary tasks are created if asked; milestones are 0d
• Dependencies are correctly set using FS and lag/lead when specified
• Resource sheet is set with correct names and rates:
  • Thandi: R 350/day
  • Sipho: R 400/day
• Resource assignments use correct units:
  • 100% for full effort
  • 50% for half effort (especially for Testing in the main consistent scenario)
• Baseline is set before progress tracking comparisons
• Progress updates reflect either % complete or actual dates as instructed
• Variance reports show baseline vs actual fields requested in the question
• Tables/views are included that directly match the submission requirements

Summary

This study material covers Microsoft Project 1 & 2 in a Boston course style: building a correct schedule through tasks, dependencies, calendars, and milestones (Project 1), then managing resources, baselines, progress tracking, variance reporting, and scenario-based decisions (Project 2). It also provides exam-credible practice scenarios using consistent dates (15 July 2026), working-day assumptions (Mon–Fri), and consistent resources (Thandi and Sipho with rates R 350/day and R 400/day). By mastering the logic, the tracking discipline, and the reporting evidence demanded in assessments, learners can confidently complete MS Project-related evaluations across Boston City Campus and related South African project management learning contexts.