25.2 Project Management, Dependencies and Procurement Schedule Risk

Procurement is part of the project schedule

A project's desired completion date does not establish how quickly procurement can lawfully occur. The buyer must coordinate needs definition, funding, market research, approvals, notice, supplier preparation, evaluation, negotiations, award, delivery, installation, testing, and transition. A schedule that omits approval or manufacturing time creates false urgency later. Identify dependencies before promising a date to stakeholders.

A project charter records the objective, scope, sponsor, participants, constraints, and decision authority. A work breakdown structure divides the required work into manageable deliverables or activities. The procurement plan connects those activities to sourcing events and contract responsibilities. A list of desired dates without predecessors, owners, and resources is not a complete plan.

Use dependencies and the critical path

A dependency states what must occur before another activity can start or finish. Some are technical, such as installing equipment before testing it. Others are legal or administrative, such as completing approval before execution. A buyer cannot eliminate a statutory dependency merely by asking a supplier to start early. Review whether activities can lawfully overlap without exposing the entity to an unauthorized commitment.

The critical path is the longest-duration dependency path through the planned network. Under the current assumptions it determines the earliest project completion. Float is the time an activity can be delayed without delaying the relevant completion or successor constraint. Float is not a permanent entitlement: a change to durations, calendars, or dependencies can create a different controlling path.

Worked network example

Assume all durations use business days, resources are available, and there are no additional lags. Activity A is requirements approval and takes five days. B is solicitation preparation and takes eight days after A. C is funding confirmation and takes four days after A. D is final release approval and takes three days after both B and C.

The A–B–D path is 5 + 8 + 3 = 16 business days. A–C–D is 5 + 4 + 3 = 12 business days, so C has four days of float before it would delay D in this simple network. A two-day delay to B moves the earliest finish to day 18 unless the team achieves a valid recovery. A two-day delay to C leaves the earliest finish at day 16. The arithmetic does not justify shortening a legal notice period in a later phase.

Schedule risk and recovery

Record the baseline schedule and the assumptions supporting supplier lead time, review turnaround, staff availability, approval meetings, and testing. Distinguish an issue, which has already occurred, from a risk, an uncertain future event. A supplier's confirmed missed manufacturing slot is an issue; the possibility of port congestion is a risk. Both need owners and responses, but neither should be hidden in an unexplained contingency allowance.

Use a risk register with the event, cause, likelihood, impact, mitigation, trigger, owner, and contingency. A long-lead transformer might require early market engagement, an alternate approved specification, staged delivery, or temporary equipment. Assess the legal method and full cost of each response. Ordering equipment before design approval can save time but create an unusable asset if the design later changes.

Fast-tracking overlaps activities that would otherwise occur sequentially and can increase rework or coordination risk. Crashing adds resources or other cost to shorten activity duration where feasible. Neither technique automatically works on every task. Additional evaluators may not shorten the supplier's statutory response period, and extra inspectors cannot replace a laboratory's required test duration.

Control changes and project information

A change request should identify the scope change, reason, alternatives, cost, funding, schedule effect, risk, and approval authority. Analyze effects on the critical path rather than simply adding every claimed delay to the completion date. Preserve the baseline, approved revisions, and current forecast as separate records so stakeholders can see both commitments and emerging problems.

Communicate status using evidence: completed deliverables, unresolved decisions, forecast dates, cost commitments, and actions needed. “Ninety percent complete” is weak information if the remaining ten percent includes untested security, missing permits, or a critical interface. A milestone should have an objective completion condition and named approver.

Apply the method to a procurement scenario

Suppose a department needs a public-service system operational by September 1. Procurement discovers that the planned schedule ignores two board meetings, a data-migration exercise, and user acceptance testing. The buyer should present a feasible schedule and options with their risks, not promise to compress every activity into an arbitrary emergency purchase.

Work with the project manager to distinguish essential go-live scope from optional later enhancements, verify any phased procurement authority, and plan service continuity. Keep competition, funding, technical readiness, and stakeholder decisions visible. The strongest applied answer addresses the actual dependency and authorized response, rather than choosing the most forceful-sounding instruction to the supplier.