Module 2: Professional Client Communication
Learning Objectives
- Conduct structured client communication from initial interview through design, documentation, permitting, construction, and closeout.
- Distinguish information, questions, clarifications, instructions, design decisions, approvals, requests for information, change requests, and scope variations.
- Create traceable agendas, minutes, action registers, decision logs, transmittals, and written confirmations.
- Manage incomplete information, disagreements, client-requested changes, decision deadlines, and scope change without obscuring professional responsibility.
- Explain why material verbal instructions should be converted into durable written records.
Project Communication
Project communication is the controlled exchange of information, questions, decisions, instructions, approvals, records, and changes among authorized project participants so that the current project basis can be understood, acted on, verified, and traced.
Information
Information is a statement or record supplied for awareness or use. It does not automatically require action, approval, or a design change.
Clarification
A clarification resolves ambiguity in existing information without, by itself, creating a new scope, design decision, or instruction.
Instruction
An instruction is a direction issued by a person with the authority to direct the relevant work. The recipient must still check whether the instruction is clear, within scope, professionally lawful, and technically actionable.
Design Decision
A design decision is a documented choice that changes or confirms the technical basis of the design and is made by the person or professional with the appropriate authority and responsibility for that decision.
Approval
Approval is a documented acceptance by an authorized party of a defined item, stage, decision, or deliverable. Approval should identify exactly what was reviewed and should not be interpreted as transferring another professional's design responsibility.
Request for Information
A request for information, or RFI, is a formal request to resolve an identified information gap, ambiguity, discrepancy, or conflict that affects project work.
Change Request
A change request is a proposal to alter an approved or current project requirement, design basis, deliverable, sequence, cost, schedule, or other controlled project condition.
Scope Variation
A scope variation is an authorized modification to the agreed scope of professional or project services, typically requiring clear definition of the added, deleted, or changed work and its consequences.
Communication Has a Technical Function
Professional communication is not an administrative layer added after design. It is part of design control.
For the progressive two-storey community/institutional building, a single client statement such as “move the stair so the hall is larger” can affect:
- architectural circulation and egress;
- structural framing and openings;
- electrical and lighting layouts;
- plumbing or fire-protection routing;
- accessibility;
- cost and schedule;
- permit documents already prepared or submitted;
- drawing revision status.
The professional response is therefore not simply “noted.” The communication must be classified, its authority established, its technical impacts assessed, and the affected records revised in a controlled manner.
Communication Classification
Classifying the message determines the correct response and prevents questions, preferences, and instructions from being treated as equivalent.
Initial Interviews and Expectation Setting
The initial interview should establish both project information and the communication rules that will govern later work.
Discuss:
- who may issue client instructions;
- who may approve project decisions;
- which communication channels are official;
- how urgent matters are handled;
- how meeting decisions will be confirmed;
- how incomplete information will be marked;
- how document revisions are identified;
- how changes are requested and evaluated;
- expected response periods for decisions;
- what information the client must supply;
- what deliverables are expected from each professional;
- what review or approval does and does not mean.
Technical language should be translated into plain language without deleting the underlying uncertainty, limitation, or professional responsibility. A client can understand “we cannot fix the structural grid until the architectural room arrangement is stable” without receiving an oversimplified promise that the grid is already final.
Professional Communication Chain
A useful project message carries context, required action, authority, timing, and a durable record rather than isolated text.
Preparing and Running a Project Meeting
- Define the meeting purpose and decisions required.
- Issue an agenda that identifies topics, responsible participants, and relevant documents or revisions.
- Confirm which participants have authority to make decisions on the scheduled topics.
- During the meeting, distinguish discussion from an actual decision or instruction.
- Record decisions, unresolved questions, action owners, due dates, and affected documents.
- Record dissent, constraints, and assumptions when they materially affect the outcome.
- Issue minutes promptly enough that participants can correct factual errors before the record becomes stale.
- Transfer actions to the action-item register and decisions to the decision log.
- Link subsequent revisions, RFIs, transmittals, or change requests back to the originating decision where practical.
- Close actions only when the required evidence or deliverable is complete, not merely because a meeting occurred.
Minutes of Meeting
Minutes should function as a project record, not as a transcript.
A useful set of minutes normally identifies:
- project and meeting title;
- date, time, and location or meeting platform;
- attendees and represented organizations;
- agenda references;
- documents or drawing revisions discussed;
- material information received;
- decisions made and by whom;
- instructions and their authority;
- unresolved issues;
- action owner and due date;
- items requiring written confirmation;
- next meeting or follow-up requirement.
Avoid statements such as “everyone agreed” when the record does not identify the decision, its scope, or the person with authority.
Action Register and Decision Log
An action register answers: what must be done, by whom, by when, and what constitutes completion.
A decision log answers: what was decided, when, by whom, on what basis, and which project information changed because of the decision.
The two records are complementary. “Client to choose door hardware by Friday” is an action. “Client approved hardware option B on 12 October against architectural schedule revision P03” is a decision record.
For consequential decisions, include enough document identity that a later reviewer can reconstruct the basis without searching through unrelated chat history.
Action Register Versus Decision Log
Actions control pending work; decisions preserve the authorized basis that later drawings and specifications rely on.
- Owner
- Required action
- Due date
- Status
- Completion evidence
- Decision
- Authority
- Date
- Basis and revision
- Affected deliverables
Material Verbal Instructions Need a Durable Written Record
When a verbal conversation materially affects scope, design, cost, schedule, construction, or another controlled project condition, record it in a durable form appropriate to the project. The written confirmation should state what was understood, identify any required action or approval, and invite correction when the interpretation is wrong. A verbal statement should not silently become a design basis that nobody can later trace.
Confirming a Material Verbal Instruction
- Record who gave the instruction, when, and in what context.
- Restate the instruction in neutral, specific language.
- Identify the drawing, specification, scope item, programme, or decision it affects.
- State any technical limitation, missing information, or professional review still required.
- Identify whether the sender has authority for the requested decision.
- Request confirmation where the instruction is consequential or ambiguous.
- Register the resulting decision or change after confirmation.
- Revise and issue affected documents through normal document-control procedures.
Document Transmittals
A transmittal establishes what was formally sent.
A robust transmittal identifies:
- sender and recipient;
- project;
- date and transmittal number;
- file or drawing identifiers;
- revision or issue status;
- purpose of issue, such as for review, for information, for coordination, for permit, or for construction where valid in the project system;
- requested response and due date where applicable;
- superseded material when relevant;
- attachments and delivery method.
The status language must match the project's document-control system. Do not invent issue statuses that the team has not defined.
Email and Formal Correspondence Principles
Professional correspondence should be:
- specific — one clear subject and identifiable project context;
- traceable — drawing numbers, revisions, meeting dates, or issue IDs where relevant;
- neutral — factual language that separates evidence from interpretation;
- actionable — identifies what response or decision is required;
- bounded — states assumptions, limitations, and dependencies;
- authorized — does not imply authority the sender does not possess;
- durable — important outcomes are captured in the project's recognized record system.
Email is a transport method, not automatically the complete project record. Important decisions should also appear in the appropriate decision, change, document, or issue register.
Controlled Communication and Change Flow
Shows how project communications are classified, checked for authority, assessed for impacts, and converted into controlled project records.
Information and clarifications may be recorded directly; instructions and changes require authority and impact review before affected documents are revised and reissued.
New project communication received → Capture sender, date, subject, source revision, and required response; Capture sender, date, subject, source revision, and required response → What kind of communication is it?; What kind of communication is it? — Information / clarification → File information or clarification with traceable context; What kind of communication is it? — Instruction / decision → Confirm authority and convert material verbal direction to written record; What kind of communication is it? — Change / variation → Open change request or scope-variation review; File information or clarification with traceable context → Issue controlled response or transmittal; Confirm authority and convert material verbal direction to written record → Authorized decision or approval obtained?; Open change request or scope-variation review → Assess discipline, cost, schedule, permit, and document impacts; Assess discipline, cost, schedule, permit, and document impacts → Authorized decision or approval obtained?; Authorized decision or approval obtained? — No → Keep status pending; do not silently implement; Keep status pending; do not silently implement → Authorized decision or approval obtained?; Authorized decision or approval obtained? — Yes → Update decision log, action register, and affected document revision; Update decision log, action register, and affected document revision → Issue controlled response or transmittal
- New project communication received: terminator
- Capture sender, date, subject, source revision, and required response: data
- What kind of communication is it?: decision
- File information or clarification with traceable context: process
- Confirm authority and convert material verbal direction to written record: process
- Open change request or scope-variation review: process
- Assess discipline, cost, schedule, permit, and document impacts: process
- Authorized decision or approval obtained?: decision
- Keep status pending; do not silently implement: process
- Update decision log, action register, and affected document revision: process
- Issue controlled response or transmittal: terminator
Managing Client-Requested Changes
When a client requests a change, first determine what kind of change it is.
A request may be:
- a clarification of the original brief;
- a design preference still within the current development stage;
- a revision to an already approved decision;
- additional professional services;
- a scope variation;
- a change affecting another discipline;
- a change affecting cost or schedule;
- a change affecting submitted, permitted, procured, or constructed work.
The project team should identify impacts before treating the request as implemented. The client's commercial authority to request a change does not replace the responsible professional's duty to determine whether the resulting design is technically acceptable and within that professional's scope.
Do Not Confuse Client Approval with Professional Design Responsibility
A client may approve a layout, finish, budget choice, or project direction within the client's authority. That approval does not make the client the technical designer, and it does not transfer regulated professional responsibility for technical design, signing, sealing, or safety conclusions.
Incomplete Information and Decision Deadlines
Incomplete information should have a visible state.
Useful states include:
- pending client information;
- pending consultant input;
- pending survey or field verification;
- pending authority interpretation;
- provisional assumption for study only;
- approved decision;
- superseded information.
Decision deadlines should be tied to consequences. Instead of “ASAP,” state why the decision is needed: for example, “required before structural framing coordination begins” or “required before permit issue set is frozen.”
If the deadline passes, the team should document whether work is held, proceeds on a clearly stated provisional assumption, or requires a revised schedule. Silent continuation is the least controlled option.
Information Status Must Stay Visible
Project information matures through explicit states; pending or provisional information should not be mistaken for approved design input.
Handling Disagreement
Technical disagreement should be resolved through evidence and authority, not through message volume.
A disciplined response is to:
- state the exact point of disagreement;
- identify the current document or criterion;
- separate factual disagreement from preference;
- identify the professional or client authority for the decision;
- obtain missing evidence;
- record alternatives and consequences;
- escalate when the issue exceeds the participant's authority;
- preserve unresolved status until a competent decision is made.
Do not rewrite another discipline's design merely to eliminate a clash unless the responsible professional has made and documented the design decision.
Poor Communication and Professional Consequences
Common failures include:
- Verbal-only change: a room arrangement changes in conversation but structural and electrical teams continue from an older plan.
- Unidentified attachment: a PDF is sent without revision status and is later mistaken for the current drawing.
- Vague approval: “looks good” is interpreted as approval of technical details the client never reviewed.
- Uncontrolled chat instruction: a site message requests relocation of an opening, but no responsible designer evaluates the structural consequence.
- Closed action without evidence: an item is marked complete because somebody replied, although the revised document was never issued.
- Late decision without impact review: a finish or layout change is accepted after procurement without recording cost and schedule consequences.
The consequences can include rework, inconsistent drawings, disputes, delayed approvals, incorrect construction, lost design intent, and inability to establish who authorized the change.
Records Retention and Traceability
Project records should be retained according to the governing law, contract, organizational policy, information-management plan, and the type of record involved. This lesson does not prescribe a universal retention period.
The project team should define:
- which communications become controlled project records;
- where the authoritative record is stored;
- how revisions and superseded records are distinguished;
- who may alter, archive, or dispose of records;
- how decisions, approvals, RFIs, transmittals, and change records are linked to affected deliverables;
- how long each record class must be retained under the applicable project and legal requirements;
- how closed projects remain retrievable for warranty, claims, audit, operation, alteration, or future reference where required.
Traceability is stronger when a later reviewer can reconstruct the sequence source → decision → authorization → revision → issue without relying on individual memory or private messaging history.
Confidentiality, Privacy, and Controlled Client Data
Project communication can contain both personal data and confidential project information. Examples include client names and contact details, government-issued identification or authorization records where legitimately required, property/title records containing identifiable persons, addresses, budget or financial information, contracts, drawings, security layouts, and other information that should not be distributed casually.
For personal data, the Philippine Data Privacy Act of 2012 and its implementing rules require lawful processing and the principles of transparency, legitimate purpose, and proportionality. Consent is one possible lawful basis for processing personal information, but it is not the only lawful basis; depending on the circumstances, processing may instead be necessary for a contract, legal obligation, vital interests, public authority, or legitimate interests, subject to the Act's requirements. Sensitive personal information has a more restrictive set of lawful conditions.
In day-to-day project communication:
- use need-to-know access rather than giving every participant unrestricted access to every client record;
- distribute documents only to authorized recipients and use the project's controlled document or collaboration system where available;
- use secure, organization-approved storage and transfer methods appropriate to the information sensitivity;
- collect and retain only the personal information that is necessary and compatible with the declared project purpose;
- verify the recipient and the authority to disclose before forwarding IDs, title/property records, contracts, financial information, or other sensitive material;
- avoid uncontrolled forwarding through personal messaging accounts, personal cloud drives, public links, or broadly shared folders when the information requires controlled access;
- apply the project's retention schedule and dispose of personal data securely when retention is no longer justified, subject to legal, contractual, claims, and legitimate business requirements;
- treat security-sensitive drawings and confidential commercial information according to the applicable contract and organizational controls even when that information is not personal data under the Data Privacy Act.
The communication record should show who was authorized to receive the information and why when a sensitive disclosure is material to the project.
Privacy Controls Apply to the Information Flow, Not Only the Final File
Copying a confidential attachment into an uncontrolled chat, emailing it to an unverified address, or sharing an unrestricted cloud link can defeat the controls on the original document. Before forwarding sensitive client or property information, confirm the project purpose, recipient authority, access method, and whether the disclosure contains more personal data than necessary.
Information-Management Standards Must Be Checked for Current Edition
ISO 19650 provides a recognized framework for managing, exchanging, recording, versioning, and organizing information across built-asset work. As of this lesson review, ISO 19650-1:2018 remains current while a replacement draft is under development, and ISO 19650-4:2022 remains the published information-exchange standard. Projects that adopt ISO-based information management should verify the current editions and their contractual information requirements rather than treating this lesson as a substitute for the standards.
Communication Review Case: A Verbal Change After Issue
A client asks by telephone to move a toilet after drawings have been issued. The meeting record should identify the request, caller's authority, affected room, current issue, and requested response date. It should distinguish requested, under review, and approved.
The action register assigns the review; it does not authorize the relocation. Obtain the responsible disciplines' impact assessment, capture the authorized decision, and distribute the resulting controlled revision through a transmittal. Close the action only when recipients can identify the new issue and the superseded information. A confirmation email alone does not prove that drawings, costs, or downstream work have been updated.
- Professional communication controls technical work because design decisions, instructions, approvals, and changes alter the project basis.
- Information, clarification, instruction, approval, RFI, change request, and scope variation are different communication states and should not be conflated.
- Material verbal instructions should be converted into durable written records with authority, context, and affected documents identified.
- Action registers control pending work; decision logs preserve the authorized basis behind later documents.
- Client approval does not transfer regulated professional design responsibility.
- Confidentiality and privacy are part of communication control: disclose personal or sensitive project information only for an authorized purpose, to appropriate recipients, using suitable safeguards.
References
- ISO 19650-1:2018 — Information management using building information modelling, Part 1 — International Organization for Standardization; concepts and principles for recording, exchanging, versioning, and organizing built-asset information. ISO lists the 2018 edition as published and under revision as of 2026-10-05.
- ISO 19650-4:2022 — Information management using building information modelling, Part 4: Information exchange — International Organization for Standardization; detailed process and criteria for controlled information exchange during built-asset delivery and operation.
- ISO 9001:2026 — Quality management systems — Requirements — International Organization for Standardization; current quality-management standard addressing communication and documented information within a controlled management system.
- Republic Act No. 10173 — Data Privacy Act of 2012 — Lawphil; establishes lawful processing criteria, security and confidentiality duties, data-subject rights, and protections for personal and sensitive personal information.
- Implementing Rules and Regulations of the Data Privacy Act of 2012 — National Privacy Commission; official guidance on transparency, legitimate purpose, proportionality, collection, retention, data sharing, lawful processing, and security measures.
- Republic Act No. 9266 — Architecture Act of 2004 — Lawphil; statutory context for architectural service agreements, project documents, coordination, and professional responsibility.