Calendars, Constraints and Schedule Quality

Introduction

A network schedule is not merely a logical sequence of activities. It is a time-based model of how work will be performed under real operating conditions. Those conditions include working days, shifts, public holidays, resource availability, contractual deadlines, regulatory dates, weather windows, supplier commitments, and interfaces with parties outside the project team. If these conditions are represented inaccurately, the calculated completion date and critical path may be mathematically correct but operationally meaningless.

Calendars and constraints therefore connect network analysis with project reality. Calendars determine when work may occur; constraints restrict when work must or must not occur; schedule-quality diagnostics test whether the resulting plan is logically sound, transparent, and useful for control. Professional scheduling is not the practice of adding dates until a desired finish is obtained. It is the disciplined construction of a time model whose assumptions can be explained, audited, updated, and defended.

This chapter develops a practical and analytical approach to working calendars, shifts, holidays, deadlines, imposed dates, external interfaces, hard and soft constraints, and schedule-quality assessment.

Learning objectives

By the end of this chapter, the reader should be able to:

1. distinguish project, activity, resource, and exception calendars;
2. model shifts, holidays, non-working periods, and cross-time-zone work;
3. distinguish logical relationships from imposed dates and external interfaces;
4. evaluate hard, soft, and unjustified constraints;
5. explain how constraints affect float and the critical path;
6. apply recognized schedule-quality diagnostics;
7. identify weak logic, excessive constraints, open ends, and calendar defects; and
8. recommend governance and corrective actions for a credible baseline schedule.

1. Calendars as a scheduling model

A calendar specifies the time intervals during which an activity, resource, or project is available for work. In a simple five-day calendar, Monday through Friday may be working days and Saturday and Sunday non-working days. In practice, calendars are often more complex: a construction project may operate two ten-hour shifts, a data-centre migration may use night windows, and a global programme may coordinate teams in several time zones.

A calendar has at least four components:

• Regular working pattern: recurring working days and hours;
• Exceptions: holidays, shutdowns, maintenance periods, elections, weather seasons, or approved leave;
• Time-zone basis: the time standard used to interpret dates and times;
• Applicability: the project, activity, resource, or location to which the calendar applies.

The schedule engine calculates dates by moving through available calendar time rather than through abstract elapsed time. Consequently, “five days” may mean five working days, five calendar days, five shifts, or 120 elapsed hours. These are not interchangeable.

1.1 Calendar hierarchy

Most scheduling systems support several calendar levels. The names vary by software, but the concepts are broadly similar.

A project calendar should be the default, not the only calendar. For example, concrete curing may continue through a weekend even though labour installation does not; a software release may be permitted only during a Saturday night maintenance window; and a regulatory review may be performed only during government office hours.

1.2 Duration and available time

For an activity with a duration measured in working hours, the schedule must identify the relevant calendar. If the activity begins at time t₀ and requires D working hours, its finish is the first point at which D hours of permitted working time have elapsed. This is a calendar operation, not simply the addition of D hours to the start timestamp.

For example, suppose a calendar permits 8 hours per day from Monday to Friday, and an activity requires 24 working hours beginning Monday at 09:00. The activity completes at the end of Wednesday’s working period, assuming no break or exception. If Tuesday is a holiday, it completes at the end of Thursday instead.

The relation between duration and effort must also be controlled. Duration is elapsed working time for an activity; effort is the amount of labour or resource time required. With one full-time resource, 16 labour-hours may correspond to two eight-hour working days. With two equally productive resources, it may be completed in one working day, subject to whether the work is divisible and whether the activity is technically capable of parallel execution.

A useful planning distinction is:

• Duration: time from activity start to activity finish;
• Effort: total resource-hours required;
• Units or loading: rate at which resources are assigned;
• Availability: time during which the resources can work.

Confusing these terms produces schedules that appear short but cannot be executed.

2. Shifts, holidays, and special working conditions

2.1 Shift calendars

A shift calendar defines recurring work periods, such as 06:00–14:00, 14:00–22:00, and 22:00–06:00. Night shifts require particular care because the shift may begin on one calendar date and end on the next. The schedule should identify whether the shift belongs operationally to its start date, end date, or a named production day.

Shift planning should address:

• handover time between shifts;
• meal and statutory breaks;
• minimum rest periods;
• supervision and safety coverage;
• equipment availability and maintenance;
• noise or environmental restrictions;
• reduced productivity during night work; and
• whether predecessor completion can be recognized at shift handover.

A nominal 24-hour operation is not necessarily 24 productive hours. Handover, access control, inspection, cleaning, and permit renewal may reduce effective capacity.

2.2 Holidays and shutdowns

Holidays should be entered as calendar exceptions rather than silently extending individual activities. A single approved holiday entered in the project calendar will affect all activities using that calendar and will be visible for audit. By contrast, manually changing several activity dates hides the cause of the delay and can damage network logic.

Shutdowns may be:

• known and recurring, such as annual factory closure;
• known and project-specific, such as a planned site shutdown; or
• uncertain, such as weather or industrial action.

Known shutdowns belong in the baseline calendar. Uncertain events should normally be handled through risk analysis, contingency, scenario schedules, or explicit assumptions rather than presented as certain calendar facts.

2.3 Time zones and daylight-saving changes

International schedules should state a reference time zone. A deadline of 17:00 may mean local time at the receiving organisation, not the project headquarters. Systems integration across locations must account for daylight-saving changes where applicable. The safest practice is to record timestamps with a time-zone identifier and to define the business meaning of the date separately from its display format.

2.4 Weather and seasonal calendars

Weather-sensitive work may be governed by a seasonal calendar or by probabilistic risk rather than a simple working/non-working flag. For example, roof installation may be prohibited during forecast high winds. A deterministic calendar can represent a planned seasonal closure, but forecast uncertainty should be managed through risk registers, weather allowances, and short-term look-ahead planning. Treating every possible adverse-weather day as non-working can make the baseline unnecessarily pessimistic; treating none as non-working can make it unrealistic.

3. Dates, deadlines, and external interfaces

A date in a schedule may have very different meanings. The distinction is essential.

• Forecast date: the date currently expected from the network calculation;
• Baseline date: the approved planned date against which performance is compared;
• Actual date: the date on which an event occurred;
• Deadline: a date by which an outcome must be achieved;
• Imposed date: a date inserted into the model to restrict an activity;
• External interface date: a date controlled by another project, supplier, regulator, or operational body;
• Milestone: a zero-duration event representing an achievement or decision point.

A contractual completion date may be a deadline, but it is not automatically a logical predecessor. The activities that make completion possible should be connected through credible relationships. A deadline is an obligation or boundary; logic explains how the work reaches the boundary.

3.1 External interfaces

An external interface is a dependency whose controlling work lies outside the schedule’s direct authority. Examples include:

• delivery of a client-furnished component;
• approval by a planning authority;
• access to an operational facility;
• completion of another project;
• utility connection;
• release of a software environment; and
• a supplier’s certified test result.

External interfaces should be represented by interface milestones or activities with named owners, required dates, assumptions, and confirmation mechanisms. A statement such as “vendor delivery on 1 September” is weaker than an interface record specifying the vendor, purchase order, delivery scope, responsible manager, required-by date, and evidence of readiness.

The schedule should not imply control where none exists. External dates should be risk-linked and monitored through interface registers. If the date is uncertain, the schedule may show a planning assumption while the risk register records the uncertainty and response strategy.

4. Hard and soft constraints

A constraint is a rule that limits an activity’s permissible timing. Constraints are useful when they represent genuine business, technical, legal, or operational conditions. They are harmful when they conceal missing logic or are used to force an attractive completion date.

4.1 Hard constraints

A hard constraint cannot be violated without making the plan infeasible or non-compliant. Examples include:

• a regulatory hearing that occurs on one specified date;
• a facility that cannot be accessed before possession is granted;
• a long-lead item that cannot be available before manufacture;
• a safety rule prohibiting simultaneous operations; and
• a contractual event with a legally binding date.

Even a hard constraint should be documented. “Hard” describes the consequence of violation, not the quality of the evidence supporting it.

4.2 Soft constraints

A soft constraint expresses a preference, target, or management objective. Examples include finishing before a preferred reporting date, aligning an activity with a budget cycle, or avoiding weekend work where alternatives exist. Soft constraints should normally be represented through logic, priorities, resource planning, or documented target milestones rather than by forcibly fixing activity dates.

4.3 Constraint classifications

Common scheduling systems provide constraint types such as:

• As Soon As Possible: activity starts at the earliest date permitted by logic and calendars;
• As Late As Possible: activity is placed as late as possible without delaying a defined successor or project finish;
• Start No Earlier Than: activity cannot start before a specified date;
• Finish No Later Than: activity must finish by a specified date;
• Must Start On: activity start is fixed;
• Must Finish On: activity finish is fixed.

The exact names and calculation effects differ across systems. The scheduler must therefore document the software interpretation and avoid assuming that similarly named constraints behave identically.

4.4 Why excessive constraints are dangerous

Constraints can reduce visible float, fragment the critical path, create artificial criticality, and prevent the schedule from responding naturally to progress updates. A fixed date may hide the fact that no predecessor exists. A “must finish on” date may cause negative float without explaining the actual recovery action. Excessive constraints can also make it difficult to distinguish a genuine delay from a modelling rule.

A disciplined constraint review asks:

1. What requirement necessitates the constraint?
2. Who owns or authorizes it?
3. Is evidence available?
4. Is the date fixed, bounded, or merely preferred?
5. Could normal network logic represent the requirement more transparently?
6. What happens if the constraint is missed?

5. Constraints and critical path calculations

In a conventional activity-on-node network, the forward pass calculates early dates and the backward pass calculates late dates. For an activity i with duration dᵢ, its early finish is conceptually:

where ESᵢ is early start, EFᵢ is early finish, and dᵢ is working duration under the applicable calendar. In an actual scheduling engine, the addition is calendar-based and may not equal ordinary clock-time addition.

For a finish-to-start relationship from predecessor i to successor j with lag Lᵢⱼ:

Here Lᵢⱼ is expressed in compatible working or elapsed units according to the relationship definition. The inequality indicates that the successor cannot start before the predecessor condition and lag are satisfied.

Total float is commonly expressed as:

where LS and LF are late start and late finish. The identity assumes a consistent forward and backward pass, a defined project completion requirement, and compatible calendar treatment. Activities with approximately zero total float are often described as critical, but the threshold and interpretation should be governed by the scheduling method and reporting standard.

A date constraint changes the feasible region of the network. If a finish-no-later-than constraint requires project completion earlier than the unconstrained calculated finish, negative float may result. Negative float is not a scheduling solution; it is an indicator that the current network cannot meet the imposed requirement under its assumptions.

Worked example: calendar and constraint effects

Assume an activity requires 16 working hours. The project calendar allows eight hours per day, Monday to Friday. It starts Monday at 08:00. With no exception, it finishes Tuesday at 17:00, assuming a one-hour unpaid break is excluded from the eight productive hours.

If Tuesday is a holiday, the activity finishes Wednesday at 17:00. If a successor requires two working days and must finish no later than Friday, the holiday may consume available float or create negative float. The appropriate response is not automatically to remove the holiday. The project manager should test legitimate alternatives: an approved additional shift, resequencing, increased resources, or negotiation of the deadline.

6. Schedule quality

Schedule quality is broader than whether the calculated finish date looks acceptable. A high-quality schedule is logically sound, complete enough for its purpose, time-scaled, resource-aware where required, traceable to scope, and capable of supporting forecasting and control.

6.1 Dimensions of quality

6.2 Recognized professional diagnostics

Professional scheduling organizations and major industry guidance commonly emphasize logic quality, critical-path transparency, baseline control, and consistent status updating. One widely used family of diagnostics is the DCMA 14-point assessment. Its exact thresholds and interpretation should be checked against the applicable organizational standard, but typical checks include:

• missing logic;
• excessive use of start-to-finish relationships;
• excessive lags;
• excessive leads or negative lags;
• high activity durations;
• high proportion of constrained activities;
• high proportion of negative float;
• invalid or missing baseline data;
• high percentage of out-of-sequence progress;
• significant difference between forecast and baseline dates; and
• excessive float or suspiciously low float patterns.

These diagnostics are screening tools, not automatic proof of failure. A high lead percentage may be legitimate in a particular industry, while a low percentage may still conceal poor logic.

Other recognized practices include the GAO Schedule Assessment Guide, AACE planning and scheduling guidance, PMI scheduling practices, and forensic scheduling principles. Their common themes are that the schedule should be comprehensive, logically linked, statusable, traceable, and based on documented assumptions.

6.3 Logic diagnostics

A robust logic review should identify:

• activities with no predecessor, except legitimate project starts;
• activities with no successor, except legitimate project finishes;
• isolated subnetworks;
• excessive dangling activities;
• inappropriate relationship types;
• excessive lags and leads;
• circular relationships;
• relationships that contradict technical sequence; and
• out-of-sequence progress.

Finish-to-start relationships are often the clearest default. Start-to-start and finish-to-finish relationships may be appropriate where overlap is real, but they require explicit explanation. Leads can obscure work that should instead be represented as a separate activity or a legitimate overlap. Lags should have a business or technical basis, such as curing time, statutory notice, or transport duration.

6.4 Duration and granularity diagnostics

Activities that are too long are difficult to status and may hide internal logic. Activities that are too short create administrative burden and false precision. The appropriate level depends on control needs, uncertainty, reporting frequency, and work type. A two-month design activity may be acceptable for a high-level portfolio schedule but inadequate for a weekly engineering control schedule.

Duration thresholds should be treated as indicators rather than universal laws. The right question is whether the activity can be objectively measured, assigned, forecast, and linked to meaningful deliverables.

6.5 Float diagnostics

Total float should be interpreted in relation to the project’s imposed completion date, calendars, constraints, and data date. Extremely high float may indicate missing logic or an over-optimistic relationship; negative float may indicate an infeasible deadline; and multiple disconnected critical paths may indicate parallel controlling chains.

Free float, where used, measures the amount of time an activity can be delayed without delaying the early start of a successor. Its calculation depends on the network and calendar rules. Float is a calculated property, not a management reserve. Consuming float is not automatically a problem, but it should trigger analysis when it threatens a milestone or reduces risk response capacity.

6.6 Schedule health dashboards

A schedule-health dashboard may report:

• percentage of activities with missing predecessors or successors;
• number and percentage of constrained activities;
• number of negative-float activities;
• percentage of relationships by type;
• count of leads and lags;
• average and maximum activity duration;
• percentage of out-of-sequence activities;
• baseline completeness;
• critical-path stability between reporting periods; and
• forecast variance against approved milestones.

Metrics must have definitions, data dates, thresholds, owners, and corrective actions. A dashboard without governance can encourage teams to optimize the metric rather than improve the schedule.

7. A disciplined schedule-quality review

A practical review can proceed through six stages.

Stage 1: Establish the basis

Confirm the approved scope, work breakdown structure, calendars, data date, contractual milestones, resource assumptions, coding structure, and schedule purpose. A design schedule and a commissioning schedule may legitimately require different granularity.

Stage 2: Review calendars

Compare calendars with site agreements, labour rules, supplier commitments, maintenance windows, permits, and local holidays. Check whether exceptions have owners and expiry dates. Verify that durations use compatible units.

Stage 3: Test network logic

Run automated diagnostics, then perform a technical review with subject-matter experts. Verify that relationships represent actual dependency mechanisms rather than merely desired dates.

Stage 4: Examine constraints and external dates

Classify each constraint as hard, soft, or unsupported. Confirm evidence and ownership. Trace external dates to interface records and test sensitivity if the date moves.

Stage 5: Assess critical and near-critical paths

Review the driving chain to major milestones, not only the single path labelled “critical.” Examine near-critical paths because they may become controlling after a small delay. Confirm that the reported path is technically credible.

Stage 6: Document findings and actions

Each finding should state the observation, consequence, evidence, owner, corrective action, due date, and closure criterion. Changes should be controlled through baseline and change-management procedures.

8. Applied case: hospital imaging-suite upgrade

The following is an illustrative case.

Background

A hospital plans to replace an imaging system in an existing diagnostic suite. The work involves demolition, shielding modifications, equipment delivery, electrical upgrades, software configuration, regulatory inspection, clinical acceptance, and a planned service outage. The hospital operates continuously, but noisy construction is permitted only from 19:00 to 06:00. The equipment supplier requires a clear delivery route and a stable environmental condition before installation.

Problem

The initial schedule shows a six-week completion period and meets the executive target date. However, the schedule uses a standard Monday–Friday calendar for all activities, includes a “must finish on” constraint for clinical acceptance, and treats supplier delivery as an unconnected milestone. It also assumes that regulatory inspection can occur on any working day.

Analysis

The project team identifies four calendar types: hospital access, night construction, supplier installation, and regulator office hours. A public holiday falls during the planned installation period. The regulator confirms that inspections require five working days’ notice and occur only on specified weekdays. The supplier delivery date is a commitment but remains exposed to manufacturing risk.

The quality review finds:

• the delivery milestone has no predecessor representing manufacturing and transport;
• the acceptance constraint hides a missing regulatory predecessor;
• demolition is shown as daytime work although the permit allows only night work;
• equipment installation duration is measured in calendar days while the supplier calendar uses shifts; and
• the schedule has negative float when the regulatory date is modelled honestly.

Approach and solution

The team replaces the fixed acceptance constraint with explicit logic: equipment installation → software configuration → regulatory inspection → clinical acceptance. A supplier interface milestone is linked to procurement, factory test, transport, and site-readiness activities. The project calendar includes the holiday, while night work is represented through an activity calendar. The regulatory inspection is placed on the regulator’s calendar with the required notice relationship.

The team then evaluates options: negotiate an earlier inspection slot, add a second installation shift, or move clinical acceptance. The hospital chooses an earlier inspection reservation and authorizes one additional supplier shift, subject to safety approval. The risk register records the supplier delivery exposure, and the interface manager receives weekly confirmation from the vendor.

Outcome

The schedule now forecasts completion four working days later than the original presentation schedule, but the date is credible and supported by traceable logic. The negative float is eliminated after the inspection slot is formally secured. The executive team accepts the revised date because the schedule explains both the obligation and the recovery actions.

Learning points

1. A fixed milestone cannot substitute for missing technical logic.
2. Calendar accuracy may be more important than apparent duration precision.
3. External interfaces require named owners and evidence.
4. A later credible forecast is more valuable than an earlier artificial forecast.
5. Constraints should be reviewed together with risk, contracts, and operational governance.

9. Governance, ethics, and technology

Schedule information influences contracts, funding, staffing, safety decisions, and public commitments. Deliberately manipulating calendars, durations, constraints, or status dates to produce a favourable forecast is a governance failure. It can also create safety risk if unrealistic work windows encourage excessive overtime or unsafe simultaneous operations.

Schedule governance should define:

• who may create or alter calendars;
• approval requirements for constraints;
• baseline and change-control procedures;
• status-date conventions;
• treatment of actuals and remaining duration;
• audit trails and version retention; and
• escalation rules for negative float and missed interfaces.

Modern scheduling tools can identify dangling activities, unusual lags, unstable critical paths, and patterns associated with poor updates. Artificial intelligence may assist by classifying risks, detecting anomalous durations, or comparing current logic with historical projects. However, AI output is advisory. It may misunderstand contractual language, local calendars, exceptional technical conditions, or deliberate strategic choices. Human schedulers remain responsible for validation, explainability, data quality, and professional judgement.

10. Best-practice principles

The following principles provide a concise professional standard:

1. Use calendars to model real working conditions, not to hide desired dates.
2. Define the time zone and the meaning of each date.
3. Prefer explicit network logic to unnecessary imposed dates.
4. Document every hard constraint and challenge unsupported soft constraints.
5. Represent external interfaces with owners, evidence, and risk treatment.
6. Use durations and units that match the calendar and reporting purpose.
7. Review critical and near-critical paths after every significant update.
8. Combine automated diagnostics with expert technical review.
9. Treat negative float as a management signal, not as a solution.
10. Preserve auditability through controlled baselines and change records.

Chapter Summary

Calendars determine when scheduled work can occur, while constraints define limits or preferences on activity timing. Accurate scheduling requires explicit treatment of regular work patterns, shifts, holidays, shutdowns, time zones, weather windows, and resource availability. Deadlines and external interfaces must be distinguished from logical relationships and represented with clear ownership and evidence.

Hard constraints reflect genuine legal, technical, operational, or contractual boundaries. Soft constraints express preferences and should not be used to conceal missing logic. Excessive or unsupported constraints can create artificial critical paths, suppress float, and make forecasts difficult to interpret. Calendar-based forward and backward passes determine early dates, late dates, and float, but these calculations are meaningful only when the underlying model is realistic.

Schedule quality should be assessed through completeness, logic, calendar accuracy, constraint discipline, traceability, update integrity, and forecast usefulness. Diagnostics such as missing-logic checks, relationship analysis, duration and float reviews, constraint counts, baseline checks, and out-of-sequence-progress analysis provide evidence for improvement. Professional judgement remains essential because numerical thresholds are indicators rather than universal proof of quality.

A high-quality schedule is transparent, technically credible, auditable, and useful for decisions. Its value lies not in producing the earliest apparent finish, but in explaining what must happen, when it can happen, what controls the outcome, and what action is available when assumptions change.

Key Terms

Calendar: A definition of permitted working time for a project, activity, resource, or location.

Project calendar: The default working pattern applied to project activities.

Activity calendar: A calendar defining special working periods for a particular activity.

Resource calendar: A record of when a person, crew, plant item, or facility is available.

Exception: A temporary departure from a regular calendar pattern.

Shift: A defined period of work within an operating cycle.

Deadline: A date by which an outcome must be achieved.

Imposed date: A date entered to restrict the timing of an activity or milestone.

External interface: A dependency controlled by another organization, project, supplier, or authority.

Hard constraint: A restriction that cannot be violated without making the plan infeasible or non-compliant.

Soft constraint: A preferred timing condition that may be changed if justified.

Lead: An overlap allowance that permits a successor relationship to begin before the predecessor is fully complete.

Lag: A waiting or separation period inserted between related activities.

Total float: The allowable delay before an activity delays the defined project completion or controlling successor condition.

Free float: The delay available without delaying the early start of a successor.

Negative float: A calculated indication that an imposed completion requirement cannot currently be met.

Out-of-sequence progress: Actual progress that occurs in a sequence different from the network logic.

Data date: The point in time separating actual historical status from future forecast work.

Schedule baseline: The approved time-phased plan used for comparison and control.

Schedule quality: The degree to which a schedule is complete, logical, realistic, traceable, and useful for forecasting.

Review Questions

Short Answer Questions

1. What is the difference between a project calendar and a resource calendar?
2. Why should a known public holiday normally be entered as a calendar exception?
3. Distinguish a deadline from a logical predecessor relationship.
4. What is the principal danger of excessive hard constraints?
5. What does negative float indicate?

Long Answer Questions

1. Explain how shifts, holidays, handovers, and time zones should be represented in a professional project schedule.
2. Compare hard and soft constraints, including examples and governance controls for each.
3. Explain how external interfaces should be modelled, monitored, and linked to risk management.
4. Discuss the principal dimensions of schedule quality and the role of professional diagnostics.
5. Describe a complete schedule-quality review process from schedule basis through corrective-action closure.

Analytical / Application Questions

1. A project uses a Monday–Friday, eight-hour calendar. An activity requires 24 working hours and begins on the day before a public holiday. Analyse the finish-date impact and explain how you would communicate the result.
2. A programme meets its contractual completion date only because twelve activities have “must finish on” constraints and several supplier milestones are unlinked. Diagnose the schedule-quality risks and propose corrective actions.
3. A global technology project has teams in three time zones, a weekend release window, and a regulator inspection that can occur only on Wednesdays. Design a calendar and interface-governance approach that would produce a credible forecast.

Multiple Choice Questions with Answers

Question 1

Which calendar most directly represents the availability of a specific crane or specialist crew?

A. Project calendar

B. Resource calendar

C. Regulatory calendar

D. Baseline calendar

Correct Answer: B. Resource calendar

Question 2

What is the most appropriate treatment for a known public holiday affecting all normal project work?

A. Add an unexplained lag to every activity

B. Enter it as a calendar exception

C. Apply a must-finish constraint to each activity

D. Delete the affected activities

Correct Answer: B. Enter it as a calendar exception

Question 3

Which statement best describes an external interface?

A. A relationship between two activities controlled by the same crew

B. A dependency controlled by another organization, project, supplier, or authority

C. A resource over-allocation within one activity

D. A reporting-period boundary

Correct Answer: B. A dependency controlled by another organization, project, supplier, or authority

Question 4

Which is normally a soft constraint?

A. A statutory inspection date fixed by law

B. A site-access prohibition imposed by safety regulation

C. A preference to complete work before an internal reporting cycle

D. A technically required curing period

Correct Answer: C. A preference to complete work before an internal reporting cycle

Question 5

What does negative float generally indicate?

A. The project has excessive unused contingency

B. The imposed completion requirement cannot currently be met under the model

C. All activities are ahead of plan

D. The project calendar has no holidays

Correct Answer: B. The imposed completion requirement cannot currently be met under the model

Question 6

For a finish-to-start relationship, which condition is generally correct?

A. The successor may start before the predecessor condition is satisfied

B. The successor cannot start before the predecessor finish plus any applicable lag

C. The predecessor must start after the successor finishes

D. The relationship eliminates the need for calendars

Correct Answer: B. The successor cannot start before the predecessor finish plus any applicable lag

Question 7

Which finding is a typical schedule-quality diagnostic issue?

A. Every activity has a named owner

B. A legitimate project-start milestone has no predecessor

C. A major activity has no successor and is not a project finish

D. A calendar includes an approved holiday

Correct Answer: C. A major activity has no successor and is not a project finish

Question 8

Why can excessive constraints reduce schedule usefulness?

A. They always increase resource productivity

B. They can create artificial criticality and conceal missing logic

C. They automatically remove all deadlines

D. They prevent the use of milestones

Correct Answer: B. They can create artificial criticality and conceal missing logic

Question 9

Which information is most important for governing an external supplier milestone?

A. Only the colour used to display it

B. The supplier owner, required date, scope, evidence, and associated risk

C. Only the activity ID

D. The number of unrelated activities in the schedule

Correct Answer: B. The supplier owner, required date, scope, evidence, and associated risk

Question 10

An activity requires 16 working hours on an eight-hour-per-day calendar. Ignoring breaks and exceptions, how many working days are required?

A. One-half day

B. One working day

C. Two working days

D. Four working days

Correct Answer: C. Two working days