CHAPTER 18
Level 1: Foundation (Planning/Organizing)

The best way to manage design in a team environment is to start well. (See Figure 18.1.) Countless teams fail because they forget to prepare or think they don't have time to plan. Make it a point to create a tightly knit working group. Set the following controls in place first, or as soon as you can.

“If you don't know where you're going – you'll end up somewhere else.”

– Yogi Berra

Illustration of an “organizing” Project Control Level 1: "Foundation" (Planning) in place.

FIGURE 18.1 Level 1: “Foundation” (Planning/Organizing).

Goals and Objectives

Set goals: Setting goals before beginning a project seems obvious. Unfortunately, it is surprising to see how often team fail to set goals. William Pena, in his classic book Problem Seeking, talked about the value of breaking goals down into subject-based categories: form, function, time, economy, and quality.

Breakdown: This breakdown method is valuable in grouping goals into categories useful in design and construction. Too many projects are launched with “lazy” goals such as: “Be on time, on budget, with high quality.” These clichéd statements do little to define project-specific needs. Strong teams articulate real goals, categorize them and commit to them.

Shared goals: The next goal setting principle is that all team members should agree to the goals. Within client organizations, multiple constituencies may have conflicting goals. The construction director nearing retirement may want to implement a safe, easy design, and an easy transition. The visionary CEO may want her new building to set new standards in innovation, energy, or worker satisfaction. The aging facilities manager may want simple, old-school systems; the environmentally conscious, newly hired advocate may pine for state-of-the-art, complex systems.

Beyond client goals, other team members may want radically different things. The engineer wants efficiency, or to recover profits lost on the last complex design job. The architect could want to execute swiftly based on past formulas, with little innovation, to keep his fee. The contractor, amid a firm reinvention, may wish to revisit the process of designing and building collaboratively, using all the technology, process, and social techniques available. The owner may wish to experiment with new IPD contracts. Without sharing goals and objectives, and strategies to accomplish them, this team is headed for trouble. When they don't resolve their differences, they march off into months of conflict. Good teams make goals explicit and agree on them before they start.

Roles and Responsibilities

Teams that begin designing and building as a group without knowing who is on their team doom themselves to interpersonal failure. How can you interact if you don't who is there, what they can do, what their role or job is, and what motivates them? To fix this problem, find out. Get an organizational chart. Make time for it.

Have a party before the project starts, not after. Learn who “they” are as companies and individuals.1 This process has many names: partnering, socializing, bonding among them. Without first setting up roles, responsibilities, and methods for working together, teams restrict workflow and confuse purpose. Even after you have listed all the players, things will change. On projects of any size, team members come and go regularly through attrition and other reasons. Keep your project directory current. Nurture and reestablish connections with existing and changing teammates. You will work together better. Connecting with your teammates is key to starting well.

Functions

The average owner or contractor teammate may not understand this: design firms have a host of job functions and people who perform them. The designer is the prime person and behavior type we discuss. Responsible for generating the building form, they are the spiritual leader that sets the project's plan and appearance. The project or production architect is responsible for producing a good set of documents. He or she is lasered-in on roof details, coordinated drawings, and communicating project scope and design intent to the contractor. Project managers are charged with leading their teams to on-time, on-budget completion, while keeping client, contractor and design teams happy and productive. All these individuals and a plethora of others like spec writers, staff designers, or technical experts can be leaders for their respective disciplines. Getting a schedule commitment from the design principal is less reliable than getting it from the project manager. Know which teammate you're dealing with to increase your chances of working together effectively. Finding teammates with skills in more than one of these functional areas is a welcome development.

TABLE 18.1 Responsibility Matrix

Responsibility Matrix
Legend: R= Responsible, S= Support, I= Inform, A/V= Veto, ?=TBD
Responsibility Owner Architect Contractor Other
Geotechnical R S S
Survey R S
Materials Testing I A/V R
Code Consultant R ?

Communication Protocols

With the many players and kinds of expertise found in modern teams, many “languages” and “dialects” are spoken. Owner, architect, engineer, user, contractor, IT, and scheduler are just a few. To align and translate these ways of speaking, set preferences, hierarchies, alignment, and means in advance. Will tech-based collaboration tools be used to share data in a central location? How often are face-to face meetings? Who should call whom? Failing to plan for these processes is likely to overload unknowing teams in landslides of email, lost data, and miscommunication. Have a communication plan. Use the best tools you can.

How will you communicate? With whom? When? How often? What technology, software and tools will automate and connect the vast numbers of professionals that convene to design and build? Surely, you will not rely solely on old-school techniques. Is a project information portal in place? A central shared data repository? A conflict resolution hierarchy? Of course. Only a fool would embark upon a major project without the best technology and smartest tools, right? No one does projects by sending lots of indiscriminate emails without a plan, do they?

BIM/VDC/Digital Infrastructure

When we built projects with hand drawings and rotary dial phones, we did not need protocols. Now, with the multiplicity of software, platforms, digital data exchanges, and wealth of use cases, we need digital plans, protocols, and infrastructures. Why develop a digital model for sharing if some team members do not know how to use it, have that software, or the server capacity to access or accommodate it? The lead times to price, approve, buy, acquire, install, and learn these tools can be long. Start these enabling activities early.

A problem well stated is half solved.”

– Charles Kettering

Programming and Research

Despite the AIA contract's longstanding assumption, few owners develop or provide adequate building programs. Some hire professionals to develop programs before design starts. Most owners rely on partners to help them figure out what they want and need during design and construction. Teams that recognize this need should jump at the chance to provide this valued service to owners – and get paid for it.

Before you start designing and building, and likely while doing so, define and articulate the owner's need by developing a program. No wonder designers are lagging – no one has determined what the owner needs! We've got to work together to create this often-lacking Project Design Control.

Beyond the program of requirements, teams should get smarter about research. In contrast to the self-informed design exploration and trial-and-error approach we have used for centuries, professionals should invest in capturing and sharing research. Those who do can add value and be more profitable. In any project endeavor, ask what has gone before. Use it as a benchmark. Site visits and comparable facility tours offer great value. They create a sense of shared history for the team, a common knowledge base that support their mission.

Project Analysis Kickoff Meeting

The project analysis kickoff meeting (see Figure 18.2) is a strategy to “launch” or “refresh” a project. It uncovers critical information, builds communication, and is proven to contribute to project success. This technique parallels “brainstorming,” “partnering,” “interdisciplinary work teams,” and other management and problem-solving techniques. It gets projects off to their fastest, best start. Several key aspects make it work:

Photograph depicting a project analysis kickoff meeting with a group of men and women assembled to “launch” or “refresh” a project.

FIGURE 18.2 Project analysis.

  • All” team members are present: a prerequisite under a team approach.
  • All” information available is present in a useful format.
  • Time is compressed, capitalizing on and contributing to the synergy, communication and momentum that result in great value to the owner and to the team.
  • Lag time is eliminated in favor of immediate understanding, consensus, and short decision cycles.
  • Rapid prototyping of ideas is accomplished with immediate, multidisciplinary input.
  • A common team mission is identified, and a bond is formed.
  • Synergy, expertise, interactivity, collaboration and greater value are the result.
  • The project is defined, balanced, and set up for success.
  • Project controls are set, and possibly, design direction.

The agenda includes:

  • People. Companies, individuals, and relationships (the soft side) are introduced. These “people” issues set the stage for factual project issues.
  • Purpose. Purpose, vision, goals, expectations are shared and recorded.
  • Project. The project is defined, and measurable project controls are set: program, budget, scope, schedule, and documents. These tangible measurable limits form the baseline for design project management.
  • Possibilities. Possibilities are explored by analyzing design options and constraints in a multidisciplinary way including cost, schedule, constructability integrated with design potential. “Design” begins, with expert input.
  • Plan. The project plan is put into place by the team with work plans, action items, and next steps. This quickly builds a working team and well-defined project. Research shows that conducting a project analysis kickoff meeting during predesign, or as early as possible, is critical in successful, balanced projects. Projects that complete a predesign, feasibility (or project validation phase as it is called in IPD circles), have a grasp of key project issues. To start well, start with a project analysis.
  1. Project Analysis Purpose, Organization, and Participants2

    Much of the thinking and text in this section was borrowed from my days at Heery International. Its origins are the work of George Heery, FAIA (verbatim excerpts, updated to modern practice), from a process developed in his book Time, Cost and Architecture (McGraw-Hill, 1975), and related to earlier CRS “squatter sessions.” (See Thomsen interview.) Heery called the process “predesign project analysis,” because predesign is the most valuable time to do it – the right time. But too many miss the opportunity to do it during predesign. This is a shame – one of the biggest mistakes a team can make. In response, I have renamed it “project analysis,” because, if necessary, it can be done anytime to reframe and reactivate a project. Regardless of where you are in the process, when new team members are added, or something changes significantly, schedule a project analysis to refresh your team. Since design happens throughout a project, a project analysis can happen almost any time, or repeat during any phase, but the earlier the better. Its purpose is to identify critical program, design, budget, schedule, scope, construction, procurement, and document considerations interactively and quickly. Since 80 percent of the direction, impact, and decisions affecting a project are made in the first 20 percent of the schedule, per the Pareto Principle, deal with pertinent data early, comprehensively, and efficiently to form a plan to balance and set up the project for success. Conducting the project analysis during predesign, planning, or programming before design begins separates problem definition and strategy from design process and solution. It also saves design and construction time due to its high-value planning and strategy early in the influence curve. In addition to being exposed to project analyses in Heery's book and conducting them as an employee in his firm, I have been lucky to do them in other contexts, including working with legendary multidisciplinary design think tank experts IDEO, and as a contractor and design manager. Borrowing and paraphrasing from all these groups, here is my recap:

    The project analysis is a multidiscipline “think tank.” Invite the owner, construction manager, architect, project manager, designer(s), engineers, landscape architect, planner, and interior designers, and all key experts as participants. Project size and nature governs who to invite. In organizing analysis sessions, don't let them become mere committee meetings, reporting sessions, or “typical” project kickoff meetings. Initiate sessions before design work starts in a way that creates a harmonious, productive, collaborative, interactive atmosphere. Challenge one another! If you are lucky enough to get your spot at the table, don't waste it. Speak up!

  2. Preparing for the Project Analysis

    Before the Session: Orientation/Preparation Package

    Before convening a project analysis meeting, brief project team members to explain its purpose and nature, and their roles. Send this overview and the agenda to describe the process. Preparation and attendance are always limited by time. Since this meeting is expensive and involves many people, it should be efficient and informative. To overcome that and stretch time, put pertinent information in participants' hands in advance by preparing a project orientation package. Compile existing pertinent project information (e.g. drawings, sketches, objectives, site and surrounding area data and photos, program of requirements, agenda, sketches, budget, schedule, zoning, agency approvals, and anything else helpful and necessary) for all attendees.

    This package informs them in advance, so they come to the meeting ready for interaction and evaluation, not orientation. Your goal is to accelerate information flow to the point of overloading in advance of the meeting. Project analyses can have different focuses: visioning, planning, team building, orientation, or design opportunity analysis. Set your sights on your purposes and plan accordingly.

    In addition to project information, distribute information management guidelines and exchange samples with participants in advance as test cases. Predetermine formats, BIM and VDC schemes and protocols, with software and hardware. Eliminate translation problems and maximize reuse of information generated in the project analysis. Hold a separate BIM Assessment, BIM Execution Planning (BxP) Session, or information or media exchange forum. Project managers leading a team through the digital design process for the first time should prepare and plan. In this case, project analysis sessions may be longer. Consider an introduction, a break of several days, and resume, with intervening work by all parties. Where projects are too large or agendas too long, break out less-interdisciplinary topics to be done offline with smaller expert groups.

    2–3 weeks prior: Set the date and confirm the attendees. Who? Do I really have to? Principal-in-charge, consultants, PM, owner, PA, architects, interior designers, engineers, preconstruction team, scheduler. Verify facility location, adequacy, and size. Develop an agenda, with team buy in.

    1–2 weeks prior: Compile Project Orientation Package (POP): What, why, background, site context, images, existing facilities, budget, program. Solicit input from others. Profile owner, organizational chart, annual report, and research data. Distribute POP to attendees with instruction and “homework assignment” to digest it before the meeting.

  3. Conducting the Project Analysis

    During the session: Managers leading their first project analysis will need extra preparation, and practice to develop their own styles, techniques, energy, and panache to make sessions productive and engaging. Project leadership should conduct the sessions jointly from a multiparty perspective.

    Create an environment conducive to productivity. Coach participants to suggest partially developed ideas and accept constructive criticism with good humor. At this stage they should understand that comments and creative contributions outside their own disciplines are not only acceptable but encouraged. Meeting effectiveness is directly related to creating an intense, continuous, focused experience, including the people, resources, spontaneity, and atmosphere to support it. To be effective, facilitators should keep pace, elicit key opinions, and avoid getting stuck on any one detail. When necessary, set issues aside and come back to them. Defer judgment during the idea generation stage.

    Prepare an agenda, so people can manage their time if they cannot attend the whole session. Prepare enlargements of the preparation package to display (or project them live) to illustrate objectives, facts, and visual relationships, and get buy in. Avoid solving tough, detailed issues. Concentrate on a wide range of parameters to get a feel for the entire project's key issues. Order in lunch to sustain focus (and the expensive group assembled). Keep together and productive. (As a benefit, you'll get to know one another during the “work-through-lunch break.”) Be visual. Use diagrams, images, and live screen capture of key points, data, and concepts.

    After the session: Prepare meeting notes, distribute sketches, concepts, program items, and results in written and graphic form as a launching pad for design. Give project information (in the right form) to those who need it. This starts the Project Definition Package – the management baseline of a balanced project. Distribute meeting notes. Continue to develop a phase-end Project Definition Package. Conduct follow up meetings.

  4. Duration, Agenda, and Results of a Project Analysis

    Project analyses may run from hours to days. One or two days are typical, including follow-up documentation. “Only rare, simple projects can be covered in a half day.”3 “Typical” Project Analyses accomplish the following:

    1. People. Introduce team, firms, individuals, roles, responsibilities, interests and abilities. Use team orientation/workshop activities to form the team. Begin the project's “soft,” “people,” “relationship” side.
    2. Purpose. Establish and capture goals and objectives in terms of cost, function, time, quality, form. Articulate goals and objectives of owner, users, CM, architect, engineers, and so on.
    3. Project. Establish Project Design Controls: program, budget, scope, schedule, and documents, that will be used to design to, collaborate with, and manage project design.
    4. Program. Outline the following program of requirements types: space, site, systems, personnel program, operational, and other program requirements.
    5. Budget. Confirm, develop or analyze the total project budget analysis. Identify potential cost problems, cost reduction possibilities, and construction purchasing opportunities. “Gut check” the budget versus program (and versus design if design exists). Identify potential cost reductions, purchasing, and other factors that influence costs.
    6. Scope. Develop project scope and extent and systems to be included for building, site, parking, furnishings, fixtures and equipment (FFE), and so on as a guide to what must be designed, budgeted, and built. Use CSI checklists and other similar tools.
    7. Schedule. Develop overall project schedule, including design, project definition, construction, commissioning and other key milestones.
    8. Documents. Identify a project-specific approach to documents, and a list of key documents required, by phase.
    9. Possibilities. Explore/establish design concept(s), options, or at least the direction design work should proceed, plus areas of needed research.
    10. Eliminate design blind alleys. Identify constraints and opportunities. To the extent feasible, including construction, fabrication and delivery constraints, and labor, design, site, owner decision and financing, agency approval, and other administrative constraints. The ability to identify constraints comes with experience. Frequent constraints are site grading and foundations, long lead equipment, and permitting. Extensive earthwork, complex excavation, or foundation work may constrain or dictate design and construction sequence.

    Other frequent constraints include structural frame fabrication/delivery/erection; labor contracts; site availability/zoning; major mechanical equipment; utility, street/site access work; electric switchgear or other electric equipment; elevator; lab equipment; furniture; special and unusual major equipment delivery/installation; agency approvals; materials availability (i.e. reinforcing steel, brick, etc.); owner's reviews and decisions, and environmental or sustainability issues can also drive timing.

    1. Analyze potential building and engineering systems. (Select them in some cases).
    2. Verify owner requirements and preferences. Discuss funding; financing; construction procurement policies, culture, objectives, interim deadlines, and key political issues.
    3. Plan. Set the management plan for procurement strategy, project duration and major activities in a critical date schedule. Develop a results-oriented plan for total project management (predesign through construction) to achieve the owner's goals – a project “road map” that defines the who, what, when, where, and how necessary to achieve the project's goals and objectives. Establish it after analyzing considerations from the programming and predesign phases. As the project proceeds, the management plan will feed the overall project schedule. Evolve the design, agency approval, purchasing, and occupancy schedules with the master schedule.
    4. Energy/environmental/sustainable/LEED considerations. Set team objectives, metrics, and strategies.
    5. Design direction or options. Each project has a point of diminishing return in the project analysis scope. For example, in a warehouse, or regular building form, a team might be able to evolve a design concept and go as far as selecting types of structural frame and wall construction systems. In a multi-building medical complex, probably only basic design options can be identified for later study.
    6. Construction procurement. What are the owner's, contractor's, design builder's, CMs, or IPD team's potential problems and opportunities in buying construction? Which subcontractors and other partners are likely to be responsive because of the prospect of repeat business?
    7. Meeting notes/project analysis record documents. The CM, PM, PA conducts the session with information distribution and reuse in mind. Prepare drawings and information in formats that can be quickly shared. Do meeting notes that capture program, objectives, schedule, budget, sketches, surveys, and action items as the point of design departure. Distribute them within two days to maintain momentum.

    By the end of the project analysis, all major disciplines should be able to move forward earlier and more productively than in traditional design approaches. The multidiscipline team should be a visible cooperating force. Mutual respect and the ability to communicate should be established, and forces likely to produce results relevant to user needs set in motion. The project analysis provides an excellent opportunity to launch a project. It focuses on key aspects and identifies problem areas before time and manpower are expended. Projects that conduct project analyses have great success. Those that don't see the opposite result.

  5. Design Charrettes.

    Project analysis turbocharges design efforts by defining the problem. Later, with “all” information in hand and all disciplines represented, conduct a problem-solving session or design workshop to synthesize a design effort. If done on the client's premises or away from the office, these have been called “squatter sessions,” “design charrettes,” and “deep dives.”

Project Definition Package (PDP)

A PDP is a product, contributed to by the entire team, that captures or incorporates by reference all Project Design Controls. PDPs can be done before a project analysis, updated during, and be reissued after. If the notion of a package or document sounds dated, think of it as a central database that is constantly updated. With a PDP, a project can be managed, having had its controls set, balanced, and recorded at the outset. Traditionally, contractors document pricing and schedule, and note the architect's documents on which they are based. Expand team documentation to include program, scope, and clarifications. Add rules, roles, responsibilities and change management processes. Teams that do will have a written basis for all project aspects useable to track changes and manage design: Project Design Controls, written and accessible by all.

Notes

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset