Skip to content

Lab 08 — Building a Project Schedule

At a glance

Learning objectives

By the end of this lab you should be able to:

  1. Derive activities from work packages and separate effort from duration.
  2. Convert effort into duration using an explicit productivity assumption.
  3. Calculate resource capacity and compare it with demand.
  4. Decide whether a project is capacity-constrained or dependency-constrained, and explain why the distinction changes your actions.
  5. Express durations on a working-day calendar.

Scenario

The university's Admission Management System project has an approved scope and a baselined WBS. Nobody has yet turned it into a schedule, and the steering committee has asked for a date.

The scope covers: a form for applicants to submit an application for one programme, upload of one supporting document per application, a rules engine that evaluates eligibility, an administrative console for reviewing applications, an integration that writes accepted applicants into the student records system, and testing and user training.

Delivery facts:

Item Value
Project start Monday 2 March 2026
Window available 16 weeks
Working pattern Five days per week; two public holidays fall inside the window (20 March and 6 April)
Developers available 4, full time
Business analyst 1, at 60% availability
Tester 1, at 50% availability
Productivity assumption 80% of paid time is available for project work; the rest is meetings, support, leave, and interruptions
Blended rate PKR 22,000 per person-day (needed in the costing lab, not this one)

Effort estimates, in person-days, agreed with the team:

# Activity Effort (person-days)
A Requirements workshops 12
B Data model design 8
C Applicant form build 12
D Document upload build 10
E Eligibility rules engine 16
F Admin review console 12
G Student-record integration 14
H Security review of the integration 3 (our effort); 10 working days of lead time
I System testing 15
J UAT and training 10

The security review is performed by the university's IT security office. It has a queue of ten working days before it begins, and it is outside the project's control.

No dependencies have been assigned yet — that is the next lab's job. In this lab you are establishing what the activities are, how long they take, and whether the team has enough capacity to do them at all.

Your role

You are the project manager. You must produce a schedule the steering committee can challenge, which means every number must have a stated basis and a stated assumption.

Project information and assumptions

The scenario is part of the example-project library — read the full description there if you want the wider context.

  • Treat the productivity assumption of 80% as given. Say what it covers.
  • The security review's ten-day queue is a lead time, not effort. Place it correctly.
  • The 16-week window ends on a Friday. Compute the date rather than assuming it.
  • Assume no resource is shared with other projects. If that were false, state what would change.
  • Ignore dependencies in this lab; that is deliberate, and Task 5 asks you to say why it matters.

Tasks

Task 1 — Total the effort

Sum the effort column. State the total in person-days.

Task 2 — Convert effort to duration

Calculate the paid person-days required, using the productivity assumption. Show the division and explain in one sentence why paid days exceed effort days.

For the security review, state separately: - the effort you contribute - the lead time you cannot control - why mixing these two numbers up would produce a schedule that looks optimistic.

Task 3 — Calculate capacity

Build a capacity table:

Resource Availability Person-days per week Person-days over the 16-week window
Developers (4) 100%
Business analyst 60%
Tester 50%
Total

Remember that availability applies to the paid working year, so the productivity factor applies when comparing capacity with the demand from Task 2. Show both figures if it helps your explanation.

Task 4 — Compare demand with capacity

State whether the project has enough capacity. Then calculate the utilisation — demand as a percentage of capacity — and interpret it. A project at 30% utilisation is not sitting idle; explain what the number actually tells you.

Task 5 — Name the real constraint

Using your numbers, answer: is this project capacity-constrained or dependency-constrained?

Calculate the two extreme bounds to support your answer: - the serial duration, if one person did every activity one after another - the theoretical parallel duration, if every activity could run at once within the capacity available

Then state which bound the truth lies near, and why none of the activities can in fact all run at once. List three specific pairs of activities that cannot run in parallel and say why for each.

Task 6 — Put it on the calendar

Convert your durations to working-day dates, excluding weekends and the two public holidays.

  1. State the last working day of the 16-week window as an actual date.
  2. Take the security review's ten-working-day queue and state the earliest date you could book it if you booked it today (2 March 2026).
  3. Write two sentences on what this date tells you about when the integration must be complete.

Task 7 — Build the milestone list

Define six milestones for this project, each with a date or date range and, for each, the evidence that would show it was met. Evidence must be observable by someone outside the team.

Deliverable

  1. Total effort and paid person-days, with working shown.
  2. The security review's effort and lead time stated separately.
  3. The capacity table, completed.
  4. The demand-versus-capacity comparison, with utilisation.
  5. A short written answer to Task 5, with the two bounds calculated and three serial pairs named.
  6. Calendar dates for the window end, the security queue, and the integration completion implication.
  7. Six milestones with evidence.

Hints and guidance

  • Effort is work; duration is time. The security review makes this obvious: three days of effort can occupy ten working days of calendar.
  • The productivity factor is a real number, not padding. If 20% of paid time is not project work, a plan built on 100% is wrong by a quarter.
  • High utilisation is not the goal. A team at 100% capacity has no room for the unexpected, and unexpected work always arrives.
  • Parallel bounds are a diagnostic, not a plan. Their value is to show whether adding people or removing dependencies is the right lever.

Self-check criteria

Check How to verify it
Effort total is correct The sum matches the table exactly
Productivity is applied once and consistently Paid days = effort ÷ 0.8, and the same factor is used in both tasks
Capacity arithmetic is right Availability × 78 working days (16 weeks × 5, less the two public holidays) for each resource, then summed
Lead time and effort are separate The security review appears twice, with two different units, clearly labelled
Both bounds are calculated Serial and parallel durations both present with working
Dates respect the working calendar Weekends and both public holidays excluded; the window end is an actual date
Milestone evidence is observable Each milestone could be judged by someone outside the team

Reflection

  1. Your utilisation figure is low, but the committee still expects the work to fill 16 weeks. Reconcile those two facts.
  2. What would you have to believe for the parallel duration bound to be achievable?
  3. If the security office doubled its queue to twenty days, what would you do first — and what would you not do?
  4. Which of your six milestones would be the first to move if the project slipped, and how early would you know?
Check your numbers
  • Total effort: 112 person-days (including our 3 days on the security review).
  • Paid person-days at 80% productivity: 112 ÷ 0.8 = 140 person-days.
  • Capacity per week: developers 4 × 5 = 20; analyst 0.6 × 5 = 3; tester 0.5 × 5 = 2.5 → 25.5 person-days per week.
  • Working days in the window: 16 weeks × 5 = 80, less the two public holidays = 78 working days. Capacity = 25.5 × 78 ÷ 5 = 397.8 person-days (≈ 398).
  • Utilisation against paid demand: 140 ÷ 397.8 ≈ 35%. Using 80 days and ignoring the two holidays gives 408 and 34% — the holidays are given in the scenario, so 78 is the right basis.
  • Serial duration: 140 ÷ 5 ≈ 28 weeks. Theoretical parallel: 140 ÷ 25.5 ≈ 5.5 weeks.
  • Window end: 16 weeks from Monday 2 March 2026 is Monday 22 June 2026, so the last working day is Friday 19 June 2026.

Full working is in the Intermediate labs answer key.

Extension challenge

Add a second project that borrows two of your four developers for four weeks, starting in week 6. Recalculate capacity and utilisation, then answer: does the project still fit the window, and what would you do about it? Present the answer as a one-page decision note for the steering committee with three options, each with its cost and its risk.