In an ideal world construction projects would be built: on time, within budget, and without unexpected events. Never happens. Why? Three reasons: (#1) mistakes and incompetence, (#2) poor coordination (and communication), and (#3) unexpected events.

We can improve # 2. The premise: make it cheap/easy to communicate delay notices, variations (i.e. potential bottle necks) and cost blow-outs in construction projects. This line of communication must originate with a sub-contractor, who in turn bubbles it up to their contractor, till the communication bubbles to the top, ending with the developer or builder. I call this communication “upstreaming”. This article seeks to unpack these concepts. I will elaborate on why this has been typically very difficult, without systematic record keeping.

First, it is helpful to identify the key players in a construction project, before outlining typical problems, and possible solutions. I beg the patience of the reader: we are only gonna focus on negatives - and most of these problems stem from human behaviour and their incentive structures.

Key Players in a Construction Project

Construction projects involve disparate parties, with often conflicting interests:

• Occupants want dwellings don’t leak etc., with good fittings. If the buyer is not the occupant, then the reverse usually applies: cheap (usually flimsy) fittings are preferred.

• The bank will want safety, and interest to be paid on time.

• Developers / Builders: wanna quickly build and get out. Poor coordination/ineptitude/communication starts here. It is further compounded by unfavourable payment terms with chief external designers: engineers and architects, who in turn suffer the same malaises. Builders set the scope of works for contractors, and set procurement terms.

• Contractors want to be paid, on time, with the least amount of work. If margins are slim, they may try to cut corners (if they can get away with it). A good project manager will be on top of this. But most project managers do not have the capacity to check what all the trades are doing all the time. Sloppy workmanship, done in order to save costs, are de rigeuer. An added complication is the business model of the industry: to rip people off. The consequence: costs are borne by others, or are passed on till they are borne by the party least able to resist it. In my experience, most tradies are unsophisticated: they care little for corporate veils, insolvent trading, and the importance of cash flow - except when they’re running out of it. Ask these hard working, hard drinking blue collar guys to sit down and read some building codes and these guys will plainly tell you to go and get….

• Engineers will typically over-engineer a building, wanting absolution in case of disaster. This does not come for free: extra steel/reo/columns has a cost and requires time/coordination.

• Architects typically want to make “a big statement”, with fancy designs, for notoriety, praise etc.

• The interests of engineers and architects are not necessarily aligned: engineers may prefer plainer, less risky designs, while architects might insist on more difficult and grandiose ones.

• Government and Regulation: a builder goes broke, a building collapses, a fire rages through killing a few kids. The politicians play politics. The only solution is to burden the construction industry with more regulation, more red tape, and more certification, more insurance, more paperwork: Australian standards, building codes, legislation etc. - they amount to 10,000s of pages of reading. I guarantee you: nobody is reading them. Nobody. But it does satisfy the politicians and the public. In effect, they add costs to the industry. And anyone who attempts to read and understand them all, will be placed at a massive a competitive disadvantage to those who do not. Administering these training regimes is not cheap. And nobody wants to do it.

• Unions: they want their members protected: job security, and decent benefits. If you don’t cooperate with them: watch out!

• All players want to maximize profit. Nobody wants to be sued. Everyone’s passing risk as far down the line as they can. But remember, in the end, someone must bear them.

The raison d’etre for many companies to work on a single construction project? We could have all parties as staff, in-house to a developer. Why have so many parties, and so many companies? Three reasons: (i) legal and risk mitigation, and (ii) it’s expensive keeping everyone on staff, (iii) quality control. If you’re a developer, and if one of your engineers makes a mistake: you have no recourse. But if an external engineer makes a mistake: then you have more scope to recover from them. Secondly, if everyone is on staff, then you will need to develop pipelines to keep them occupied - which can become expensive. If they’re external contractors, you needn’t worry about coming up with the cash to pay them, even when you have down time. Lastly: quality. If you’re a contractor, and if you make a few mistakes: you’re not going to get paid. If you’re on staff, you can probably survive.

The interplay is complex.

The key point to understand, is that interests are disparate, and costs can be imposed by one party on another. Let’s unpack this point with an example:

Current Problem: Communication and Costs are Hidden

Fabricators might bid for a project, given a particular set of engineering drawings. Steel detailers do the same. Typically after winning the job, defects in the engineering/architectural drawings are discovered. Drawings are rarely perfect.

Then ensures a costly and time consuming process of devising solutions. Emails fly back and forth. There are many issues to be resolved, 100s of drawings, with 5-6 revisions of those drawings. (Email is a really poor solution in construction projects: we have no way of knowing whether something was actioned or not, we have no way of versioning documents, and no easy way of organising or finding things - but that’s a separate problem). In addition, engineers and architects are not given to responding quickly, nor agreeing: they have no interest to do so. Flawed designs are proposed, and the cycle repeats. The project slowly gets delayed.

But who gets the blame? Typically the sub-contractor: because it is patently obvious to everyone that the steel hasn’t been erected. But often, on digging deeper (through 1000s of emails), one typically sees:

(1) Delays in asking questions. (2) Delays in answering and resolving those questions. (3) And the most insidious of all: cost blow-outs: designers may propose solutions which impose costs/delays on others, but not themselves.

Typically, an engineer might impose a solution on the steel detailer, which massively increases the detailer’s work load. How are these costs to be passed on?

A system is required to cache/record information

This entails a burdensome documentation obligation. Variation proposals must be: justified with clear proof. Gathering the proof, and presenting it in a form that can readily be assented is hard work. It is typically the domain of lawyers. Then they must be sent (often times it is created but not sent) and then approved, and tracked. Approvals are not easily forthcoming. Nobody wants to pay. And nobody wants to say they “approved”. But they want the variation work done. Builders are stuck in a quandary. If they don’t approve quickly, then a delay results. And they know it. Most imply the variation will be approved, without explicitly stating so. If you’re silly enough to do the variation work, they resort to the cry: “I never approved”, while still demanding the drawings with those variation amendments. If you wait for the approval, then they will argue: “why did you delay the work?”. The variation is in a state of quantum entanglement: it is approved and rejected at the same time, while being neither. I call it: “Schrodinger’s variation”. How are you meant to manage all of this in an organisation with many employees, given time pressures, with multiple projects on the go? Did Freddie send a variation request? Was the request approved?

• Email will not do: variation requests need to be tracked across the organisation, and chased down if unapproved. Coordination needs to occur with a book keeper. Management will need to pry into things to ensure things are being pushed along. How can this occur with email?

• Often, the variation documentation goes wanting. Why should your employee bother with the tedium of variation documentation? He’s busy completing the job, so he doesn’t get blamed by his employer for late delivery. And whether the variation documentation is produced or not doesn’t directly affect his pay. The cost is considerable to the employer though: the employer cannot raise an invoice for the variation and these costs can never be passed up the line. The builder never hears about these costs, or delays. Unless you have a system, there is no easy way of tracking and documenting those variations “up the line”. The costs are hidden.

• A further problem: a small variation to a detailers, which takes 2 minutes, might cost 1000s of dollars to a fabricator. For example: the addition of a few beams. It’s easy to click a few buttons to add a few beams, but much harder to order and erect those beams. The fabricator is typically not across the project, and will never know about those extra beams, but for the detailer bringing it to his attention with an invoice. Most detailers are not sufficiently incentivised to do so. In short, costs are typically absorbed by contractors up the line, and invoices and delay notices are not raised. Consequently, the developer never finds out.

And all of a sudden, a project gets delayed: that’s a big problem.

Caching of information, as it happens, is critical. Why? It’s very difficult to dig through emails, after a project has been completed, to put together material to justify your variations or delay notices. It’s impossible. There are thousands of emails to parse. To do so might take many weeks. Nobody has the time. Not even a team of highly paid lawyers.

But if you cache the documentation along the way: with links to attachments - it’s a piece of cake to justify everything after the job’s done. If the matter should ever get to court, it makes it very easy for your lawyers to argue, and it acts as an insurance policy against a lengthy court battle: because the documentation will make it self-evident who will win or lose. Lawyers can put together a brief in less than a few hours, when it would otherwise take months. Favourable settlements will result.

This information cache can be aggregated by many people in an organisation, with records sequestered by project, making it super easy to find and/or share. There in lies the benefit of an app: email is a primitive tool.

The Solution to the Delay and Cost Problem

This is why I developed the “the Quote app” - because it allows for variations to easily flow up the chain. Now, when the engineer/architect makes a change, there will be a cost attached with that design: they can no longer operate with impunity and ask others to absorb that cost. And when there are invoices involved, this affords plenty of opportunity for project managers to address bottle necks, and to force engineers/architects to devise solutions that are cheaper and faster.

Notices of Delay can be Passed Up Too

In addition to passing variations up the line, notices of delays can also be passed up too. Builders typically do not get clear notifications of potential delays. All detailers should create notices of delays, the second they become aware of them.

Contractors have every incentive to provide these notices: they serve as an insurance policy for them. If they are accused of delaying a project, or threatened with liquidated damages, they will not have to spend week ploughing through emails to fight these allegations. And the best part? No contractor need start from scratch with the documentation associated with a potential delay: they can simply add to the documentation which is “streamed” up to them. For example, a fabricator can build upon the variation request of a steel detailer - he can add his costs, on top of the detailer’s, and pass that on. The fabricator will not be as intimately involved on a project as a steel detailer. The fabricator will never be able to put that documentation together, because he is not even aware of the problem. The problem is hidden. He can now do so. Consequently, variations and notices of delay, with justifications, can easily flow up the chain in a very timely and seamless manner. This concept, if applied, can revolutionise the building and construction industry: developers can address bottle necks. And contractors can pass on costs. Projects can hopefully be delivered more efficiently as a result.

The only detriment will be for designers proposing bad solutions: there’s no where for them to hide now. The invoices given to builders will make this patently clear. The following diagram might illustrate the general principle:

Bad designs, and bad designers are the bane of this industry. Attributing costs will push them out, or force them to mend their ways. And the solution which makes it all possible: the Quote app.

What does this mean?

(1) Payments Intregrated Through the Chain via the App

• It means that you have all the incentives structures in place for people to quickly and accurately communicate costs (and get paid) up and down the line. Payments can be made seamless. Legal protection applied where none are forth-coming. And the holy-grail of holy grails: “pay when I get paid” is now here - so that big developers ensure that subcontractors have the liquidity to operate, the second they disperse payments. It can all happen down the line.

(2) Delays Communicated Through the Chain

A project manager at the top can see, in fine grain nuance, where the hold-ups in the project occur. And he can incentivise, or fix, or demand solutions accordingly. Hopefully, this would ameliorate billion dollar cost blow-outs.

I think it eminently possible. I just have to prove the concept. And build the payment systems. And handle all the nuances and objections which occur along the way.

Summary

The Quote app solves the following problems:

• Caching information (easy to search / find).
• Protects you from legal disputes (due to precision documents being cached along the way)
• Better coordination (easy to follow up / track in large organisations, across a network of suppliers).
• Passing delay notices & variations up the chain (easy to build requests, based on the documentation work done by downstream contractors).
• Gets you paid.