Why can't IT deliver big projects on time like construction?

Construction slips too. Three contract devices explain the gap: a paid design phase, signed change orders with measurement, and one named engineer of record.

Before the first member goes up, the structure already has stamped drawings and a signature behind it

Construction slips too. It slips badly, and anyone who has signed off on steel erection knows the gap between the schedule that was sold and the day inspection releases a section. What makes the question feel fair is paperwork. When a build slips, there is a signed document saying what changed, who asked for it and what the change costs. In software, the same slip shows up in a status meeting under the word surprise.

A 2012 question on Software Engineering Stack Exchange has been viewed 123,583 times, holds a score of 543 and collected 31 answers: why can't the IT industry deliver large, faultless projects quickly as other industries do. Most of the answers talk about estimation, essential complexity and changing requirements. All true, and none of it is what separates the two industries. Three contract devices do: a design package approved and paid for before execution starts, a signed change order with measurement every time scope moves, and an engineer of record, a human name, standing behind the structure.

The site slips too, and the gap shows up in this month's pay application

On site, a scope change comes with a price, a revised date and somebody signing for it

On a cement plant erection, a section budgeted at nine days took closer to three weeks because a member arrived with the bolt holes off position and the crane sat idle waiting. Rain, a late supplier, weld rework. None of that is unique to software.

The difference is that the slip became a line in that month's pay application. The owner saw tonnage erected, saw what did not go up, and saw why, long before the whole schedule blew. By the end of the contract nobody had to explain the delay, because the explanation had been assembled in pieces, each one signed.

Your software project runs the other way. Status stays green until the month of the promised date, the activity chart keeps climbing, and the hard conversation happens once, late, when there is no decision left to make. That is why a build that ran about 20% long reads as normal and software that ran the same 20% long reads as failure. One was measured along the way, the other showed up finished at the end. Worth checking whether your tracking measures erected work or just a chart with cards moving on it.

On site, the design comes first and it costs money

Before the first machine rolls onto the lot there are stamped drawings, disciplines coordinated against each other, and a permit issued. The drawing specifies each member, the hole pattern, the weld. The erector does not decide in the designer's place, he installs what has already been decided and checked.

That design package is a line in the budget, not a freebie. Nobody on site calls it bureaucracy.

In software the equivalent phase is discovery plus architecture plus whatever the team has to open up before it can estimate anything. Almost every buyer wants that folded into the proposal, unpriced, settled in a one hour call. The sentence that holds the arrangement together is always the same: we'll figure it out as we go. Figuring it out as you go, on a job site, has a different name, and it involves demolishing finished wall.

When I ran a construction equipment rental startup I was the buyer in this story. I hired developers without being able to judge a date and without fully understanding what they told me. The sprint ended without the delivery, and I blamed the team. What was missing was a design, and I did not know enough to miss it.

Scope changes with measurement, a number and a signature

In software the same change slips into the sprint as a tweak and never reaches the contract

On site the owner changes his mind constantly. He moves the warehouse layout after the foundation is poured, adds a crane bay, raises the clear height. There is a path for that, and it is deliberately tedious: change request, price, revised date, signature. Only then does the crew touch steel.

The change order protects both sides. It protects the owner because the price of the change lands before the work does, and it protects the contractor because the date moves along with the scope.

I have lived the other extreme. A client bought a course platform and, mid project, started demanding a streaming experience, holding invoices as leverage. Every meeting brought a new screen, always presented as a small tweak. It ended in termination, with delivered work unpaid. Months later he came back, heard a fair price, called it absurd and went elsewhere. That project died there. I tell it for the lesson: the defect was in the contract we signed, not in the people in the room.

In software a change order fits in two lines of email. Every approved change becomes a work order with an effort range, the schedule impact and a written acceptance before it enters the sprint. Without that, scope change becomes a favor, and favors have no date.

"But software requirements change constantly, it's different"

That is the honest objection, and it misses the target. Construction changes too. What construction does not do is pretend the change will not happen: the mechanism for it is written into the contract from day one, with pricing rules and measurement criteria.

Software contracts do the opposite. They freeze a scope nobody can freeze, then treat every alteration as a hallway conversation. The change happens anyway, just without a price and without a new date.

The change is coming either way. The question is whether it passes through a number and a date before it enters the sprint, or slides in sideways as a tweak. And the product does not stop moving on handover day: it keeps living after the sign-off, and the contract has to say who pays for that next month.

Somebody's name is on the structure

I was the engineer of record for the steel structures at the Interlagos racetrack in São Paulo. That was not a title, it was personal liability on file: if the structure fails, there is a name, and the name is mine. It changes what you approve, what you refuse, and the moment you stop the crew.

In your software contract the signature belongs to a company. The engineer who designed the solution at kickoff may not be in your repository by month four, and the contract allows it. Nobody is acting in bad faith, there is simply no name tied to the structure.

You can fix that without inventing a licensing board: write into the contract who owns the architecture, who reviews what reaches production, and what happens when that person leaves the account. If the vendor stalls on that clause, you learned a lot in fifteen minutes. A short audit of the vendor usually surfaces the rest.

The villain is fixed price with elastic scope

Put the three together and one culprit is left standing, and it is the contracting model. Fixed price pays the vendor for finishing. Elastic scope gives the buyer the right to push new ideas in without touching the number. On the same page, those two create a perfect incentive to ship a pretty shell: tests that run without a single expect, a health endpoint returning 200 behind a colorful dashboard fed by nothing. Complete from outside. Nothing under the structure.

The vendor cuts what the buyer cannot evaluate. That is the good case, with no bad intent involved.

Three clauses that change the game on your next proposal:

• Pay for the design phase separately from build, with a written deliverable, so the estimate comes from something a human actually opened.
• Agree that every scope change produces a work order with an effort range and a revised date, accepted in writing before it enters the sprint.
• Put a person's name on technical responsibility and define what happens to the project when that person rolls off.

None of those mentions technology, and none depends on the hourly rate. The rate is the only line both proposals write the same way, which is exactly why it becomes the wrong basis for a decision. If you want the market range before you compare, it sits in our rate breakdown.

Where the comparison breaks

Construction has codes, inspectors, permits and a board that can pull a license. Software has none of that, and will not have it any time soon. Anyone promising you job site discipline for a digital product is selling more than they can deliver.

There is a second limit, and it is an honest one: for a new product still hunting for customers, fixed scope is genuinely bad. There the answer is short cycles with frequent measurement, not thick paperwork. I am not sure these clauses pay for themselves in a three person team before first revenue, because the process may cost more than the rework it prevents.

For everyone else, run the count today. Take the last project that blew its date, count how many times the scope moved, and count how many documents anyone signed because of those moves. If the second number is zero, the delay was not a surprise. It was the deal.