1.4 Contract Requirements and Delivery Constraints

1.4 Contract Requirements and Delivery Constraints

The official PSP scope begins planning inputs with contract requirements. Before building activities, the planner must understand what the project has promised to deliver, when access and decisions will occur, how performance will be demonstrated, and which schedule submittals the parties require.

Build the document hierarchy

Project requirements may come from the agreement, general and supplementary conditions, statement of work, drawings, specifications, addenda, permits, owner standards, proposal clarifications, and executed changes. A planning team should know the document-precedence clause and should not resolve a conflict by silently choosing the most convenient source.

A requirements matrix makes the input traceable:

Extract time obligations

Look for more than final completion. The plan may need:

• notice-to-proceed and access dates;
• sectional, interim, turnover, and substantial-completion milestones;
• owner-furnished information or equipment dates;
• review and approval periods;
• procurement lead times and required-on-site dates;
• environmental, safety, traffic, or operating windows;
• testing, commissioning, training, and closeout obligations;
• notice deadlines and change-evaluation procedures; and
• update, narrative, coding, cost-loading, and recovery-schedule requirements.

Contractual dates should be recognizable in the schedule and traceable to their source. Internal targets can be more aggressive, but label them as internal so they are not mistaken for contractual commitments.

Delivery strategy changes planning interfaces

Design-bid-build, design-build, engineering-procurement-construction, construction management, and multiple-prime arrangements allocate design and coordination differently. A design-build schedule may integrate design release, procurement, and construction packages. A design-bid-build plan may contain more owner/designer review interfaces before construction. The delivery model influences who supplies information and controls an interface; it does not excuse incomplete logic.

Payment type also affects controls. Lump-sum work may use a schedule of values; unit-price work may rely on measured quantities; cost-reimbursable work may emphasize authorization and cost collection. In every case, the schedule must represent the physical and managerial plan rather than merely reproduce billing lines.

Translate prose into model elements

Use the least distorting treatment:

• a zero-duration milestone for a required event;
• an activity for work or review that consumes time;
• a calendar for recurring working restrictions;
• a relationship for a real dependency; and
• a constraint only when an external date must be represented and its effect is understood.

Do not replace a review activity with a finish constraint simply because both show the same date in the baseline. The activity preserves duration, responsibility, and logic; the constraint can hide the actual interface.

Resolve ambiguity

When documents conflict, log a request for interpretation. Model the current approved assumption, identify it in the schedule basis, and assess alternatives when the difference can affect a milestone. A planner should not provide unauthorized legal interpretation, but must expose the schedule consequence of unresolved language.

Quality check

Before baseline approval, reconcile the requirements matrix to the WBS, milestone list, calendars, schedule specification, risk register, and change log. Each material time obligation should have an explicit home. This prevents late discovery of omitted turnovers, assumed access, or unrealistic review periods after the network has already been accepted.

Applied review: turn obligations into model tests

A useful requirements matrix is not merely a document index. For each requirement, record the controlling source and clause, the responsible party, the promised event or performance, the schedule representation, the evidence that will confirm completion, and any unresolved interpretation. For example, an owner-furnished equipment date may require an owner procurement chain, a delivery milestone, an inspection activity, and a successor installation activity. A contractual completion milestone may also require separate internal targets that preserve management flexibility without being mislabeled as contractual dates.

Test each extracted requirement against the schedule. Can a reviewer trace a required notice period to logic? Do owner review durations match the governing documents? Are seasonal restrictions represented by activities or calendars that users can understand? Does a milestone describe a real event, and is the work needed to achieve it modeled? If two documents conflict, log the conflict and obtain direction; do not silently choose the convenient interpretation.

On an exam scenario, separate three ideas: the obligation stated by the contract, the planner's technical model of how the obligation can be achieved, and a management target adopted for control. The source controls the first, sound planning supports the second, and management may set the third. Keeping those categories visible prevents an internal goal from becoming an invented contract term and prevents a contract milestone from disappearing inside a summary bar.