CHAPTER 23
Understanding and Using the Framework
Order and Logic: “Visual Onomatopoeia”
Think of the PDC management framework in stages, in the order and logic of construction. This thematic approach draws on familiar patterns, a “visual onomatopoeia” for designing and building, a metaphor with meaning, an allegory to construction.
- Level 0 forms the “Subsurface,” the formation of the team, their duties and contracts into which the other levels are built.
- Level 1 lays the “Foundation,” the planning and organizing activities that support the management structure.
- Level 2 builds the “Structure,” the columns and beams that frame the house: program, budget, scope, schedule, and documents.
- Level 3 roughs in the “Systems,” the human, relational aspects that power the project's management system. The things with complex moving human parts that make design management run: trust, relationships, and collaboration.
- Level 4 adds the “Enclosure,” that protects the project from stormy weather and keeps its occupants safe: issues tracking, decisions, critical thinking, coordination, and completion.
Within each of these levels, touch on their five checkpoints – a total of twenty-five things to consider, cycling through each quickly to ensure it's in place and aligned.
Too Simple? Change It
Design managers who think this management “playhouse” overly simplistic or a trope are welcome to view it under some other mental model, work intuitively, or use another method, but they should use its principles. My experience is most will develop a fluency in short order and understand its value. Means aren't important, results are. For every one of these tips, there's a way to break them, or do them in a different way.
Enter Slowly
For the timid, skeptical or reluctant, managing design doesn't have to be an instant, all-in proposition – on or off, all or nothing. More than a binary phenomenon, it allows a gradual entry into its new world. Try some of the metrics or soft skills. See if they help. Then more. You'll do best to use them all but start slowly if you must. Learn to trust it. Develop your relationship with this paradigm and migrate it across your team. The nexus of design and management can be a symbiotic coming together, not a clash. A both/and, not an either/or. I hope it is for you.
Processes: Repeatable, Shared, One Off?
Design and construction are “gig” economies. Their project-based, one-time endeavors contribute to our difficulties. Beyond language differences and first-time, unfamiliar teams, tools and processes aren't always aligned. Those without time to support shared standards but interested in improving methods use another team-limiting trick: they develop their own processes to cope.
What is a process? Nothing more than a series of steps repeated consistently and shared to ensure predictable results. Most of the ideas in this book are the result of a “process mindset” – an ability to see around corners or react after bumping into a corner. To a degree, it's doing something better next time.
Have a problem? Find a solution? Did you use a tool or process? Save it for reuse the next time the problem arises. If you can save it for others to repeat, then it's a process. One thing we all have in common: we need processes. We're better when we share them. If we can do that across company or industry lines, that's even better. But that takes time – and our project is happening now!
It doesn't take many projects for team members to find inefficiencies. “I'm only one year out of school, but I've seen that issue before. Where's my tool to fix it?” Even better: “My teammate was one step ahead of me. With better vision and planning skills, she gave me the tool before the problem happened.” Process! Sharing! Teamwork! Does it matter whether your teammate got their paycheck from within your architectural firm, the owner, or the contractor? I think not. We are a team, aren't we?
Software developers have made careers by developing and sharing “freeware.” Later, when everybody realizes how valuable it was, they get their rewards. Usually, it's by selling their solution to a bigger company expert at selling and marketing. Construction teams may not reap rewards like selling millions of software seats, but they can make their projects better by sharing.
What synergy we create when we share processes with mutual benefit! We should do more of it, but it takes desire. We've tried not sharing for centuries. It hasn't worked. That's why our industry is morphing to collaborative delivery models. As professionals, we should be skilled at sharing and efficiency. Knowing we need one another should inspire more sharing. It can't be any worse than what we're doing now, can it?
Twenty-Five Points
In total, twenty-five Project Design Control touchpoints track, manage, and adjust design. Forget one at your own peril. Combine, integrate and automate them if you can. Simplify and reduce them to their essence to focus on value-adding activities. Experienced, trusting teams don't waste time demanding or reminding one another to do them; they do them automatically.
Causes and Effects, Actions and Reactions
Project Design Controls are inextricably linked and affect one another. They are listed in levels and categories to provide a structure and language with which to manage design. When a cost estimate is done, and the building area has grown by 20,000 square feet since the last estimate, we ask why. It's certainly a Scope increase. It was reflected in the documents. If there was no commensurate Budget increase or owner-requested program change, we will face tough decisions. Why did this happen? What's the schedule impact? Where did our collaboration, communication, and change management systems break down to let this happen? Can we mitigate the effects? Like the McKinsey 7-S diagram, the connections are strong and powerful.
The Project Design Controls framework is a planning, management, and leadership matrix – a tool for oversight and leadership, strategy and intervention. Each of its intersections should be part of a continuous circuit; its nodes active parts of a dynamic grid. Without any one, the circuit is broken, failure the result.
Target versus Actual: Balance
Measure the targeted and actual values for each Project Design Control at each phase. Note variances between the two. Manage and act upon them as part of the change aspect of project controls to balance all factors. Use the three-question litmus test. (You can find it in Chapter 16, and again at the end of this chapter.)
Implicit in the idea of a matrix or circuit is continuous flow or balance. Project balance is a temporary condition, in which all project controls are present, compatible, and in equilibrium, for which anticipated changes are planned via contingencies.
Statics and Dynamics
Projects are never static. Balance is fleeting. Things are always in motion. Your design management mission (you have no choice but to accept it) is to return balance as quickly as possible to continue the flow. Forces seek to resolve themselves in the easiest way – or fail. Seconds after the pricing is presented and the team celebrates being in budget, the pendulum swings. Design begins anew. Risk rears its head. Soon after, a program change surfaces, a market shortage emerges, and prices spike. The roller coaster ride starts again. A prime consultant is fired, and a deadline is missed. This is where the conflict, and the fun, of managing design happens. Those who like it quiet and stable should change careers. They're not cut out for the tenuous balance and constant change of designing and building. That takes cross-trained, change-ready, smart, agile types.
Design Process: “The Integral”
Owners and contractors are sometimes baffled by the design team's slow or reluctant response to direction. “What's so hard?” they ask. “Just fix it and move on. We told you we cannot afford the balconies. Take them off.”
What these questioners may not understand is that building design is holistic. Change a piece, change the whole. In the cost estimate, the balcony line-item costs can be deleted, and the estimate stays whole. The spreadsheet or cost database recalculates. In the design, maybe the balconies were a critical formal element, a needed articulation in the building composition. Perhaps they fulfilled a code requirement, area of refuge, or maintenance access. Deleting the balconies may dictate revisiting the floorplan, elevations, materials, details, or core idea of the building.
Situations like this can result in the design adding something in place of the balconies, or even a wholesale reconsideration of the design concept. Why? Because designers are trained, with good reason, that the building is an integral whole, not a sandwich that can be consumed regardless of whether or not the lettuce or tomatoes are present.
When these design revisitations or reinvestigations happen, teammates should understand the necessary ripple effects on time, cost, and design process. Beyond the emotional costs such direction may have, owners and contractors should allow for the implications such a seemingly simple change may have on design.
Design Process: “Muddling”
Those who have not studied or done design cannot possibly understand the uncharted and varied nature of its processes. Some prefer a calculated approach. Others intentionally begin without a plan. Almost all are taught that a certain amount of free play time is essential. Designers Gunnar Birkerts and Frank Lloyd Wright spoke of “marinating.” That is, throw all the ingredients in the pot and let them soak for a while. These design masters would absorb the program data, then step away to let their minds work subconsciously. At some future time, having been precooked, ideas would emerge and be made explicit via drawings and models.
Others, such as my late mentor, renowned architect Terry Sargent, spoke of Charles Lindblom's famous phrase, “The Science of Muddling Through.”1 Originally used to describe the benefits of incrementalism in public policy, Sargent adapted it to describe his design process. Traveling unknown paths, circling back, and trying ideas left a circuitous trail, but yielded masterful work: more the result of exploration and persistence than planning, discipline or rigor. Whether subconscious or visible, ordered or playful, design can look like muddling, but there is a method to its madness.
FIGURE 23.1 “The Science of Muddling Through,” after T. Sargent and C. Lindblom.
Design Process: Leaps and Lights
Other phenomena underappreciated by people familiar only with “business” process, are leaps. Unlike proformas or schedules, design is characterized by alternating periods of refinement and exploring new ideas. This rapid prototyping can lead to creative discoveries or “leaps.” These “aha” or “Eureka, I've found it!” moments are serendipitous. One could play and explore for weeks and not find one. Finding them under pressure, deadlines, or time constraints can be even harder. Teams that restrict or direct design partners run the risk of missing great solutions or settling for subpar work.
Conflicting Values
Value systems and paradigms of project players range across a broad continuum. On the left reside those who see it as their mission to create from scratch, all else be damned. They value the new, innovative, and designed, over time, money, and results. Their love of process – their greatest strength – is not surprisingly their greatest weakness.
At the right end of the continuum are linear thinkers, step-by-steppers who see the world as black or white, seldom gray – like their left-leaning counterparts. The right fringe prides themselves on their ability to make decisions, get things done, work logically and decisively, and drive out uncertainty in a militaristic march to completion. The inherent, inevitable clash of these generalized types is the essence of design management. But there's another view. Political columnist George Will put it thus:
“The world can be divided into two kinds of people – those that divide the world into two kinds of people, and those that don't.”
To migrate to a more central position, let's explore the range of motivations to manage design. Yes, it's the great middle of the spectrum, the gray area between the extremes, filled with thousands of passionate centrists who share parts of both belief systems that's important. This range is what makes projects interesting and hard to manage: the fundamental, eye-opening shock that at multiple turns we're trying to do completely opposed things, with Dr. Jekyll and Mr. Hyde/Sybill-esque multiple personalities, styles, and methods in play. What fun!
On occasion, resolving these conflicts can be done simply by talking or spending time together. What a great surprise to find you were separated only by a small, correctable language barrier instead of a core belief. Maybe you both wanted desperately to resolve the issue or find a better way; you were just going about it differently. This range exists on all projects. It's the reason why no pat answer works for all situations
For designed-focused architects, the threats of time and money limitations, angry clients, or putting one's career in jeopardy aren't powerful enough to resist architecture's allure. Its pull is too compelling. Design types are bred this way – educated, trained and encultured to be design-inclined. This is the perennial challenge of all who manage design. To compound things, even when they want to manage their process, it's very breadth, complexity, and integrated nature can render their attempts futile.
Contractors, charged with making design ideas real, are usually a more linear lot: “Tell me what to do and I'll do it.” Theirs is not to set design direction, rather, they drive to it by any means necessary. But creativity can be found among contractors, engineers, and players typically cast as “set-in-their-ways” types. They've had to learn it to survive what they are given. A construction colleague, engineer and architect, David J. Miller, once said:
“Contractors have to build the whole building. Architects only have to draw part of it – the part they care about or have to draw. They leave the rest to us figure out.”
His words ring true. Projects need all the design and management creativity they can get, regardless of source. With this stereotypical framing of design management's extremes, and the great numbers of us in the middle trying to cope, Project Design Controls offer a survival system.
Design Risk
From contractors' and owners' perspectives, to manage design is to manage risk. Designers should adopt this outlook. A late, over budget, overly-innovative, or uncoordinated project drives costs skyward. Managing risk is the mission of everyone on the team, but designers haven't been schooled in risk. They're trained to induce it. Designers need to catch up in this regard. Each of the constructs offered as Project Design Controls are strategies to mitigate design risk – and yield dazzling, successful projects with happy clients and teams. Beyond the solutions offered by the Project Design Controls, the following issues are surfacing – the subjects of future books.
“The world can be divided into two kinds of people – those that divide the world into two kinds of people, and those that don't.”
– George Will
Risk Trends
Shifts
“An ecosystem, as it shifts, demands that every part find its new fit. As our industry shifts, architects and members of building teams need to find theirs – to re-design or re-imagine the new fit.”
“Designers can design all day long, and all night, yielding wild, innovative solutions with someone else's money, but they can't – or won't – do it for their own process, firm, life, or future.”
– David Ferguson, Interim Dean, College of Architecture and Planning, Ball State University, Muncie, Indiana
Why is that? Because they have no training, culture, skills, or motivation for it? No desire, responsibility or ability? By contrast, young graduates working in a construction company are immediately given responsibility to manage risk. They engage trade contractors, check scope and insurance, and procure work. Risk is trained for and controlling it is rewarded. To manage design, we all must embrace and manage risk.
To make sense of this yin-yang relationship, we need a dose of reality. I include myself in that broad condemnation. I saw it twenty years ago and did something about it. By associating myself with contractors who excel at managing risk every day, I have grown. I would like to think it's been a two-way street – that I have taught them a little about how design professionals think and work.
The industry trend is for more risk shedding for survival. But where does the risk go? If you're managing a team, beware of the following:
Delegated Design
This growing category stretches from simple delegated design (e.g. storefront glazing systems) to first-of-kind integrated solutions that tax the marketplace. (See the Wayne Wadsworth interview in Chapter 12.) Blurred responsibilities come with this tendency to delegate design responsibility.
Temporary Construction and Protection
Many structures are designed to be stable only in their final form, with the benefit of bracing and surrounding structure. Without engineer, contractor, and trade contractor agreement on a construction and erection sequence, managing design and construction of a structure can be risky – and dangerous. A sad example is the 2017 collapse of a pedestrian bridge at Florida International University, Miami, during construction. Clarify responsibility for interim structural conditions.
Warranties
The design profession has long steered clear of warranties such as the implied warranty of merchantability established by the Uniform Commercial Code that applies to products. As a service profession, design is governed instead by the common law “standard of care” of the design professional's performance. That is, what a reasonable professional practicing in a similar area would have reasonably done. As such, human error, gaps, errors, and omissions are expected in design services for customized projects. They're the norm, a far cry from product warranties that have had the benefit of years of refinement, mass production, feedback loops, and corrections. Be cognizant of the warranties attending to design and construction, and lack thereof.
Consultant Ownership
To cope with the growing number of consultants required, many architects are retracting their reach. In recent projects we've seen an attitude of architects separating from consultants rather than owning and integrating them. In these situations, engineering consultants are left on their own to coordinate or pass this duty to the contractor as means and methods. Where the architect has traditionally been contractually and spiritually responsible for design, coordination, and documentation of the entire building, a mentality of disowning consultants is replacing this responsibility.
Liability Shedding
As a defense mechanism and proof of the decline of consultant ownership, we have begun to see projects in which the architect states that he or she is responsible only for work on sheets bearing his or her professional registration and licensure seal. Buyer beware. In these cases, who then is responsible for the design, integration and coordination of the whole building including architecture, engineering, and other design disciplines? Address these areas of contract intent and responsibility in the contract and planning phase, not later.
When Does Design Management Happen?
Having learned Project Design Controls, our next challenge is when to apply them. Can we use them at the earliest possible moment, at project inception, predesign, design, and preconstruction, through construction, commissioning, and closeout?
Managing design happens throughout the project life cycle. It can start in the team assembly stage, between projects, in relationships with partners. Most often, it begins at the design or preconstruction stage. An often-missed opportunity – one we can create by scheduling it – is the planning or predesign phase, where we define and set projects up for success. We also control, and interact with design during construction and closeout, but in a different way, since design and programming should already be “complete.” To be most effective, we should understand design during all project phases.
“Steps, Actions, Tasks” to Managing Design
Take the following steps to manage a design team. Repeat them throughout the project for each Project Design Control and task.
- Step 1: Own It and Want It
Be aware of, and motivated to care about design. Having read the interviews in Part 1 and experienced these things yourself, your team should be primed to “own” design management – and want to fix it.
- Step 2: Start
Conduct a Project analysis to launch your project well. Refresh it periodically.
- Step 3: Define
Define the project. Collect and use Project Design Controls at all levels: forming, planning, structural, systems, and enclosure.
- Step 4: Document
Record all project defining aspects as PDCs. Capture them in a project definition or project controls package. Periodically update and redocument them using the Project Design Controls framework.
- Step 5: Monitor, Test, and Manage: Ask
Monitor and manage design as it advances. Do not assume that because you set something up early, that it's good for the duration. Do a litmus test on each control periodically. Ask your team at random. If any one of them doesn't know if a certain checkpoint is in place, what it's supposed to be, or if it is in line with the others, you are in trouble. Recheck things at a frequency that suits you. Continually test for balance, then act. Revisit baselines, understand and realign variances.
- Step 6: Collaborate
Use soft skills such as design understanding, communication, and trust to interact with design partners. Employ relationship building and other soft skills. Nurture these skills. Reap the benefits and synergies that activate your hard metrics.
- Step 7: Change and Adapt
Manage the change that will occur. Document all revisions and balancing actions. Be creative in your Darwinian approach to evolving your team.
Personalizing, Reporting, and Rewarding
Don't feel restricted to use the names or organization described in the PDC framework. Rename or restructure them as necessary. Automate and integrate them into your processes. Use lean techniques. Make them yours. Adapt them to your team's style.
Once you have created and used Project Design Controls, share and report them. They offer feedback and mutual benefit. Post design management metrics on the walls, on screens, and review them at weekly meetings. Make them visible, accessible, and an automatic part of your process. Use visual controls and dashboards; make them fun and easy. Help the team buy into and use them. After all, few of us really want to manage or be managed anyway, we'd rather “do.”
Be accountable. Celebrate successes. Show progress against schedule. Highlight scope capture. Study metrics. Care about managing design. If you do it right as a team, it will reward you with a project and team you'll remember for a long time: the kind of thing you got into this business for.
Aspire to that.
Try, Team, and Talk
Don't become frustrated if a tool, process, or technique is not available, working, or suited to your need. Scale it or change it. We do not have all the answers. Apply judgment and experience in team-specific ways. Seek the advice, and lessons learned of peers and supervisors. Don't neglect an important resource – talk to your design partners! Learn their issues and obstacles. Help them overcome theirs and they may help with yours.
Reasons for Failure (and Success)
Some may think this model is too complex. Five layers. Twenty-five touchpoints. More issues to consider with context. Potentially hundreds of tools and tasks. It's not. The Project Design Controls framework is a time-tested assembly of interdependent aspects, each required and dependent upon the others. Remember, the Einsteinian goal: to make it “as simple as possible, and no more.”
Those who attempt to reduce design management's essence to one or five simple things are misguided. Einstein said it best:
“For every complex problem there is a simple solution – and it's wrong.”
Those who persist at design management oversimplification probably have not designed – they are linear thinkers challenged by complexity and ambiguity. They need simple answers – now – to resolve the uncertainty! And they are wrong. When it comes to design, there is no such thing.
Problems (and Solutions)
Experienced practitioners agree, on any project, every one of the Project Design Controls can be – and has been – a reason for dysfunction. Like these:
- Forgot to exchange a BIM/VDC execution plan? Problem.
- Set up measurable structural baselines (i.e. program, budget, scope, schedule, documents) but failed to develop a trusting relationship among the team within which to use them? Problem.
- Had all controls in place but failed to set up change mechanisms to track and manage owner decisions to completion? Problem.
- Forgot to carve out a planning phase? Problem.
Conversely,
- Set up and balanced all other PDCs? Mastered the people, relationship, trust and change process? Solution!
- Planned and conducted an exhilarating project analysis work session to kick off your project? Got to know those you will work with? Shared goals and objectives? Identified constraints and opportunities? Congratulations – design managed! (For the time being.)
- Tracked pending owner decisions to enable design starting and finishing? Well done!
How to Know
Now that you understand Project Design Controls and when to apply them, how do you know they are right? Some are objective and quantifiable, others are subjective and less discernable. Design controls will serve little if you can't put them into action and know they are working. Here's how you can know.
Level 1 Controls
Level 1 controls are task-based: classic management and planning activities. You'll know when you have completed them.
- Schedule and conduct a full team, interactive, interdisciplinary project analysis work session. Share project information in advance. Get to know your team. Set Project Design Controls. Seek out a sample agenda for an interactive meeting like this. Prepare. Define all project aspects. Use the Project Design Controls to collect and classify project information. Get help from your team to gather the information. Get off to a great start. When you're done you can hold the work product in your hand, share it, and launch your team.
- Develop a project communication plan. Who talks to whom? When will you meet and with whom? How will you resolve conflict? What communication tools will you use? Write it. Share it. “Why didn't you send your file? I didn't get the email.”
- Create a digital infrastructure and VDC/BIM execution plan. In today's practice, digital tools are the means of design production. Teams that don't plan for such things do themselves a disservice. Gather the information technology team. Discuss data sharing. Develop a BIM execution plan with hardware, software, infrastructure, training, and protocols. Don't doom teams to “spaghetti” file transfer, un-interoperable data, and non-standard nomenclature.
- Develop a program of requirements if the owner doesn't have one. Analyze it together. Drive out generic goals and convert them into specific targets organized by category. Use research to inform your process rather than reinventing the wheel. Capture, share, and use your research.
Level 2 Controls
Set, record, and share tangible, measurable metrics for the five “Structural” design controls: program, budget, scope, schedule, and documents, as a baseline. Later, when they change, update them and reset the balance. You'll be able to because you have a baseline. Check and reconcile if the building is being drawn at the programmed size or has grown.
Level 3 Controls
Level 3 controls are more difficult to measure. How can you tell if you have trust? Do you really have a relationship? Who's to say whether you're collaborating or just working on the same project reluctantly? Here's a way to answer the litmus test for “softer” items. Ask questions. To test trust, ask yourself: When Joe the architect sends me a new concept, do I dread it, or look forward to it? Do I generally expect to believe and trust what he sends me? Why? Why not? Find out. Do we have a relationship? When you call her, does she take your call? Answer with a smile in her voice? Have you had coffee together? Do you know where she went to school? And vice versa. Those kinds of tests track the soft items. You'll know. Read Chuck Thomsen's interview in Chapter 2. The way they could tell if they were doing a good job was to ask their client. If the client said he liked a person, they had a good relationship. It was that simple, and still is.
Level 4 Controls
Managing the project's enclosure system is harder and riskier, but just as important. Like a human or building skin, this level keeps the weather out and uses sensory organs to perceive and regulate. Together with Level 3 controls, Level 4 controls make things happen and deploy cognitive “executive functions” to compartmentalize, decide and keep course. How can you use them? With three skills:
- Collect: The first is collecting and tracking data, by looking, capturing, gathering, and recording problems and issues on lists.
- Analyze: The second skill analyzes and prioritizes that data by importance and urgency. Which outstanding issue is most problematic or urgent? Address it first. Can we assign someone to deal with the other issues? Look at the current reality – the present (Where are we?) and project into the future. Look ahead for roadblocks and clear them. (Where are we going? Is the path clear?) Example: We still don't have owner direction on cafeteria program requirements – and we're building the building! We better do something. We have 97 outstanding issues and decisions required. The owner and design team say they're working on them but aren't keeping up. How can we help them focus and answer first things first? They can't work on them all at once.
- Synthesize: The third skill involves soft skills to help teammates clear paths to get work done. Can't make that decision? Need more information? How can we help? Set up a meeting? Do an options analysis? Get pricing? Come up with more alternatives? Bring things together.
Listing, analyzing, prioritizing, and path clearing are prized Level 4 skills. You'll know if you're doing them right if you have such tools and use them to make decisions. Decision tools get design and construction completed. Managing others and their decisions is part of managing design.
How to Coach
Design managers find themselves in the roles of budget, schedule, and constructability mentors. How you handle that role is a personal choice. Like parents, coaches, or psychologists, some coax and cajole their charges positively: “Come on, you can do it! We gave you the targets. Let us help.”
Others beat them into submission: “We've only got $150/SF to spend! The drawings were due last week. These documents are bad, uncoordinated, incomplete. We can't build from them!” Conflicted and unsupported, the design team, unable to reign in their tendencies to overdo, launch their teams into tumult once more. The miasma of “too much” returns. In choosing your management style, ask yourself which you'd prefer.
Motivating Designers
Designers are driven by the same forces as everyone else, except they value them differently. In his book Drive: The Surprising Truth about What Motivates Us (Riverhead Books, 2009), Dan Pink reveals the power of intrinsic motivation. More than being motivated by fear, money, or external pressures, the surprising truth is that most professionals are motivated by factors within themselves. Designers have this in spades. Stereotypically introverted and introspective, they thrive on synthesizing design solutions. It's who they are. Given the chance to exercise their most loved, highest aptitude skills, otherwise known as design, they anger when external forces get in the way of their self-realization, given the chance to shine.
When it comes to schedules and commitments, ask what they can do, don't tell. Having gotten their buy-in, you can give the support, structure and interim checkpoints they need. We're all better with a coach, someone to lead and push us. But what happens when we still fail? We agreed on a deadline and missed it? In those cases, reset and rethink. How can we adapt and overcome? What can we get by with? In these cases, the team fails on an interim milestone, not the entire project. Set targets, but don't be surprised when you miss a few. It's design, remember? Just think where you'd be if you hadn't set goals at all?
How to Succeed
If these examples show how not to motivate designers, can we offer any ways to do it successfully? Here are a few I've seen work well:
- Conduct an immersive, thought-provoking, aspirational kick off meeting (project analysis.)
- Share the project vision. Why is it important? What is it trying to do? Designers need to know.
- Look at comparable facilities to benchmark likes and dislikes and create shared experiences.
- Bring food and drinks. Keep the energy levels up. Have fun. Include social activities.
- Let the design team “go” in alternating sessions of convening and separating to explore design freely. Check in periodically to pull it back in.
- Review options with cost, schedule, function, aesthetic, and pro/cons. Track your progress.
- Join in. Be willing to get dirty hands. Participate in the mission rather than direct from afar.
Without sharing the “why” and making them “want to,” your design team operates with handcuffs on, as technicians, not design professionals. Shun prescriptive mandates. Let your team grow from being laborers to the value-adding, wonder-creating professionals they want to be. Then, back them with the limits, structure, support and checkpoints they need. What if you fail? Reset and adjust. You'll only have missed an interim milestone. If they continue to fail to perform, they've earned the right to be supported differently or replaced. Use these scenarios to shed light on what to do and say to motivate designers.
Inclusion
When do we include more information, diverse perspectives, and people in our decisions and work? The following synopsis draws from a 2018 presentation by inclusion expert Dr. Steve Robbins to Holder Construction Company.
Inclusion, Teams, and Tribes: Ancient and Modern Brains
By now, we know designing and building are team sports. That's good, because, as humans, our DNA has hard-wired us to belong to a group, and to connect. Why? Because it makes us better and helps us survive. But we've evolved beyond basics. Now we have two modes of functioning. Our ancient brain is for survival: it's quick and instinctive. Our modern brain is refined. It's about quality. In doing their jobs, our brains build mental models to make assessments. The first one we learn for survival is: is danger present? Is a tiger waiting nearby to eat me? Does an enemy threaten me? Are you an insider or an outsider? We use superficial cues to decide such things because we're genetically programmed to, and quickly. How you look, how you dress, your stance, what you say, and how you say it are, or could be, clues as to who you might be. Our self-serving survival reaction to new information is to default to the negative and look for variances, to ask: What's in it for me and my tribe? In design and construction, we're conditioned to build and fix. Restated as ancient skills this was: Hunt. Kill. Solve. Get rewarded: Eat. Live. Sometimes we should pause and use our modern brains. That's what good designers, builders, and design managers do.
Seeing and Thinking
Scientists tell us that 30 percent of the brain's neurons are devoted to vision and only 2 percent to hearing. What does that tell us as managers? Look! Collect and process information. Write things down to see and share them better. We can use documented information to keep our distance from potential threats and to have time to reflect, react, and see. Used with the brain, seeing is the most important sense, Together, they have one job: to keep us alive. In the Project Design Control framework, Level 4 controls are our brains, and what they're trying to keep alive are our projects (and our happiness, careers, and personal lives, indirectly.) But in doing so, we face obstacles and distractions. Like noise. Noise can hide things, particularly the signal demanding focus in our heads. It's the manager's job to sort noise from clear, intended signals, so he or she can decide between blocking new information (possible noise) or being open and accepting it.
Open or Closed?
What does being open mean? Asking questions. Being curious. It's a hallmark of creative, empathic managers and leaders. But our brains operate on an efficiency principle. We like to operate in our comfort zone – the known, not the unknown. We have a bias toward the familiar. Bias is neutral – a cognitive shortcut the brain takes to conserve energy or achieve a goal. That sets up an inherent conflict: choosing a shortcut vs. a longer route out of our comfort zones. Because our bias is toward quick decisions, we tend to simplify questions. We have many biases, such as the availability bias: we choose from the options available to us. Familiarity bias says: I just saw x, so I'm thinking about x. (See Daniel Kahneman, Thinking, Fast and Slow.) While these biases exist for good reason – to help us process vast amounts of information quickly for survival – they can make it confusing, even dissonant to distinguish from our subconscious biases. Cognitive dissonance occurs when we're “caught between,” in “information overload,” when things “don't make sense.” When that happens we don't like it, so we're motivated to get out of it fast. That leads to closed mindedness. We block the new. To change it, reframe it to explore context, new inputs, and changing conditions. In systems theory, closed systems eventually die. Those that don't adapt to changing environments go into entropy. Open systems take in new inputs and have outputs. They entertain new information and cast off some old.
What to Do?
What should we do to address these genetic traits? Listen more. Take in more information. It's the design manager's job. Look, see, then decide. What does the observational data tell you? What do you see? Collect more data. We need other perspectives to be smarter. Aristotle said, “The measure of a wise person is to entertain new ideas but not necessarily accept them.” While it always takes less energy and ego to block new information, the question is: should we? Is this the time to stand pat and risk drawing the wrong conclusion? To be more inclusive, be less certain. Be more curious.
Goals
Throughout this book the goals have been constant:
- To help our industry get better at understanding designers and design process
- To better align our different tools, languages, processes, cultures, biases, and defaults
- To expose issues and actions to effect dramatic change in our disconnected profession
- To share a theoretical model and best practices as best-case Project Design Controls, for applied, tailored use to make your projects better
While the introduction framed issues and opportunities, Part 1, “Perspectives” (the interviews), and Part 2, “Project Design Controls,” have been designed to serve these goals. I hope they've succeeded.
Self-Evaluation Quiz: Managing Design Litmus Test
As a final test before you return to your working life and apply – or forget – these principles, give yourself the “Managing Design Litmus Test,” on your project, or for your firm:
- Do you have Project Design Controls in place?
In some form? Written? Can you hand them to a colleague to use? Enforce them?
- Do they match what they're supposed to be?
How are you doing? On time? In budget? Good drawings? Strong relationships? Can you point to the approved target and actual values that have been documented?
- Are they aligned and balanced?
Do some controls restrict or block others? Maybe good management metrics are in place, but no one trusts them or using them? Perhaps great camaraderie can be seen, but no limits are in place?
Scoring
How did you do? Readers who answered yes to all three questions on all Project Design Controls on all five levels – congratulations! You're managing design. (As well as anyone can.) The rest of you better get busy. You've got work to do.