13.1 Feasibility Studies: Identifying Project Stakeholders

Why Stakeholder Identification Comes First

Before a single drawing is sketched or a budget is modeled, the interior designer must answer one question: who has a stake in this project, and what do they need from it? CIDQ's IDPX Domain I opens with stakeholder identification because every later feasibility decision—program fit, code path, budget envelope, schedule—flows from the people the project must serve. Missing a stakeholder early is the most expensive mistake a designer can make. A brand standard discovered during construction, or a neighbor's easement revealed at permitting, can trigger a redesign that costs weeks and tens of thousands of dollars. Feasibility is the cheap moment to find these constraints; construction is the expensive one.

Types of Stakeholders

A stakeholder is anyone who affects or is affected by the project. IDPX expects you to distinguish among the following types and to know what each one cares about.

The designer's job at feasibility is to name each stakeholder for the specific project, not to work from a generic list. A hospital renovation has very different stakeholders than a boutique retail fit-out.

Participatory Design

Participatory design actively involves end-users and other stakeholders in design decisions rather than designing for them. In a workplace project, this may mean workshops with department heads and surveys of staff; in a healthcare renovation, interviews with nursing staff and patients; in a school, sessions with teachers and maintenance crews. The goal is to surface operational knowledge the designer would otherwise miss—where the cart storage actually needs to be, which corridor gets congested at shift change, which finish fails under the real cleaning regimen.

The trade-off is time. Participatory processes slow early phases but reduce late-stage changes, which is almost always the cheaper trade. IDPX items may test whether participatory design is appropriate for a given project type; it is most valuable when the user group is identifiable and the design has operational complexity.

Stakeholder Surveys and Requirements

A stakeholder survey is a structured instrument—questionnaire, interview, or workshop—used to gather input on needs, wants, and constraints before programming begins. Surveys convert opinions into data the designer can weigh, rank, and reconcile. IDPX distinguishes between two layers of requirements that surveys surface:

• Project requirements — what the project must deliver to be successful, often owner-driven: a budget ceiling, a schedule, a brand standard, a lease obligation.
• Stakeholder requirements — what each stakeholder group needs from the result, often user-driven: privacy, daylight, throughput, accessibility, durability.

Conflicts between the two are the designer's first negotiation problem. An owner who wants the minimum cost per square foot and a user group that wants private offices are not wrong about their own needs; they are simply in tension. The feasibility study's value is in surfacing these tensions early, in writing, so the owner can resolve them with real numbers rather than with wishful assumptions.

Funding Sources and Budget Constraints

How a project is funded determines how tightly scope is constrained and what restrictions attach. IDPX lists three broad sources:

A grant-funded historic adaptive reuse carries very different constraints than an equity-funded tenant improvement. Historic tax credits require the Secretary of the Interior's Standards be met, which constrains everything from window replacement to interior feature retention. Identifying the funding source early lets the designer tailor the program and quality level to what is actually affordable and permissible.

RACI: Roles and Responsibilities

IDPX expects familiarity with the RACI matrix, a tool for clarifying who does what across a stakeholder set:

• Responsible — does the work (e.g., the designer drafts the program).
• Accountable — owns the outcome and approves it; only one A per task.
• Consulted — gives input before the decision is made (e.g., the operator reviews FF&E).
• Informed — is told after the decision is made (e.g., neighbors notified of construction schedule).

A clear RACI prevents the most common feasibility-stage failure: an unspecified approver who stalls the schedule because no one routed the decision to them. The matrix is especially valuable when the owner is a large institution with multiple internal approvers—a facilities director, a CFO, a board committee—each of whom may be A for a different task.

Exam Scenario

An IDPX item may describe a hotel renovation and ask which stakeholder must approve the guest-room FF&E. The operator/brand representative typically holds brand-standard approval rights; the owner is accountable for the budget but not for brand compliance. Knowing which stakeholder owns which decision is the key to these items. A second item may ask which funding source most likely imposes historic-preservation restrictions on interior finishes; the answer is a grant or tax-credit source, not equity or conventional debt.