I run into many people and businesses that live with design-build as the basis of all of their projects. And it’s not just about construction, but also IT, software, and systems projects. However, I’ve come to realize that it can mean different things to different people. In construction, design-build is based on the old master builder concept where one person was responsible for a project from design to building. Until relatively recently when this design-build concept regained popularity, these two activities, design and building had been segregated and were performed by two distinct entities sequentially. Once the design was complete the project moved to a completely separate group to oversee the construction.

The return to the master builder model brings a unified team to the project that is intimately involved in the project from start to finish. This collaborative approach enables the team to work together to determine the best design, materials, and construction methods to lower costs and maximize the value for the owner. It’s not meant to cut corners on planning and design, but rather, when appropriate, undertake certain activities concurrently, streamlining the process.

Too often in the world of IT, software, and systems projects, design-build is misapplied to mean designing the deliverable while building it. Rather than planning, designing, and building in a logical and thoughtful order, the so-called plan is to figure it out as they go, invent it on the fly, be flexible and meet the needs without all that “formality stuff.” The project is under the guidance of a so-called “master builder” who has the vision and skills to hold the project together, yet lacks a critical ingredient: the plan.

There may be a few instances when this design on the fly process works, such as spare time projects – the work that happens in most businesses when there are gaps in between pressing business – or diversionary work that helps with team spirit. But these are certainly the minority of projects.

Sometimes I see design-build in use because the work appears to be too hard to plan. This is often the case with research – or because of the naïveté of an owner.

However, in these and in most instances, this misapplied approach to design-build is the reason many things go wrong that affect the project and, ultimately, the business that has contracted the work. Interestingly, although companies think they are cutting the up front costs incurred in a define-and-plan approach, they commonly end up with serious cost control problems. Too often, I’ve seen small businesses discover – only after having spent a lot of money – that the amount required to finish is just not affordable. It’s not hard to see how the lack of a plan and budget, can put a company in this predicament.

True design-build on the other hand is attractive for a number of reasons: there is a unified team working on the project from beginning to end so responsibility is shared and finger-pointing is minimized, the process is streamlined, budgets are more accurate, and money is saved. Take my acquaintance who calls his construction business design-build. They will design a building, get a client signoff, and then build it. No surprises, plenty of checkpoints, and risk mitigation throughout. Very successful.

Yet if with your keen sense of what’s needed, you feel that design on the fly works, go for it. If, on the other hand, you’re convinced that the best way to succeed is with a true design-build model, get clear on what it means, what you need to do, who the clients are, and when your project has to be delivered. Get ready by building a balanced team, agreeing on leadership, and sketching a high level plan. Get started by building a team, articulating clear roles, and launch the project.

Home | Privacy