Project Management: The CM Plan and Procedures Manual as Workflows

Every PMC firm has a procedures manual. Very few can show, on any given day, that their teams actually followed it. The difference is whether the manual lives in a binder or in the workflows people use to do the work.

When a PMC firm wins a mandate in the Gulf, one of the first deliverables is a CM plan or project management plan. It sets out the organisation, the roles and responsibilities, the communication protocol, the meeting cycle, the document control rules, the reporting calendar and the closeout approach. It is usually well written, reviewed by the client and signed off. Then it is filed.

From that point the plan competes with habit. Correspondence is sent from personal mailboxes. Meeting minutes are drafted in word processors and circulated days later. Action items are tracked in a spreadsheet that one person maintains. The reporting calendar slips because each month's report is assembled from scratch. By the time the project reaches closeout, the lessons learned workshop relies on memory, and nothing it produces reaches the next project.

The CMAA Standard is clear on this point: planning and procedures are only valuable if they are applied, monitored and kept current. For a PMC firm the practical question is how to make the procedures manual executable, so that following the procedure is the easiest way to do the work, and so that the evidence of following it is created as a by-product.

This article explains how the elements of the CM plan and the firm's procedures manual become PMWEB workflows, forms, templates and reports. As always, each PMC firm and each client executes these processes in its own way. PMWEB is configured to the firm's procedures; the CMAA Standard stays the reference. And because those configurations are reusable, they become something more valuable than a project setup: the firm's practice library.

The CMAA Standard places project management at the centre of the CM's services. It expects the CM to prepare a CM plan early, defining the project organisation, the responsibilities of each party and the procedures that will govern the work, and to keep that plan current as the project moves from pre-design through design, procurement, construction and post-construction. It expects a defined communication protocol, a regular cycle of meetings with documented outcomes, controlled correspondence and document management, periodic reporting to the owner and, at the end, an orderly closeout with lessons captured for the future. The CM is expected to manage information on the owner's behalf so that decisions are traceable and the project record is complete.

How GCC PMC Firms Typically Do It Today

• The CM plan is a document, not a configuration. It is approved at mobilisation and rarely consulted afterwards, so the organisation chart and RACI drift from reality.
• Correspondence lives in mailboxes. Letters are numbered manually, logged inconsistently and difficult to retrieve when a notice period or an instruction is disputed.
• Meetings produce minutes but not actions. Action items sit in documents or spreadsheets with no owner, due date or follow-up, and the same items reappear month after month.
• Monthly reports are rebuilt each month. Project engineers spend days assembling data from several sources, and each project's report looks slightly different.
• Every project starts from scratch. Forms, numbering conventions and approval routes are recreated for each new mandate, so the firm's practice varies by project director.
• Lessons learned are captured too late and used never. A closeout workshop produces a document that no one on the next project will read.

How PMWEB Digitalises It

The approach is to translate each section of the procedures manual into a PMWEB configuration element: a record type, a form, a workflow, a numbering rule, a report, or a dashboard. Once built, these elements are saved as templates and applied to new projects, so the firm's procedures travel with it.

The CM plan, organisation and RACI

PMWEB's portfolio and programme structure mirrors the client's organisation, and the project directory records every party, company and contact. The RACI from the CM plan becomes the set of security roles and workflow roles: who can create, who reviews, who recommends, who approves and who is informed. Because routing is role-based rather than name-based, a change of personnel is a change to one assignment, not a rewrite of the procedure. The CM plan itself is stored as a controlled document, and its key parameters, such as reporting dates and meeting frequencies, are held as structured data that drives the system.

Communication protocol and correspondence

The communication protocol states who writes to whom, on what subjects, with which numbering and with what approval. In PMWEB, correspondence is created within the system with automatic numbering by project, party and type, routed for internal review and sign-off according to value- and type-based rules, and issued with a complete record of who approved it and when. Incoming letters are logged, assigned and tracked for response. Where a letter is a notice under the contract's notice provisions, the correspondence type flags the record so that response periods are tracked from the day of receipt.

Document control and transmittals

Document control in PMWEB covers the project's controlled documents, drawings register and transmittals, with revision control, distribution matrices and acknowledgement tracking. Where the design team manages drawings and models in its own platform, PMWEB transmittals and correspondence reference the exact revision issued, so the decision record and the document record stay connected.

Reporting

The reporting calendar in the CM plan becomes a set of SSRS reports and dashboards drawing on live data, with Power BI integration where the client has standardised on it. Monthly progress reports are generated from the same records the team works in every day, so each report is consistent with the one before it and with every other project in the portfolio. Narrative sections are written by the project team; the numbers are never re-keyed.

Closeout and lessons learned

Closeout checklists translate the procedures manual's closeout section into tracked steps with owners and evidence. Lessons learned are captured throughout the project, not only at the end, as structured records categorised by process, phase and delivery method. Because they are structured, they can be searched when the next project's CM plan is drafted, and the firm can update its templates in response.

Templates as the firm's practice library

The most valuable outcome of this work is not any one project's configuration. It is the library of templates the firm builds and refines: project templates by delivery method and sector, form and workflow templates, meeting templates, report templates, numbering conventions and closeout checklists. A new mandate starts from the library and is tailored to the client's requirements, rather than being built from nothing. Over time the library becomes the firm's codified way of working, which is precisely what a standard of practice is meant to produce.

Configuring PMWEB to Your Firm's Procedures

The CMAA Standard says what a CM plan and its procedures must achieve; each firm, and each client, decides how. Those decisions become configuration in PMWEB, held in the practice library and tailored per mandate.

Evidence That the Practice Is Working

Key takeaway

A CM plan and procedures manual describe how the firm intends to work. PMWEB turns them into roles, forms, workflows, templates and reports, so that following the procedure is the natural way to work and the evidence is created as the work is done. That is how the project management expectations of the CMAA Standard are executed and evidenced, not merely documented.

This is alignment, not certification. Each firm's procedures differ and should, and PMWEB is configured to them. Over time the templates become the firm's practice library: a codified, reusable standard of practice that improves with every project.

Next in the series: Article 4 — Cost Management: From Budget to Final Cost Reconciliation