Hmmm. Meeting with investors:
"Good morning folks! We've buttoned down forty acres of prime property. We don't know just what we're going to do with it. Basically we'll fill it with office buildings. From the footage available, we're guessing we'll need about $150 million. Who's in?"
The iterative process in the construction business just doesn’t sense to me. For the iterative process to work in construction I suspect that some fairly tight constraints would have to be in place.
The building is going to sit on the ground, sounds simple enough. Not so, the range of soil types is significant. Some soils expand and contract significantly more than others. Witness cracked slabs, etc. Call the Geo-technical Engineers. One can’t say Oh; let’s build a high rise instead of a mid-rise. Everything changes.
Nor can we forget the structural engineers, or mechanical, electrical and plumbing. Moreover, we must think of the heating, ventilation and air conditioning designers and contractors. Parking spots and utilities must be considered.
I don’t think many contractors would bid a job without seeing the blue prints and other specifications. Very risky, unless, the engineers and contractors can get a cost plus deal.
Developers and lenders don’t like cost overruns.
Sooner or later the Architect is going to have to freeze his design. An architect still trying to finish a rendering while the building is going up doesn’t make sense to me.
However, I may have misread you post. Correct me if my thinking has gone astray.
I find the idea of iterative development in construction a bit too risky. It does sound very appealing but unlike in the software development, the construction involves high risk factors like Human life and a lot of money.
Freezing of design would have to be done at some time. In software, it is possible to mitigate the risk and prevent the cost from flaring up. However, the same analogy doesn't apply to the construction business. I doubt in times like today, anyone would be ready to invest money into something which is just a vision and not a finality.
Please do correct me if I am wrong.
(Reply from the author:)
Many thanks to those who posted the above comments. I was hoping to provoke - and that it what has happened. But rest assured, though - you have not been punked - and you have not misread my post: iterative development really does exist in the construction industry exactly as described.
Checking back with my source in the industry, the driver for this approach often has to do with funding requirements: government stimulus funding is made available only for shovel-ready projects, where actual construction must begin by a specified date. In such cases, in order to qualify, the firm is forced by these constraints to get shovels in the ground before they have had enough time to complete the design. To make this workable, they have adopted some best practices in order to minimize the risk - such as selecting design solutions that leave the most room for flexibility in those aspects that are scheduled for specification in later iterations, and delaying decisions as long as possible. Of course, there are architectural decisions that cannot be put off till later. But this is no different from iterative software design, which also requires that certain architectural decisions be made (and even realized) in early iterations. Here, as in the construction industry, the trick is to develop best practices that minimize risk.
While the drivers for iterative development in the two industries are often similar (pressure from the sponsor for early results), one of the differences seems to be the response of the designers: enthusiasm on the part of software designers (witness the loyalty of agile fans) vs. a grin-and-bear-it attitude amongst architects in the building industry. (But of course, if any of you out there know architects who feel otherwise, please invite them to share their experiences here).
- Howard Podeswa
Try Googling the term shovel ready. There are many questions about the terms origin and actual meaning.
From what I understand there is a 90 day use-it-or-loose it clause. What I’ve been told by friends in the business, the programs that would meet the bill’s 90-day restriction are, for the most part, a mix of projects that were either shelved after being fully designed and engineered or are projects with limited scope and ambition. Moreover, it would seem that this rules out projects already underway.
It seems strange to me that someone would define a project shovel-ready when the design is not complete. Oh well our government does many thing I don't understand.
We may have a semantics problem. Some architectural firms may be composed only of architects. Others called A&E firms contain both architects and multiple engineering disciplines. These engineers make decisions that may have little if any bearing on the architects design. And we have construction firms in the mix.
Moreover, there are may large infrastructure projects that don't require the services of an architect e.g. highway resurfacing, water systems, etc.
I don't think we are on the same page yet.
Zarfman may be right about legalities surrounding 'shovel-ready' (I am certainly no expert on the construction industry) but I have been assured that design does indeed continue after construction. The response of my source after reading some of the skeptical postings above went something like this: "I can understand why people would want to believe that the buildings that they live and work in are all fully designed before construction begins - and why they would want to hold onto that fantasy - but it's just not the case."
FYI - without outing the architecture firm - I can say that the case study I was originally referring to is a project that involves the construction of campus buildings. 'Nuf said.
It's an interesting analogy, but I see (and agree with) what you're saying... The reality is that time is a priority in building these 'assets' - whether software or property. And when time is a priority, agile methodologies prevail. I would compare prefabricated homes to model driven development more aptly than iterative and agile development. In other words, why build the whole thing from scratch when you can click (hammer, integrate, what have you) and save a ton of time (and money). This makes for a building that wouldn't be 'scary' to be in... See "Blurring the Lines between Business and IT" in the community blog for more on that.
You're right in that we stand by our agile ways more so than any architect would 'admit' to their iterative design... Then again, I believe it was Darwin who said "It’s not the strongest who survive, nor the most intelligent, but the ones most adaptable to change.”