A Proposal for a Process Model for Data Collection in Facilities Programming ()
1. Introduction
Facilities (also called architectural) programming is an important part of the facility (or building) development process. It precedes the architectural design phase, providing information about building users. In effect, this is a social science research endeavor. The process model we present here is a guide or a road map for collecting user information for developing design requirements. Facilities programming involves collecting, organizing, analyzing, and evaluating information (Duerk, 1993; Sanoff, 1977, 2016a; Pena & Parshall, 2012; White, 1972, 1991) about building users, their culture, activities, needs, and requirements regarding the spaces they will inhabit, live, work, and so forth (Cherry, 1999; Duerk, 1993; Preiser, 1993; Sanoff, 1977, 2016b). This information is later “translated” into descriptions of spaces and their features. This is the facility or architectural program, which specifies the characteristics of the building. In its final form, the program delivers design requirements as well as background information on how to interpret them to the project architects (Duerk, 1993; Hershberger, 1999, 2015).
Programming consists of two major phases, functional programming and space programming (Davis & Szigeti, 1978). In this paper, our talk will be mostly about the functional programming phase. For brevity, we will refer to it as facilities programming or simply programming. We focus on this stage because it is mostly about the study of building users, their culture, activities, and needs. Social scientists are uniquely educated and experienced to conduct such studies.
The most laborious part of facilities programming is collecting and analyzing information about building users, their culture, and activities (Duerk, 1993; Preiser, 1993; White, 1972, 1991). This work involves a lot of field research and information gathering. All building design situations, and in particular, large and complex buildings, despite foundational similarities, are different in various degrees, and require customized guidelines for information collection. During the programming process, the volume of collected information is tremendous and can be overwhelming. It may be way more than in typical social science projects because of the numerous user groups and aspects of the building use. This makes the programming information collection process a unique exploration with very high complexity (Preiser, 1978, 1985, 1986, 1993, 2015b). From a research perspective, this is applied social research that needs both a strong methodological foundation and a solid plan of action.
Historically, programming is done mostly by architects using precedents, personal experience with similar design projects, and tacit knowledge. Architects’ training typically doesn’t involve social science research coursework beyond several general education courses and an architectural course on programming. Because of this, we see a niche for applied sociologists where they can contribute their knowledge and skills. However, we would also like to increase the awareness and professional sophistication of architects by providing methodological ideas and research models for data collection.
The literature on programming is limited both in absolute terms and compared to the publication record of other fields, domains, and thematic areas. In a period of fifty years, there are barely more than a dozen core books and somewhat more on tangential issues and discussions. One very strong indicator for this is that the international publisher Routledge started reprinting many old works on programming in their Routledge Revivals series (Hershberger, 1999, 2015; Preiser, 1993, 2015a; Sanoff, 1977, 1992, 2016a, 2016b). There is a clear need for information, and the supply is evidently not adequate. Even journal publications form a very small pool of information compared to other fields and research domains.
Although there are dozens of papers related to facilities/architectural programming, they are spread over a wide area of different aspects, topics, and problems. Most of the papers and book chapters present programming cases and rarely deal with explicating the programming process (Preiser, 1978, 1985, 1986, 1993, 2015a). This creates a problem for sharing knowledge, developing new knowledge, explicating practice wisdom, and teaching new generations of programmers. There is hardly a critical mass of publications for creating strong methodological, theoretical, and research information bases. Again, most of the publications are case studies or research on particular problems. Programmers need to do their best to reconstruct information collection process models and learn from the experience of their colleagues. This situation indicates a niche for research and publication on programming process models, and in particular, plans for information collection.
In this paper, we interpret a process model as an organized sequence of specific activities which should be done in a particular order (O’Donovan et al., 2005; Wynn & Clarkson, 2005; Wynn & Clarkson, 2018). The process model guides professionals in what should be done and how it should be done. The model can be organized at macro level in activity units that most often are viewed as parts, stages, or phases, and at micro level, in a bigger detail, they can be tasks, steps, or procedures (Wynn & Clarkson, 2005: pp. 34-59). The terminology is very diverse because of variations across disciplines.
A process model can also be called procedural model, task model, step-by-step model, and so forth (Burton et al., 2006; Clarkson & Eckert, 2005). O’Donovan et al. (2005) write that all process models are abstractions, which means that they do not include all details of the real-world practice. This abstract nature of the process models helps to better understand the process and to adapt it to a specific practice situation. We focus on this idea and the very specific, esoteric, and idiosyncratic nature of the programming research process in order to construe our goal as creating a generic process model for collecting programming information.
Process models are very useful in the professions (Ullman, 2010). They guide the professionals in their work and substantially prevent wrong or ineffective actions, missed opportunities, and proceeding in the wrong direction (Becker et al., 2003). They guide professionals to the most important activities and in this way save time and effort. Process models are very important for novices in the profession, but also for experienced professionals who need to know what the others are doing (Becker et al., 2003; Clarkson & Eckert, 2005). In professional education, process models are part of the teaching and learning process, showing students (future professionals) what to do and how to do it. Researchers in various professional domains benefit from process models in several ways. They can use them for additional research and development. They can use them as theoretical material for analysis and evaluation, as well as building new models (Clarkson & Eckert, 2005).
The goal of our project is to develop a generic process model for collecting programmatic information. Our objectives are to provide a guiding instrument for planning programming research activities in the most efficient way, with a focus on information that is most useful for programming and design decision making, and in a sequence that is most supportive for different levels of decision making. In addition, we have decided to focus on the content and the content sequence of the process rather than on methods for information collection. Methods and techniques for field research constitute a cross section of the programming practice which, albeit closely related to content, constitute a thematic area of their own. We also envisage this model as a generic and general guide, abstract enough to be applicable to many building types, and flexible enough to be customized to the specifics and uniqueness of complex programming projects.
We see this model as a step towards developing a critical mass of programming process models, which will bridge the gap between current practices based on professional tacit knowledge and personal experience, and future practices using well explicated and codified professional experience that can be taught and disseminated. We are working on further detailing of this model according to the specifics of major building types, in particular very complex facilities like hospitals. We also foresee its further development in an array of more prescriptive models for programming cultural and community facilities, leisure and entertainment centers, and any other unique and complex civic facilities.
Our objectives are based on our vision about the unique nature of programming practices, the specifications and work requirements that emerge in programming for various building types, as well as the feasibility of this endeavor (Preiser, 1993, 2015a). We delimit our work to a generic process model for information collection in facilities programming, a model that is abstract enough and flexible enough so that it can be customized for different building types and different programming projects. We also delimit the information gathering to the sociocultural aspects of future building users and building use. Any technical aspects and data are left to engineering performance specification practices. This process model is intended to guide professionals with good social science background and field research skills who need to be informed about the scope of the sociocultural information necessary for programming and design decision making.
Our paper shows the theoretical process for developing a process model. Our methodology of theorizing is informed by systems theory (Banathy, 1996; Luhmann, 2012), the science of the artificial (Simon, 1996) and an ecological vision of the social world (Bronfenbrenner, 2005). These perspectives and theoretical vantage points are selected because our conceptualization of the socio-spatial objects and phenomena as holistic, complex, and multifaceted systems. The systems theory and the corresponding approach is the amalgamating medium. The ecological vision and approach are strongly influenced by a system’s type of thinking (Dyball & Newell, 2014). And the science of the artificial is created from a systems perspective (Simon, 1996).
We show our methodological “moves” in two layers--theoretical assumptions and guidelines for our model building. The theoretical assumptions constitute the foundation for developing the guidelines (Pathirage et al., 2007; Ruona, 2000). They direct our thinking and inform us how to proceed developing the next layer of instruments, the guidelines. We need these guidelines as important tools for streamlining the process of model building and for focusing in the right direction and the right content. In this respect, we treat the next two parts of the paper, theoretical assumptions and creating guiding principles as a presentation of our methodology of theorizing programming process models.
In brief, this paper consists of three main sections that build on each other. We develop the generic process model for data collection in facilities programming step by step. We begin with a methodological “detour” starting with major theoretical assumptions that constitute the foundation for our methodological work. We then develop guidelines that will direct us in the process of programmatic information collection. Finally, we will use these guidelines to develop a “road map” or a process model for data collection and analysis. The process model itself is organized in three parts; each one of them contains several steps.
2. The Theoretical Assumption
Below, we present fundamental theoretical notions that guide our thinking in the process of understanding and conceptually recreating relationships and connections that are important for understanding and modeling our object of study, as well as assisting in creating methodological structures necessary for field research (Pathirage et al., 2007; Ruona, 2000). In this case, we explore the social functioning of the buildings, as well as the functioning of social entities in the buildings. We can also see this picture in terms of socio-spatial interactions, a concept that mediates and fuses these two aspects (the social and the spatial) of the social reality.
These theoretical notions are assumptions about the nature of socio-spatial phenomena (Baker, 2005; Jabareen, 2009; Pathirage et al., 2007; Ruona, 2000; Staubmann, 2006). Their purpose is to recreate a holistic picture that will keep our attention focused on the aspects of the social reality that we need to study (Jabareen, 2009; Ruona, 2000; Staubmann, 2006) for the purposes of and in the process of facilities programming. We order and group these assumptions for presentation purposes, although we will use them simultaneously, in different groupings and configurations when we make decisions for the stages, steps, and tasks in the programming process.
First, buildings or spatial structures exist and function in social environment (Brand, 1995; Jessop et al., 2008; Lefebvre, 1991). This point of view helps us see the socio-spatial interactions in an architectural way, constantly keeping the building in mind, but at the same time thinking about the social environment as an important constituent of the socio-spatial realities.
Second, we can see both buildings and social entities as systems or subsystems, as needed (Banathy, 1996). This perspective helps us use the rich “toolbox” of the Systems Approach (Hitchins, 2008; Luhmann, 2012).
Third, every system (or its subsystems or components) engages in several relations with its environment (Banathy, 1996; Hitchins, 2008; Jessop et al., 2008). Regarding each of the relations, a norm of congruence emerges and sustains an environmental fit (Norris, 2001; Shareef, 1994). The system is in a constant pursuit of sustenance of the fit and a homeostasis (Hitchins, 2008).
Fourth, when the system can no longer sustain the norm of congruence in respect to one of the relations with the environment, this change in its state can be rationalized as an emergence of a need (Banathy, 1996; Moos, 1987). Every time the congruence or fit is disrupted, a state of need follows and affects the behavior of the system.
Fifth, the restoration of the norm of congruence can be rationalized as need satisfaction, and the means-as need-satisfiers (Artinger et al., 2022; Pervin, 1987). In socio-spatial aspect, these could be the organization of space, time, meaning, etc.
Sixth, the design of socially and culturally effective spatial structures (facilities) requires the identification of social/socio-spatial needs (Jessop et al., 2008; Lefebvre, 1991).
Seventh, in order to identify the social needs, we have to analyze and describe social organizations as activity systems, whose purpose is to satisfy a predetermined number of needs emerging from their social functional environment (Blackler, 1993; Holt & Morris, 1993; Prenkert, 2006).
Eight, the activity structure of every social organization (social entity), as well as its needs, is a function of its larger social functional environment (Blackler et al., 2000). Thus, the organization and its needs are shaped by its social environment.
Although numbered sequentially, these theoretical assumptions can be combined and recombined in several different ways to produce guiding principles that direct the design of a process model for data collection in facilities programming. In fact, it is difficult to pinpoint an exact sequence because of the complex and intertwined nature of the social and socio-spatial relationships that are the subject of architectural programming. In the following section, we discuss in more detail the creation of the guiding principles and guidelines that will bridge the theoretical assumptions and the articulation of the process model for data collection and analysis.
3. Creating the Guiding Principles
These theoretical assumptions lead to the creation of several methodological principles or guidelines for model building in facilities programming. The first two have a systems’ nature and will provide a systems direction to the whole model-building process. The first principle is “from the environment toward the system” (Banathy, 1996; Ford & Ford, 1999; Jackson, 2000; Luhmann, 2012; Nadler, 1981; Tuohy & Coghlan, 1997). It directs us to begin designing the system, artifact, or building starting with researching and understanding the (social/organizational) environment of the building: the social environment in which the building will function and which it will serve.
We can operationalize the system’s nature of the principle using organizational design literature (Banathy, 1996; Fararo, 2001). Therefore, the idea of starting with researching the environment in order to define the boundaries of the system can be reformulated in the following way: “from the organizational environment toward organizational goals.” This principle directs us to analyze the organizational environment and discover the environment’s needs that are to be served by the organization (Banathy, 1996; Luhmann, 2012). This principle tells us that the formulation of the goals of the artificial system depends to a large degree on the environment’s characteristics, needs, and functional niches as well (Luhmann, 2012; Nadler, 1981). The social or organizational environment becomes the foundation for determining organizational goals.
The second principle also has a system’s nature, and again we will both formulate in the system’s realm and will operationalize it in the realm of organizational design (Luhmann, 2012; Fararo, 2001). This principle directs us to work “from the goals toward the means (for achieving these goals)” (Banathy, 1996; Jackson, 2000). The goals should direct the design of the instruments or means. In our case, the instrument or means for achieving social and organizational goals is the building, although the building is only one of the instruments for achieving social goals. This principle also tells us that the design of the means (in our professional field, the building) is based on the organizational teleological or goal structure, which in turn is strongly influenced by the organizational environment (Tuohy & Coghlan, 1997). The second principle is both an elaboration and a complementary notion to the first one; thus, we can say that the first principle is operationalized using the second one.
The third principle is “from goals toward activity systems” (activities that serve as means for achieving the goals). Here we move from general systems thinking to the realm of social science and organizational design thinking (Banathy, 1996; Blackler, 1993; Shareef, 1994). We substitute activity systems for instruments or means and move the discourse and the research process in the realms of the social sciences and management. In this way, we can better see the people, their organizational structures, processes, and operations (Blackler, 1993; Prenkert, 2006). Systems thinking helped us start from the peripheral circles and move towards the center, the core, so that each layer closer to the center is well-interfaced or connected with its social functional environment (Banathy, 1996; Luhmann, 2012).
The fourth principle is “from activities toward socio-spatial needs”. The realm of activities and activity systems is quite broad and abstract for making an interface with architectural design (Lang & Moleski, 2010). Activities have multiple aspects to study and reconstruct. For the needs of architectural design, we will narrow the programming research work to the socio-spatial needs or activity needs that are satisfied with spatial-material resources (Lang & Moleski, 2010). Once we narrow down our search to that domain, the programming work becomes more manageable, less time-consuming, and requires fewer resources, compared to a comprehensive field research of human activities.
Having in mind the purpose of facility programming and its basic tasks related to the description of the social functional environment of the facility, the mental pictures of the organizational milieu and the environment of the socio-spatial system are important instruments for model building. That is why the research process should begin with solving these problems and then continue with the analysis of the social entities to be accommodated by the building. These social entities are construed first as activity systems, and then they are described regarding the necessary conditions that need support by environmental structures. The necessary conditions are treated as “needs”. The needs are later translated into design requirements and in this format, they are submitted to the designers for implementation and design decision making.
In general, we propose a process modeling approach in three phases: a) Generating and selecting theoretical assumptions that will guide to develop the guiding principles; b) Building guiding principles or guidelines for constructing the process; c) Based on these principles, building a model of the process that is intended to work as a guidebook or process manual. This guidebook will help programmers construct their own version of the programming process which is customized for their specific project programming situation. This modeling approach can be applied in nested “circles” from the periphery toward the core. It is not only applicable to the whole process, but also later can be developed further and in more detail at each concentric level of the nested circle, up to the core.
The guiding principles delineate several stages or parts of the organizational design (Tuohy & Coghlan, 1997) and the programming process: analyzing the environment of the social organization, explicating or designing the goal system of the organization, designing the activity systems and their structures, and on this ground—defining the user needs that should be satisfied with architectural means. In the second half of this paper, when we present our proposal for a process model for collecting and analyzing programming information, we will put these principles or guidelines into action.
4. Designing the Process Model for Collecting Programmatic Information
These guiding principles and visions about the social environment and the socio-spatial interactions direct us how to build a process model for collecting programmatic information. However, this model is only one of the possible options. We see several other options, but we also see the need for exploring several directions, developing competing or complimentary models, all with the purpose to advance the field of facilities programming. We are aware that each programming project is idiosyncratic and has its own peculiarities. The process model presented below is intended to serve as a general prototype that will be adapted, changed, and modified each time it is used in field work. The model is intended to be a guide in situations with multiple idiosyncrasies that require research design flexibility and methodological inventiveness.
The process model is structured in four parts, each of them consisting of several “steps”. These parts roughly correspond to the system of guiding principles and theoretical notions. The first part is about analyzing the environment of the social entity (or the organization) that will be accommodated with the new facility/building. The second part is closely related to the first part: developing the organizational goal system (mission, goals, objectives). The third part focuses on analyzing the social entity as an activity system. And the fourth part is devoted to analyzing and reconstructing the socio-spatial needs of that system.
5. Part One of the Process
In this part, an analysis of the social environment of the social organization takes place and is carried out in two steps: first, analysis of the sociocultural attributes of the environment and second, identification of the needs of that social environment of the organization. Here we will mention again that there are several nested levels of environment. The outer layer is the social environment of the organization. The inner layer is the organization itself as a functional environment of the building. The investigation of the social environment can be conducted with the same approach that mentioned above: theoretical assumptions, guiding principles, and a process model. Presenting such a methodology in detail would require a lot of publication space. For that reason, we will talk about it in another paper. Here we will mention several important steps that illustrate the work in that part of the process.
The first step is defining the scope of this investigation of the social functional environment the organization that will be accommodated with the new facility/building. This step is very important because the object of this investigation, the social environment, is ultimately broad and requires tremendous resources and time (Galbraith, 2014). To make it feasible regarding time, budget, and effectiveness, we need to narrow the scope, to become selective about what to study, in how much detail, and how to study it. Programmers must decide what information they need, in what detail, and for what purpose. Usually, programmers need information for constructing the mission, the goal structure of the organization, and the strategies. For that purpose, most often they need to reconstruct the needs of the social functional environment, as well as the marketing niche of the organization and the range of competitors.
The second step is defining the stakeholders in general, as well as focusing on the most important of them. The identification of stakeholders might precede many other tasks since programming very often is a participatory, collaborative activity. Therefore, programmers must decide early in the process whom to invite for participation. It is wise to define all stakeholders that are affected by the new facility, not just the parties that will be researched at this part step. The stakeholders that belong to the social environment of the organization might be interacting with the leadership of the organization and might be difficult to separate. Alternatively, this step can be performed later in the process, when the social environment is well researched, articulated, and described.
In many cases, programmers need to make a decision whether they will go in more detail at this step and research, describe, and analyze the social groups that compose the environment. The alternative is to do this after investigating the business environment. In the latter case, programmers would have narrowed down their scope of work and would expend fewer resources by focusing on less social entities to study.
The fourth step is about the business environment of the organization. The business environment is a more focused look at the social environment, a narrower segment. However, it is the most important part of the social environment that directly affects the organization (Galbraith, 2014; Shareef, 1994). The analysis of the business environment is quite a laborious activity and can be subdivided in a number of sub-steps. Here we provide only a general view of this process. It includes a study of business opportunities and constraints, as well as markets, market niches, competition, and similar issues. Programmers narrow down their scope of research by focusing on information that will help them understand the needs of the population(s) that constitute the social environment; the demand for products and services; as well as the market size and the market niches. Programming researchers are aware of the subsequent parts of the programming process and try their best to collect enough information for decision making during the next steps.
The fifth step focuses on even narrower segments of the social environment. Programmers look at cross-sections, aspects, and populations in the social environment to come closer to the identification of social needs that the social organization intends to satisfy. The problem of “needs” is basic to new product development and facilities development. Every organization is an artifact that is to satisfy needs—that is to say, current problems of the organization’s social environment (Simon, 1996; Van Aken & Romme, 2009). Their scope is defined by institutional domain and range of operation, the operation range of other institutions (organizations), as well as by additional regulations, customs, and so forth. Programmers should consider many other options, because often facilities offer unintended affordances and are subjected to unpredictable and spontaneous ways of use due to unforeseen needs. This work prepares more refined information for the next steps in the process when organizational goals and objectives will be developed.
6. Part Two of the Process
In the second part of the project, programmers move “from the organizational environment toward organizational goals”. Here they develop the teleological (goal) system of the social functional environment of the facility. In fact, this is the goal system of the organization that will be accommodated by the building. In principle, this part includes organizational mission, goals, and strategy. Depending on the programming practice, at this part of the process, the strategic interests of major stakeholders might be considered as well. We will illustrate this part of the process with several steps that show the nature, content, and amount of work.
The first step is developing the organizational mission. This is the start of the implementation of the principle “from the social environment towards the goals”. The mission statement links the organization and its social functional environment and expresses the essence of that link. The mission statement provides the direction of the organizational design (Galbraith, 2014; Shareef, 1994). It directs the development of goals, objectives, and strategies (Burton et al., 2006; Tuohy & Coghlan, 1997). In this respect, it can be considered a guiding principle for designing the organization. This is very important for facilities programming since it directs programmers in defining the areas of the social environment that need to be researched and analyzed.
Thesecond step is “a definition of the goals and objectives of the organization”. This is an operationalization of the organizational mission (Burton et al., 2006; Tuohy & Coghlan, 1997) and a more detailed conversion (or “translation”) of the social environment needs into organizational goals. Because of typical limits on resources and the facility construction budget, only a fraction of the existing and identified needs are intended to be satisfied (Galbraith, 2014). Although the social functional environment’s needs are the basis and the most important prerequisites in the process of goal formulation, many other factors exert pressure on it. Some of these factors come from the analysis of the social environment, while others are idiosyncratic components of the hierarchical systems of planning and design thinking, for example, values, priorities, and compromises.
The third step is evaluation and feedback of this part of the process. It is intended to foresee the general consequences of the mission, goals, and objectives. If undesirable side effects are identified, the decisions that contribute to their emergence will be modified at this point. In the third and fourth parts of the process analogous steps will also be performed to provide process monitoring and corrections.
7. Part Three of the Process
The third part of the programming process is guided by the principle “from goals toward activity systems” (Banathy, 1996; Blackler, 1993; Shareef, 1994). It forms the core of the programming process. The social organization is viewed and described as an activity system (Banathy, 1996; Prenkert, 2006). The analysis takes place in four steps: First, defining the activities, that need to be performed in order to attain the goals; second, analyzing the way they are carried out; third, describing activities and activity systems; and fourth, assessing activity systems’ impact on organizational environment, identifying potential problem areas, and introducing corresponding corrections in the activity system. This part of the process is loaded with details. This makes it most extensive, laborious, and time consuming, compared to the other parts.
The first step is concerned with the identification and selection of appropriate activities for achieving the proposed objectives (Banathy, 1996; Blackler, 1993; Luhmann, 2012; Prenkert, 2006; Shareef, 1994). This set of activities is defined in relation to the needs that have to be satisfied. Activities are viewed as means for achieving the goals and functions of the organization (Banathy, 1996; Tuohy & Coghlan, 1997). Each function may be performed by one or more activities that are systematically bound in a chain or a situation. It should be noted that one activity or activity system can satisfy several different needs.
In organizational theories and documents, activities are described by their functional dimensions: the results (products) they supply to other activities in the activity chain, such as staffing, personnel characteristics, and job descriptions. Such information could be gathered by studying organizational documents: organizational charts, plans, programs, regulations, manuals, instructions, ordinances, orders, etc. These encompass mainly questions of competence, obligations; technological requirements, sequence of processes, input-output relations, hierarchy, power, etc.
The second step is analyzing activities regarding how they are organized and performed (Blackler, 1993; Prenkert, 2006). Activities can be described in a number of aspects. One type of description can focus on the conative, affective, and cognitive processes structured in the form of patterns, algorithms, etc. and defined by prevailing stereotypes. The volume of operations is included, as well. It can be defined by the type and volume of resources used (let’s say, all inputs), the outputs, and the number of participants. The organization of an activity with all its features depends on culture and traditions (Cameron & Quinn, 2011). The patterns of organization of all activities in a system is also a cultural act that introduces cultural specificity to the system.
The third step is organizing activities in a system and organizing the main activities or process flows (Banathy, 1996; Blackler, 1993; Mast et al., 2000; Prenkert, 2006). This system of task can be considered the core of the programming process, at least when we consider the amount of effort, resources, time, and budget. Its complexity is enormous, considering different traditions in the study of organizational structures, process flows, and activities.
When we talk about process flows, we move the discourse and the conceptualization of the programming research action to a high level of abstraction and use the resources of well-developed and influential fields like management, organizational design, and logistics. This is important for building the overall framework for organizing activity systems and for developing a scaffolding for the details. The discourse in terms of activities, activity systems, and activity flows will guide the programming process to more details, more considerations, and to a richer overall system of background information and requirements.
These are the flows (process flows) of matter, energy, information, power, control, and decision-making. The flows of matter are quite diverse—raw materials, prefabricated components and goods, by-products, wastes, finished products, as well as moving equipment and people (Blackler, 1993; Mast et al., 2000; Prenkert, 2006). In this respect, and only for designing the building circulation, people are viewed in anthropometric terms. The flows of information are differentiated according to the information carrier and the human senses: visual, auditory, etc. Each flow has its specific requirements—for example, the necessity of visual information about the situation requires good observability, conditions for surveillance, etc. The flows of power, control and decision-making are interconnected with the hierarchy, in fact, they make up its basis (Blanchard, 2004).
Different approaches to activities and activity systems lead to several descriptions that are different in content, conceptualization, and terminology, depending on disciplines where they are created, as well as their paradigmatic traditions (Brannick et al., 2007; Lamport et al., 1989; Staubmann, 2006; Wilson et al., 2012). However, there is a certain degree of mutual influences, interrelationships, and even borrowing. Such interrelations bring about the emergence of a complex picture of the connections and process flow directions, which must be maintained and sustained when an organization is functioning in reality (Bertelsen & Bodker, 2003; Tobach, 1999).
The sociological perspectives on organizations (Collins, 1998; Fang et al., 2011) pay special attention to informal communication and social interaction. They are of high importance for sustaining organizational morale and job satisfaction. In this way, efficiency is increased. In sociological terms, this aspect is nominated “informal”. It is one of the components of the social dimension of the social organization (Fang et al., 2011). Another component is the personal needs of the participants. They generate a set of activities whose role is to service and sustain the personnel. These activities form their own subsystem, hierarchy, and circulation flows that strongly influence satisfaction, efficiency, and work safety.
These aspects of the organization influence the main problem of architectural design—creating conditions for facilitating the process flows and the interconnections. Other dimensions of the organization may have an impact on socio-spatial structures, but failure to take them into consideration is not destructive, only disruptive, if at all. They may lead to minor impediments and difficulties, discomforts, decrease in performance and efficiency, but hardly ever cause substantial obstacles to activity processes and make the building obsolete and impossible to use. A perfect facility must be responsive to all kinds of flows, corresponding requirements, and wishes.
The importance of different types of structures for the functioning of the organizations sets the priorities and sequences of design procedures. The processes that are directly involved in attaining the organizational goals should be designed first. Then the logistical, service, and informal activities are organized in accord with the already designed most important structures. On these grounds, we can envisage two related principles and suggest a sequence of modelling “from goal attaining activities toward servicing activities” and “from formal to informal (activities, relations, groups)”.
The fourth step is intended for feedback and corrections. At this stage, a careful assessment is made of the impact that organized activities might have on social and physical environment. The coordination and compatibility of various activities are studied in relation to both their functions and social effects. Socio-spatial implications are identified, and an attempt is made to foresee future problems. In the end, the activity system is modified and restructured to prevent undesired consequences.
8. Part Four of the Process
The fourth part of the process is concerned with the identification of user needs that emerge during activity and that can be satisfied by organizing the built environment in a particular way. Such user needs can be a result of user-environment interactions or more complex interactions involving several users in a joint action (Caprotti, 2018). We can conceptualize these needs as necessary conditions that are satisfied or provided by the (built) environment’s features (Tay & Diener, 2011). We can also call them socio-spatial needs using theoretical developments on space and spatiality (Hillier, 2008). These needs are different from the needs of the social environment that we discussed in Part One of the process. This part of the programming process is organized in three steps: first, identifying socio-spatial needs; second, selecting the socio-spatial needs that are most important to satisfy within existing budget and resources; and third, revising and correcting the model.
The first step is identifying the socio-spatial needs or needs that emerge in the process of interactions among users and the built environment (Caprotti, 2018; Hillier, 2008). The basic prerequisite for starting this analysis is the interpretation of the social entity as an activity system or an activity setting. This operation is an implication of the theoretical propositions that activity is the medium of people-environment interaction and in addition, that the purpose of the built environment is to satisfy needs emerging in the process of activity. A second prerequisite is the adoption of a suitable concept about needs. “Need”-type phenomena are heterogeneous and have a diverse nature (Dean, 2010; Doyal & Gough, 1991; Max-Neef, 1989).
The issues of needs are complex and present challenges even for the leading theorists (Dean, 2010; Doyal & Gough, 1991; Koltko-Rivera, 2006; Max-Neef, 1989). A separate project on socio-spatial needs in programming research is in process and a publication is pending. According to selected vantage points, needs can range from basic personality needs to conditions and resources that are necessary for the individuals in the process of their activities (Dean, 2010; Doyal & Gough, 1991; Max-Neef, 1989). Depending on the purpose of the study or project, needs can also be differentiated according to their subjects—individuals, groups, etc. A homogeneous “cluster” of needs is formed around the individual and the processes that constitute his/her existence. The second cluster of needs stems out of the processes of social interaction and interpersonal communication. A third cluster is comprised of the necessary conditions for the optimization of activities, their interconnections, mutual compatibility and coordination.
The second step is a matching the socio-spatial needs with resources and technological solutions (Caprotti, 2018). Not all socio-spatial needs can be satisfied, however, either because of budget restrictions or lack of technical solutions. Prioritization of needs is a complex and complicated process because of conflicting stakeholder values and priorities (Alio, 2017; Goodin, 1985; Sharpe et al., 2021). Programmers have to make difficult decisions regarding which needs to consider, and which needs to ignore. In effect, the selection is driven by values and priorities. Programmers must consider the values and priorities of all stakeholders, engage in a difficult moderation process, and develop a list of needs that is optimal for all parties involved. This process requires not only social science knowledge, but also participatory programming experience and conflict management skills.
The identification of needs at this part of the project has similarities with researching the needs of the social functional environment of the organization and the general needs of the organization as an autonomous social entity. It involves conceptualizing needs, researching needs, and prioritizing needs. However, in this part of the process, there are substantial differences stemming from the scale of social interactions and the focus on socio-spatial conditions. Now the socio-spatial needs or necessary conditions are related to the needs of human individuals in small activity settings. This is turn requires a different approach to conceptualizing the object of study and the relevant field research methodology.
The third step in this part is the last stage of the process. Its objectives are to make a final revision and introduce corrections in all parts of the programming project where necessary. If in this third part of the process a disproportionate and unfeasible demand for resources is established, then the basic goals and objectives of the organization, set in the first part, must be reviewed and some of them might be modified or omitted. The same streamlining approach can be applied to an organization’s processes and operations. If necessary, they can be reconfigured, simplified, or partially modified. Some of them may even be dropped.
Because of its unpredictability and complexity, this step is structured in several operations. Programmers reassess the scale of the facility, the available financial resources, and the technical feasibility. Programmers attempt to identify potential socio-spatial conflicts and search for ways to solve these problems. If the solution to such problems by spatial/architectural means is impossible, not feasible, and financially prohibitive, programmers must search for other options. Technological or social adjustments, modifications, and changes are considered. The activity systems may be reorganized so that socio-spatial conflicts will be resolved, reduced, or mitigated by reorganizing space. For socio-spatial purposes, only a very narrow range of organizational changes are admissible. In principle, these modifications should be nonessential and unimportant from a managerial point of view. They should not influence the main organizational structures and process flows. Such modification should only affect the spatial dimensions of communication flow, work groups, departments, spatial relations between them, etc.
9. Concluding Remarks
In this paper, we have traced the development of a generic process model for collecting and analyzing facilities programming information. We have started with theoretical assumptions that drive the creation of guiding principles, and after that they direct the design of the programming process model in each individual case. The model is intended to serve as a generic source and needs to be adapted to each programmatic case. In order to provide such versatility, we have intentionally worked at a high level of abstraction. This has led to a careful selection of only the most important aspects of modeling the realm of social entities and socio-spatial interactions, so that our model can be applicable to a wider range of cases. We are fully aware that when building case-specific process models, the differences between the social organization and the functional aggregates bring about substantial changes in every case.
The process model proposed here is one of the many possible options. It can be subjected to variations, modifications, and changes, either in the number and type of steps, or in their order, composition, etc. These are contingent upon situational factors, including type of problem, goals, intellectual resources, etc. Moreover, it is accepted that universal models of this type should be adapted to the specific situations they are used in.
In the future, this model can be adapted to many building types. In this way, we will have fewer abstract models, models that have more details pertinent to the targeted building type. In the next phases of our project on programming, we will develop such type-specific models, as well as even more specific, case-driven models. We also propose that the facilities programming community experiment with and develop such models at their discretion. “Ad hoc” operationalization and adaptation will enrich the knowledge base and will create critical mass for new reflection and reconsideration. We will be happy to see a growing number of models that offer improvements, details, and solutions to existing problems. Such a variety can become a foundation for a rich discussion on the programming process, leading to better, more effective, and more efficient programming practices.