Project Management Standard Operating Procedures

Document ID: WBL-INT-PMSOP-v1.0 Classification: Internal — Project Managers, Account Directors Version: 1.0 Effective Date: [DATE] Owner: [Managing Director / Senior PM] Next Review: [DATE + 12 MONTHS]

Purpose: This document defines Webility's standard project management procedures. Following these procedures consistently produces better client outcomes, fewer disputes, and a team that can scale without depending on individual heroics.

These are not suggestions. They are the standard. If you believe a procedure is wrong, raise it with the Managing Director — do not simply skip it.

1. Project Initiation

1.1 From Signed Contract to Kickoff

When a contract is signed and the deposit is received:

Billing trigger: Confirm with the Account Director that the deposit invoice has been issued and received before project work begins.

1.2 Project Setup Checklist

Before the kickoff meeting:

• Project created in project management tool with all phases, milestones, and tasks from SOW
• Timeline mapped against agreed delivery dates
• Internal team assignments confirmed for all phases
• Client has accepted project tool invitation
• Shared drive / file repository set up and shared with client
• Document ID assigned and filed (WBL-[TYPE]-[CLIENT ID]-v1.0)
• Onboarding documents sent and receipts confirmed
• Risk register created (at least 3–5 initial risks identified)
• Kickoff agenda sent to client at least 24 hours before meeting

2. Kickoff Meeting

2.1 Kickoff Agenda (Standard)

(60–90 minute meeting. Adjust for project size.)

Always end the kickoff with:

• Confirmed first deliverable and date
• Confirmed client input(s) required and deadlines
• Scheduled next meeting

2.2 Kickoff Meeting Output

Within 24 hours of the kickoff meeting:

• Meeting notes sent to client (PM)
• Decisions log entry created in project tool (PM)
• Action items assigned in project tool with due dates and owners (PM)
• Client responsibilities formally noted in writing (in the email or project tool)
• Updated project timeline published to project tool (if any changes from kickoff discussion)

3. Project Execution

3.1 Phase Gate Process

Every phase ends with a formal gate. No phase begins without written client approval of the preceding phase.

Phase gate steps:

Critical rule: Phase gates must be documented. Verbal approvals do not count. If a client gives verbal approval, PM must confirm in writing: "Just confirming — you've approved [Phase X] as submitted. We'll proceed to [Phase X+1]. Let me know if that's not correct."

3.2 Weekly Status Updates

Every active project requires a written status update every week. This goes to the client contact on Mondays (or the first business day of the week).

Status update format:

Subject: [PROJECT NAME] — Weekly Update — [WEEK OF DATE]

Hi [Name],

Here's your update for the week of [DATE]:

📍 STATUS: [On track / Minor delay — see below / At risk / Blocked]

✅ COMPLETED THIS WEEK:
- [Item 1]
- [Item 2]

🔜 THIS WEEK:
- [Item 1]
- [Item 2]

⚠️ OPEN ITEMS / BLOCKERS:
- [Any client action needed — with deadline]
- [Any external dependency]

📅 NEXT MILESTONE: [Milestone name] — [Date]

Let me know if you have any questions.
[PM NAME]

If the project is on track and has no issues, the update is short — 5 minutes to write. Never skip it because "nothing is happening." Silence creates client anxiety.

3.3 Internal Team Check-Ins

Weekly internal project meeting (or async, for smaller projects):

• What was completed?
• What is in progress?
• Any blockers or risks?
• Any client communication needed?
• Any timeline risk?

PM maintains an up-to-date task board in the project management tool at all times. Never let the task board go stale — it is the source of truth.

3.4 Risk Management

A risk register is created at kickoff and updated bi-weekly.

Risk register fields:

• Risk description
• Probability (Low / Medium / High)
• Impact (Low / Medium / High)
• Risk owner
• Mitigation plan
• Status (Open / Mitigated / Closed / Escalated)

Risks that must be escalated to Account Director immediately:

• Timeline risk that may affect the final delivery date by more than [5] business days
• Budget risk (scope is expanding without a Change Order)
• Client relationship showing signs of deterioration
• Any legal or compliance concern
• Any security incident involving client credentials or data

4. Scope Management

4.1 Change Order Process

A Change Order is required whenever the client requests work that is:

• Not in the agreed SOW
• Beyond the included revision rounds
• A modification to an already-approved deliverable
• An accelerated timeline requiring extra resources

Steps:

1. Client makes a request (in any channel)
2. PM acknowledges: "That's outside the current scope. I'll prepare a Change Order with the cost and timeline impact — you'll receive it within [2] business days."
3. PM prepares Change Order (WBL-CO-[ID]-v1.0) with: description, rationale for why it's out of scope, hours, cost, and timeline adjustment
4. Account Director reviews and approves the CO before sending to client
5. Client signs Change Order — no work starts before signature
6. PM updates project timeline and budget tracking
7. PM records CO in cumulative Change Order log for the project

Common mistake to avoid: Doing "just a small thing" without a CO because it feels awkward. Small things compound. A project with 5 small out-of-scope additions that each took 2 hours is 10 hours of uncompensated work. Every time.

4.2 Handling Scope Creep in Real Time

If a client is consistently asking for small items outside scope:

1. Document them
2. Address it with the client directly: "We've now had [X] requests outside the agreed scope. I'd like to do a quick scope review with you — some of these may be things we should fold into a revised SOW, or we can handle them as individual Change Orders. Which would be more useful?"
3. This is a billable conversation for the Account Director, not something to avoid.

5. Billing Triggers

Every billing event must be initiated by the PM — not by the client, and not by accounts.

PM must confirm billing accuracy before any invoice is issued. Incorrect invoices damage client trust and delay payment.

6. Handover Process

6.1 Pre-Handover Checklist

Before issuing the project handover document:

• All deliverables from the SOW have been delivered and approved
• All source files organized and named per file naming convention
• All credentials have been tested and transferred to client (via secure transfer)
• Client accounts created on all platforms (client owns their own accounts — not Webility accounts with client delegated access)
• Agency credentials revoked from all client systems
• Training completed and training guide delivered (WBL-DEL-TG-[ID]-v1.0)
• Launch checklist completed and signed (WBL-DEL-LC-[ID]-v1.0) — if web project
• Final invoice issued and paid (no IP transfer until paid in full)
• Project Handover document (WBL-DEL-HR-[ID]-v1.0) prepared and signed
• Warranty terms communicated and warranty period start date confirmed
• Post-launch monitoring set up (if managed by Webility)
• Client Satisfaction Survey issued (WBL-DEL-CSS-[ID]-v1.0)
• Portfolio / case study rights confirmed with client
• Internal project debrief scheduled

6.2 Post-Project Debrief (Internal)

Within [5] business days of project close, the PM leads an internal debrief:

• What went well?
• What would we change?
• Were the estimates accurate? If not, why?
• Any process improvements to capture?
• Was this a good-fit client? Would we work with them again?

PM documents debrief notes and any process improvements in [internal knowledge base].

7. Project Management Tools

7.1 Required Tool Stack

7.2 File Naming Convention

All project files must follow the naming convention:

WBL-[CLIENT_CODE]-[PHASE]-[DELIVERABLE]-v[VERSION]-[YYYYMMDD].[ext]

Examples:
WBL-ACME-P1-WIREFRAMES-v1-20250301.fig
WBL-ACME-P1-WIREFRAMES-v2-20250310.fig
WBL-ACME-P2-HOMEPAGE-v1-FINAL-20250401.fig
WBL-ACME-MSA-SIGNED-20250215.pdf

Version numbering:

• v1, v2, v3 for client-facing revisions
• Append -FINAL when client has approved
• Never overwrite — always save as a new version

7.3 Document Retention

• Active project files: Retained for duration of project + [12] months post-handover
• Signed contracts and legal documents: Retained for [7] years
• Client credentials: Deleted from vault within [30] days of project close (after confirmed client transfer)
• Satisfaction surveys: Retained indefinitely (anonymized data)

8. Escalation

8.1 When to Escalate to Account Director

Escalate any of the following immediately — do not attempt to resolve alone:

• Client expresses dissatisfaction with the project or the team
• Client threatens to terminate the engagement
• Timeline will miss a contractual milestone by more than [3] business days
• Scope dispute — client believes something is in scope that is not
• Legal question (anything involving contract interpretation, IP, data breach, complaint)
• Invoice dispute
• Any conduct issue (inappropriate client communication toward team; team conduct issues)
• Security incident involving client data

8.2 Escalation Template

When escalating, provide:

• Project name and client
• What happened (facts, not interpretation)
• When it happened
• What you've done so far
• What you need from the Account Director

Webility — WBL-INT-PMSOP-v1.0 | Project Management SOP Internal document — not for client distribution.