Schedule

Primavera as L1/L2 master; platform owns L3/L4 progress capture from WIR, field reporting, and BIM.

What it is

Schedule lives in Primavera at L1/L2 layer. The platform integrates rather than replaces — daily progress is captured from WIR closures, field mobile reporting, and biometric data; these feed back into the L3/L4 schedule. Variance surfaces through EWS (Early Warning System) — schedule slip patterns trigger root cause analysis before someone has to chase. BIM-vs-actual progress is tracked continuously.

Inputs

Triggers

·Project registered in M03 — master schedule seeded
·CC receipt from M04 — site mobilisation unlocked
·New WO released in M14
·Daily progress report from CM
·WIR closure events from M19
·Biometric attendance data from M20
·Slip pattern detected by EWS

Data reads

·GTM milestone date from M06
·Approval milestone dates from M04
·Design milestone dates from M07
·Awarded WO timelines from M14
·WIR closure rate from M19
·Labour deployment from M20
·Past-project velocity history

Artefacts consumed

·L1/L2 schedule template (Primavera)
·L3/L4 detailed activities per package
·Daily progress reports
·Constraint and dependency logs

Tools & Techniques

Methods

·L1 through L4 schedule decomposition with single source of truth
·Primavera integration for L1/L2; native for L3/L4
·EWS (Early Warning System) on slip patterns — not just status reports
·Critical path tracking with float visibility
·Velocity-based forecasting from biometric and WIR data
·Cross-function date locking — GTM, RERA, MD register all reference one schedule

Policies

·scheduling policy with L1-L4 definitions
·EWS threshold policy — what triggers an alert
·Re-baselining policy — when, by whom, with what approval
·Milestone register policy with cross-function ownership

Decision rules

·Re-baselining above threshold requires CPT Head plus Director approval
·EWS alert auto-routes to package owner, CM, CPT
·Slip pattern (three consecutive weeks behind) escalates regardless of magnitude
·Critical path activities cannot be re-sequenced without explicit approval

Outputs

Artefacts produced

·L1/L2/L3/L4 schedule (live, versioned)
·Milestone register tied to schedule
·EWS alert log with response history
·Velocity reports per package and per vendor
·Re-baselining decision log with reasoning

Data writes

·Schedule updated daily from field data
·Milestone register updated on each milestone close
·Velocity metrics updated continuously

Downstream triggers

·EWS alert fires to package owner and CPT
·Milestone close triggers downstream-dependent activities
·Schedule update propagates to GTM (M06), Approvals (M04), and Design (M07)
·Slip pattern triggers vendor performance flag in M13

Stakeholders

PMOOwns master schedule, WBS, milestone definition
CMDaily progress capture from site
Site engineersField reporting via mobile
PMO HoD · MDEWS review, intervention decisions

The flow

01WBS preparation per policy
02L1 schedule in Primavera
03L2/L3/L4 schedule levels
04Milestone definition aligned to RERA, MD review, GTM dates
05Daily progress capture from field, WIR, biometric
06Continuous schedule update; P6 synced
07Variance alerts on slip patterns

State change

Before

P6 updated weekly; daily progress in WhatsApp; WIR closure does not auto-update schedule.

After

Schedule live to the day; WIR closures auto-update; variance surfaces before it is asked about.

Real-world example

Worli — MEP rough-in flagged −5 days against L2 plan on 14 May. EWS triggered. Root cause analysis links the slip to Sterling vendor capacity constraint flagged earlier this morning. PMO alerted; CM notified; intervention options auto-suggested. Portfolio average variance −2.4 days; trend improving 4 consecutive weeks.

Artefacts

·WBS
·L1 schedule (Primavera)
·L2/L3/L4 schedules
·Daily progress records
·Variance reports
·EWS alerts

Pain today

P6 updated weekly at best. Daily progress lives in WhatsApp groups. WIR closure does not auto-trigger schedule update. Slippage discovered when it is already 3 weeks deep.

Integrations

Primavera P6