See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/273750768

Modeling Knowledge for Architectural Programming

Article in Journal of Architectural Engineering · June 2013

DOI: 10.1061/(ASCE)AE.1943-5568.0000099

CITATIONS READS
14 764

2 authors:

Mohammad A. Hassanain Mohammed Juaim

King Fahd University of Petroleum and Minerals Thamar university
144 PUBLICATIONS 2,992 CITATIONS 3 PUBLICATIONS 41 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Mohammad A. Hassanain on 03 October 2023.

The user has requested enhancement of the downloaded file.

 Modeling Knowledge for Architectural Programming
Mohammad A. Hassanain1 and Mohammed N. Juaim2

Abstract: Architectural programming practices are still being perceived to be inefficient. This research endeavors to respond to this concern by
proposing a generic framework model that aims at capturing the process of properly identifying and communicating client and user require-
Downloaded from ascelibrary.org by KFUPM KING FAHAD UNI OF on 05/09/13. Copyright ASCE. For personal use only; all rights reserved.

ments to design teams. To achieve this objective, the writers have investigated the current practices of architectural programming for the pur-
poses of describing the approaches followed for identifying the requirements of building projects, the methods adopted to communicate these
requirements to design teams, and the limitations of these practices. Development of the framework model was based on knowledge derived
from the literature and observed professional practice. The paper is of practical value to architectural programmers and design professionals. It
could act as a guide for conducting architectural programming activities and provides a way of bridging the gaps in architectural programming
practices. This paper provides for an improved comprehension of the roles of all project participants in the programming process in addition to
promoting frequent communication among all participants throughout the process. DOI: 10.1061/(ASCE)AE.1943-5568.0000099. © 2013
American Society of Civil Engineers.
CE Database subject headings: Architecture; Design; Communication; Client relationships; Information management.
Author keywords: Architectural programming; Framework; User requirements; Design solutions.

Introduction that needs to be taken into account and the challenges present in the
process of identifying and conveying clients’ actual needs and
The attributes of an ideal building project range from a project that requirements properly to design teams during the programming
does not exceed the budget of the owner, a project that could be phase, architectural programs are still being perceived to be unclear
easily constructed and delivered on time, and a project that satisfies and inefficient, and as such, they may not accurately manifest client
the requirements of the owner and users. Different stakeholders in and user requirements. To overcome these challenges, a number of
building projects are facing a multitude of problems according to studies have been conducted to develop programming guides for
their degree of involvement in the project. Building owners suffer inexperienced clients. Despite these attempts, the current pro-
from project delays and cost overruns. Contractors are challenged by gramming practices are still considered to be inadequate (Yu et al.
constructability problems for their projects. Building users are af- 2005; Bogers et al. 2008). It is widely acknowledged that the lack of
fected through occupying buildings that do not meet their require- a systematic and comprehensive framework for identifying and
ments and expectations. communicating client and user requirements to design teams is the
Recently, architectural programming has received noticeable main obstacle to the success of the final building design (Kelly et al.
attention, because it is one of the most significant phases in the 2003; Yu et al. 2005; Shen and Chung 2006; Bogers et al. 2008).
development of building projects. The term architectural pro- The objective of this paper is to present the development of
gramming is used to describe “the process of identifying and a generic framework model that aims at capturing the process of
articulating client requirements in the early design process of a properly identifying and communicating client and user require-
construction project” (Yu et al. 2007). Research on the efficiency of ments to design teams. The developed framework model could act as
various stages of the project delivery process reveals that there are a guide to professionals charged with developing and implementing
serious gaps between the client and user expectations and the the architectural program for building projects.
degree to which building projects meet their user requirements
(Hudson 1999; Smith 2002; Erdener 2003; Shen and Chung 2006;
Bogers et al. 2008). Research Methodology
Previous research on architectural programming (Duerk 1993;
Shen and Chung 2006; Bogers et al. 2008; Kelly et al. 2003; Yu et al. To accomplish the objective of this research, the following activities
2005) reveals that, because of the massive amount of information were carried out:
• Addressing the significance of the architectural programming
phase and its effect on the final performance of building projects;
1
Associate Professor, Architectural Engineering Dept., King Fahd Univ. • Investigating the current practices for architectural programming
of Petroleum and Minerals, Dhahran 31261, Saudi Arabia (corresponding in Saudi Arabia through presenting a description of the ap-
author). E-mail: [email protected] proaches followed for identifying the requirements of building
2
M.S. Student, Architectural Engineering Dept., King Fahd Univ. of projects, the methods adopted to communicate these require-
Petroleum and Minerals, Dhahran 31261, Saudi Arabia.
ments to design teams, and the limitations of these practices;
Note. This manuscript was submitted on January 15, 2011; approved on
• Synthesizing the available knowledge sources into a formal
May 31, 2012; published online on May 15, 2013. Discussion period open
until November 1, 2013; separate discussions must be submitted for generic framework model in an effort to standardize the meth-
individual papers. This paper is part of the Journal of Architectural odology that architectural programmers can adopt in their pro-
Engineering, Vol. 19, No. 2, June 1, 2013. ©ASCE, ISSN 1076-0431/ fessional practice of developing architectural programs for
2013/2-101–111/$25.00. project owners; and

JOURNAL OF ARCHITECTURAL ENGINEERING © ASCE / JUNE 2013 / 101

J. Archit. Eng. 2013.19:101-111.

 • Discussing the various benefits of the developed framework and in the project (Yu et al. 2005, 2010; Shen and Chung 2006; Zwemmer
reflecting briefly on the applicability of information technology and Otter 2008). As the building industry is fragmented with separate
(IT) support in the architectural programming processes. entities involved in every phase of the building industry, including
clients, users, design professionals, and project and facility managers,
ordinary communication among this large cast of characters is usually
Architectural Programming: Value Added Process difficult.
to Building Quality

The quality of a building can be expressed in terms of the level at Current Practices of Architectural Programming
which the final design of a building meets its clients’ actual needs
and requirements. Design teams aim primarily at developing entirely Interviews were carried out with a selected sample of 10 architects/
functional buildings that meets the expectations of the clients (Clift architectural engineers at architectural/engineering (A/E) design
Downloaded from ascelibrary.org by KFUPM KING FAHAD UNI OF on 05/09/13. Copyright ASCE. For personal use only; all rights reserved.

1996; Oliveira et al. 2008). To achieve this goal, it is essential for firms in addition to two representatives of project owners. The
design teams and client’s stakeholders to collaboratively interact interviews were conducted for the purpose of understanding the
together to define the scope of the project to be designed and develop current practices of identifying and communicating client and user
the architectural program for the building project accordingly. In requirements to design teams, as well as the challenges and the
fact, this is in agreement with the principles of quality function limitations of these practices. The 10 architects/architectural en-
deployment that focus on assuring the design quality while the gineers were selected based on their professional experience as
building project is in the design phase. Akao (2004) described programmers and designers. Their experience stemmed from working
qualify function deployment as a “method for developing a design on several project types, including residential, educational, office,
quality aimed at satisfying the customer and then translating the recreational, sports, and commercial buildings. The two owner re-
consumers’ demands into design targets and major quality assurance presentatives were the project managers of two large organizations.
points to be used throughout the production stage.” Zwemmer and These two organizations own a diverse set of infrastructural facil-
Otter (2008) defined architectural programming as “the process of ities, including educational, administrative, and housing facilities.
capturing the purpose, intended use, requirements, objectives, and
desired qualities of a construction project, resulting in an output Classifications of Architectural Programmers
document: the client’s program. Furthermore, the program provides
the design team with data to commence their design, without the The interviews revealed that the service of architectural program-
preservation of their artistic expression.” ming is practiced differently depending on the classification of the
Architectural programming is perceived “as an information programmer, namely external consultants and in-house staff, as
processing system setting out design directions that will accom- follows:
modate the needs of the user, the client, the designer, or the de- • External consultants: They are hired by clients from the private
veloper” (Sanoff 1992; Van der Voordt and Van Wegen 2005). The sector. Mostly, the external consultant, being an architect/
output of the architectural programming process is a program of architectural engineer, would be responsible for identifying
requirements. This program of requirements “serves to incorporate the project’s requirements and developing the design solutions
into the design process communication between the client and the for the project. The client verbally communicates his goals,
future users of the building on the one hand and architect and needs, and requirements to the external consultant. The consul-
consultants on the other, in line with basic assumptions and taking tant would then directly prepare a functional program, followed
account of the conditions to be satisfied, the needs, requirements, by a series of conceptual and schematic designs for the project.
wishes and expectations of the client and future users, by means of • In-house staff: Commonly referred to as the project management
a coherent set of activities, designed to achieve the complete and team. These employees are usually part of the client’s organi-
unambiguous collection, processing, evaluation, and transmission of zation, which could be a public sector client or a corporate client.
information, in phases from global to detailed” [Building Research The project management teams in such organizations would be
Foundation (BRF) 1996; Van der Voordt and Van Wegen 2005]. responsible for the preparation of the organization’s project
Previous studies on architectural programming (Othman et al. requirements. The project manager or the programmer collects
2004; Yu et al. 2007; Zwemmer and Otter 2008; Bogers et al. 2008) the functional requirements and needs of the end users for the
indicated that, in essence, there are two different approaches to purpose of developing a functional project program. The pre-
architectural programming in the building industry. The first ap- pared program would then be discussed with the end users.
proach views the program to be the outcome of a separate entity and/ However, if the end users are unknown, the project manager
or activity that should be held static after a specific time frame. The or the programmer would simply develop the project require-
second approach views the architectural program to be the outcome ments by modifying the existing requirements of previous sim-
of a developing and iterative process that accommodates feedback ilar projects and submit it for approval. The prepared program, in
from collaborative project participants over a series of stages. a written form, would only contain the functional requirements
Gibson (2004) identified 13 areas of information for inclusion for the project (spaces, areas, number of end users), as well as the
in the development of the architectural program. These areas of scope of work. The design team would then be expected to
information include program statement; building summary space list; develop the remaining components of the project program such
overall adjacency diagrams; stacking diagrams; growth and phased as space relationships, priorities, and site requirements.
development; circulation and open space requirements; functional
relationship diagrams for all rooms; loading, unloading, storage
Attention to Client and Project Requirements
facilities requirements; transportation requirements; building fin-
ishes; room data sheets; furnishings, equipment and built-ins; and The interviews indicated that there exist variations in the level of
window treatment. attention exerted to identify client and project requirements ac-
Challenges pertaining to the architectural programming process are cording to the client type, namely private sector clients and public
mainly attributed to communication problems among the participants sector and corporate clients, as follows:

102 / JOURNAL OF ARCHITECTURAL ENGINEERING © ASCE / JUNE 2013

J. Archit. Eng. 2013.19:101-111.

 • Private-sector clients: Mostly developers who will sell or offer architectural programs are usually prepared by a group comprising
their buildings for rent to the public. They tend to be more of few participants from the client organization or by an architect/
focused on the economical side and the completion date of their architectural engineer in the industry. Moreover, it was also in-
investments. Hence, they do not focus much on the identification dicated that some clients do not know exactly who the end users
of project requirements. Consequently, project requirements are are, and as such, the end users were not involved in the process.
not defined well in private sector projects. Interviewed architects/ • Changing requirements at a later stage of the design process:
architectural engineers indicated several challenges that impact Interviews indicated that in most cases, private sector clients
the development of the project requirements, including client’s may not know what exactly their wants are or their project
lack of experience; absences of commitment from some clients requirements. In addition, they may frequently change their require-
toward the development of project requirements; lack of aware- ments. On the other hand, most of the changes in the projects owned
ness among most of the clients about the significance of archi- by the public sector and corporate clients are attributed to the set
tectural programming; unknown end users; unclear goals and policies of the organization and the available budget.
Downloaded from ascelibrary.org by KFUPM KING FAHAD UNI OF on 05/09/13. Copyright ASCE. For personal use only; all rights reserved.

requirements set by the clients; changing requirements at later • Lack of time allocated for the programming phase: Interviews
stages during the design process; setting a vague budget for the revealed that many clients request reductions in the amount of
projects; and lack of a devoted fees for the process of identifying time allocated for identifying the requirements of the project.
the requirements of the project. These requests are demanded for the purpose of initiating earlier
• Public-sector and corporate clients: Statements of needs for this starts for the design and construction phases. This results in the
category of clients are prepared through research on the end poor identification of project requirements at the early stages of
user’s requirements. Additionally, in-house staff would conduct the building process.
studies pertaining to the collection of project requirements. Thus,
client requirements in this category are generally well defined.
Interviewed owner’s representatives indicated several challenges Generic Architectural Programming Framework Model
that impact the development of the project requirements, in-
cluding the end users sometimes do not know their requirements; Investigation of the current practices of architectural programming
the end users sometimes are unknown; imposed constraints on revealed that these practices are not really effective in providing
the architectural program because of the organization’s policies a clear definition and understanding of the requirements of clients
and budget; and rapid changes in the organizational requirements and projects. There is a need to develop a standard methodology that
because of changes of work methods, technology developments, architectural programmers can adopt in their professional practice of
and organizational structure. developing architectural programs for project owners. The proposed
framework model is developed based on knowledge obtained from
the international literature and observation of professional practices
Challenges to the Current Practice in Saudi Arabia. It consists of six sequential processes. For each of
The findings revealed that the current practices of architectural the processes, a number of supporting activities have been defined
programming in Saudi Arabia are not effective in providing a clear with their logical sequence and information requirements. The six
understanding of the client’s and project’s requirements. Several processes forming the framework model are as follows: (1) identify
challenges were identified as follows: project information; (2) research the project type; (3) identify
• Lack of a clear methodology or guidance on architectural pro- requirements of end users; (4) analyze and balance the identified
gramming: Interview findings indicated that programs are pre- requirements; (5) document the project’s program; and (6) review
pared formally, or informally, depending on the client type, as well and update the developed program.
as the nature of the project. Architects/architectural engineers and The developed generic framework model herein is described
owners usually consider architectural programming as an event schematically in the form of an integration definition for function
and not as a process. The focus is usually on the development of modeling (IDEF0) process model diagram, as shown in Fig. 1. A
conceptual and schematic designs only, rather than the develop- process model serves to represent or model a process that occurs in the
ment of the project requirements that are developed concurrently real world [International Alliance for Interoperability (IAI) 1999].
during these design stages. Consequently, several problems may IDEF0 is one of several modeling languages in the field of systems
arise such as changing requirements at later stages during the and software engineering. It is a modeling language, derived from the
design phase and even during the construction phase. well-established structural analysis and design technique (SADT)
• Lack of client’s experience with the building process: Interviews graphical language, which was mainly developed to address infor-
confirmed that one of the major challenges to the building mation models and database issues [National Institute of Standards
industry is lack of experience among private sector clients with and Technology (NIST) 1993]. The developed process model de-
the building process. In such cases, the architects/architectural scribes the activities that take place within every business process and
engineers should be responsible for informing the client about defines the decisions, actions, and tasks that the architectural pro-
the value and the expected benefits of the architectural program- grammer needs to undertake within each process. It displays the
ming phase during the project life cycle. Contrasting with the interactions between activities in terms of inputs and outputs while
private sector clients, specialized project management teams work- showing the controls placed on each activity and the types of resources
ing for public sector and corporate clients are comprised of design assigned to each activity. In IDEF0 notation, boxes represent tasks,
professionals who are familiar with the building process. There- whereas arrows from the left, right, top, and bottom represent inputs,
fore, this problem of lack of client’s experience with the building outputs, controls, and mechanisms, respectively.
process is not a serious concern for public and corporate clients.
• Lack of participants’ involvement in the architectural programming
Identify Project Information
process: Interviews highlighted that the involvement of participants
who are able to identify the strengths and constraints of the projects Process Definition
from their different perspectives is essential for identifying the This process (Node P1 in Fig. 1) involves the identification and
client and project requirements. However, it was indicated that the collection of general information about the project, the project’s

JOURNAL OF ARCHITECTURAL ENGINEERING © ASCE / JUNE 2013 / 103

J. Archit. Eng. 2013.19:101-111.

Downloaded from ascelibrary.org by KFUPM KING FAHAD UNI OF on 05/09/13. Copyright ASCE. For personal use only; all rights reserved.

Fig. 1. General processes involved in architectural programming framework model

owner, the project’s end users, and the project’s goals and objectives. 2010). Project goals and objectives range from economical, aesthetic,
This process depends on the involvement of the project owner and functional, and technical to time to anticipated future expansions
is facilitated by the extent of the owner’s experience with the building (Cherry and Petronis 2009). These goals and objectives serve as
process, as well as the architectural programmer’s ability to com- a consistent set of guidelines for decision making on many of the
prehend the project requirements. This process can be conducted project matters. The project programmer should encourage the owner
through a series of face-to-face meetings between the architectural to determine as much information as possible on all the related goals
programmer and the owner. A site visit can also be useful to acquaint and objectives for the project.
the architectural programmer with the available site that will be used Assemble Preliminary Information (P1.2). This function serves
for developing the project. The main input necessary to carry out this to identify the project type, capacity, site information, end users, and
management process is the need for the facility as a project. This information related to time and budget constraints. In their in-
need should have emerged as an objective to implement the facility vestigation of the briefing process, Shen and Chung (2006) state that
plan. An output of this process is a statement of the goals and the architectural program could vary significantly in length, content,
objectives of the project. Outputs also include statements on the and style depending on the type, scale, and configuration of the project
project type, project capacity, site area, geometry, orientation, and (Konya 1986). Further, information for the allocated budget for de-
architectural style. In addition, outputs also include statements for veloping the project is an essential concern for the architectural
the period of time allocated for developing the architectural pro- programmer (Bogers et al. 2008).
gram, the allocated budget for developing the project, the partic- Identify Participants (P1.3). This function serves to identify the
ipants in the programming process, and the programming contract. individuals who will participate in the architectural programming
This process is divided into four functions as described subsequently process and their roles. The owner of the project should identify the
and illustrated in Fig. 2. personnel who represent him to participate in the programming
process. Brauer (1992) points out that because of the diversity of the
Process Activities types of building users, confusion about who to seek requirements
Identify Goals and Objectives (P1.1). The earliest step in all from or who has the authority to approve requirements may occur.
projects involves the clear and adequate identification and declara- Yu et al. (2007) state that it is very important to involve a sufficient
tion of the project’s goals and objectives by the owner. This step representation of all the parties that represent the client organization
defines the outcomes of the project and the necessary steps to to address their needs and requirements. Ormerod and Newton (2005)
achieve these outcomes (Palmer 1981; Pena and Parshall 2001; Goetz stress the importance of involving a diverse range of participants

104 / JOURNAL OF ARCHITECTURAL ENGINEERING © ASCE / JUNE 2013

J. Archit. Eng. 2013.19:101-111.

Downloaded from ascelibrary.org by KFUPM KING FAHAD UNI OF on 05/09/13. Copyright ASCE. For personal use only; all rights reserved.

Fig. 2. Node P1, identify project information

in developing the architectural program, either as owner repre- the extent to which a facility, once occupied for a period of time, meets
sentatives or for providing specialist input. Zwemmer and Otter the intended organizational goals and user-occupant needs.” The
(2008) indicate that by being aware of the strategic benefits of information generated from the evaluation of past projects provides
the architectural program, project participants are expected to valuable feedback to facility planners, design professionals, facility
devote commitments for this significant phase of the building managers involved in the planning, and design and operation of
process. projects (Preiser et al. 1988). Hadjri and Crozier (2009) assert that
Develop the Programming Contract (P1.4). This function is results obtained from postoccupancy evaluations could be used to
very important for the efficient management of the programming either improve space use in existing buildings or for programming
process, because it ensures the commitment of all participants in future buildings.
the programming process. As the architectural process takes place Identify Typical Functional Requirements (P2.2). This func-
prior to the design phase of any project, the terms for this service can tion serves to identify the required typical space types, areas, and
be defined and agreed on within either a separate contract or within relationships, as well as the typical site requirements for the specific
the contract that administers the terms of the design process between project under consideration. A vital source of information for this
the client and the design firm. programming step is relevant codes and standards that apply to the
specific project type under consideration.
Identify Technical Requirements (P2.3). This function serves
Research the Project Type to identify the structural, mechanical, electrical, and security require-
Process Definition ments relevant to the type of the project under consideration. Brauer
This process (Node P2 in Fig. 1), involves gaining familiarity with (1992) states that technical and functional requirements provide the
the specific project type under consideration and its sets of func- information necessary to develop an appropriate design solution.
tional and technical requirements. It entails exploring and identi- Technical requirements deal with structural, mechanical, environ-
fying the applicable codes and municipal standards for the specific mental, safety, and fire protection and other matters that require
project type for which an architectural program will be developed. specialist knowledge and training. These requirements can be acquired
Cherry and Petronis (2009) state that this step is necessary if the from technical literature, state laws, codes, and standards.
programmer is working on a project type for the first time. The inputs
necessary to carry out this process are statements pertaining to the Identify Requirements of End Users
project type, capacity, and site information. The outputs generated
Process Definition
from this process are the typical technical and functional project
requirements. This process is divided into three functions as de- This process (Node P3 in Fig. 1) involves exploring detailed in-
scribed subsequently and illustrated in Fig. 3. formation pertaining to the requirements and needs of the project’s
end users. This can be best achieved through two data collection
methods. The first is face-to-face meetings between the architectural
Process Activities programmer and the owner. The second is through conducting
Investigate Similar Type of Projects (P2.1). This function serves a survey aimed at the end users for the purpose of collecting data
to identify the advantages and disadvantages and also the problems related to their requirements and needs. Cherry (1999) indicates that
and solutions of similar type of projects, as well as identifying the development of a user profile for each type of user is a practical
the users’ requirements and needs. The results obtained from post- approach to organize the information related to the end users of the
occupancy evaluations provide architectural programmers and design building project. To a large extent, the effectiveness of this process
professionals with insights into the outcomes of past design decisions depends on the involvement of the end users, the owner’s level of
and the resulting facility performance. Preiser et al. (1988) defines experience with the building process, the ability of the architec-
postoccupancy evaluation as “the process of systematically evaluating tural programmer to comprehend the requirements of the project,

JOURNAL OF ARCHITECTURAL ENGINEERING © ASCE / JUNE 2013 / 105

J. Archit. Eng. 2013.19:101-111.

Downloaded from ascelibrary.org by KFUPM KING FAHAD UNI OF on 05/09/13. Copyright ASCE. For personal use only; all rights reserved.

Fig. 3. Node P2, research the project type

Fig. 4. Node P3, identify requirements of end users

the commitment of all participants to contribute to the programming and attitudes. Moreover, these end users might be part of the client
process, and the inclusion of all influential project parties. The inputs organization, external tenants, or combination of both types, or they
necessary to carry out this process are statements of the goals and might be individuals or groups on whom the organization relies, such
objectives of the project, project type, capacity, site information, as its customers and visitors.
and typical technical and functional requirements of the project. Identify End Users’ Activities (P3.2). This function serves to
The outputs from this process are statements on the end users’ identify the activities that are housed in the building project. As
requirements, needs, and priorities for the facility. This process is occupant comfort with a building is directly related to the suitability
divided into five functions as described subsequently and illustrated of that building to accommodate the activities conducted within
in Fig. 4. (Turpin-Brooks and Viccars 2006), the architectural programmer
should be aware of the type of activities that will take place in the
building. Brauer (1992) indicates that the end users’ facility require-
Process Activities ments are derived from an analysis of the operations and activities that
Identify End Users’ Types and Numbers (P3.1). This function take place in the facility.
serves to identify the number and types of building user groups. Blyth Identify End Users’ Functional Requirements (P3.3). This
and Worthington (2010) clarify that the end users may constitute function serves to identify the types and amounts of space that will
a diverse collection of individuals or groups with different interests enable the end users of the building to carry out their activities.

106 / JOURNAL OF ARCHITECTURAL ENGINEERING © ASCE / JUNE 2013

J. Archit. Eng. 2013.19:101-111.

 Brauer (1992) indicates that functional requirements entail the types (Yu et al. 2005). The architectural programmer has to be aware of
and amount of space and various characteristics of space that must be the fact that it is challenging for one individual to identify all the
prepared to support people, activities, and equipment. Bogers et al. requirements needed in the building project. Therefore, the pro-
(2008) assert that the architectural program should contain as much grammer needs to verify all the incoming requirements from the
information as possible about the requirements of the different types several participants in the programming process to eliminate in-
of users. correct requirements, as well as add any requirement that was
Identify End Users’ Needs (P3.4). This function serves to overlooked (Brauer 1992). Data that constrain this process include
identify the needs and expectations of the end users from the building. the project’s goals and objectives, set budget, ability of the archi-
Cherry (1999) explains that identifying attitudes and psychological tectural programmer to comprehend the requirements of the project,
needs is usually much more difficult than identifying functional and building codes and municipal standards. Activities throughout
requirements. This is mainly because of the fact that these needs are this process are performed by the programmer and the owner and
personal. Depending on the nature of the project, this type of in- facilitated by a series of face-to-face meetings between the two
Downloaded from ascelibrary.org by KFUPM KING FAHAD UNI OF on 05/09/13. Copyright ASCE. For personal use only; all rights reserved.

formation can be gathered formally or informally by conducting parties. The inputs necessary to carry out this process are statements
interviews or administering a questionnaire survey to the end users. on the typical technical and functional requirements for the project,
Establish Priority Levels (P3.5). Establishing priority levels is as well as statements on the end users’ requirements, needs, and
very important to balance the identified requirements during a priority levels. The outputs generated from this process are state-
decision-making process. This function serves to identify prefer- ments on the confirmed spaces types, areas, relationships, and re-
ences and priorities among the identified requirements. Establishing fined and confirmed statements on the technical systems, including
a priority level for each requirement in the project is an integral part the structural, mechanical, electrical, and security systems. This
of the data needed to develop and implement the project’s archi- process is divided into three functions as described subsequently and
tectural program (Kumlin 1995). Cherry (1999) indicates that de- illustrated in Fig. 5.
pending on the nature of the project, this type of information can be
gathered formally or informally, through conducting interviews with Process Activities
the end users, or administering a questionnaire survey for the purpose Analyze and Verify the Identified Requirements (P4.1). This
of collecting data related to their requirements and needs. function serves to perform an analysis of the identified different
requirements and needs of the project owner and the end users.
Additionally, the architectural programmer will need to verify these
Analyze and Balance the Identified Requirements
requirements. Several statistical techniques have been developed for
Process Definition the purpose of verifying the identified requirements. One of these
This process (Node P4 in Fig. 1) involves verifying, analyzing, and techniques is the strategic needs analysis as described by Smith et al.
balancing the identified project and users’ requirements and needs. (2005). It involves collecting information from the stakeholders to
While developing the architectural program, it is necessary to comprehend the nature of the demanded requirements. Once the
consider and maintain a proper balance of the interests of all parties requirements for the project are discussed, options would then be

Fig. 5. Node P4, analyze and balance the identified requirements

JOURNAL OF ARCHITECTURAL ENGINEERING © ASCE / JUNE 2013 / 107

J. Archit. Eng. 2013.19:101-111.

 developed to satisfy the demanded requirements. A preferred option The final documentation can be accomplished through the use of
would be selected and recommended for implementation (Smith different methods (figures, pictures, and text). The input necessary to
et al. 2005). Yu et al. (2005) describe another technique based on the carry out this process is the confirmed final project requirements. The
application of value management in project briefing. This technique output generated from this process is the project’s architectural
examines the impact of 13 variables for their impact on the archi- program document. This process is divided into three functions as
tectural programming process. described subsequently and illustrated in Fig. 6.
Balance the Identified Requirements (P4.2). This function
serves to balance the identified requirements of all parties. The Process Activities
number of requirements in any project depends on the building size Develop the Scope of Work (P5.1). This function serves to
and the complexity of the building function (Van der Voordt and determine the intended scope of work for the project by the design
Van Wegen 2005). For example, large-scale projects that have team. The scope of work describes the work that needs to be per-
a complex function, such as hospitals and air port terminals, would formed by the design team. It should be documented in the project
Downloaded from ascelibrary.org by KFUPM KING FAHAD UNI OF on 05/09/13. Copyright ASCE. For personal use only; all rights reserved.

require the identification of an extensive set of project requirements. program.

Van der Voordt and Van Wegen (2005) indicate that the in- Document Confirmed Requirements (P5.2). This function
corporation of all the identified requirements would be extremely serves to document the confirmed project and users’ requirements,
challenging because of time and budgetary constraints. Further- as well as the developed scope of work. Hershberger (1999) outlines
more, it may not be practicable for the project architect to make 11 fields of information that should be documented in an architectural
a decision on which are genuine project requirements and which are program, as a minimum. These fields include goals and objectives, site
not (Brauer 1992). Therefore, requirements have to be balanced information, building occupants’ characteristics, requirements of site
during a decision-making process, based on an identified set of restrictions and limitations, building functional requirements, tech-
priorities as stated in the section Establish Priority Levels. nical requirements, functional relationship, budget of the project,
Confirm Final Project and User Requirements (P4.3). Based project future growth anticipation (flexibility), and priorities among
on the previous two activities, this function serves to develop the requirements.
a confirmed statement with the project owner on the final set of Approve the Developed Program (P5.3). This function serves
functional and technical requirements of the project. to approve the developed program document. Yu et al. (2007) in-
dicate that the architectural program should be compiled, completed,
Document the Project’s Program and agreed on before starting the design phase for the project. In
essence, it is the writers’ view that the architectural program should
Process Definition act as a reference document, which is made available to all project
The Document the Project Program process (Node P5 in Fig. 1) parties before the design phase. Cherry and Petronis (2009) state that
involves identifying the intended scope of work for the project. The sometimes the programmer stays involved throughout the remainder
process also involves documenting the final architectural program of project phases.
to be handed over to the design team, once approved by the owner.
Kumlin (1995) indicates that the final documentation of the program
Review and Update the Developed Program
can be organized in a variety of methods, depending on the end users
requirements and needs. The adequacy of the documentation Process Definition
methods used to compile the architectural program is an influential The Review and Update the Developed Program process (Node P6
factor toward the development of a satisfactorily design solution. in Fig. 1) involves reviewing and refining the project program during

Fig. 6. Node P5, document the project’s program

108 / JOURNAL OF ARCHITECTURAL ENGINEERING © ASCE / JUNE 2013

J. Archit. Eng. 2013.19:101-111.

 the early design phase. The design phase aims primarily at producing have been missed or overlooked. Brauer (1992) reveals that if
a functional building that meets a set of actual needs and require- requirements are identified accurately, comprehensively, and are well
ments of the client. At this process, the architect prepares schematic documented, the amount of time necessary to complete the de-
designs, including sets of drawings and other documents for ap- velopment of the design solution can be reduced. The designer will
proval by the owner. The architect also submits to the owner also spend less amount of time to gather missing information or to
a statement of the probable construction cost. Practically, the de- verify data and can move quickly and confidently toward developing
veloped program continues to develop even further during the design the best design solutions.
phase as many questions and ideas arise (Van der Voordt and Van Refine and Update the Developed Program (P6.3). At this
Wegen 2005). If the requirements are well documented, the designer step, the program should be frozen to commence the detailed design
can reduce time needed to interact with users, and as such, will need phase. Interviews with architects in Saudi Arabia revealed that
to make fewer assumptions. This process depends on the methods project owners, especially those in the residential sector, may not be
that are used to document the requirements and the ability of the able to identify their requirements without reviewing preliminary
Downloaded from ascelibrary.org by KFUPM KING FAHAD UNI OF on 05/09/13. Copyright ASCE. For personal use only; all rights reserved.

architect to comprehend the developed program, as well as the set design documents. Brauer (1992) points out that any unnecessary
deadline to freeze the project program. This process can be facili- change is money wasted. Most changes can be avoided by carefully
tated through a series of face-to-face meetings between the owner compiling the project and end users requirements. However, care-
and the programmer with the design team. The inputs necessary to fully defined user requirements will result in minimizing the chances
carry out this process are the developed project program. The outputs of wasting money on unneeded space. Othman et al. (2004) indicate
generated from this process are the project schematic design, the that changes made to the architectural program at later stages of the
final project program, and the probable construction cost. This project could affect the cost, time, and quality of the project.
process is divided into three functions as described subsequently and
illustrated in Fig. 7.
Discussion

Process Activities Programming practices are still being perceived to be inefficient

Develop Schematic Design Solutions (P6.1). This function as indicated by many researchers around the globe. This is mainly
serves to interpret and translate the documented information in the attributed to the massive amount of information that need to be
project program into facility project plans. At this step, the designer considered and the difficulties exhibited in identifying and communi-
should develop all possible design solutions. The type and the cating clients’ actual needs and requirements properly to design teams
amount of information depicted in the building design affects the (Shen and Chung 2006; Bogers et al. 2008; Kelly et al. 2003; Yu et al.
building’s final quality (Clift 1996; Oliveira et al. 2008). Shen and 2005).
Chung (2006) indicate that during the design phase, architects Interviewees stated that programs are prepared formally or in-
develop a number of conceptual designs based on their interpretation formally depending on the client type, as well as the nature of the
of the complied project program. project. Further, the findings also revealed that the current practices
Compare the Developed Design with the Developed Program of architectural programming are not really effective in providing
(P6.2). At this step, the developed design solutions should be a clear definition and understanding of the clients and projects
comprehensively examined to ensure that no potential alternatives requirements. One of the main challenges to the current practices of

Fig. 7. Node P6, review and update the developed program

JOURNAL OF ARCHITECTURAL ENGINEERING © ASCE / JUNE 2013 / 109

J. Archit. Eng. 2013.19:101-111.

 architectural programming was identified as lack of a clear meth- writers envisage that the process of developing an architectural
odology or guidance on architectural programming. Other signifi- program for an adapted building to fit a different use could pose quite
cant challenges were identified as lack of client’s experience with difficult challenges for architectural programmers and design pro-
the building process, inadequate involvement of all relevant parties fessionals. Adaptive reuse may require adhering to new regulatory
in the architectural programming process, changing requirements at conditions, and as such, may require zoning permission. Moreover,
a later stage of the design process, and insufficient time allocated for in working with an adapted building, architectural programmers and
the programming process. design professionals would be constrained by the existing building
The developed framework model is described schematically as systems. Design and construction interventions would be minimized
an IDEF0 process model for illustrating the functions involved in the to reduce the cost of, and time for, construction development.
architectural programming process. IDEF0 process models serve to
illustrate the interactions between activities in term of inputs and Acknowledgments
outputs while showing the controls placed on each activity and the
Downloaded from ascelibrary.org by KFUPM KING FAHAD UNI OF on 05/09/13. Copyright ASCE. For personal use only; all rights reserved.

type of resources assigned to complete each activity. Usefulness of The writers thank King Fahd University of Petroleum and Minerals
the developed framework stems from the following: for the support and facilities that made this research possible. The
• Providing project programmers with descriptions of the stan- writers also acknowledge the cooperation of the interviewees who
dardized functions that need to be performed, the required kind of described the approaches they follow for identifying the require-
data to perform these functions, and the constraints that control ments of building projects and the methods adopted to communicate
these functions; these requirements to design teams.
• Including the programmer as a role player during the design
phase to ensure that the defined requirements in the program are
actually accommodated in the developed design solution; References
• Identifying the project participants at the early stage of the
program development process, before the development of con- Akao, Y. (2004). Quality function deployment: Integrating customer
tract to secure the commitment of all project participants; and requirements into product design, Productivity Press, New York.
• Describing the roles of all project participants in the program- Blyth, A., and Worthington, J. (2010). Managing the brief for better design,
ming process, in addition to promoting frequent face-to-face 2nd Ed., Routledge, London.
communication among all participants throughout the process. Bogers, T., Van Meel, J. J., and Van der Voordt, T. J. M. (2008). “Architects
The framework model could act as a guide for conducting ar- about briefing: Recommendations to improve communication between
clients and architects.” Facilities, 26(3/4), 109–116.
chitectural programming activities and provides a way of bridging
Brauer, R. L. (1992). Facilities planning: The user requirements method,
the gaps in architectural programming practice. An added value of 2nd Ed., American Management Association, New York.
this framework model is that each activity is seen in its proper Building Research Foundation (BRF). (1996). Programme of requirements:
context relative to the other activities, and the project programmer An instrument for quality control, Building Research Foundation,
can identify the impact of any change on the whole process. Rotterdam, Netherlands.
The research aims at supporting the development of IT solutions Cherry, E. (1999). Programming for design: From theory to practice, Wiley,
that could be used for capturing the process of properly identifying New York.
and communicating client and user requirements to design teams. Cherry, E., and Petronis, J. (2009). Architectural programming. Whole
The writers envisage the development of interoperable software that building design guide, National Institute of Building Science, Wash-
integrates data and knowledge to be developed for architectural ington, DC.
Clift, M. (1996). “Building quality assessment (BQA) for offices.” Struct.
programming applications.
Surv., 14(2), 22–25.
Duerk, D. P. (1993). Architectural programming: Information management
for design, Wiley, New York.
Conclusions Erdener, E. (2003). “Linking programming and design with facilities
management.” J. Perform. Constr. Facil., 17(1), 4–8.
This paper presented a framework model that aims at capturing the Gibson, G. E. (2004). Project definition rating index (PDRI). Construction
process of identifying and communicating client and user require- Industry Institute (CII), Cockrell School of Engineering, Univ. of Texas,
ments to design teams. The framework was developed based on Austin, TX.
knowledge from the international literature and observed pro- Goetz, R. (2010). “Defining project goals and objectives.” Project Smart,
fessional practice in Saudi Arabia. The developed framework is U.K., Æhttp://www.projectsmart.co.uk/æ (Apr. 5, 2012).
Hadjri, K., and Crozier, C. (2009). “Post-occupancy evaluation: Purpose,
generic, meaning that the activities involved can be adapted and
benefits and barriers.” Facilities, 27(1/2), 21–33.
applied for any project type and by two types of project pro- Hershberger, R. G. (1999). Architectural programming and predesign
grammers, namely external consultants and in-house staff. manager, McGraw Hill, New York.
Commitments among all participants in the project to facilitate Hudson, J. (1999). “Briefing and design: The role of creativity.” Proc., RICS
a collaborative interaction ensure the development of an efficient Foundation Construction and Building Research Conf., Univ. of
architectural program. The writers envisage that the main challenge Salford, London, 284–289.
that will obstruct the implementation of the developed framework is International Alliance for Interoperability (IAI). (1999). Specification de-
the level of commitment from the client and the participants, espe- velopment guide, Industry Foundation Classes–Release 2.0, Interna-
cially in the private sector. To overcome this problem, the pro- tional Alliance for Interoperability, Washington, DC.
grammer would be responsible for informing the client and the Kelly, J., Shen, Q. P., Hunter, K., and Yu, A. (2003). “The development of
a theoretical framework for briefing using a value management ap-
participants about the value and the expected benefits of the archi-
proach.” Proc., RICS Foundation Construction and Building Research
tectural programming phase during the project life cycle. Conf., Univ. of Wolverhampton, London, 328–337.
The intent of the developed framework presented in this paper is Konya, A. (1986). Sports buildings: A briefing and design guide, Archi-
to illustrate the process of architectural programming for new tectural Press, London.
building projects. However, nowadays, many clients are endeav- Kumlin, R. (1995). Architectural programming: Creative techniques for
oring on the process of adaptive reuse for economical reasons. The design professionals, McGraw Hill, New York.

110 / JOURNAL OF ARCHITECTURAL ENGINEERING © ASCE / JUNE 2013

J. Archit. Eng. 2013.19:101-111.

 National Institute of Standards and Technology (NIST). (1993). “Integration Smith, J. (2002). “Strategic client briefing: Stakeholder experience.” Proc.,
definition for function modeling (IDEF0).” Federal Information Process- RICS Foundation Construction and Building Research Conf., Not-
ing Standards 183, Computer Systems Laboratory, Gaithersburg, MD. tingham Trent Univ., London, 2–17.
Oliveira, L. A. D., Maizia, M., and Melhado, S. B. (2008). “Influence of the Smith, J., Love, P. E. D., and Heywood, C. (2005). “A method for per-
performance and buildability requirements on the building quality: formance briefing at the project inception stage.” Facilities, 23(7/8),
Comparison between the Brazilian and the French renovation design 319–329.
process.” Proc., Joint CIB W096 Architectural Management and CIB Turpin-Brooks, S., and Viccars, G. (2006). “The development of ro-
TG49 Architectural Engineering Conf., CIB, Rotterdam, Netherlands. bust methods of post occupancy evaluation.” Facilities, 24(5/6),
Ormerod, M. G., and Newton, R. A. (2005). “Briefing for accessibility in 177–196.
design.” Facilities, 23(7/8), 285–294. Van der Voordt, D. J. M., and Van Wegen, H. B. R. (2005). Architecture
Othman, A. A. E., Hassan, T. M., and Pasquire, C. L. (2004). “Drivers for in use: An introduction to the programming, design and evaluation
dynamic brief development in construction.” Eng. Construct. Architect. of buildings, Architectural Press, Oxford, U.K.
Manag., 11(4), 248–258. Yu, A. T. W., Chan, E. H. W., Chan, D. W. M., Lam, P. T. I., and Tang,
P. W. L. (2010). “Management of client requirements for design and
Downloaded from ascelibrary.org by KFUPM KING FAHAD UNI OF on 05/09/13. Copyright ASCE. For personal use only; all rights reserved.

Palmer, M. A. (1981). The architect’s guide to facility programming,

American Institute of Architects, Washington, DC. build projects in the construction industry of Hong Kong.” Facilities,
Pena, W., and Parshall, S. (2001). Problem seeking: An architectural 28(13/14), 657–672.
programming primer, 4th Ed., Wiley, New York. Yu, A. T. W., Shen, Q., Kelly, J., and Hunter, K. (2005). “Application
Preiser, W., Rabinowitz, H., and White, E. (1988). Post-occupancy eval- of value management in project briefing.” Facilities, 23(7/8), 330–342.
uation, Van Nostrand Reinhold, New York. Yu, A. T. W., Shen, Q., Kelly, J., and Hunter, K. (2007). “An empirical study
Sanoff, H. (1992). Integrating programming, evaluation and participation of the variables affecting construction project briefing/architectural
in design, Ashgate Publishing Company, Brookfield, VT. programming.” Int. J. Proj. Manag., 25(2), 198–212.
Shen, G. Q. P., and Chung, J. K. H. (2006). “A critical investigation of Zwemmer, M., and Otter, A. D. (2008). “Engaging users in briefing and
the briefing process in Hong Kong’s construction industry.” Facilities, design: A strategic framework.” Proc. CIB Joint Conf.: Performance
24(13/14), 510–522. and Knowledge Management, CIB, Rotterdam, Netherlands, 405–416.

JOURNAL OF ARCHITECTURAL ENGINEERING © ASCE / JUNE 2013 / 111

View publication stats J. Archit. Eng. 2013.19:101-111.