Extreme Project Management for Architects
One of the fastest, easiest, and most effective ways to define Level of Quality (LOQ) for a repetitive drawing task is to develop a prototype; a full working solution. Prototypes make sense in any project because they ultimately save time. They're critically important in an XPM project because each drawing can be modified by any team member. We need to insure consistency no matter who works on the drawing.
Defining LOQ for any task is important because it determines the amount of effort required to complete the task. The more precisely we can define the LOQ, the more likely we are to satisfy it.
Say, for example, our task is to draw a "schematic level" elevation. What does "schematic level" mean? Do we include notes, dimensions, material symbols, grid lines? What standards do we follow? Do we key in wall and building sections? Do we draw freehand or on CAD? Until we know what's included and what level of quality is expected, we can't estimate the task. We can't even reasonably do the task!
Defining LOQ is part of defining a task; part of understanding exactly what the customer expects of us. Through some process or another, we ultimately merge customer requirements with our own, attempting to provide a solution satisfactory to all.
How we go about defining LOQ depends of the type of task. There are many techniques available; developing a prototype is only one. Prototypes are most suitable for repetitive tasks like drawing details, elevations, wall sections, and building sections. They're somewhat less, but still useful, for drawings required only once or twice, like site plans and roof plans.
In XPM, a prototype is a model upon which other similar drawings are based. It is therefore drawn with particular care. Yet, in its interim stage, it is created quickly, discussed, and modified as required to build consensus. Through the process of developing a prototype, we come to an agreement on what to show and how to show it.
A prototype goes through three stages: interim, final and real. An interim prototype is used to foster consensus. It is developed, often with variations, then discarded when a final prototype is selected. A final prototype serves as a model for other similar drawings. It may be discarded after it's served its purpose. A real prototype is one incorporated into the drawing set after review and approval. It becomes the new prototype.
There are two kinds of interim prototypes. The first represents a drawing type, like a wall section. The second represents an issue, like whether or not to include flashing in a wall section. The first often incorporates elements of the second.
When discussing prototypes, it helps to distinguish prototypes from the processes used to create them. The prototype itself goes through several transformations, as an interim prototype, before it becomes a real prototype. The process of creating the prototypes, evolving the transformations, and of getting consensus is just that -- a process. It we look at processes independent of prototypes, we see that there are many different processes, or ways to gather consensus. The process we choose depends on complexity of the prototype and the degree of agreement or disagreement over components of the prototype as well as other factors. There is no benefit to using the same process to create each prototype.
A group of similar drawings can be looked at as a set. Each drawing in the set is similar and related. For example, a set of window details consists of head, jamb, and sill. A set of wall sections show variations at different building locations. The set consists of a parent and its children. The parent contains almost all of the information required to accurately represent the set. Children contain information specific to themselves only. They don't duplicate information shown by the parent. We typically create a prototype for both parent and child. Prototypes for children distinguish the amount of information shown from that omitted to reduce redundancy.
In addition to helping define LOQ, we create prototypes for several other important reasons:
A prototype merges the sometimes conflicting requirements of the customer, review agencies, office, and personal standards.
A prototype is a full working example of a typical solution. If we intend to draw a series of elevations, our prototype is a single elevation that includes the exact level of detail and quality we expect to produce for the rest of the elevations.
When I say full working example, I mean we include everything expected for that drawing. If our elevations will require notes, the prototype includes some sample notes. Likewise for grid lines, cross hatching, dimensions, etc. It conforms to all related office and project standards like line weights and hatching symbols. It's drawn on the correct CAD layers using appropriate sheet layouts and titles. In other words, our example includes everything that will be included on an actual drawing sheet. It should, in fact, be drawn on an actual drawing sheet.
As the prototype is being developed, we test it. We should xref it, import it, file it, find it, reduce it, enlarge it, print it at half size and plot it at full size. When we review it, we must review both hard copy and the CAD screen version. We want to make sure the prototype looks and performs as we expect. The closer we can simulate actual use, the actual life cycle, the more useful the prototype will be.
Why do we go through so much effort in an example? Because we want to learn from it. First, we want to verify that we understand the customer's requirements, and that we can translate them into a physical representation. Second, we want to expose hidden obstacles and glitches that might arise when we do the actual drawing. We want to know what problems we might run into, and deal with them now, rather than later.
Even though the prototype is an example, it should be as close to an actual drawing as possible. Why not just use a real drawing, say the first in a series of elevations? Not recommended. Using a real drawing slows us down. In a real drawing, we'll want real dimensions and real notes. Instead, we want a model that we can create quickly and change quickly. We want to present it to team members, get feedback, and make changes in short cycles. Using a real drawing inhibits fast turnaround.
Prototypes are usually created early in each phase of the design process. They're one of the first tasks chosen when starting a new phase of the work. We might develop a prototype elevation for schematics, then, modifying the original prototype, show another level of detail for design development, and an even higher level of detail for contract documents.
We develop additional prototypes or variations as the need arises. Whenever we come up with new type of repetitive drawing task, we first create a prototype.
We develop prototypes when choices must be made; when alternative ways of presenting something must be discussed. We create several alternatives, then select the best and discard the rest.
While we recognize their value, we create prototypes only in response to a specific need. We don't create a prototype unless required by a task card.
Prototypes are best based on other prototypes and prior "tested" drawings -- drawings that have been used and modified over time to reflect office efficiencies and standards. Office standards, if kept up to date, can be quickly adapted to create prototypes.
Ideally, everyone who uses the prototype should review and approve it. We prefer approval by consensus. In reality we use judgment, often limiting our reviews to team members, but sometimes including the customer. We include other office staff if the prototype must conform to office, as well as project, standards.
Approval usually requires review of printed versions, plotted versions, and CAD screen versions.
Prototype as gold standard: After the prototype has been developed, reviewed and approved, use it as the "gold standard". All similar drawings should conform to the prototype, showing no more and no less than the original. Drawings based on the prototype, after they've been reviewed and approved, become the prototype for subsequent drawings.
Multiple prototypes to show variations: If necessary, create additional prototypes, based on the original, to depict variations.
Alternative prototypes to foster consensus: There are many ways to depict anything. Create a set of prototypes to reflect each alternative, then select the best. It's easier to make decisions by comparing working prototypes than by discussing abstract concepts.
Additional prototype uses: In addition to their intended use, prototypes can help foster learning and enhance communication. For example:
Anything requiring more than one variation is a candidate for a prototype:
Create a different prototype for each phase of the work, showing successively more detail as you complete schematics, design development, and contract documents.
Do the benefits of prototypes really outweigh the efforts required to produce them? In XPM, we value experimentation over speculation, so one way to decide is to try an experiment.
As a normal task, create a prototype, of a wall section, for example. Get team consensus on the every aspect of the prototype, then use it in practice for an iteration and evaluate its effectiveness in a retrospective.
As part of the retrospective:
Following the retrospective, create another prototype, say for a window detail, and repeat the process. Compare working with the new prototype with something similar, say a door detail. We expect the prototype process to run smoother in the second iteration. Verify, in the retrospective, that it has. Add more iterations and more prototypes as required, until you are comfortable making a go or no-go decision on using prototypes.
We create prototypes to achieve specific objectives: to foster consensus and consistency. Prototypes and the process of producing them generates additional benefits as well.
Click here for a version of this page that's more suitable for printing. After printing, click the back-arrow of your browser to return to the original format with an index alongside.
I welcome your comments and suggestions. See contact us for more information.
Copyright 2004 - 2016, Dennis V. O'Neill