Control Room Design Responsibilities
Who Owns What on a Large Project?
Six weeks into a control room project, the drawings stall. The console team is waiting on final monitor counts. The technology team is waiting on confirmed room constraints. The project lead discovers that a key interface was never assigned in writing. Nobody necessarily failed at their own discipline. The project failed between disciplines.
The confusion often starts much earlier, with the phrase someone types into Google: “control room design.” The phrase sounds like one service, but on a large control room project it can describe several different scopes: overall project delivery, facility and human-factors design, technology and systems integration, the end user’s operational requirements, and the console or technical-furniture package.
Search the phrase, and you will find architects, engineering firms, integrators, consultants, EPC companies, and console manufacturers all using similar language. They are not necessarily competing for the same scope. Several of them may be required on the same project.
This is a practical guide to control room design responsibilities: what each project function owns, what they need from one another, and where the console scope fits.
Who designs a control room?
Large control room projects need five functions to be owned clearly: project delivery and interface management; facility, engineering, and human-factors design; technology and systems integration; end-user operational requirements and approvals; and console and technical-furniture engineering. One company may own several functions, and one function may be split across several companies. The important step is to define ownership, required inputs, deliverables, and interfaces in writing before design decisions harden.
These are the five functions most directly involved in shaping and coordinating the operator workstation and console package specifically. Large capital projects often also carry separate procurement, construction, commissioning, cybersecurity, physical security, safety, training, or maintenance scopes, depending on the project and delivery model. The five here are not an exhaustive list of every discipline on a control room build, they are the ones whose decisions most directly touch the console.
Rule of thumb: do not assume scope from a company label. A website may call a company a “control room designer” or “control room solutions provider.” The useful questions are what that company actually designs, approves or stamps, supplies, coordinates, requires from others, hands back to others, and explicitly excludes.
The Five Project Functions at a Glance
| Function | Primary ownership | Typical deliverables | Typical coordination |
| Project delivery & interface management | Overall delivery structure, schedule, commercial interfaces, decision flow, cross-discipline coordination | Project schedule, responsibility/interface matrix, contracts, decision and risk tracking | Owner, architects/engineers, integrators, console vendor, contractors |
| Facility, engineering & human factors | Room architecture, building systems, circulation, accessibility, sightlines, environmental conditions, discipline engineering | Floor plans, elevations, construction documents, engineering packages, human-factors studies where applicable | Project lead, end user, integrators, console vendor, contractors |
| Technology and systems integration | IT, OT, AV, communications, and visualization systems, and applicable operational platforms (e.g. SCADA, EMS, OMS, DCS); exact systems vary by vertical | Systems design, equipment lists, rack elevations, network/signal diagrams, termination schedules, integration documentation | End user, project lead, facility team, console vendor |
| End user / operations | Operational mission, staffing, workflows, equipment needs, operating priorities and budget constraints as applicable, growth, acceptance | Operational requirements, equipment inventory, review decisions, approval/sign-off | Every other function |
| Console / technical furniture | Operator workstation geometry, equipment accommodation, ergonomic configuration, accessories, internal cable management, fabrication and delivery | Console drawings, BOM, equipment provisions, installation/delivery information, manufacturing release | End user, facility team, project lead, integrators |
The exact contracting structure varies. An EPC firm, architect/engineer, owner’s representative, general contractor, consultant, design-build team, or other project lead may perform or coordinate several of these functions.
The Company Label Is Not the Scope
This distinction matters because the market does not divide cleanly into five company types. An EPC firm may self-perform engineering. An architecture or engineering firm may serve as prime consultant. A specialist control room consultant may cover human factors, room planning, and technology strategy. An AV or systems integrator may also supply furniture. A console manufacturer may provide extensive planning support without taking responsibility for architecture, electrical design, or systems integration.
The safer question is not “What kind of company are you?” It is: “Which project function do you own, what do you need from the other teams, and what will you hand back to them?”
A Closer Look at Each Function
On capital-intensive projects, this function may sit with an EPC firm, owner’s project manager, owner’s representative, prime consultant, construction manager, or design-build team. Its job is to keep the overall project moving: schedule, scope boundaries, procurement interfaces, review gates, decision ownership, and coordination between disciplines.
For the console package, this team does not need to become a workstation ergonomics specialist. It needs a console vendor that can identify dependencies early, commit to a review and manufacturing schedule, and produce documentation that fits the project’s submittal and approval process.
This function shapes the physical environment around the operators. Depending on the project, it may include architecture, room planning, accessibility, sightlines, lighting, acoustics, HVAC, power, security, circulation, supporting spaces, and human-factors analysis. The work may be delivered by one multidisciplinary firm or several specialist consultants.
The console is an input to this work and an output of it. Room geometry, columns, floor boxes, HVAC, lighting, video-wall location, and circulation affect workstation placement. Once the console is configured, its footprint, clearances, equipment loads, service zones, and operator sightlines become inputs back to the facility team.
This function covers the technology operators use to run, monitor, communicate, and visualize the operation. The specific systems depend on the vertical. Electric-generation environments may be DCS-heavy, while transmission and distribution control centers commonly rely on SCADA, EMS, OMS, and related grid-management platforms. Security, transportation, public-safety, and network operations centers use different system stacks again.
Across those verticals, the workstation interface is consistent: monitor models, computer hardware, KVM, radios, phones, control panels, peripherals, shared displays, cable quantities, mounting requirements, heat-generating equipment, and service access all have to be reconciled with the console package.
The operating organization defines what the room must do. That includes operator roles, staffing by shift, primary and secondary workflows, equipment inventory, collaboration requirements, growth plans, resilience expectations, budget, and the date the room must be operational.
This role is easy to underweight because operations may not produce architectural drawings or engineering packages. But every other discipline is translating operational requirements into its own deliverables. If those requirements are incomplete or change without being captured, rework follows regardless of how well the individual disciplines perform.
Tresco’s core scope is the operator workstation and related technical furniture. That includes console geometry, equipment accommodation, monitor-support configuration, accessory selection, internal cable management, ergonomic adjustment, buildability, fabrication, and delivery. The exact contracted scope should always be stated in the proposal and project documents.
That scope does not automatically include room architecture, electrical engineering, HVAC design, acoustics, network design, or operational-system integration. Tresco still needs information from those disciplines, and it needs to return usable interface information to them. That is the difference between staying inside scope and working in isolation.
The Real Coordination Problem: The Interfaces
Most control room decisions are not one-directional. A monitor count influences worksurface depth. A floor-box location can constrain workstation placement. A structural column can limit console width. Equipment loads affect cable capacity and service access. Sit-stand movement affects clearances. Video-wall location affects operator sightlines. The console specification responds to the room and technology, then sends requirements back into those same systems.
That means the practical coordination question is not simply who owns each discipline. It is what each discipline must receive from the others before it can finish its own work.
| Interface | Input to console scope | Effect on console | Output back to project team |
| Architecture / room | Room dimensions, columns, circulation, doors, elevations, finish constraints | Footprint, orientation, row spacing, service access, operator placement | Console footprint, clearances, sightlines, anchoring and interface conditions |
| Electrical | Floor-box locations, available circuits, UPS strategy, emergency-power requirements | Power entry, internal distribution assumptions, equipment placement, movement clearance | Console power-entry locations, requested receptacle locations, equipment load assumptions |
| Technology / systems | Monitor models, CPU dimensions, KVM, radios, peripherals, cable quantities, video-wall/display requirements | Worksurface depth, monitor layout, bay capacity, cable pathways, heat and service access | Equipment capacity, cable pathways, mounting provisions, access requirements |
| Mechanical / environmental | HVAC diffuser and return locations, known thermal constraints, ventilation and service conditions | Workstation placement relative to airflow, equipment heat considerations, console clearances | Console clearance requirements and equipment heat assumptions for HVAC coordination |
| Human factors / operations | Operator roles, tasks, collaboration, viewing needs, reach frequency, staffing and growth | Geometry, adjustability, monitor arrangement, seating position, adjacent-role relationships | Configured workstation dimensions and operator-facing layout for review |
| Project delivery / construction | Review gates, installation sequence, access limitations, delivery method, logistics windows, responsibility split | Release timing, packaging, installation logistics | Submittal schedule, delivery/install requirements, release status, unresolved dependencies |
Mechanical/environmental interface note: Tresco does not engineer the room’s HVAC system or calculate the formal cooling load. This row reflects the console-relevant inputs and outputs at that interface only.
Key point: a clear scope exclusion is useful, but an interface definition is better. “Electrical by others” tells the project who is not responsible. “Console requires power entry at these locations; electrical design and installation by others” tells the project what must happen next.
Where Tresco Fits
Tresco’s project deliverables are concrete: configured console drawings, bill of materials, equipment and accessory provisions, delivery and installation information where included, and the documentation required to release the approved design for manufacturing. The value of the console package depends on how well those deliverables stay connected to the room, operator, equipment, and project constraints around them.
A useful vendor test is therefore simple: ask the console manufacturer to state what it designs, what it manufactures, what it documents, which interfaces it coordinates, what inputs it still needs, and what it explicitly excludes. Clear boundaries make coordination easier, not weaker.
Why CORTEX exists
Control room console projects have traditionally depended on repeated handoffs between discovery, sales, design, engineering, and customer review. A requirement changes on a call, an equipment list is updated in an email, a room constraint appears in a drawing revision, and the next proposal has to reconcile all of it again.
CORTEX is designed to reduce that fragmentation inside the console-planning scope. It keeps console-related requirements, room context, equipment needs, configuration decisions, scope dependencies, review status, and project revisions connected in one traceable planning record. It does not replace the architect’s construction documents, the integrator’s systems package, the EPC or project manager’s master schedule, or the owner’s formal document-control system. See Tresco’s CORTEX page for the current public description of the tool.
CORTEX helps define, review, and hand off the interface between the console package and the rest of the control room project. That is the whole positioning, nothing broader.
Five Functions, One Project: A CORTEX Workflow Example
The five-function framework applies across control room verticals. The walkthrough below follows a representative project through CORTEX to show the interfaces in practice, from intake to an approved console package. The exact technology stack and stakeholder mix change by industry; the coordination problem does not.
Intake
The session opens with the Discovery Details panel: the operational driver behind the project, budget context, who on the client side was in the room and their role, client pain points, likely contract flow, the decision maker, and the project timeline. These are not a substitute for the owner’s formal requirements documents. They are the project-context inputs a sales rep captures directly from the client conversation, and they stay visible as the workstation package develops. A separate Notes tab holds free-form project notes alongside the structured fields.
Room context
The verified room footprint, structural constraints, doors, columns, and other known conditions are brought into the planning record before consoles are finalized. Workstation positions are then configured against the real room instead of a generic template.
Console configuration and comparison
Different operator roles may carry different monitor counts, equipment loads, collaboration needs, and duty cycles. Dispatch, security, supervisor, or other operator positions do not have to share one workstation configuration simply because they share one room. CORTEX allows the project team to compare configurations against the requirements of each position.
Design checks and dependencies
Before release, the configured workstation package can be reviewed against known room constraints, footprint, equipment accommodation, operator spacing, delivery conditions, installation responsibility, and other console-related dependencies. Open questions stay visible rather than disappearing into a separate email thread.
Review and handoff
The approved console package can then move forward with a clearer record of what was decided, which assumptions remain, what Tresco is supplying, and what information adjacent disciplines still need to coordinate.
How CORTEX Supports Each Stakeholder’s Workflow
CORTEX is useful to a multidisciplinary project when the console-related outputs can be consumed by the people working around the console scope. The record should support those interfaces without pretending to replace each stakeholder’s own design system or document-control process.
| Stakeholder / function | What CORTEX can give them | What CORTEX does not replace |
| End user / operations | A traceable record of console-related requirements, configured positions, decisions, open items, and revisions | Formal operational procedures, staffing studies, owner requirements management, or corporate approvals |
| Architects / engineers / consultants | Dimensioned console footprints, clearances, equipment interfaces, and other physical requirements needed for room coordination | Architectural, structural, mechanical, electrical, life-safety, or stamped engineering documents |
| Project delivery lead | Console-package status, dependencies, review gates, delivery/install responsibilities, and unresolved interface items | The master project schedule, contracts, risk register, submittal platform, or enterprise document control |
| Technology and systems integrators | Console equipment provisions, physical accommodation, mounting and cable-path information, and known interface constraints | SCADA/DCS/EMS/OMS design, network engineering, rack design, AV system design, cybersecurity, or commissioning documentation |
| Tresco | The approved planning record used to develop the console drawings, BOM, equipment provisions, and manufacturing release | Other disciplines’ engineering or contractual responsibilities |
CORTEX carries console-related inputs and confirmations in, and returns an approved console package and interface information to the rest of the project.
Before Finalizing a Console Spec, Answer These in Writing
- Who owns project delivery and interface management, and is that responsibility visible in a responsibility or interface matrix?
- Who owns facility architecture, building systems, human-factors review, technology integration, and the console package?
- What are the verified room constraints, including dimensions, columns, door swings, circulation, floor or wall service locations, and video-wall conditions?
- How many operators are required by shift and function, and what growth or spare capacity should the room support?
- What is the monitor and equipment inventory by position, ideally by model number and physical dimensions?
- What are the expected power, data, communication, and cable-termination requirements at each workstation?
- Which console decisions depend on information still outstanding from architecture, electrical, IT/OT, AV, or operations?
- Which review gates require formal approval before the console can move into manufacturing release, and who signs each one?
- What is the delivery and installation window, what access constraints apply, and what project work must be completed before consoles arrive?
- Which items are Tresco scope, which are adjacent scope, and what interface information must pass between them?
Control Room Design Stakeholders FAQ
-
Who designs a control room?
No single company designs a whole control room. Five functions are most directly involved: project delivery and interface management, facility and human-factors design, technology and systems integration, end-user operational requirements, and console/technical-furniture engineering. Which companies own which functions depends on the contracting model.
-
Who is responsible for control room design?
There is rarely one universal answer. Large projects distribute control room design across several functions: project delivery, facility and human-factors design, technology integration, operations, and workstation/console engineering. The contracting model determines which companies own those functions, and it is worth confirming in writing rather than assuming it from a company’s marketing language.
-
What does a control room design company actually do?
It depends entirely on the company, which is the point. A firm calling itself a “control room designer” or “control room solutions provider” could own facility architecture, technology integration, console engineering, or some combination. Ask what it designs, what it stamps or approves, what it supplies, what it coordinates, and what it explicitly excludes before assuming scope from the label.
-
Do I need an architect, systems integrator, consultant, or console manufacturer?
Most large control room projects need several of these, not one. Use the five-function framework to check which functions your delivery model already covers (an EPC firm or design-build team may self-perform more than one) and which still need a named owner.
-
Who coordinates a large control room project?
Project delivery and interface management, typically an EPC firm, owner’s project manager, owner’s representative, prime consultant, construction manager, or design-build team, owns overall coordination: schedule, scope boundaries, review gates, and decision ownership across disciplines.
-
What does a console manufacturer need from the other disciplines?
Verified room dimensions and constraints from architecture, floor-box and power information from electrical, equipment and cable requirements from technology integration, and operational requirements from the end user. The interface table earlier in this article breaks down exactly what moves in each direction.
-
What is the difference between an architect, systems integrator, and console manufacturer on a control room project?
The architect and engineering team shape the room and building systems. Technology integrators design and connect the operational, visualization, communications, and related systems. The console manufacturer designs and builds the operator workstation and its furniture-side equipment provisions. Their work overlaps at interfaces, which is why the handoffs need to be defined explicitly.
-
Does every control room use DCS?
No. Process control facilities may rely heavily on DCS, while transmission and distribution control centers commonly use SCADA, EMS, OMS, and other grid-management platforms. The exact system architecture depends on the operating function.
-
What should I send when I ask for a console design?
Start with verified room plans, operator count and role breakdown, monitor and equipment inventory, video-wall or shared-display requirements, known power/data constraints, growth expectations, delivery timing, and the date the room must be operational. If some inputs are unknown, identify them as open dependencies rather than assuming them.
-
Which standard is most relevant to control room console ergonomics?
The ISO 11064 series is the primary international reference for ergonomic design of control centers, including room layout, workstation design, displays and controls, environmental conditions, and evaluation. The applicable requirements for a specific project may also include industry, jurisdictional, safety, accessibility, cybersecurity, and owner standards.
-
Does control room technology integration raise cybersecurity considerations?
Yes, and it sits with the technology and systems integration function, not the console vendor. NIST SP 800-82 is a useful reference for the operational-technology security context behind modern control environments.
-
How does CORTEX fit into an EPC-led or consultant-led project?
CORTEX supports the console package by keeping console-related requirements, room context, equipment needs, decisions, dependencies, revisions, and release status in a traceable record. The EPC firm, consultant, architect, or project manager can use those outputs in its own coordination process without CORTEX replacing the project’s formal schedule, engineering documents, or document-control platform.