The PATH Projects — Episode 1
Managing Design and Construction in the Age of Immediacy—a Business Novel
The Challenge
“There’s got to be an easier way to get projects designed and built!” exclaimed Stuart to his friends in the Horse and Hounds pub. They were gathered for their ritual Friday evening get together and weekly download, a pleasurable habit started when they were attending the nearby architecture school and needed a break from the 24/7 studio environment.
Stuart (Stu to his friends) and his business partner Sara were there. They had formed their two-person architectural partnership as soon as they had become registered architects, a process that took them three years after graduation. “They call that fast these days,” Sara had often said, impatiently, “But it seemed like the longest three-year anticipation of my life!” After five years, their practice had grown to the stage where they had just hired their first employee, an intern architect named Iris, to assist with their growing project list. Currently they have three residential and commercial projects starting construction within the next couple of months, and several others in design or “on the boards”, an odd name for the construction documentation phase, since that work all now happens on computers. One of their projects in design is a school addition, an exciting new project type for their young firm. They wished they had paid more attention to the Professional Practice and Construction Administration courses they had been required to take when they were interns.
“Try explaining that to Designer Mary here!” added Martin. He sometimes called Mary a Capital-D “Designer” just to bug her. Mary and Martin had been working for several years at a medium-sized design-build company, a dozen professional and technical folks who first design, then build their own projects as well as projects for others. The company takes on whatever it can get, including similar work to Stuart and Sara, and more recently high-rise residential and healthcare projects. Even at a dozen employees, the business is large enough to require some specialization. Martin, who self-describes as a “techie kinda guy”, had recently been asked to take over the company’s project management after his predecessor, Mike, had retired following some forty years of practice. Classmate Mary had gravitated to the design side of the company and Martin was having more than a little challenge getting the company’s design work, including Mary’s, through the design process and ready for construction in the fashion intended by their documents. The firm currently has eight projects in design, another eight under construction. Martin misses Mike. He misses Mike’s project management spreadsheets even more.
“Try cleaning up someone else’s design and construction messes!” added Lynda, who works with their classmate Lawrence (Lawrence to his friends) at a larger, forty-person firm. The firm’s partners had finally noticed they were often losing money during design and almost always during the construction of every project and had just this week asked Lynda and Lawrence to examine the firm’s project management processes and make them consistently profitable. To be clear, the partners were comfortable with their practice management systems such as resource allocation, effort recording, invoicing, etc. They felt they just needed help with their project management practices.
Lynda and Lawrence’s firm also includes interior designers, landscape architects and urban planners, making for a very broad range of project types. The firm recently hired its first engineer, Edgar, to manage a new structural engineering department. At least some of the impetus to examine project management processes comes from Edgar, who complains to anyone who will listen: “No engineer would ever manage this way!” was a common refrain. It had not necessarily made him friends, but had caught the attention of the firm’s Principles, Pauline and Patrick, as well as the heads of the various divisions of the practice.
Thence, Lynda and Lawrence were now being asked to develop and implement consistent project management systems for the full range of project types, of which about one third were in design, one third in documentation and one third under construction. The projects range in size from a $1 million pocket park to a $300 million hospital addition.
Returning with a second round of drinks (the Horse and Hounds being styled as an English pub where you order food and drink at the bar and bring your own drinks to your table), Mary noted, “While I was waiting for our order, I realized that we are at a similar place in our professional and business evolution—and that’s a good thing!” She continued, “Here we all are complaining about our struggles with our project management systems (or lack of them) in our three very different firms. Perhaps we can collaborate and develop something that works for all of us.”
Lawrence interjected: “But the problems of a small firm like Stu and Sara’s are so very different from our large firm problems, and certainly different from your mid-size design-build firm issues, Mary.”
“Are they really?” Sara joined in. “Our projects are currently quite small, but with CADD, BIM, etc., a three-person firm like ours can take on a $20 million+ project, just not as many at a time as your larger firm can. I actually think we have the same issues across the board. And we’ve already been approached by one contractor who wants to collaborate on a design-build project.”
There was a brief pause while the others took this in. “So,” added Martin, “What you’re suggesting is that we all have similar challenges and might all benefit from developing project management systems useful at any scale of practice?”
“Exactly, well stated,” continued Mary. “And with our three current scales of practice and types of company we have an ideal sounding board to ensure our ideas work for any size or type of design or construction company. And six heads are better than one or two.”
“I’m up for this,” chimed in Lynda, “so let’s each come up with a scheme, compare them, do some cherry picking and voilà, problem solved!”
“If it were that easy it would have been done long ago. In fact,” added Stuart, “it has been done long ago and I think that’s the problem.”
“How so?” asked Lawrence.
“Well,” replied Stuart, “we were all mentored by practitioners who started their careers before the Internet, in fact, before email and in some cases, before fax machines.”
“Whatever,” interjected Lawrence. “How does that matter today, Stu?”
Stuart replied: “It matters because the project management systems traditionally available to architects and contractors were developed for paper communication. Fax was just electronic paper and email much the same, because our mentors insisted on printing out every email and filing them in file drawers – correct?” There was a murmur of assent.
“So here we are in 2019[1],” Stuart continued, “with an evolutionary set of practice tools little understood by any of us. We can add laptops, analog applications like Excel, even cloud-based databases and apps to the mix. Yet we each use our own messy combination of technologies in varying combinations depending upon what we are doing in design and construction today.”
“But there are comprehensive solutions,” protested Lawrence. “You know, the ones where there are modules for each design and construction function, they all “talk” to each other and to our clients, consultants and contractors, not to mention the accounting department. We use some in our firm already.”
Stuart continued, “Lawrence, I think you’ve captured one key aspect of the problem. Those “comprehensive” solutions are way too expensive for all but the largest firms to install and operate, they have a huge learning curve and, frankly, they were largely developed for construction personnel and project cost accountants. They aren’t designed the way we design buildings, in fact I would argue they’re not designed at all, except by software “architects” (I hate how they’ve stolen our title) who have little understanding of our role in construction.”
“And yet,” added Mary, “We are all in the same profession and project management is much the same regardless of project size or complexity. The more I think about it over my second beer, the less sense it makes that we can’t design a project management system for “one and all.””
Lawrence interjected: “So how do you think we should proceed, Stu?”
“I’ve been listening to the debate,” Martin interjected, “and it’s leading me away from thinking we should all caucus after “doing our homework.” I think we have to work this out together.”
“So what do you have in mind?” asked Lynda.
“It’s probably the hardest approach, but I think we need to tackle this like we’re a design team assigned to a building design project,” responded Martin. “Think about it. The best designs are often based on the strongest, simplest concepts. Yet that simplicity is actually built on our deep knowledge of the client, community, complexity and other factors that inform our design concepts. Some of that knowledge is project-specific, other knowledge is historic, for example “Here’s how we do that in Vancouver.” Some is core knowledge of how we do what we do, like submittals and field review, for example. Other knowledge is specific to the project at hand.”
“Then,” added Lawrence, “There’s that universal objection to systems, you know, “Our clients, our projects are all different from yours.”” He gestured quotation marks over his now-empty beer glass.
“And all too often any project-specific improvements and potential new knowledge about project management gets buried or lost until the next similar project, when it has to be reconstructed or reinvented at great waste of time,” added Sara.
“You’re getting ahead of yourself, Sara,” interjected Stuart, “something you frequently do!” Sara flicked a bit of beer foam at him.
“What I was getting at,” continued Stuart as he wiped the foam from his eyebrow, “was that we need to design our project management systems. We were trained as designers, yet we have largely left our design skills at the door when it comes to how we manage the design and construction of our projects. Sure, we learned some rational and not a few “mystical” design processes at school, which we may still use. But at school we actually worked on only a few project types. Now every project’s combination of client, contractor, consultant and community are usually different, not to mention every contract, schedule, construction type and complexity. But this doesn’t mean we should throw our hands up in despair and become reactive rather than leading project management.”
“This is beginning to get interesting,” mused Martin. “Since we get together every Friday evening, we have a de facto group meeting already scheduled. If we can figure out an agenda, I suppose we can aim to knock off one thing at a time until we are done?”
Now Mary chimed in: “I like this. As a Designer (everyone groaned in unison), when I put my design hat on, I start with research into the design challenge—finding out what I know (and don’t know) about all of those Cs you mentioned above, Stu. I’m talking about Clients, Contractors, Contract types, Communities, Construction types, and project Complexity. And there may be others. Since we don’t know all of the Cs, and they change from project to project, we are talking about a project management system that manages a changing group of Cs. I can work with that.”
Stuart jumped in with excitement in his voice: “So let’s all prepare for next Friday by thinking about what we currently do for project management and what are the concepts that underlie that reality. Can we agree that’s a good start?” Impromptu glasses were raised:
“Let’s have a toast to designing construction!”
Author’s Note
One of the most effective communications tools is to tell stories that convey content. That is the approach I have taken with our six main characters, and others you will meet along the way. The characters and the details are fictitious, but I have had or participated in all of their conversations, explorations and findings. I could have simply laid out my approach as a textbook, but as with most things in life, the journey is essential to appreciating the destination. So at one level this is a true story of collaboration and discovery about how to design and build an integrated system for the management of any project, product or process.
I first introduced the PATH process in my book, “An Architect’s Guide to Construction.” The PATH Projects now reaches back to explain how the PATH has evolved and improved since the second edition of my book was first published in late 2019.
There would be little point in the PATH process if the results were not simpler, more efficient, effective and profitable than what you are probably doing at the moment. I believe PATH is all of those things. In addition, PATH is scalable from the individual practitioner to the largest businesses and their projects, products and processes. I have worked as a sole practitioner, also in companies where my systems have been successfully used in projects up to $2 billion in construction value.
Convention: Large projects require complex management systems.
PATH: Simple systems can manage at any scale.
This is the first of many episodes describing the design of The PATH Projects through the eyes of our characters. All published episodes may also be viewed at https://brianpalmquist.substack.com. The technical underpinnings of PATH will be captured in the appendices to my next book, “The PATH Projects—Managing Design and Construction in the Age of Immediacy—a Business Novel.”
Brian Palmquist is an Architect, BC’s first accredited Building Envelope Professional, a Certified Professional and a LEED Accredited Professional. He is the author of the award-winning nonfiction book, “An Architect’s Guide to Construction—Enduring Ways in the Age of Immediacy.”
[1] I have chosen to place this story in 2019 so as to avoid the COVID19 details that would attend a realistic 2020 story and distract from the DC plot.