FIELD GUIDE / APPROVALS

How to schedule drawing reviews and approvals

Turn a vague approval allowance into clear submission, response, revision, and release dates.

The main point

An approval date is an assumption until the review cycle, owner, and release scope are clear.

Break 'approval' into events

A single approval bar often hides four different stages: prepare the submittal, send it, receive comments, and issue a usable release. Some packages need more than one cycle. The schedule should distinguish the date your team controls from the date another party controls.

Record the submission package, reviewer, contractual or agreed review period if one exists, expected response, revision allowance, and the scope that can be released afterward. Do not invent a guaranteed review duration; confirm the project-specific expectation and label an unconfirmed estimate.

  • Use a submission milestone with evidence of transmission.
  • Track the response due date and actual response date separately.
  • Define what 'approved for production' means for this package.

Plan from the release needed by the shop or field

Work backward from the date purchasing or production needs the released information. Add time for your revisions and internal checking, then the agreed external review period. This gives a latest practical submission date. If it is already past, flag the conflict immediately rather than compressing the review period on paper.

For phased work, plan releases by area or system. A complete building-wide approval may not be necessary to begin a specific fabrication sequence, but partial release must be explicit about what is and is not authorized.

  • Tie each release to the work it unlocks.
  • Show the latest submission date as a planning target.
  • Avoid assuming a partial approval covers the whole scope.

Manage comments without losing the schedule

When comments arrive, distinguish clarification from redesign. The former may fit inside the planned revision allowance; the latter may affect procurement, quantities, or installation. Update the schedule using the actual response date and the realistic revision effort. Preserve the prior baseline so the team can explain what changed.

Escalation should be specific: identify the package, the response needed, the downstream release, and the milestone it supports. A generic 'drawings late' message gives the recipient little to act on.

  • Log each review cycle and its disposition.
  • Separate a pending decision from drafting time.
  • State the downstream effect in a follow-up request.

Worked example

A glazing team needs a confirmed opening dimension before ordering fabricated units. The drawing package was submitted on time, but a structural opening detail remains unresolved. The schedule should show the open decision as a predecessor to measurement confirmation and ordering, rather than mark all shop drawings 'in review'.

If other elevations are ready, release them separately. The unresolved area remains visible, and the team can decide whether a partial purchase is economical without overstating progress.

  • One unresolved detail need not freeze unrelated areas.
  • The schedule should show the purchasing consequence of a late response.

Make the drawing log and schedule agree

The drawing log often has more detail than the schedule. That is fine, but each schedule release should point to the package or area in the log. If one late detail governs production, the PM must be able to identify it without searching every line of a submittal register.

Use a regular cut-off for status. A package returned with comments is not necessarily an approved release, and a verbal direction may not satisfy the project's documentation requirements. Record what has been authorized, by whom, and for which scope. Ask the reviewer to clarify when a response is ambiguous.

When partial releases are possible, agree on the risk boundary with the shop. Fabricating a component before unresolved interfaces are settled may protect time but can create rework. Put that decision outside the schedule calculation and document its owner.

Weekly approval check

Review the drawing log beside the schedule, not as a separate administrative exercise. Every open item should have an owner, next action, expected response, and affected work. Close outdated dates rather than carrying them forward week after week.

  • What was submitted and when?
  • What response is due next?
  • Which work is waiting on it?
  • What is the latest useful decision date?

Common questions

Should the schedule assume one review cycle?

Only if the scope and reviewer support that assumption. Carry a revision allowance or scenario when the outcome is uncertain.

When should we escalate?

Before the latest useful response date, with the package, affected work, and decision needed. Waiting until production stops removes options.

Keep the plan connected.

Milno is being prepared for its first users. It is designed to help subcontractors build schedules around milestones and update linked work as dates change.

Get launch updates