Multi-site workplace programmes fail when a standard is either too loose to guide procurement or too rigid to fit a real building. The useful middle is a kit of decisions: what must repeat, what can adapt, how changes are approved and how each site proves readiness.
For a Pune or Mumbai project, the useful question is not whether a design looks current. It is whether the brief, building, services, procurement and operating rules agree. The following framework is written for decision-makers who need a workplace that can be priced, built, occupied and maintained.
Create a design language
Define the elements people should recognise: palette, signage logic, room names, key materials, workstation family, technology experience and accessibility principles. Keep the list short enough to use. A design language is not a catalogue of every chair and tile that has ever been approved.
For each standard, state why it exists. If a room naming convention helps visitors, say so. If a workstation supports maintenance, document the reason. When local teams understand the intention, they can propose an equivalent rather than waiting for a central exception.
Classify what can change
Put decisions into three groups: fixed, adaptable and local. Security boundaries and critical technology may be fixed. Room ratios and furniture quantities may adapt to attendance and work. Artwork, local materials and pantry details may be local. This classification keeps reviews focused on meaningful risk.
Use a deviation log, not informal exceptions. Record proposed change, reason, impact, approver and whether the learning should update the standard. A multi-site programme gets stronger when local knowledge returns to the kit instead of disappearing in email.
Use a common room catalogue
Room data sheets make comparison possible. Define small meeting, medium meeting, boardroom, focus room, phone room, training, collaboration and support spaces by use and technology. Then allow local teams to select the rooms they need rather than drawing every location from scratch.
A catalogue also supports procurement and facilities training. The same room can have a different area or finish while retaining the same user promise. That is more valuable than forcing identical dimensions into unrelated floorplates.
Plan the supply chain
A standard must survive availability, lead time, local labour and maintenance. Name approved alternatives and define the performance they must match. Ask who will replace the product two years later. A product that is easy to specify but impossible to service is not a robust standard.
Connect procurement decisions to the project's sustainability ambition. IGBC and GRIHA are official sources for different green-building rating conversations, but each site must confirm which pathway and evidence apply.
Make technology supportable
Standardise the user experience and support model, not only the hardware. Define room controls, cable management, booking, access, displays, cameras, microphones and fault reporting. A regional IT team should be able to diagnose a room without learning a different system at every address.
Test the standard in one representative room before scaling. Include facilities, IT, security, users and the local contractor. The pilot should be allowed to reveal a problem. That is its purpose, not a failure of the programme.
Measure the rollout
Set readiness checks for design, procurement, site quality, commissioning, handover and user launch. Track defects by type and location. After occupation, ask whether rooms book, whether people find the settings, whether the support route works and which standard created friction.
Use the findings to revise the kit. The Vektor process and blog are natural places to explain the link between strategy, delivery and operation. A standard is a living control system, not a PDF that nobody opens after approval.
Before approval, ask three plain questions. What is known from the site or the client? What is still an assumption? What will prove the decision worked after installation? Put the answers beside the relevant drawing, schedule or source. This keeps the conversation honest when the project moves from strategy to design, from design to procurement and from procurement to handover.
A decision checklist for the project meeting
Use this checklist to turn the article into a controlled next step. It is intentionally practical: each item should have a named owner, a source or drawing, a decision date and a test that another person can verify. If an item is still an assumption, label it as one. That is not a weakness. It is a warning before the assumption reaches procurement or site work.
- Create a design language: define the owner, evidence, decision date and acceptance test before the drawing or order is released.
- Classify what can change: define the owner, evidence, decision date and acceptance test before the drawing or order is released.
- Use a common room catalogue: define the owner, evidence, decision date and acceptance test before the drawing or order is released.
- Plan the supply chain: define the owner, evidence, decision date and acceptance test before the drawing or order is released.
- Make technology supportable: define the owner, evidence, decision date and acceptance test before the drawing or order is released.
- Measure the rollout: define the owner, evidence, decision date and acceptance test before the drawing or order is released.
For a live project, carry the open questions into the brief, cost plan, programme and handover record. The team should be able to tell what is confirmed, what is provisional, what is excluded and what will be checked after installation. That discipline is more valuable than adding another adjective to the design description.
Decision matrix for this project
This guide is most useful when it becomes a project control. Use the table below to assign an owner, retain the evidence and define what will count as done. It keeps a design conversation connected to procurement, site work and handover.
| Decision area | Question to answer | Evidence to retain |
|---|---|---|
| Design language | What should people recognise at every location? | Short standard with reasons |
| Flexibility | Which choices are fixed, adaptable or local? | Deviation log and approval route |
| Room catalogue | Which settings can local teams select from? | Room data sheets and technology standards |
| Learning | How will one site improve the next? | Readiness checks, defects and post-occupancy review |
Implementation checklist
Before releasing the next drawing, order or site instruction, check each of these items. A useful checklist does not replace judgement. It makes the judgement visible to the people who must approve, build and operate the workplace.
- Design language: record the decision owner, evidence source, decision date and acceptance test.
- Flexibility: record the decision owner, evidence source, decision date and acceptance test.
- Room catalogue: record the decision owner, evidence source, decision date and acceptance test.
- Learning: record the decision owner, evidence source, decision date and acceptance test.
Questions decision-makers ask
The central decision is building a multi-site office standard that repeats the user promise while allowing responsible local adaptation. Keep that decision visible in the brief so layout, procurement and delivery choices can be tested against it.
Confirm the evidence listed in the decision matrix: the scope, responsible owner, relevant drawings or records, and the date when the decision will be accepted. Mark assumptions instead of treating them as facts.
Coordinate it before procurement and before ceilings, partitions or services are closed. Late coordination usually turns a design question into a variation, rework or an operational compromise.
Pilot the standard in one representative room or site, document the deviations, and update the kit before wider procurement. The useful next step is a controlled review with a named owner, an agreed evidence source and a simple acceptance test.
Sources and scope note
This article uses the official and professional reference pages below for the limited points they publish. Recommendations about layout, procurement and delivery are Vektor Spaces' practical project guidance, not a claim that a rating, code approval or performance outcome has been achieved. Confirm the current requirements with the appointed consultants, landlord and authorities for the actual project.
- IGBC Green New Buildings rating system. Official IGBC page describing its Green New Buildings rating system and the wider family of green-building programmes.
- GRIHA rating. Official GRIHA page describing the national green-building rating approach and project evaluation.
- Bureau of Energy Efficiency. Official BEE website. The article treats energy-code compliance as a project-specific design and approval question, not a universal promise.
- CIBSE Knowledge Portal. Professional engineering guidance portal used as a reference point for building-services design and operational questions.