Module 1: From Client Inquiry to Building Project
Learning Objectives
- Explain the complete project-initiation path from first inquiry to a controlled project definition.
- Convert a vague client request into a structured brief covering use, site, scope, budget, schedule, records, constraints, and required decisions.
- Distinguish client wants, verified requirements, assumptions, constraints, and missing information.
- Identify hold points that must be resolved before downstream drafting is treated as reliable.
- Relate early project definition to later multidisciplinary design, permit documentation, construction, revision control, and closeout.
Project Definition
Project definition is the controlled statement of what the client is trying to achieve, where the project will occur, what constraints and evidence are known, what remains uncertain, who must participate, and what decisions are required before design development can proceed responsibly.
Project Brief
A project brief is a traceable project-definition document that records the intended use, users, functional needs, site and property context, approximate scale, budget and schedule expectations, known constraints, existing records, required professionals, assumptions, unresolved questions, and approval status.
Assumption
An assumption is a temporary proposition used to continue limited analysis when a fact is not yet verified. It must be explicitly identified, assigned an owner for confirmation, and prevented from silently becoming a permanent project fact.
Constraint
A constraint is a condition that limits the feasible project solution, such as property boundaries, access, physical site conditions, client budget, time, existing structures, utility conditions, professional-scope requirements, or applicable regulatory requirements.
The Project Begins Before Drafting
A building project does not begin with lines on a CAD screen. It begins with controlled discovery.
For the progressive training scenario, assume a client is considering a two-storey reinforced-concrete community and institutional building on an identified property. The client initially says only that the building should contain flexible rooms, offices, toilets, service spaces, and room for future expansion.
That statement is not yet a design basis. Before dependable drafting begins, the project team must determine:
- who the client and decision-makers are;
- what the building is intended to do;
- who will use it and in what occupancy context;
- where the project will be located;
- what property and site evidence exists;
- what approximate project size is contemplated;
- what budget and schedule expectations exist;
- what future expansion is anticipated;
- what existing structures, utilities, access conditions, and records affect the site;
- what professional disciplines are required;
- what decisions are already made and what decisions remain open;
- what information is verified, provisional, missing, or contradictory.
The output of this stage is not a finished design. It is a controlled project definition from which design can begin.
From Vague Request to Controlled Project Definition
A client statement becomes definition-ready only after purpose, evidence, constraints, decisions, and responsibilities are made explicit; authorization to proceed is a separate later gate.
The Who–What–Why–Where–When Intake Framework
A disciplined intake can be organized around ten questions.
- Who? Identify the legal client, operational users, authorized decision-makers, funding parties, property owner where different, and primary project contacts.
- What? Define the intended facility, functions, approximate size, space needs, performance expectations, and whether the project is new construction, alteration, renovation, addition, or another form of work.
- Why? Establish the underlying problem or need: capacity, safety, service delivery, expansion, replacement, accessibility, operational improvement, or another objective.
- Where? Identify the property, lot references, address, access, surrounding context, existing structures, available survey information, and known site constraints.
- When? Record target start, target completion, externally imposed dates, phased occupation needs, procurement expectations, and decision deadlines.
- Budget? Record the client's working budget range, funding constraints, exclusions, contingencies, and whether the amount is a confirmed funding ceiling or only an initial expectation.
- Constraints? Record property, physical, operational, regulatory, utility, environmental, financial, schedule, access, or stakeholder limitations.
- Existing records? Inventory titles or property records, survey plans, technical descriptions, prior drawings, utility records, geotechnical reports, photographs, permits, maintenance records, and other relevant evidence.
- Required professionals? Identify disciplines needed for the actual project scope and current jurisdiction rather than assuming that one profession owns every design task.
- Required decisions? List what the client or responsible professional must decide, by when, and what downstream work depends on each decision.
This framework is a discovery tool, not a substitute for professional judgment or jurisdiction-specific requirements.
Client Intake Information Hierarchy
Good intake separates purpose and authority from technical evidence, constraints, and pending decisions.
Client Wants, Verified Requirements, Assumptions, and Constraints
These categories must not be mixed.
- Client wants express preference or aspiration. Examples include a flexible hall, a future third-floor allowance, a particular façade character, or a target opening date.
- Verified requirements are confirmed requirements supported by an authoritative source, an approved project decision, a competent professional determination, or a governing requirement applicable to the project.
- Assumptions are explicitly provisional. They may support limited study but must be identified and later confirmed or replaced.
- Constraints limit what is feasible or permissible.
- Unknowns are not assumptions until the team deliberately assigns a provisional basis and records how it will be verified.
- Conflicts occur when two sources, decisions, disciplines, or project objectives cannot simultaneously be satisfied without resolution.
A common project failure occurs when a preference is treated as a requirement, an assumption is treated as a surveyed fact, or a preliminary budget is treated as a validated cost plan.
Evidence Classification Before Design
The same statement can have very different reliability depending on its source and verification status.
- Client preference
- Unverified recollection
- Approximate site sketch
- Preliminary budget expectation
- Approved project decision
- Verified survey information
- Applicable governing requirement
- Responsible professional determination
Do Not Draft Critical Geometry from Unverified Assumptions
If lot identity, property geometry, controlling levels, access, existing structural conditions, utility interfaces, or another critical basis remains unresolved, the team should identify a hold point rather than quietly inventing data. Preliminary studies may continue when clearly labeled, but provisional geometry must not be allowed to masquerade as verified project information.
Developing the Initial Project Brief
- Record the inquiry, client identity, project contact, and date.
- Conduct a structured intake using the Who–What–Why–Where–When framework.
- Inventory property, site, utility, existing-building, and prior-project records.
- Separate client preferences from verified requirements and constraints.
- Identify assumptions, missing evidence, contradictions, and decisions still required.
- Establish an initial scope statement describing what is included and what is not yet included.
- Record approximate budget and schedule expectations without presenting them as validated cost or programme commitments.
- Identify professional disciplines required by the project scope and applicable law or regulation.
- Perform a preliminary feasibility screen: site, use, access, project scale, budget, schedule, technical complexity, and known regulatory constraints.
- Issue the project brief for review, record comments, and obtain documented alignment before it becomes the working project definition.
Project Initiation, Definition, and Authorization Gate
Shows the separate gates for project-definition readiness and documented authorization to proceed with the proposed professional-service stage.
A complete project brief does not itself authorize downstream professional work; unresolved definition issues or missing engagement authority return the project to a hold or revision state.
Client inquiry received → Collect objectives, site, budget, schedule, records, and constraints; Collect objectives, site, budget, schedule, records, and constraints → Classify facts, assumptions, constraints, and missing information; Classify facts, assumptions, constraints, and missing information → Critical project-definition information adequate?; Critical project-definition information adequate? — No → Record information hold and obtain missing evidence; Record information hold and obtain missing evidence → Collect objectives, site, budget, schedule, records, and constraints; Critical project-definition information adequate? — Yes → Prepare controlled project brief; Prepare controlled project brief → Perform preliminary feasibility and professional-team screen; Perform preliminary feasibility and professional-team screen → Project definition ready for the proposed service stage?; Project definition ready for the proposed service stage? — No → Resolve scope, priority, budget, schedule, or site-definition conflicts; Resolve scope, priority, budget, schedule, or site-definition conflicts → Prepare controlled project brief; Project definition ready for the proposed service stage? — Yes → Document scope, deliverables, exclusions, responsibilities, schedule, and commercial basis; Document scope, deliverables, exclusions, responsibilities, schedule, and commercial basis → Documented authorization to proceed obtained?; Documented authorization to proceed obtained? — No → Hold unauthorized downstream services; resolve engagement or approval; Hold unauthorized downstream services; resolve engagement or approval → Document scope, deliverables, exclusions, responsibilities, schedule, and commercial basis; Documented authorization to proceed obtained? — Yes → Proceed within the authorized professional-service scope
- Client inquiry received: terminator
- Collect objectives, site, budget, schedule, records, and constraints: input output
- Classify facts, assumptions, constraints, and missing information: process
- Critical project-definition information adequate?: decision
- Record information hold and obtain missing evidence: process
- Prepare controlled project brief: document
- Perform preliminary feasibility and professional-team screen: process
- Project definition ready for the proposed service stage?: decision
- Resolve scope, priority, budget, schedule, or site-definition conflicts: process
- Document scope, deliverables, exclusions, responsibilities, schedule, and commercial basis: document
- Documented authorization to proceed obtained?: decision
- Hold unauthorized downstream services; resolve engagement or approval: process
- Proceed within the authorized professional-service scope: terminator
Preliminary Feasibility Is a Screen, Not a Final Approval
Early feasibility asks whether the project appears capable of proceeding to design with the information currently available. It does not replace later professional design, formal regulatory review, cost planning, or permitting.
A useful preliminary screen considers:
- whether the intended use can reasonably be investigated on the identified property;
- whether the stated project scale appears compatible with available site information;
- whether access and utility issues are known or require investigation;
- whether existing structures affect the proposed works;
- whether the client budget and schedule are broadly compatible with the stated ambition;
- whether the necessary consultant disciplines can be engaged;
- whether critical property, survey, geotechnical, or existing-condition information is missing;
- whether the project requires specialist studies or approvals that must be planned early.
The correct output may be proceed, proceed with stated investigations, revise the brief, or hold pending critical information.
A Budget Number Is Not Yet a Cost Plan
A client may state an amount during the first meeting, but that amount may represent an aspiration, funding cap, partial budget, or outdated expectation. The project brief should state what the number means, what it includes or excludes, and whether a qualified cost estimate has been prepared.
The Building-Project Lifecycle
The broader training follows a controlled lifecycle:
- client inquiry;
- project definition and brief;
- property, survey, and site-information verification;
- regulatory and permit-path review;
- preliminary and schematic design;
- consultant exchange and multidisciplinary coordination;
- coordinated design development;
- discipline drawing and specification production;
- QA/QC and document control;
- permit submission and authority comments;
- construction-stage coordination and approved revisions;
- record and as-built documentation;
- occupancy, handover, and closeout.
The sequence is not always perfectly linear. Design decisions may expose missing survey information; authority comments may require revisions; construction discoveries may require coordinated changes. The control principle is that each loop must preserve responsibility, revision identity, evidence, and approval status.
Building Project Lifecycle
Project information matures from intent to verified records; every later stage depends on controlled inputs from earlier stages.
Progressive Project Scenario: Module 1 Output
At the end of this module, the training project should have a project-definition package containing, at minimum:
- client and decision-authority record;
- intended facility use and principal user groups;
- preliminary accommodation and functional needs;
- approximate project scale;
- working budget statement with status and exclusions;
- target programme with known fixed dates and assumptions;
- property and site records received;
- existing-structure and utility information received;
- known constraints and risks;
- missing-information register;
- required-professional screen;
- initial scope boundary;
- list of decisions required before design development;
- approved or pending project brief status.
Later modules will progressively replace preliminary assumptions with verified survey, regulatory, architectural, structural, plumbing, electrical, mechanical, fire-safety, and other discipline information.
Project Engagement and Authorization to Proceed
A complete project definition establishes what the project is. It does not, by itself, establish that every professional service or design stage has been commercially and organizationally authorized.
Before detailed professional work proceeds, the organization should have a documented engagement basis appropriate to the project and profession. At a minimum, that basis should make the following visible:
- scope of services — the professional tasks or stages included in the engagement;
- intended deliverables — the drawings, reports, models, calculations, specifications, meetings, submissions, or other outputs expected at the agreed stage;
- explicit exclusions — work not included, deferred work, specialist services by others, or information that the client must separately procure;
- responsibilities and client-supplied information — who provides property records, surveys, existing drawings, operational data, approvals, and other inputs;
- schedule and milestones — the intended service sequence, decision dates, review points, and dependencies;
- commercial or fee basis — only to the level needed to understand what services, assumptions, reimbursables, or stage limits the commercial arrangement covers;
- authorization mechanism — the organization's appropriate signed agreement, written approval, purchase order, notice to proceed, or other documented authority to start the stated services;
- change-control trigger — the point at which a changed project brief, deliverable, programme, client instruction, or other agreed basis must be reviewed as a potential scope, fee, or schedule change.
The exact contract form, fee structure, and authorization instrument vary by profession, organization, procurement method, and client. This lesson does not prescribe a universal contract template.
Project Definition Complete ≠ Professional Services Authorized to Proceed
A project may be sufficiently defined for a proposal or service agreement while detailed design is still not authorized. Treat project-definition readiness and authorization to proceed as two separate gates. Do not interpret an approved brief, meeting minute, preliminary sketch, or client enthusiasm as automatic authority to perform every downstream service.
Confirming the Engagement Gate
- Confirm that the current project brief is sufficiently defined for the proposed service stage.
- State the services and deliverables to be provided in that stage.
- State important exclusions, client responsibilities, assumptions, and required upstream information.
- Record the intended programme, review milestones, and dependencies.
- Record the commercial or fee basis at the level required by the organization's engagement process.
- Obtain the appropriate documented agreement or authorization to proceed.
- If the agreed basis later changes, evaluate the change before silently expanding, deleting, or accelerating the professional service.
Philippine Professional and Permit Context
In the Philippines, building work may involve multiple regulated professions and the building-permit system administered under the National Building Code framework. The project team should identify applicable professional scopes and current local permit requirements for the actual project rather than treating this lesson as a universal permit checklist. Current requirements, forms, local procedures, and referral-code obligations must be verified at the time of application.
Intake Review Case: Separate Three Different Commitments
The client requests future expansion, supplies an undated sketch, and states a fixed opening date. Record each statement separately before accepting the brief:
| Statement | Required treatment | Evidence needed to close the item |
|---|---|---|
| Future additional floor | Client requirement awaiting technical definition | Agreed expansion scope and responsible consultants' design inputs |
| Sketch represents the property | Unverified geometry | Identified, current survey/property information |
| Building will open on the requested date | Target rather than validated programme | Reviewed design, approval, procurement, and construction sequence |
Readiness means these distinctions and their owners are visible. It does not mean every client expectation has become a verified fact or an authorized commitment.
- A building project begins with controlled project definition, not with unverified drafting.
- A structured intake converts a vague client request into explicit objectives, evidence, constraints, assumptions, responsibilities, and decisions.
- Client wants, verified requirements, assumptions, constraints, and unknowns must remain visibly distinct.
- Critical property, geometry, level, access, utility, and existing-condition uncertainties create hold points for downstream drafting.
- The project brief becomes the first controlled information baseline that later disciplines progressively verify and develop.
- Project definition readiness and professional authorization are separate gates: a complete brief does not automatically authorize detailed downstream services.
References
- Republic Act No. 9266 — Architecture Act of 2004 — Lawphil; statutory context for architectural pre-design, planning, design, coordination, and professional responsibility.
- Republic Act No. 544 — Civil Engineering Law — Lawphil; statutory context for regulated civil-engineering services.
- Presidential Decree No. 1096 — National Building Code of the Philippines — Senate of the Philippines Legislative Reference Bureau; primary legal framework for building-code administration, permits, construction, use, occupancy, and maintenance.