Project Coordinator SOP and Operating Playbook

Model Project Coordinator SOP and Operating Playbook

Purpose and scope

Purpose

The Project Coordinator turns an approved business need into a controlled, visible, and decision-ready flow of work. The role connects authorization, scope, schedule, stakeholders, risks, delivery evidence, status, changes, acceptance, handoff, and closeout.

The playbook helps the coordinator:

• confirm that work has an owner, purpose, success evidence, and decision route;
• organize requirements and boundaries before commitments are made;
• maintain a credible schedule that separates the approved baseline from the latest forecast;
• keep risks, issues, assumptions, dependencies, actions, and decisions distinct;
• obtain progress evidence from work owners and reconcile conflicting information;
• produce concise status reports that show variance, forecast, decisions needed, and next actions;
• route changes and exceptions to the right authority;
• preserve acceptance and handoff evidence at closure; and
• maintain records in approved systems with clear ownership, version, and freshness.

Included work

This model applies to one bounded, cross-industry project or workstream with a named sponsor or accountable owner. Typical examples include an internal process improvement, a small implementation, a service launch, a campaign, a reporting change, a training initiative, or a coordinated operational improvement.

Excluded work

This model does not authorize the coordinator to:

• approve funds beyond delegated limits;
• interpret or amend contracts;
• approve engineering, clinical, legal, regulatory, safety, or other licensed judgments;
• change an approved baseline without the required decision;
• represent assumptions as confirmed facts;
• publish confidential, personal, or restricted information in an unapproved tool;
• replace a designated approver, accountable owner, or receiving owner; or
• treat an AI-generated draft as approved project evidence.

Roles, interfaces, and responsibility boundaries

Required inputs and source-of-truth rules

Before work begins, collect the smallest sufficient set of approved inputs:

• approved business need or initiation request;
• named sponsor or accountable owner;
• measurable objective and success evidence;
• known constraints, assumptions, dependencies, and target dates;
• requirements and their sources;
• in-scope and out-of-scope boundaries;
• deliverables and acceptance criteria;
• available people, capacity, and simple cost assumptions;
• affected stakeholders and required communication;
• known risks, issues, and decisions;
• approved systems, document locations, naming rules, and access rights; and
• relevant employer policies, contract routes, security classifications, retention rules, and regulated review requirements.

For every record, identify:

• record owner;
• authoritative source;
• current version;
• last updated date;
• next review date or event;
• approval state;
• linked evidence; and
• permitted audience.

Local-control field: approved system of record for each artifact. If teams use more than one tool, identify which system is authoritative and how secondary copies are reconciled. A dashboard, message, email, or AI summary is not automatically the source of truth.

Trigger-to-close workflow

1. Receive and qualify the trigger

A project-control workflow begins when an authorized person submits a new business need, approved initiative, workstream, material change, recovery request, or handoff request.

The coordinator:

• records the request date, source, purpose, requested outcome, target date, and known constraints;
• confirms whether the request is a project, routine operation, incident, change, or idea needing further qualification;
• identifies the sponsor or accountable owner;
• checks for duplicate or conflicting work;
• records missing information as open questions; and
• routes urgent safety, legal, security, regulatory, or service-continuity concerns immediately through the approved local path.

Decision: Is there enough authority and information to prepare a project charter?

• If yes, proceed to authorization.
• If no, return a concise clarification list to the request owner.
• If the request is outside the role boundary, route it to the named authority without silently accepting responsibility.

Output: intake record and clarification log.

2. Confirm authorization and create the charter

Draft a charter that records:

• business need;
• measurable objective;
• success evidence;
• sponsor and decision ownership;
• coordinator and project lead;
• high-level deliverables;
• boundaries;
• assumptions and constraints;
• initial target dates;
• initial resource or cost assumptions;
• highest known risks;
• acceptance and closure route; and
• authorization decision.

Check that the objective describes a result, not merely an activity. Separate confirmed facts from assumptions. State what the project will not do.

Local-control field: who may authorize the project, what form approval takes, and where approval evidence is stored.

Decision: Is the work authorized within the stated boundary?

• If approved, record the approval evidence and continue.
• If approved with conditions, record each condition, owner, and due date.
• If not approved, close or return the request according to local policy.

Output: approved charter or documented disposition.

3. Establish requirements, scope, and acceptance

For each requirement, record its source, description, priority, owner, acceptance evidence, and current status. Group related requirements into deliverables. Define in-scope and out-of-scope boundaries in plain language.

The coordinator checks for:

• ambiguous terms;
• conflicting requirements;
• missing owners;
• missing acceptance criteria;
• hidden dependencies;
• requirements that exceed the charter;
• sensitive-data implications; and
• requests that require specialist or regulated review.

Decision: Can each planned deliverable be traced to an authorized requirement and a named acceptance route?

If not, request clarification before baselining the plan.

Outputs: requirements record, scope statement, acceptance record, and traceability links.

4. Decompose deliverables into manageable work

Break each deliverable into work packages that are small enough to estimate, assign, track, and verify. Then identify the activities required to complete each package.

For every work package, record:

• deliverable link;
• owner;
• completion evidence;
• required inputs;
• predecessor and successor dependencies;
• duration assumption;
• resource or capacity assumption;
• milestone contribution; and
• known risk or constraint.

Avoid creating a task list that has no connection to deliverables or acceptance. A useful work plan shows why each activity exists and what evidence will prove completion.

Output: work breakdown and activity plan.

5. Build the schedule, baseline, and forecast

Sequence activities according to real dependencies. Identify milestones as meaningful decision, acceptance, readiness, or delivery points rather than arbitrary dates.

The coordinator:

• confirms calendars, availability, and lead-time assumptions;
• checks for missing predecessors and impossible overlaps;
• records owner commitments;
• calculates or reviews planned dates;
• highlights constrained or critical sequences;
• obtains the required baseline approval; and
• preserves the baseline while maintaining a separate current forecast.

Local-control field: scheduling method, working calendar, baseline approval authority, tolerance thresholds, and approved scheduling system.

Never overwrite the baseline merely because the forecast changes. Variance is useful decision evidence.

Outputs: approved schedule baseline, current forecast, milestone list, and dependency record.

6. Map stakeholders and design communication

Identify people and groups affected by the project, able to influence delivery, responsible for decisions, or needed for acceptance and handoff.

Record role-based information:

• relationship to the project;
• information needed;
• likely impact;
• influence on decisions or delivery;
• preferred approved channel;
• communication frequency;
• message owner; and
• feedback or decision route.

Do not profile sensitive personal traits. Use job role, project impact, decision responsibility, and information need.

Local-control field: approved communication channels, accessibility requirements, confidentiality classification, and distribution restrictions.

Outputs: stakeholder register or map and communication plan.

7. Establish risk, issue, assumption, and dependency controls

Keep four concepts separate:

• A risk is an uncertain event that may affect objectives.
• An issue is a current condition already affecting the project.
• An assumption is something treated as true for planning but not yet confirmed.
• A dependency is an input, event, or commitment that one part of the plan relies on.

Write risks in cause-event-effect form. Apply the approved probability and impact criteria. Assign an owner, response, due date, trigger, residual exposure, and escalation state.

Write issues with observed evidence, current impact, owner, next action, target resolution, and decision or escalation needed.

Local-control field: risk scales, risk appetite, escalation threshold, issue severity, review frequency, and approved repository.

Outputs: risk register, issue log, assumption log, and dependency log.

8. Launch the operating cadence

Confirm that each owner understands:

• assigned output;
• completion evidence;
• current forecast;
• dependencies;
• risks and issues;
• update frequency;
• approved working location; and
• escalation route.

Run a launch or planning review that resolves contradictions across the charter, scope, schedule, resources, risks, stakeholders, and acceptance route. Record decisions and actions rather than relying on memory.

Outputs: launch record, action log, decision log, and agreed cadence.

9. Collect and reconcile progress evidence

At each update point, request evidence rather than percentages alone. Useful evidence includes an approved document, completed review, test result, accepted deliverable, system record, meeting decision, or confirmed handoff.

The coordinator:

• records actual start and finish information;
• updates remaining work and forecast dates;
• checks milestone and dependency effects;
• reconciles conflicting owner updates;
• identifies new risks, issues, assumptions, and decisions;
• updates budget or resource visibility from approved sources;
• records actions and due dates; and
• preserves an audit trail of material changes.

If evidence is incomplete, label the update as unconfirmed. Do not convert optimism into reported completion.

Outputs: current forecast, progress evidence record, updated logs, and variance analysis.

10. Prepare status and decision communication

A concise status report should answer:

• What outcome and reporting period are covered?
• What has changed since the last report?
• What is complete, and what evidence supports completion?
• What is the baseline-versus-forecast position?
• Which scope, schedule, resource, cost, risk, or quality variances matter?
• Which risks and issues require attention?
• Which decisions are needed, from whom, and by when?
• What will happen next?

Use an overall status only when the criteria are defined. Explain the evidence behind the status. A colour alone is not a report.

Local-control field: status criteria, report frequency, audience, approval before distribution, and distribution channel.

Outputs: status report, dashboard if locally used, decision requests, and updated actions.

11. Control changes

A change begins when someone requests or identifies a material alteration to scope, acceptance, schedule, resource, cost, risk exposure, deliverable, or operating condition.

The coordinator:

• records the request and source;
• confirms the reason and urgency;
• identifies affected requirements, deliverables, activities, stakeholders, records, and handoffs;
• obtains impact estimates from appropriate owners;
• presents options, consequences, recommendation, and decision deadline;
• routes the request to the authorized decision-maker;
• records the decision and conditions; and
• updates affected baselines and communications only after approval.

Local-control field: what counts as a controlled change, who approves each type, emergency-change route, financial threshold, and required evidence.

Outputs: change request, impact assessment, decision record, change log, and authorized baseline updates.

12. Verify acceptance, hand off, and close

Before closure:

• reconcile planned deliverables against acceptance criteria;
• obtain acceptance evidence or record open exceptions;
• confirm operational ownership and support route;
• transfer approved records and knowledge;
• close or transfer remaining actions, risks, issues, and dependencies;
• reconcile final schedule, resource, and cost information from approved sources;
• archive records according to local policy;
• record lessons as observations, not unsupported claims;
• identify who will review expected benefits later; and
• obtain the required closure decision.

Local-control field: acceptable signature or evidence, retention period, archive location, open-item tolerance, benefits-review owner, and closure authority.

Outputs: acceptance record, handoff record, closeout checklist, lessons record, and closure decision.

Operating cadence

Daily or active-work cadence

• Review new messages, approved system alerts, overdue actions, and near-term dependencies.
• Confirm evidence for work due soon; do not wait for the reporting deadline to discover a blocker.
• Update issues and urgent risks when conditions change.
• Reconcile material differences between verbal updates and the source of truth.
• Route decisions and exceptions with owner, evidence, consequence, and needed-by date.
• Protect focus by separating urgent exceptions from routine follow-up.

Local-control field: working hours, emergency route, response expectations, and notification settings.

Weekly cadence

• Collect owner updates using a consistent cutoff.
• Update actuals, remaining work, forecast dates, milestones, and dependencies.
• Review risks, issues, assumptions, changes, actions, and decisions.
• Reconcile resource and simple budget information with approved sources.
• Prepare the status report and decision requests.
• Conduct the project review meeting when useful.
• Distribute approved status communication.
• Record actions, decisions, owners, dates, and follow-up.

Local-control field: reporting day, update cutoff, meeting format, status criteria, and approver.

Monthly or governance cadence

• Review continuing alignment with the charter and success evidence.
• Examine forecast stability and recurring causes of variance.
• Review resource and cost trends at the permitted level.
• Confirm stakeholder and communication needs.
• Review aged risks, issues, decisions, and changes.
• Check record quality, access, retention, and system reconciliation.
• Confirm upcoming acceptance, handoff, or governance events.

Local-control field: governance forum, required pack, financial period, records review, and decision quorum.

Event-driven cadence

Run an event review when any of the following occurs:

• new project request or authorization decision;
• baseline approval;
• new material risk or issue;
• missed or threatened milestone;
• blocked dependency;
• material change request;
• decision deadline at risk;
• resource or cost exception;
• vendor commitment change;
• security, privacy, safety, legal, or regulatory concern;
• deliverable review or rejection;
• acceptance, handoff, pause, cancellation, recovery, or closeout.

The event review records what happened, evidence, impact, owner, decision route, required action, and next review.

Decision and authority model

Local-control field: complete the actual decision-rights map before using the playbook.

Handoffs

Every handoff should state:

• what is being transferred;
• current state and version;
• acceptance or readiness criteria;
• linked evidence;
• open risks, issues, assumptions, dependencies, actions, and decisions;
• accountable receiving owner;
• transfer date;
• support or escalation route; and
• confirmation of receipt.

Key handoffs include:

• request owner to sponsor for authorization;
• sponsor or project lead to coordinator for control setup;
• coordinator to work owner for an assigned output;
• work owner to reviewer or acceptor;
• coordinator to sponsor for a decision;
• vendor or external party to project team;
• project team to operational owner; and
• project records to the approved archive.

A sent message is not automatically a completed handoff. Confirm that the receiving owner has the material, understands open conditions, and accepts the next responsibility.

Escalation model

Escalation is a controlled transfer of decision attention, not an admission of failure. Escalate with concise evidence.

Escalation packet

• Situation: what changed or is at risk.
• Evidence: the current verified facts and source.
• Impact: objective, scope, schedule, resource, cost, quality, stakeholder, or compliance consequence.
• Timing: when a decision or action is needed.
• Options: feasible choices and trade-offs.
• Recommendation: the coordinator or project lead recommendation within role boundaries.
• Owner: who can decide.
• Next step: what happens after the decision.

Escalation triggers

• forecast variance exceeds the approved tolerance;
• an acceptance criterion cannot be met;
• a risk exceeds the approved exposure threshold;
• an issue threatens a milestone, objective, or controlled requirement;
• a decision is overdue and blocks work;
• resource or cost information conflicts with the approved source;
• a change is being implemented without approval;
• a vendor or external dependency misses a material commitment;
• confidential information appears in an unapproved location;
• a request requires authority, qualifications, or access the coordinator does not hold; or
• a legal, regulatory, security, safety, clinical, engineering, or ethical concern is identified.

Local-control field: thresholds, severity definitions, named escalation recipients, emergency route, response time, and after-hours process.

Records and approved tool categories

Tool categories may include spreadsheets, project scheduling software, work-management platforms, document repositories, collaboration tools, dashboards, finance systems, procurement systems, and service-management systems. The evidence does not support treating one named platform as universal.

Local-control field: approved tools, access roles, data classification, naming conventions, version rules, backup, retention, integrations, automation permissions, and reconciliation owner.

Quality measures and KPIs

Use measures to improve control quality, not to manufacture certainty. Report definitions, sources, and caveats.

Local-control field: KPI definitions, targets, tolerances, source systems, reporting period, exclusions, and accountable reviewer. Do not invent targets when none have been approved.

Exception handling

AI-assisted work with human control

AI may assist with drafting, summarizing approved notes, checking consistency, identifying missing fields, generating alternative wording, or testing whether a report answers required questions. It does not become a source of project truth.

Before using AI:

• use only an approved tool and permitted data;
• remove or protect confidential and personal information;
• supply the relevant approved context;
• ask for structured output that maps to the project record;
• compare the result with authoritative sources;
• require a named human reviewer;
• correct unsupported statements; and
• record the final decision in the approved system.

Local-control field: approved AI tools, permitted data classes, review requirement, retention, disclosure, and prohibited uses.

Reusable SOP model

Copy and adapt the following model before operational use. Entries labelled local-control require an approved employer value.

Operating identity

Trigger and completion

Roles and handoffs

Ordered operating steps

1. Record and qualify the trigger.
2. Confirm sponsor, purpose, authorization, and boundaries.
3. Establish requirements, scope, deliverables, and acceptance.
4. Decompose deliverables into owned work.
5. Build and approve the schedule baseline; maintain a separate forecast.
6. Map stakeholders and configure communication.
7. Establish risk, issue, assumption, and dependency controls.
8. Launch the operating cadence and decision records.
9. Collect and reconcile progress evidence.
10. Report status, variance, forecast, decisions, and next actions.
11. Route material changes through impact assessment and approval.
12. Verify acceptance, hand off ownership, archive records, and close.

Control configuration

Output checklist

• authorized charter;
• requirements, scope, deliverables, and acceptance records;
• work plan, schedule baseline, and current forecast;
• stakeholder and communication record;
• risk, issue, assumption, and dependency records;
• action and decision logs;
• status reports;
• change requests and change log;
• acceptance, handoff, lessons, archive, and closure records.

Final quality checklist

Before using any output from this playbook, confirm:

• the project is authorized and bounded;
• roles, decision rights, and escalation routes are explicit;
• facts, assumptions, risks, issues, and dependencies are distinct;
• every deliverable traces to a requirement and acceptance route;
• the baseline is preserved and the forecast is current;
• records have owners, versions, dates, sources, and permitted audiences;
• status statements are supported by evidence;
• changes are assessed before approved baselines are updated;
• handoffs name a receiving owner and open conditions;
• local policies and approved systems control operational use;
• sensitive information is handled only through approved routes; and
• a named human owns every decision and reviews any AI-assisted draft.