Establish Goals

Goals are important to designers who want to know the what and why of things rather than a list of spaces. They wont find inspiration in a list.
They will find it in goals. Project goals indicate what the client wants to achieve, and why.

However, goals must be tested for integrity, for usefulness, and for relevance to the architectural design problem. To test them, it is necessary
to understand the practical relationship between goals and concepts.

If goals indicate what the client wants to achieve, concepts indicate how the client wants to achieve them. In other words, goals are implemented
through concepts.

Goals are the ends. Concepts, the means. Concepts are ways of achieving goals. The relationship of goals and concepts is one of congruence. The
test for the integrity of goals depends on their congruence with concepts.

Practical goals have concepts to implement them. Lip -service goals, on the other hand, have no integrity and should be disregarded. They may
well be faithless promises in a public relations publication with no plan to keep them. Regardless of good intentions, it is not always what the client
says but what he or she really means.

No one can argue against motherhoodgoals. They are unassailable; however, they are too general to be directly useful. Who can argue against
the goal to provide a good environment?or the goal to get the most for the money?Theres nothing wrong with including a few
motherhoodgoals, especially if they can be processed to be specific enough to clarify the situation; however, intellectually hard, clear project
goals are absolutely essential.

On the other hand, a few motherhoodgoals are needed to inspire designers, who like ambiguity to trigger the subconscious in their search for
design concepts.

Do not forget that trying to mix problems and solutions of different kinds causes never -ending confusion. To put it positively, a social problem
calls for a social solution. After there is a social solution, then it can be part of a design problem for which there will be a design solution. You
cannot solve a social problem with an architectural solution.

Programmers must test goals and concepts for relevance to a design problem and not to a social or some other related problem that cannot be
solved architecturally. This test for relevance includes testing goals and concepts for design implications that might qualify them as part of a design
problem.
Collect and Analyze Facts
Facts are important only if they are appropriate. Facts are used to describe the existing conditions of the site, including the physical, legal, climatic,
and aesthetic aspects. These facts about the site should be documented graphically to be really effective. Other important facts include statistical
projections, economic data, and descriptions of the user characteristics. Theres no end to facts. Yet programming must be more than fact finding.

The facts (and figures) can become too numerous to promote definite conclusions. Collect only those that might have a bearing on the problem,
and organize them into categories. Seek facts that are pertinent to the goals and concepts. Massage these facts and figures so that become useful
information. Process them to determine the architectural implications.

Facts may involve many numbers such as the number of people that generates space requirements: 2000 seats in a concert hall. Numbers need
to be accurate enough to ensure the impartial allocation of space and money, yet rounded out enough to allow for a loose fit: 150 square feet per
office occupant. Predictive parameters have to be just accurate enough to be realistic: 15 square feet per dining seat

When programmers ask questions, what they hear may not be what they want to hear; nevertheless, they must try to

avoid a bias so as to collect impartial information. They must avoid preconceptions and face the facts squarely. They must be realistic, neither
optimistic nor pessimistic. Programmers must separate fact from fantasy. They must seek what is true or even what is assumed to be true.
Assumptions in this case are things to be lived with. Programmers must tell the difference between established fact and mere opinion. They must
evaluate opinions and test their validity.

Uncover and Test Concepts

It is critical to understand the difference between programmatic concepts and design concepts, which is very difficult for some people to grasp.

Programmatic concepts refer to abstract ideas intended mainly as functional solutions to clients performance problems without regard to the
physical response. On the other hand, design concepts refer to concrete ideas intended as physical solutions to clientsarchitectural problems, this
being the physical response. The key to comprehension is that programmatic concepts relate to performance problems and design concepts relate
to architectural problems.

The difference between programmatic concepts and design concepts is illustrated in these examples: convertibility is a programmatic concept; a
corresponding design concept is a folding door. Shelter is a programmatic concept; a corresponding design concept is a roof.

Abstract ideas are required. Ideas must be kept in a pliable, vague form until the designer jells them into a physical solution. It s really best if
design can wait until all
Determine Needs
Few clients have enough money to do all the things they want to do. Therefore, distinguishing needs from wants is important. What the rich man
considers a necessity, the poor man thinks a luxury. Thus, judgments on the quality and adequacy of space are difficult to make. It is also difficult
to identify real needs . The client usually wants more than he or she can afford. So the client and the architect must agree on a quality level of
construction and on a definite space program relating to funds available at a specific time.

The fourth step is, in effect, an economic feasibility test to see if a budget can be determined, or a fixed budget balanced. It should be noted that
the best balance is achieved when all four elements of cost are to some extent negotiable: (1) the space requirements, (2) the quality of
construction, (3) the money budget, and (4) time. At least one of these four elements must be negotiable. Thus, if agreement is reached on quality,
budget, and time, the adjustment must be made in the amount of space. A serious imbalance might require the re -evaluation of Goals, Facts, and
Concepts.

The clients functional needs have a direct bearing on space requirements, which are generated by people and activities. Allowance must be made
for a reasonable building efficiency as expressed by the relationship of net areas to gross areas. The proposed quality of construction is expressed
in quantitative terms as cost per square foot. A realistic escalation factor must be included to cover the time lag between programming and mid-
construction.

Phasing of construction may be considered as an alternative:

When the initial budget is limited.

When the funds are available over a period of time.

When the functional needs are expected to grow.

Cost control begins with programming, and is basic to the whole architectural design problem to be solved. Cost control does not inhibit an
architects creativity; economy is a major consideration, not a constraint. An architect might petulantly think that cost control is a constraint, but
not if he or she is committed to giving clients what they need, what they can afford.

Predicting costs at programming is not too difficult since the total planning proceeds from the general to the specific, from the broad scope to
details. During programming, cost estimates can be made by successive approximations from the roughest tally of gross area, testing it with
different quality levels of construction, while keeping an eye on building cost and other anticipated expenditures. First -phase programming (for
schematic design) requires schematic estimates. Second- phase programming (for design development) requires more detailed estimates. As the
project advances in refinement, it is possible to test, to rebalance, and to update the budget estimate
a