Programming-The Third Dimension 4


PREFACE

A facility program makes explicit the goals, facts, concepts, and facility needs of a building in a way that is useful for making design decisions. Facility programming provides essential information to the client and designer about the building requirements necessary to support required functions. As such, it is an important step in the facility delivery cycle. This cycle incorporates all the activities of bringing a facility from conception to occupancy and the evaluation of this effort to feed – forward to the next project.

Quality architecture originates from a synthesis of quality programming and visionary design. This article will explore the nature of the interrelationships between programming and design in health care facility planning.

INTRODUCTION

Large hospitals only look like hierarchical organizations; in reality, they are closer to symbiotic organisms, dependent on maintaining a functional and political balance among components. This is a challenge the health care programmer must recognize and accommodate.

Managing a creative building project becomes particularly challenging in this environment. Responding to departmental goals and the complex balance of power can limit the ability of an organization to seek new, bold visions for the future. Maintaining rigorous project budgets in response to severe economic pressure requires deciphering the “real” needs of each user group and balancing these needs against the overall organizational goals. This must be done while developing and maintaining a total building concept that seeks to integrate needs and express visionary solutions.

There are a series of complex and conflicting concerns that must be successfully resolved during every health care programming and design process:

  • create a humane environment for patients and staff
  • provide a functional design that ensures efficient, safe, and appropriate work spaces
  • accommodate technical requirements for highly sophisticated equipment
  • provide an unambiguous path for arrival at and entry into the building
  • create clear, segregated paths for movement of people and material within the building
  • conform to a myriad of often conflicting building codes and regulations
  • blend technical and functional requirements into a design that brings delight to those who use the building and those who pass it by
  • develop building systems concepts that can accommodate rapid change
  • facilitate incremental growth and replacement of facilities over time

INTEGRATION OF PROGRAMMING AND ARCHITECTURAL DESIGN

The complexity of programming health care facilities has led to specialization of programming skills and a fragmentation of the programming process from what traditionally were closely interrelated design activities. Forces that have resulted in the separation of programming from design include the following:

  • focus on non – facility related strategic planning
  • bias in architectural schools against specialization
  • perceived conflict of interest between defining building scope and providing architectural services
  • contemporary definitions of, and compensation for, basic architectural services
  • increasing need to achieve new levels of operational efficiency
  • limited education of architects in psychology, communications, finance. statistics, and other skills necessary for effective programming.

The dividing line between programming and design is very inhibiting. Great buildings rarely result from a sequential process of programming and architectural design. They result from a symbiosis of form giving and user insight, a collaboration of design and programming skills. Splintering of the processes for user decision and design presents one of the major challenges to the creation of quality architecture. Effective programming requires specific technical knowledge and interpersonal skills to help users define needs, identify relationships, and visualize future opportunities. The programming process is ultimately the translation of external opportunities, the users needs, available resources, and institutional values into a viable building concept. This requires an interactive collaboration between client, programmers, and architectural designers. Programming is the first step in the design process.

The fallacy of segregating programming from architectural design is that traditional programming builds from the inside out and is two – dimensional in nature. It is valuable in that it is sensitive to the needs of users; it is limited in that it deals with physical relationships and square footage in the abstract. That is, programs are developed in isolation from building and site realities and potential. Sequential programming is a two – dimensional approach. It assumes that complete building requirements and operational systems can be established without testing context – sensitive site and building concepts and without addressing building form and mass.

Traditional architecture, on the other hand, is ‘outside – in’. It tends to derive the form of the building with only a cursory understanding of the program and the total square footage required. It is three – dimensional in that it deals with the reality of the building, but often it is insensitive to user requirements. For example, the building may be conceived in a formalistic sense, with symmetry around a grand entrance and atrium lobby or two triangles with points touching, independent of the actual needs of those for whom the building is intended. The needed space is later stuffed into the building form in the best way possible.

Great architecture requires interaction between programming and design. That is, a third dimension is needed in programming. The program must be derived from the concept and at the same time define the concept. It must speak about the building as a piece of architecture as well as a place to house users. It must define and establish the aesthetic goals for the building. It must also establish in the collective client’s mind the possibilities that a well – designed building can reveal.

Imagine the parts of a grand piano scattered separately in one place. While all the makings of a great instrument are there, a talented craftsman would be at a loss as to what to do with the pieces, unless he or she had a concept: first, the idea of music; and second, the idea of a piano. Only then could the skill of the craftsman be applied to make a truly great instrument. Architecture is similar. The programmer produces the parts and the architectural designer must visualize the great instrument. Throughout the planning process, the client also must be able to visualize the end product in order to fulfill his or her role in making appropriate decisions. Thus, the programmer and the designer must collaborate and work simultaneously, not sequentially as at present, with the client as an integral part of this collaboration. A shared vision – the music – must exist between all three.

PROGRAMMING IN THE THIRD DIMENSION

An integrated programming / design process has many of the components of traditional, sequential programming and design. The following will describe the challenges of developing a major building program for a complex hospital using an integrated and highly interactive programming / design approach.

Establishing an Organizational Concept         

Elegance is defined by the American Heritage Dictionary as “refinement and grace in movement, appearance, or manner.” This term is frequently used to describe a design solution that creates a unique, effective, and pleasing solution to a problem. The creation of an elegant design solution needs to begin in the programming phase, through identifying user needs and instilling in users the possibilities and opportunities that exist in creating new space or using existing space in new and interesting ways.

The political nature of space (territory), status, and control in hospitals presents a major barrier to the type of open communications necessary for identifying needs and opportunities for design solutions, particularly as these cross traditional departmental boundaries. Space is a critical resource and is also a symbol of the success and strength of an administrative program or medical discipline. Realignment, sharing, or reduction of functions or space can be perceived as a threat to departmental goals and long – term status. Programming within this context must encompass several simple, but frequently overlooked, fundamentals, to ensure success:

  • effective communication of the proposed process to all involved
  • resolution of institutional goals with goals of each subcomponent
  • application of methods for defining space and functional needs that do not lock in preconceived solutions
  • maintenance of subcomponent needs in perspective with overall organizational goals and resources as the process proceeds
  • provision of opportunities for frequent testing and review of architectural design concepts as functional and space models are explored during the programming process

Preparing an institution to plan and program complex and diverse spaces, such as those in hospital and research facilities, requires a dedicated staff that is positioned to transcend the organization, one that understands and incorporates the organizations decision – making subtleties. A programming process such as this requires considerable attention to defining the scope and approach of the project. A team approach on the part of the institution and consulting firm is called for, beginning with careful selection of a consulting firm that is compatible with the institutional culture and that has the skills and knowledge to work with diverse, often highly specialized, technical individuals. The process requires the dedication and attention of the institutions top management to quickly resolve conflicts and make required decisions so that planning and programming can progress. Most importantly, it requires a clear definition and understanding of the goals and priorities of the institution.

Tools and Techniques 

A rigorous treatment of a methodology for health care facilities programming will be beyond the scope of this lecture. However, certain observations will be made on the subject.

The design team must know how to manage user group interviews to avoid two common tendencies that lead to collecting user “wish lists” based on a limited frame of reference. First, user groups sometimes encourage inexperienced design teams to jump prematurely into discussions of precise space requirements and detailed design issues before departmental goals are established and there is a clear understanding of such goals. Second, it is difficult for many users to visualize or consider future requirements and opportunities as opposed to present activities, and the facility implications they represent.

Traditionally, facility programming has examined various key functional parameters to derive space requirements and planning criteria. For instance, space allocations for clinical and other technical departments should be based in part upon a careful examination of present and projected future workload. Depending on the department, workload is measured in terms of the future projected volume of procedures, tests, daily deliveries, or similar indicators; equipment; staff; functional systems; and hours of operation. For less technical areas such as offices, the primary drivers of space needs are indicators such as staffing projections, forecast changes in technology, and the expected volume of specialized activities such as conferences, training classes, records processing, document reproduction, and so forth.

A variety of statistical techniques and related data analysis tools are commonly used to project expected daily requirements for key rooms around which a specific department is organized. For instance, given the projection of expected daily and weekly surgical procedures by type and associated equipment requirements for specialized rooms, simulation and queuing modeling are often employed to infer an optimal number of operating rooms in surgery. Similar techniques are used to determine medical center educational conference and training rooms by size and type, given historical and projected data on meeting schedules and staffing.

The most important value of such analyses is not precise mechanical estimates of room requirements as the end point in the programming process. Rather, it is the opportunity such estimates provide to inform a user group as to reasonable boundaries for space needs. The technique of grounding user group discussions in a rigorous examination of workload – based functional activities can be essential in sorting out true space needs from unsupported wish lists. The data from technical analyses can be employed to keep the process objective and, along with the application of appropriate group leadership skills, to balance competing departmental power group interests. Finally workload and space projections also provide a familiar vehicle that users can understand and apply to address the future and free themselves from focusing only on current physical building requirements. Workload – based programming is one of the more valuable techniques to keep all participants oriented to an appropriate planning horizon and future needs.

Interdepartmental Collaboration

A common pitfall of traditional programming has been to overly emphasize functional and space needs assessment techniques that sequentially examine individual departments or organizational units in isolation from other issues. This leads to architectural space programs that are simply an amalgamation of individual department programs with little sense of how the total building is to work functionally or physically. It is a typification of the “ inside – out” approach to building programming and design.

A dramatic example of cross – departmental collaboration in the redefinition of operational policies and structure at a large teaching hospital in the US in the area of cancer care was in the critical care area. A multidisciplinary user group composed of surgeons, internal medicine physicians, pediatricians, anesthesiologists, nurses, and hospital administrators was formed to discuss common programs and issues. Radiologists, pharmacists, infection control staff, and laboratory medicine staff met with the user group on an ad hoc basis. It became apparent that a physical adjacency of the intensive care units could be beneficial from a quality of care and resource perspective. In addition, there was concern about the growing number of patients with extraordinarily long lengths of stay in the intensive care units and the emotional burden this places on the patients’ family. The need for a pediatric intensive care unit was identified, because of new leadership and a change in treatment philosophy of the pediatrics department. The critical care model developed by this cross – departmental user group included medical, surgical and pediatric units and a supportive care unit that would permit increased visitation by family members, all physically adjacent to one another and sharing important resources such as special treatment rooms, treatment areas, and  staff support functions.

The programming and planning team worked with the user group to identify space needs and shared support space and to develop and test possible layouts that would accomplish the stated goals. It was also recommended by the user group that a critical care division be established with the primary responsibility for managing the care of patients in all the units.

In groups where individuals represent different organizational reporting lines, building consensus is often difficult because of conflicting goals and priorities. The critical care group effectively overcame these obstacles because of initial well – defined and consensual objectives. Among these objectives was the goal to establish physically adjacent critical care units, which would improve quality of care and avoid a duplication of support services caused by organizational reporting lines. The user group recommended that the critical care units be adjacent to the surgery suites (because of the close association between surgical intensive care and the OR’s); the planning team determined that this was not physically possible on the same floor level. However, the priorities established by the user group prevailed and the comprehensive critical care adjacency remained intact, with the units located on a different level than surgery. Working together, the user group and the planning team developed a feasible solution that retained the comprehensive critical care structure, while maintaining a dedicated vertical link to the operating rooms.

A related issue was the feasibility of creating a floor plate big enough to accommodate all the critical care beds on one level. The site was limited and major issues of allocation of site footprint to research or to clinical space surfaced early in the planning process. The testing of floor plate size was necessary to feed into the critical care committee discussions. Had it not been possible to locate all these beds on one level, further complex discussions would have ensued to set new program priorities.

The critical care example illustrates the importance not only of crossing traditional departmental boundaries in structuring programming focus groups, but also of testing physical solutions as programming discussions proceed, so that unobtainable objectives can be recognized early and alternative solutions can be found.

Hospitals and related health care facilities are knit together by numerous cross-facility logistical and technological systems. These are the sinews and arteries that connect functions into a coherent whole. The most important of these systems include intradepartmental circulation routes and horizontal and vertical transport systems (elevators, escalators, conveying devices, stairs) for staff, patients, visitors, and materials; cross – departmental systems, procedures, and technologies; and telecommunications and information systems. These systems dramatically affect interdepartmental adjacency needs, specific space allocation within departments, and overall building support space size, type and location.

Often, intradepartmental issues are addressed only superficially in conventional programming. This is a serious omission. An integrated programming / design process mandates that these issues be addressed. In order to do so, cross -disciplinary user groups must be formed and the realities of adjacencies, and building organization must be the basis for planning. For many systems – information transfer, for example – spatial organization is not an issue. The programming of these systems, however, is closely interrelated to departmental function and should be addressed with other programming issues.

Visualizing Alternatives       

 Finally, it is important that the user and the building owner fully understand the building that is proposed. Most users have never been exposed to the possibilities that architecture can offer; they have never seen an excellent building. Most users have difficulty visualizing a room of 200 square feet, or a space about 12 feet by 18 feet. The planning team can present plans of typical rooms from other architectural projects with equipment layouts to assist in visualization. This is also true of overall building concepts, which will remain abstractions if concept plans are not developed simultaneously.

Hard data – derived estimates of space allocations should be supplemented with techniques to help users visualize the impact of alternate systems, procedures, and approaches to patient care. Taking user groups on tours of different new facilities can provide valuable perspectives on the implementation and relative success of new design concepts in a ‘live’ situation. Specific functional systems and design details need to be fully clarified and evaluated in user meetings after each field visit. For instance, in programming critical care patient rooms, the effect of providing a service column system instead of a conventional bed headwall system for medical gases and utilities is best visualized on field trips with users. Systems such as these can significantly affect options for space in the room, the position of the bed, and the accessibility for the medical team in the room during routine procedures or a major resuscitation situation. In the absence of a field visit, a graphic presentation, a dynamic computer – aided design modeled directly in a user meeting, or, in some cases, a full size mock – up may be effective in exploring options and for assisting users to come to a decision.

Techniques such as an analytical approach to workload forecasts and utilization patterns, computer simulation of operations, and cross – departmental focus groups are useful tools for programming when applied in the right circumstances. So are tests of physical possibilities during programming discussions, examination of cross – departmental systems early in the programming process, and the identification of ways to assist users to visualize new solutions. These techniques will provide a scope and depth of information that is far greater than the traditional space listing. A program must also contain design data, which can be derived and tested most effectively if programming and design occur in tandem. Rarely is this done in traditional programming.

Programming / Design Interrelationships

There are many benefits to simultaneous programming and designing; that is, bringing the program “ out of the paper.” Great buildings are born of great concepts, a higher level of exploring the “third dimension.” Rarely are great buildings conceived exclusively from the programming process. Functional and space programming is an activity of inquiry and information seeking. It evaluates what is and builds on a body of ideas that have been evolved over a period of trial and error at other institutions, hopefully with new ideas added in the process. The program remains, however, a series of aspirations and ideas that do not express a total building reality; it is without life, without the third dimension.

Great concepts are derived from knowledge and understanding, the ability to grasp the essence of the whole. A planning effort that has as a goal innovation and new insights must have both client and architect who are willing to take an intellectual leap, to go beyond what any one individual user or the collective user conceives. This is why the programming process is the essential first step in the design process and must be interactive with exploration of physical solutions. Both client and programmer / planner must collaborate closely in combining creative energies to visualize the whole as well as the parts, simultaneously throughout the programming and planning process. Fully realized, programming is a creative act of the highest order and essential to great architecture.

Building Re-use

In today’s health care environment, capital must be conserved wherever possible. Therefore, in many programmatic situations, existing buildings must be renovated and re-used. Where programming for re-use is done without testing architectural design, traditional ratios of net to gross space often are invalid. Existing space cannot be used with the same level of efficiency. Likewise, building costs cannot be accurately forecast without a through assessment of mechanical, electrical, and plumbing cost implications. The configuration of existing building wings or elements may also be a limiting factor in deciding the proper re-use of a given space. All of these considerations require an experienced architectural assessment and testing of design solutions.

Expansion Strategies

There have been many ways of ensuring that a facility can accommodate growth and change. Use of an integrated building systems approach is one that has been mentioned. Another commonly used technique is to locate highly complex space, which would be expensive to relocate, adjacent to “soft” space, which can be moved with little disruption or cost. This technique provides a built-in area for expansion. Knowledge of expansion capabilities affects program area; if a zone for expansion is available, less internal expansion needs to be programmed in the initial configuration. These strategies also affect the amount of initial space to be provided, the building footprint, and horizontal adjacencies. Expansion strategies are almost never considered in programming unless architectural concepts are developed simultaneously.

Building Character and Amenities

Buildings are for people. Traditionally, hospitals are thought of as the doctor’s workshop and have been built for technology, not for people – least of all the patient. The result is that user groups relate to what they have experienced – the workshop – and become advocates for more of the same. Programmers reflect what the users tell them, and this often means that no-one is the advocate for patients and others who use the building. The architectural designer is trained to act as the advocate for people, including patients, un-represented in normal user discussions.

The building must be a good neighbor; it must fit in the context of the community and neighborhood in which it is located. It must offer delight. In the case of a hospital, it must provide a sense of reassurance and well – being to those who are frightened or confused. The building is a statement of institutional culture. The building is a work place. There must be consideration of natural light and air, energy consumption, colors, and art. Most of all, there must be a unifying concept to the building, a sense of organization and clarity of structure to it.

Concepts of human needs and responses must become an integral part of the program and the project budgeting process for every building. This rarely happens in today’s traditional, sequential ( two – dimensional ) programming process.

A NEW DIRECTION

A tradition has developed that programming should be completed before an architect is hired to develop building concepts. The programmer may be trained as an architect, an hospital administrator, an accountant, or a health planner / statistician. The discipline doesn’t matter, as long as the assessments of need are objective and not influenced by an “ edifice complex, that is, a bias to build too much. In health care architecture, the tradition of programming in isolation from building design is misguided. It may be misguided for other building types as well.

There is clearly a specialty of health care programming. The best programmers do not necessarily emerge from the architectural professions, although many of them do. A programmer is not a generalist; it is unlikely that many could design a good hospital without assistance. Architectural design is also a specialty. Most architectural designers are poor programmers. Collaboration should be based on mutual respect. It is not necessary for health care architects to develop in-house programming capability. What is necessary is for both disciplines, design and programming to be involved simultaneously in the very early formative stages of project conception. There also needs to be mutual respect for each other’s specialization and a close working relationship as an integrated team.

Great buildings come from a collaboration of individuals, each of whom can subordinate their preconceptions and together capture a new vision. The client must be an equal partner in this collaboration. The new possibilities that grow out of this fusion of thoughtful and innovative minds, each with a different perspective, if widely adopted, would quickly elevate health care architecture to a new level.

 

BIBLIOGRAPHY

Strategic Asset Management: An Expanded Role for Facility Programmers

John P. Petronis, Architectural Research Consultants, Alberquerque, New Mexico.

Programming: The Third Dimension

Wilbur H. Tusler, SMP, San Francisco, California, with Frank Zilm, James T. Hannon, and Mary Ann Newman.

Programming Processes for Military Health Care Facilities

Clarence E. Maxwell and Dale R. Brown, United States Army, Washington, D.C.

Preiser, Wolfgang F.E., Professional Practice in Facility Programming, New York:Van Nostrand Reinhold, 1993.

 


Leave a Comment

Your email address will not be published. Required fields are marked *

4 thoughts on “Programming-The Third Dimension