An excellent product at a low cost is every consumer’s dream; and for most owners ready to create a program for their upcoming construction project, the desire is often the same. Packaging a world-class design firm together with the most cost competitive construction contractors sounds like the perfect recipe for a successful project. So, why does this not always produce the outcome that owners, architects, engineers, and contractors often desire? Oftentimes, it has a lot to do with the contracting methods that are used and how they encourage or discourage collaboration. Moreover, the risks that each of the different team players will be asked to take on are not always correctly identified.
The idea of ‘design-assist’ brings with it an unclear definition of roles, responsibilities, and expectations that can leave a project in jeopardy of not achieving positive outcomes. Ask several industry professionals to define this and each answer will likely be different. Who is assisting who? To what extent are the different team members obligated to help another project participant? Design-assist has a few core concepts that many may agree on, but the fringes of responsibility often fade, missing a universal definition. Without clear roles, the risk of failing in commitments and obligations, and ultimately taking on risks that were not planned for, increases.
Most owners do not usually initiate the design-assist process. It has its roots in a more traditional design-bid-build delivery method, but somewhere along the way a variable gets introduced that changes the plan. These variables are usually the cost of work or a compressed construction schedule. Due to design-assist not being intentional, the result is a hybrid of blended roles that are cobbled together in an attempt to salvage a project for an owner. Architects are pushed to work with contractors in order to pull together a design that meets a specific price point—often, while still ensuring the owner’s initial vision is not sacrificed.
Next, general and specialty contractors are introduced into the process and are constantly poking holes in the program or design solution in an effort to reduce cost or improve the schedule. At the end of the day, what is left is a list of good ideas and a potential pathway to make the project work. This is where the risks transfer and the implementation of programmatic changes typically fall apart. It is rare that all of these decisions can be implemented as they were originally suggested; nonetheless, the team’s commitment to a price and schedule is locked in and each partner now owns the risk.
Wherever a project team member sits in the building lifecycle, there is a chance that they may be unclear as to how to implement the assistance they committed to as part of the design-assist contract. Everyone is motivated differently and goals are often misaligned with the desired outcome due to some partners taking their responsibility more seriously than others. It is unfortunate, but most of the time this will not be identified until much later in the project.
Do you think there is a risk in utilizing design-assist methods? Let us know in the comments!
To learn how to achieving a successful project outcome with a design-assist model read part two of this article, here.
Show Comments (0)