M2.1 — Planning & Schedule Development

M2.1 — Planning & Schedule Development

1. Practical outcome

By the end of this section, the learner should be able to turn authorised scope and an agreed delivery strategy into a credible, structured and maintainable project schedule that explains what work must be performed, in what broad sequence, over what durations and calendars, through which interfaces and milestones, and with enough detail to support later logic analysis, resource assessment, progress updating, forecasting and control.

The objective is not to produce the greatest possible number of activities or the most visually impressive Gantt chart. It is to build a useful model of intended delivery: one that reflects the project’s real work, exposes important interfaces, can be challenged by delivery teams, and can respond logically when assumptions or circumstances change.

A useful question throughout this Knowledge Area is: “If I hide the dates and software formatting, does this schedule still describe a believable way of delivering the project?”

2. Core concepts

Planning and scheduling are related but not identical

Planning is the thinking process used to decide how the project will be delivered. It considers scope, sequence, methods, interfaces, responsibilities, resources, assumptions, approvals and constraints. Scheduling converts that delivery thinking into a time-based model containing activities, milestones, calendars, durations and dependencies. A schedule created without sufficient planning may be technically complete but operationally weak.

The practitioner should therefore resist treating scheduling as a software-entry exercise. Before activities are created, there should be a coherent view of the delivery strategy: what will be produced, how the work will be packaged, what must be available to start it, who is expected to perform it, which interfaces matter and what outcomes or decisions must be achieved along the way.

The schedule is a model, not a promise and not a diary

A project schedule is a structured model of intended and then current delivery. It simplifies reality so that the project can understand timing, dependencies, criticality, resource demand, progress and forecast consequences. Like every model, it contains assumptions and boundaries. Its usefulness depends on whether those assumptions are visible and reasonable.

The approved baseline may represent the authorised plan, while the current schedule later represents the latest credible forecast. Those are different control concepts. M1.3 establishes the integrated baseline; M2.4 addresses progress updating; M2.5 addresses schedule forecasting. M2.1 focuses on building the schedule model well enough that those later controls have something credible to work with.

Scope provides the starting point

The Work Breakdown Structure (WBS) developed in M1.1 provides the principal scope backbone. Every material area of authorised project scope should be represented in the schedule at a level appropriate for control. That does not mean one schedule activity per WBS element. A work package may require many activities, while some minor scope may be represented more simply. The important point is traceability: the schedule should be capable of showing how the authorised scope is intended to be delivered.

Coding and control structures from M1.2 should be applied so that activities can be grouped by WBS, responsible organisation, contract/package, location, discipline, phase or other required management view. This allows one schedule dataset to support multiple useful questions without maintaining separate inconsistent schedules.

Activities describe work; milestones describe significant points

An activity represents work that consumes time and usually requires effort, resources or an external process. A milestone represents a significant event or state and normally has zero duration. Useful milestones include approvals, contractual dates, interface handovers, access dates, readiness points, decision dates and completion outcomes.

Good activity names communicate an observable piece of work. “Technology” or “Building works” is too vague. “Install network switches – Level 1” or “Complete community-room acoustic finishes” is much more useful. A good activity name often contains a verb and a clear object. Milestones should describe a state that can be objectively recognised, such as “Design approved” rather than an ambiguous label such as “Design milestone”.

The level of detail should support control, not administration

There is no universally correct activity count or duration threshold. The appropriate level of detail depends on project complexity, reporting cycle, risk, delivery method, interfaces, contractual requirements and the decisions the schedule must support. An activity should normally be detailed enough that responsibility, progress and remaining duration can be assessed meaningfully, but not so detailed that maintaining the model becomes disproportionate.

Long activities can hide important internal sequence and delay. Extremely short activities can create noise, false precision and excessive maintenance. The planning team should be able to explain why the chosen level of detail is useful. Different parts of the same project may legitimately require different levels of detail when the control need differs.

Planning levels can coexist if they reconcile

Large projects often use several schedule levels: an executive milestone view, an integrated project schedule, detailed contractor or team schedules, and short-term look-ahead plans. The labels “Level 1”, “Level 2”, “Level 3” and so on are used differently between organisations, so the labels matter less than the defined purpose, content and relationship between levels.

The important control principle is reconciliation. Higher-level milestones should be driven by credible lower-level work rather than manually maintained to show a preferred story. Detailed schedules should map to the integrated control structure, and changes in the detailed plan should flow visibly into the higher-level forecast where they are material.

Use rolling-wave planning where distant work cannot yet be detailed credibly. Preserve its authorised scope, budget, interfaces and milestone commitments in identifiable planning packages, then convert it into executable detail before work starts under the agreed control process. Reconcile the detail to the higher-level plan; progressive elaboration is not permission to lose scope or conceal performance. See M6.3 for controlled replanning.

Calendars are part of the schedule logic

A duration such as “10 days” has little meaning without a calendar. Calendars define when work can occur: working days, shifts, weekends, holidays, seasonal restrictions, access windows or specialist working patterns. Different activities may legitimately use different calendars, but the consequences should be understood because calendar interactions can influence forecast dates and critical paths.

Calendars should represent the planned way of working rather than being manipulated to force target dates. If a package genuinely operates six days per week while another operates five, model that explicitly. If weekend working is only a potential recovery action, it should not normally be embedded silently in the baseline as though already committed.

Durations should be evidence-based and separate from dates

An activity duration is an estimate of the working time required to complete the activity under defined assumptions. It should be informed by quantities, productivity, resources, supplier information, historical performance, expert judgement or other relevant evidence. Selecting a finish date first and then entering whatever duration makes the activity fit is target-driven scheduling rather than planning.

The basis of a material duration should be understandable. For example, 1,000 square metres of repetitive external paving at an expected production rate of 100 square metres per working day provides a transparent 10-day starting point, subject to resource and access assumptions. Where uncertainty is significant, document it rather than hiding it inside an arbitrary duration.

Dependencies and interfaces connect the plan

Activities do not exist independently. Design outputs enable procurement; procurement enables manufacture and delivery; building readiness enables installation; testing enables handover. Internal and external dependencies therefore need to be identified during schedule development. The detailed choice and analysis of logical relationships, critical path and float is taught in M2.2. M2.1 establishes the work and interfaces that the logic network must represent.

Interfaces deserve particular attention because they are common sources of schedule failure. One team may plan to “start installation in June” while another only plans to release the area in July. Interface milestones, handover criteria and dependency ownership make these assumptions visible before they become delays.

Constraints should represent real restrictions, not preferred answers

Some dates are genuinely constrained: a statutory hearing, externally fixed possession window, contractual access date or fixed public opening may impose a real condition. Constraints can therefore be legitimate. Problems arise when hard constraints are used simply to hold activities on desired dates, masking incomplete logic or an unachievable plan.

During schedule development, distinguish between a requirement that the project must manage and a date that should be calculated by the network. The fixed public opening date in the Reference Project is a genuine management requirement. The schedule should show whether the work can achieve it, not force every preceding activity to appear compliant.

Resources and productivity need an early feasibility screen

Detailed resource loading, optimisation and productivity analysis are addressed in M2.3, but schedule development should not knowingly assume impossible resource availability. If the same specialist commissioning team is required simultaneously in three places, the initial plan is not credible even if the logic network calculates correctly.

At M2.1 stage, identify activities whose durations or timing are strongly resource-driven, specialist skills with limited capacity, equipment or access constraints, and work packages where productivity assumptions materially determine duration. This provides a sound basis for the deeper analysis in M2.3.

A schedule needs a planning basis

Important schedules should carry a concise record of the assumptions on which they were built. This may include scope status, design maturity, calendars, productivity assumptions, expected supplier lead times, access assumptions, approval periods, external dependencies, planning exclusions and the schedule data date. The purpose is not to create a large narrative document; it is to prevent assumptions becoming invisible facts.

A Schedule Basis or Planning Basis is particularly valuable at baseline and major reforecast points because it allows later users to understand what the plan assumed when it was created. If a supplier lead time later doubles, management can distinguish a change in circumstance from a planning error only if the original assumption was recorded.

Schedule quality includes technical and operational credibility

Automated schedule-health checks can identify symptoms such as open ends, excessive constraints, very long durations, unusual relationship types or high float. They are useful, but they do not prove that the plan makes sense. A schedule can pass every numerical check while still omitting an important approval, using unrealistic productivity or failing to represent how two contractors actually interface.

Quality therefore has two dimensions: technical integrity and delivery credibility. M2.1 should establish both at a basic level; M2.2 then deepens the logic and path analysis.

Schedule development is collaborative, but ownership must remain clear

The planner or scheduler should not invent the delivery plan in isolation. Package managers, engineers, procurement, commercial teams, suppliers and operational stakeholders often hold critical knowledge about method, durations and interfaces. Structured planning workshops can surface that knowledge. However, collaboration does not mean accepting every preferred date without challenge.

The schedule professional adds value by converting delivery knowledge into a coherent integrated model, testing assumptions, identifying contradictions, and preserving the difference between an agreed plan and an unsupported aspiration.

3. Step-by-step method — how to develop a credible project schedule

1. Define the purpose, audience and control level of the schedule.

Clarify what the schedule is intended to support: baseline approval, integrated project control, contract management, executive reporting, near-term coordination or some combination. Define the reporting cycle and the level at which progress and forecast decisions will be made. This prevents a single schedule from becoming either too coarse for control or so detailed that it cannot be maintained.

2. Confirm the authorised scope and current WBS.

Start from the scope structure established in M1.1. Check that the work being planned is authorised or clearly identified as pending/assumed. Confirm exclusions and interfaces. Map the schedule to the WBS so every material scope area can be traced and gaps can be identified.

3. Confirm the delivery strategy and major phases.

Before creating detailed activities, describe how the project is intended to move from definition through design, procurement, delivery, testing, handover and opening. Identify packaging strategy, major work fronts, phased handovers, procurement routes and any deliberate overlap. If the team cannot explain the delivery strategy in plain language, it is premature to build detailed schedule logic.

4. Establish the milestone framework.

Identify contractual, statutory, approval, interface, readiness, handover and executive decision milestones. Give each milestone a clear definition and owner. Distinguish between externally imposed dates, management targets and calculated forecast milestones. Avoid creating milestones merely because a report template expects them.

5. Select the appropriate planning granularity.

Determine the level of activity detail needed for each workstream. Consider reporting frequency, duration, risk, interfaces, responsibility and ability to measure progress. Define any practical rules of thumb, but allow justified exceptions. A two-week reporting cycle, for example, may make a six-month undifferentiated activity difficult to control.

6. Decompose work packages into meaningful activities.

For each work package, identify the discrete pieces of work required to produce the deliverable. Use activity names that describe action and object. Separate work where different owners, calendars, locations, resources, progress methods or dependencies apply. Do not split activities simply to increase apparent sophistication.

7. Identify external and cross-workstream interfaces.

For every workstream, ask what must be received from others and what it must provide to others. Record access dates, information releases, approvals, material deliveries, area handovers, utilities, system availability and operational inputs. Create interface milestones or activities where needed so the dependency can be seen and owned.

8. Apply coding, ownership and schedule attributes.

Use the structures established in M1.2. Assign WBS, responsible organisation, package/contract, phase, location and other useful codes. Record a responsible owner for material activities or groups of activities. Keep identifiers stable so schedule history and integrations remain traceable.

9. Define and assign calendars.

Create only the calendars needed to represent genuine working patterns. Record working week, shifts, public holidays and material non-working periods. Confirm that supplier or contractor calendars are understood. Review whether different calendars across linked activities could create unexpected dates.

10. Estimate durations using transparent assumptions.

Use quantities and productivity where practical; otherwise use supplier information, historical data, analogous work or structured expert judgement. Document the basis for material durations. Separate working duration from waiting periods where doing so improves visibility—for example, regulatory review time or manufacturing lead time may deserve explicit activities.

11. Establish the initial dependency network.

Connect activities according to physical, technical, contractual, approval and external dependency. At this stage, focus on representing the real delivery sequence. M2.2 then tests relationship type, open ends, critical path and float in depth. Avoid using constraints as a substitute for missing logic.

12. Apply genuine constraints and date requirements explicitly.

Identify fixed external requirements, no-earlier-than access dates, statutory events or other legitimate restrictions. Record the rationale and owner. Keep management targets distinguishable from hard constraints so the schedule can reveal when a target is no longer achievable.

13. Perform an initial resource and productivity feasibility review.

Identify obvious conflicts involving scarce teams, specialist equipment, shared access or unrealistic production rates. The objective is not full optimisation at this point, but to prevent the base schedule from relying on plainly impossible assumptions. Flag items requiring detailed M2.3 analysis.

14. Integrate workstream schedules and reconcile schedule levels.

Combine the workstreams into one coherent project model or establish controlled interfaces between schedules where a single file is not appropriate. Check that detailed activities drive higher-level milestones, that package schedules use the same key interface dates and that no important dependency disappears at organisational boundaries.

15. Calculate the schedule and perform first-pass quality checks.

Run the network calculation. Review start and finish dates, milestone sequence, long activities, open ends, constraints, lags, calendar effects and areas of unusual float. Do not treat the first calculated result as correct merely because the software produced dates.

16. Validate the schedule with delivery stakeholders.

Walk through the plan by workstream and then end to end. Ask package owners whether the sequence is executable, whether durations are credible, whether interfaces are complete and whether responsibilities are understood. Challenge optimistic assumptions and resolve contradictions. Capture unresolved assumptions visibly rather than burying them.

17. Record the planning basis and unresolved assumptions.

Prepare a concise Schedule Basis or equivalent record covering data date, scope basis, calendars, duration assumptions, key interfaces, external dependencies, resource assumptions, constraints, exclusions and areas of uncertainty. Link significant assumptions to risks where appropriate.

18. Complete readiness checks for baseline or control use.

Confirm traceability to scope, coding completeness, milestone definitions, schedule ownership, progress-measurement readiness and integration with cost and risk. If the schedule is to become part of the integrated baseline, route it through the M1.3 baseline-readiness and approval process rather than simply labelling the latest schedule “baseline”.

4. Worked Reference Project example

The Community & Learning Centre provides a neutral example because the learner does not need specialist engineering knowledge to understand the sequence. Consider the Digital & Technology Systems workstream (WBS 1.4). The project needs functioning network, user devices, room technology and supporting systems before operational-readiness testing can complete.

A weak schedule might contain one activity called “Install IT – 60 days” ending shortly before opening. That activity provides little control value. It hides design, procurement, area readiness, installation, configuration and acceptance, and it gives management no visibility of which interface is driving the work.

A more useful planning breakdown might include:

·       1.4.10 Confirm operational and user technology requirements — 10 working days.

·       1.4.20 Complete detailed technology design — 15 working days.

·       MS-1.4-01 Technology design approved — milestone.

·       1.4.30 Prepare and issue procurement package — 10 working days.

·       1.4.40 Tender, evaluate and award technology supply package — 25 working days.

·       1.4.50 Manufacture / configure off-site equipment — 30 working days.

·       MS-1.2-AREA-A Area A ready for technology installation — interface milestone from Site & Building.

·       1.4.60 Install containment, cabling and network equipment in released areas — 15 working days.

·       1.4.70 Configure network and room systems — 10 working days.

·       1.4.80 Integrate and test technology systems — 8 working days.

·       1.4.90 User acceptance and defect close-out — 5 working days.

·       MS-1.4-READY Technology systems ready for operational-readiness testing — milestone.

This is still only a planning fragment. M2.2 will establish and challenge the detailed relationships. However, even before detailed logic analysis, the learner can see several important interfaces. Technology design depends on sufficiently mature operational requirements. Installation depends on building areas being physically ready and secure. Testing depends on power and network services. User acceptance requires operational representatives to be available. The final readiness milestone feeds WBS 1.6 Operational Readiness, Testing & Handover and ultimately the fixed public opening date.

Example: duration basis rather than target fitting

Assume 120 room technology endpoints need installation. The delivery team expects one crew to complete approximately 8 endpoints per working day once areas are released. A first estimate is therefore 15 working days. If management wants the activity completed in 8 days, the appropriate question is not “Can we type 8 days into the schedule?” but “What has to change?” Perhaps a second crew can be mobilised, productivity can be improved through pre-configuration, or areas can be released earlier. The schedule should make the operational assumption visible.

Example: calendars

The main project team uses a five-day calendar. The technology supplier can perform off-site configuration six days per week, but on-site installation is restricted to normal site access hours. The schedule may therefore use different calendars for off-site and on-site activities. The learner should understand that a nominal 10-day duration can produce different elapsed dates depending on the calendar and that linked activities on different calendars need careful review.

Example: milestone definitions

“Area A ready for technology installation” should not simply mean that the building team considers its own work substantially complete. The interface definition might require the area to be weather-tight, permanent power available, ceilings accessible where necessary, dust-producing work complete and safe access provided. That definition converts a vague date into a controllable handover condition.

Example: the fixed opening date

The Reference Project has a fixed public opening date. That is a genuine project requirement, but the schedule should not be manipulated to guarantee it. The planning model should calculate whether design, procurement, delivery, testing and operational readiness can achieve the date. If the calculated forecast later moves beyond it, the variance is management information. Recovery or scope decisions can then be considered transparently rather than hidden by hard constraints.

Example: integration with the rest of M1 and M2

The Digital & Technology activities carry the WBS and control codes created under M1.2. Their planned dates and time-phased costs will form part of the integrated baseline governed by M1.3. Progress methods for design, procurement, installation and acceptance are defined under M1.4. Source dates and schedule versions are controlled under M1.5. M2.2 will test logic and criticality, M2.3 will test resource feasibility, M2.4 will status the work and M2.5 will use it to forecast. This is why M2.1 should be treated as the construction of a control model, not merely the production of a Gantt chart.

5. Interpretation and professional judgement

A technically complete schedule is not automatically a credible schedule. The practitioner needs to make and challenge planning judgements continuously. Several recurring questions are especially important:

·       Does the schedule explain how the authorised scope will actually be delivered, or has it simply reproduced headings from a contract or WBS?

·       Is the level of detail sufficient to expose meaningful progress, responsibility and interfaces without creating maintenance for its own sake?

·       Are long durations justified by the nature of the work, or are they hiding multiple steps that need different dependencies or progress evidence?

·       Are very short activities genuinely useful for control, or do they create false precision and clutter?

·       Do activity names describe observable work clearly enough that someone outside the immediate team can understand them?

·       Are milestones objectively defined outcomes, or are they labels whose completion criteria will later be disputed?

·       Are calendars realistic and approved, or have working patterns been changed simply to recover a target date on paper?

·       Are durations based on quantities, productivity, supplier commitments or credible judgement, or have they been reverse-engineered from desired dates?

·       Are important external dependencies visible in the schedule even when they are outside the project manager’s direct control?

·       Are interface dates jointly understood by both the giving and receiving parties?

·       Does the schedule distinguish a fixed requirement from an internal management target?

·       Are resource assumptions at least plausible before detailed optimisation?

·       Can higher-level milestones be traced to the underlying work, or are they manually maintained?

·       Would the schedule respond credibly if a major activity were delayed, or would constraints and manual dates prevent the impact from flowing?

·       Are important planning assumptions visible enough to be turned into risk, action or decision where needed?

One of the most important professional judgements is deciding when to stop adding detail. More activities are not automatically better. The schedule should contain enough detail to represent the delivery model and support control. If an additional activity changes no decision, ownership, dependency, progress rule, resource assumption or forecast insight, it may add little value.

Another important judgement concerns uncertainty. A schedule is usually built before everything is known. The answer is not to wait for perfect information, nor to hide uncertainty behind precise dates. Plan with the best available information, record material assumptions, identify risks and progressively refine the schedule as definition improves. This is especially important for early design and procurement where false precision can create unjustified confidence.

The schedule professional should also be willing to challenge infeasible commitments. If the only way to meet a required date is to assume unapproved seven-day working, unlimited specialist resources and zero approval time, the schedule is not demonstrating achievability. It is demonstrating the assumptions that would be required. That distinction is valuable management information.

Questions the practitioner should be able to answer

·       What delivery strategy does this schedule represent?

·       Where is each major scope element represented?

·       What are the key project and interface milestones, and what precisely do they mean?

·       Why is the schedule detailed to this level?

·       Which activities have duration assumptions that are especially important or uncertain?

·       Which calendars materially affect the dates?

·       What must the project receive from external parties, and when?

·       Which workstreams are most tightly coupled through interfaces?

·       What resource or productivity assumptions could make the plan infeasible?

·       Which dates are genuine constraints and which are calculated or target dates?

·       What planning assumptions should become risks or management actions?

·       How will the schedule be measured, updated and reconciled once delivery starts?

6. Practice diagnostic

Use this table to challenge the quality of the approach or deliverable. The rows consolidate the most important recurring red flags and checks; they are prompts for professional judgement rather than a substitute for the method above.

7. Try-it-yourself practical exercise

Using the Community & Learning Centre Reference Project, develop a controlled first-pass schedule model rather than simply drawing a bar chart:

1. Write a one-page delivery strategy covering Definition, Design, Procurement, Delivery, Testing, Handover and Opening. Explain any deliberate overlap between phases.

2. Create a milestone framework of at least 12 milestones, including design approval, one procurement award, two cross-workstream interface handovers, testing readiness, handover and the fixed public opening. Define the acceptance condition for each milestone.

3. Select two Level-1 WBS elements, one of which must be Digital & Technology Systems or Furniture & Specialist Equipment. Decompose them into at least 30 meaningful activities in total.

4. Give every activity a clear verb-object name, WBS code, responsible owner/team, package code and planned calendar.

5. Define the calendars required for the exercise. Include at least one different working pattern and explain why it is legitimate.

6. Estimate the duration of at least ten activities using an explicit basis such as quantity/productivity, supplier lead time, analogous work or structured expert judgement. Record the calculation or rationale.

7. Identify at least eight external or cross-workstream interfaces. State what must be provided, by whom, to whom, and what objective condition defines successful handover.

8. Establish the initial dependency network. Do not optimise it yet; focus on making the physical and information flow credible. M2.2 will be used to perform the deeper logic and critical-path analysis.

9. Identify any genuine fixed-date constraints or no-earlier-than restrictions. For each one, record the source and explain why it cannot simply be calculated by normal logic.

10. Identify at least three obvious resource or productivity feasibility concerns that should be tested later in M2.3.

11. Calculate the schedule and inspect the resulting dates. Identify at least five outcomes that appear surprising, optimistic or operationally questionable and investigate why.

12. Conduct a simulated planning review with the “Site & Building”, “Technology”, “Operations” and “Procurement” leads. Record at least six challenges or changes arising from the review.

13. Produce a concise Schedule Basis covering scope status, data date, calendars, duration assumptions, interfaces, constraints, resource assumptions, exclusions and major uncertainties.

14. Identify at least five planning assumptions that should also appear in the risk or action process.

15. Produce a one-page schedule-readiness note stating whether the model is ready to proceed to detailed M2.2 logic assurance and eventual M1.3 baseline approval, together with any conditions that must first be resolved.

What good performance looks like

The exercise is successful when the learner can explain the delivery plan in ordinary language, trace the schedule back to authorised scope, justify the chosen level of detail, show credible duration and calendar assumptions, expose the important interfaces, and explain why the resulting model is useful for control. The objective is not a perfect schedule on the first attempt; it is a transparent, challengeable planning model that can now be strengthened through the logic, resource and update disciplines that follow.

8. Bridge to capability

The How-to teaches how authorised scope and a delivery strategy become a credible schedule. At APPLIED and above, capability assessment should test whether the practitioner can develop and challenge a realistic model, justify its assumptions and identify weak interfaces. Scope links, activity definitions, calendars, duration evidence and a documented schedule basis should support the assessment. Supporting work products are illustrative and should be assessed with the practitioner’s reasoning. Sample learning questions illustrate the judgement at each recognition level; they are discussion prompts rather than validated assessment items.

Learning question: Do you understand how a delivery strategy is represented in a schedule?

Capability question for APPLIED and above: Can you demonstrate a scope-linked schedule, defend its assumptions and explain how the work can actually be delivered?