Build the world like you build software

Build the world like you build software

Back in the days of waterfall project management in software, the complete design of a system was completed before a single line of code was written or an end user even understood what the product looked like, not to mention how it would function. By the time the product was visible enough for engineers, programmers and end users to view it, there were often challenges and required alterations brought to light.

Sure, some of these alterations affected only downstream development, but mostly the project took a step backwards and previously written product had to be replaced entirely.

My architect, engineer, and construction (AEC) friends, does this sound familiar?

Has selection of means and methods ever been at odds with the design intent?

Has the owner ever walked a project and stated those horrible words. “That isn’t at all what I was picturing”?

Even if the design was absolutely perfect, even if all functionalities were created using the most efficient programming processes, even if the design met every requirement the end user expressed at the beginning of the process, our world does not stand still. The end user’s requirements, even the end user’s company can shift between project onset and project completion. There was no guarantee that what the end user desired at the beginning of this long process would still be desired once they actually put it into operation.

How many buildings have we built that are out-of-date by the time they are complete?

The waterfall method is intrinsically combative, rigid, inefficient, and counter-intuitive to providing true synergistic effectiveness and value to the end user.

Is there a better way?

What if we took a hint from our software development friends and developed our built world as they have been developing technology for decades?

The two prominent philosophies in modern day software development are lean and agile. Hacker Chick, Abby Fichtner gives a fantastic explanation and differentiation of the two here. https://hackerchick.com/agile-vs-lean-yeah-yeah-whats-the-difference/

Lean shouldn’t sound too foreign to us construction folk. As a version of Lean Manufacturing, Lean Construction has gained prominence in construction in recent decades. That being said, how often does Lean Construction incorporate Lean Design? How often do we get the entire project team engaged to best eliminate waste and optimize the whole system? The “system” referring to the process from requirements gathering to operations and maintenance of a built environment.

Agile, on the other hand, is seldom brought up in construction.

The Agile Manifesto for Software Development lists Agile’s values as:

  • Individuals and interactions over processes and tools
  • Software (Product) over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

You can read more here: http://agilemanifesto.org/

I am sure many of you audibly scoffed at the notion of applying some of these values to the way we deliver the built world. I would argue that the power behind these values are the same reasons behind the proliferation of alternative project delivery methods such as design build and integrated project deliveries.

To some, this is nonsense. To others, this is common sense.

“Alright, hold up Chris. All software companies have to do is type. All they have to do is put people in an office who hit the correct buttons on a keyboard and VOILA! SOFTWARE!” Having people who push the correct buttons and know what goes where, when, is what our two industries share. The aspect that we don’t share? Uncontrolled operating conditions, suppliers of materials, management of equipment, and most difficult of all: The fact that there are dozens of different names on the hard hats of these labor forces and the contracts that come with that reality.

Most will argue that the world of construction cannot be tamed due to these variables. We at Grit argue that it must, exactly because of them.

The not-so-surpising irony of building as a software company builds is that we will require a software that allows us to do so.