Problem Seeking E-Book

William M. Pena

• Herausgeber: John Wiley & Sons
• Kategorie: Geisteswissenschaft
• Sprache: Englisch

Seitenzahl: 275

Veröffentlichungsjahr: 2012

Beschreibung

The classic programming guide for architects and clients¿¿--fully updated and revised Architectural programming is a team effort that requires close cooperation between architects and their clients. Problem Seeking, Fifth Edition lays out a five-step procedure that teams can follow when programming any building or series of buildings, from a small house to a hospital complex. This simple yet comprehensive process encompasses the entire range of factors that influence the design of buildings. This Fifth Edition of the only programming guide appropriate for both architect and client features new information related to BIM, integrated practice, and sustainable design when programming. Supplemented with more than 120 illustrations and diagrams updated for this edition, this indispensable resource provides revised technical information and faster, easier access to explanations, examples, and tools, including: * Guidance on incorporating the latest technological tools when programming * A primer on discounted cash flow analysis and net present value analysis * Project statement examples organized by project phase and building type * Useful techniques for data management, functional relationship analysis, and more

Leseprobe

Table of Contents

Title Page

Copyright

Foreword

Preface

Acknowledgments

Part One: Problem Seeking

Overview

The Primer

The Search

Programmers and Designers

Analysis and Synthesis

The Separation

The Interface

Process

Five Steps

Procedure

Considerations

The Whole Problem

Four Considerations

Framework

Information

Information Index

Organizing Information

Two-Phase Process

Data Clog

Processing and Discarding

Participation

User on Team

Effective Group Action

Team

Participatory Process

Background Information

Decision Making

Communication

Steps

Establish Goals

Collect and Analyze Facts

Uncover and Test Concepts

Determine Needs

Cost Estimate Analysis

Abstract to the Essence

State the Problem

Summary

Programming Principles

Part Two: How to Use the Method

Introduction

Definitions and Examples

On Theory and Process

On Considerations

On Goals

On Facts

On Concepts

On Needs

On Problem Statements

Programming Procedures

Establish Goals

Collect and Analyze Facts

Uncover and Test Concepts

Determine Needs

State the Problem

Programming Activities

Typical Programming Activities

Four Degrees of Sophistication

Variable Conditions

How to Simplify Design Problems

Useful Techniques

Data Management

Questionnaires

Interviews and Work Sessions

Audio- and Videoconferencing

Functional Relationship Analysis

Gaming and Simulation

Space Lists

Program Development

Brown Sheets and Visualization

Analysis Cards and Wall Displays

Electronic White Boards and Flip Charts

Electronic Presentations

Programming Reports

Program Evaluation

Building Evaluation

Selected Bibliography

Index

About the Authors

This book is printed on acid-free paper.

Foreword

Preface

Acknowledgments

HOK Team

Editor:Melinda ParshallProject Manager:Lauren GibbsSpecial Contributors:Erik Andersen, Robin Ellerthorpe, William Hellmuth, Frank Kutilek, Eberhard LaeppleGraphics & Photography:Gerald Callo, HOK Visual CommunicationsCover Graphics:Jay Dacon, HOK Visual Communications

We are grateful to those programmers, past and present, who have contributed to this book—some much more than others—but all contributing more than they realize.

Part One

Problem Seeking

An Architectural Programming Primer

Overview

The Primer

Good buildings don't just happen. They are planned to look good and perform well. They come about when good architects and good clients join in thoughtful, cooperative effort. Programming the requirements of a proposed building is the architect's first task, often the most important.

There are a few underlying principles that apply to programming—whether the most complex hospital or a simple house. This book concerns these principles.

Programming concerns five steps:

1. Establish Goals.

2. Collect and analyze Facts.

3. Uncover and test Concepts.

4. Determine Needs.

5. State the Problem.

The approach is at once simple and comprehensive—simple enough for the process to be repeatable for different building types, and comprehensive enough to cover the wide range of factors that influence the design of buildings.

The five-step process can be applied to most any discipline—banking, engineering, or education—but when applied specifically to architecture, it has its proper content that is an architectural product: a room, a building, or a town. The principle of this process is that a product will have a much better chance of being successful if, during the design, four major considerations are regarded simultaneously.

These considerations (or design determinants) indicate the types of information needed to define a comprehensive architectural problem:

Function Form Economy Time

Architectural programming, therefore, involves an organized method of inquiry—a five-step process interacting with four considerations.

The Search

Programming is a process. What kind? Webster's spells it out specifically: “A process leading to the statement of an architectural problem and the requirements to be met in offering a solution.”

This process, derived from the definition and referred to as the five-step process, is basic. The word “basic” is used advisedly. Since the advent of systematic programming six decades ago, different degrees of sophistication have evolved. But the procedures presented here remain basic to all.

Back to the definition.

Note “statement of an architectural problem.” This implies problem solving. Although usually identified with scientific methods, problem solving is a creative effort. There are many different problem-solving methods, but only those few that emphasize goals and concepts (ends and means) can be applied to architectural design problems.

Almost all problem-solving methods include a step for problem definition—stating the problem. But most of the methods lead to confusing duality—finding out what the problem is and trying to solve it at the same time. You can't solve a problem unless you know what it is.

What, then, is the main idea behind programming? It's the search for sufficient information to clarify, to understand, and to state the problem.

If programming is problem seeking, then design is problem solving.

These are two distinct processes, requiring different attitudes, even different capabilities. Problem solving is a valid approach to design when, indeed, the design solution responds to the client's design problem. Only after a thorough search for pertinent information can the client's design problem be stated: “Seek and you shall define!”

Programmers and Designers

Who does what? Do designers program? They can, but it takes highly trained architects who are specialized in asking the right questions at the right time, who can separate wants from needs, and who have the skills to sort things out. Programmers must be objective (to a degree) and analytical, at ease with abstract ideas, and able to evaluate information and identify important factors while postponing irrelevant material. Designers can't always do this. Designers generally are subjective, intuitive, and facile with physical concepts.

Qualifications of programmers and designers are different. Programmers and designers are separate specialists because the problems of each are very complex and require two different mental capabilities: one for analysis, another for synthesis.

It may well be that one person can manage both analysis and synthesis. If so, he or she must be of two minds and use them alternately. However, for clarity, these different qualifications will be represented by different people—programmers and designers.

Photo courtesy of HOK

Analysis and Synthesis

The total design process includes two stages: analysis and synthesis. In analysis, the parts of a design problem are separated and identified. In synthesis, the parts are put together to form a coherent design solution. The difference between programming and design is the difference between analysis and synthesis.

Programming Is analysis. Design Is synthesis.

You may not perceive the design process in terms of analysis and synthesis. You may even question problem solving as an approach. You may think of the design process as a creative effort. It is. But the creative effort includes similar stages: Analysis becomes preparation or exposure, and synthesis becomes illumination or insight. The total design process is, indeed, a creative process.

Does programming inhibit creativity? Definitely not! Programming establishes the considerations, the limits, and the possibilities of the design problem. (We prefer “considerations” to “constraints” to avoid being petulant.) Creativity thrives when the limits of a problem are known.

Sometimes I think we arrive at a solution before we know what the problem is. We say: “My next design will be Round!” without logic or analysis.

—William Peña

The Separation

Programming precedes design just as analysis precedes synthesis. The separation of the two is imperative and prevents trial-and-error design alternatives. Separation is central to an understanding of a rational architectural process, which leads to good buildings and satisfied clients.

The problem-seeking method described in this book requires a distinct separation of programming and design.

Most designers love to draw, to make “thumbnail sketches,” as they used to call these drawings. Today, the jargon favors “conceptual sketches” and “schematics.” Call them what you will, they can be serious deterrents in the planning of a successful building if done at the wrong time—before programming or during the programming process. Before the whole problem is defined, solutions can only be partial and premature. A designer who can't wait for a complete, carefully prepared program is like the tailor who doesn't bother to measure a customer before starting to cut the cloth.

Experienced, creative designers withhold judgment and resist preconceived solutions and the pressure to synthesize until all the information is in. They refuse to make sketches until they know the client's problem. They believe in thorough analysis before synthesis. They know that programming is the prelude to good design—although it does not guarantee it.

Corita Kent, artist and educator, wrote, “Rule Eight: Don't try to create and analyze at the same time. They are two different processes.”

—Today You Need a Rule Book, 1973

The Interface

The product of programming is a statement of the problem. Stating the problem is the last step of the five-step process in problem seeking (programming); it is also the first step in problem solving (design). The problem statement, then, is the interface between programming and design. It's the baton in a relay race. It's the handoff from programmer to designer. In any case, the problem statement is one of the most important documents in the chain that comprises the total project delivery system.

While many theorists extol the virtues of the problem statement, few practitioners stop to formulate a statement, to verbalize it. This programming method requires that you actually write out a clear statement of the problem. Since this statement is the first step in design, as well as the last step in programming, its composition must be the joint effort of the designer and the programmer.

Process

Five Steps

The competent programmer always keeps in mind the steps in programming: (1) Establish Goals, (2) Collect and Analyze Facts, (3) Uncover and Test Concepts, (4) Determine Needs, and (5) State the Problem. The first three steps are primarily the search for pertinent information. The fourth is a feasibility test. The last step is distilling what has been found.

Curiously enough, the steps are alternately qualitative and quantitative. Goals, con-cepts, and the problem statement are essentially qualitative. Facts and needs are essentially quantitative.

Programming is based on a combination of interviews and work sessions. Interviews are used for asking questions and collecting data, particularly during the first three steps. Work sessions are used to verify information and to stimulate client decisions—particularly during the fourth step.

Briefly, the five steps pose these questions:

1. Goals: What does the client want to achieve, and why?

2. Facts:What do we know? What is given?

3. Concepts: How does the client want to achieve the goals?

4. Needs:How much money and space? What level of quality?

5. Problem: What are the significant conditions affecting the design of the building? What are the general directions the design should take?

Procedure

The five steps, then, are not inflexibly strict. They usually have no consistent sequence; nor is the information scrupulously accurate. For example, a 10,000-student university, a 300-bed hospital, and a 25-student classroom are only nominal rather than actual sizes. Information sources are not always reliable, and predictive capabilities may be limited.

The steps and the information, then, do not have the rigor or the accuracy of a math-ematical problem. Programming, therefore, is a heuristic process and not an algorithm. As such, even good programming cannot guarantee finding the right problem, but it can reduce the amount of guesswork. The method is just as good as the judgment of the people involved.

Working through the steps in numerical sequence is preferable; theoretically, this is the logical order. But, in actual practice, steps may be taken in a different order or at the same time—all but the last step. It is frequently necessary, for example, to start with a given list of spaces and a budget (fourth step) before asking about Goals, Facts, and Concepts (first, second, and third steps). It usually is necessary to work on the first four steps simultaneously, cross-checking among them for the integrity, usefulness, relevance, and congruence of information.

The fifth step is taken only after marshalling all the previous information, extracting, abstracting, and getting to the very essence of the problem.

Considerations

The Whole Problem

It's important to search for and find the whole problem. To accomplish this, the prob-lem must be identified in terms of Function, Form, Economy, and Time. Classifying information accordingly simplifies the problem while maintaining a compre-hensive approach. A wide range of factors makes up the whole problem, but all can be classified in the four areas that serve later as design considerations.

Too little information leads to a partial statement of the problem and a premature and partial design solution. The appropriate amount of information is broad enough in scope to pertain to the whole design problem, but not so broad as to pertain to some universal problem. As the Spanish proverb states: “He who grasps too much, squeezes little.” Grasp only what you can manage and what will be useful to the designer.

As a professor might say, “Before you answer individual questions, be sure to look at the whole examination.” Designers should look at the whole problem before starting to solve any of its parts. How can a designer who does not have a clear understanding of the whole problem come up with a comprehensive solution?

Four Considerations

Take a closer look at Function, Form, Economy, and Time. There are three key words to each consideration:

Function implies “what's going to happen in the building.” It concerns activities, relationship of spaces, and people—their number and characteristics. Key words are: (1) people, (2) activities, and (3) relationships.

Form relates to the site, the physical environment (psychological, too), and the quality of space and construction. Form is what you will see and feel. It's “what is there now” and “what will be there.” Key words are (4) site, (5) environment, and (6) quality.

Economy concerns the initial budget and quality of construction, but also may include consideration of operating and life-cycle costs. Key words are: (7) initial budget, (8) operating costs, and (9) life-cycle costs.

Time has three classifications—past, present, and future—which deal with the influ-ences of history, the inevitability of changes from the present, and projections into the future. Key words are: (10) past, (11) present, and (12) future.

Framework

Use the four considerations to guide you at each step during programming. By estab-lishing a systematic set of relationships between the steps in problem seeking and these considerations, between process and content, a comprehensive approach is assured. The interweaving of steps and considerations forms a framework for information covering the whole problem.

All four considerations interact at each step. For example, in the first step, when goals are investigated, function goals, form goals, economy goals, and time goals should emerge. With each of these considerations having three subcategories, the process includes asking 12 pertinent questions regarding goals alone. Since the first 3 steps constitute the main search for information, 3 times 12 provides the basis for 36 pertinent questions.

Consider these to be key questions. The answers will provide opportunities for fur-ther questions. The Information Index on the following pages indicates more than 90 items in these 3 steps.

Programmers do not have to know everything the client knows, but they should know enough of the client's aspirations, needs, conditions, and ideas that will influence the design of the building. For this, programmers have to know the right questions to ask; they start with the 36 subcategories.