The Modern Analyst Blog for Business Analysts

Howard Podeswa
Howard Podeswa

Agile Development: What we can learn from property developers – or what they’ve learned from us

Agile Development: What we can learn from property developers – or what they’ve learned from us

Readers of this blog (both of you; I know you’re out there!) may have gathered by now that I’m a big fan of mixing it up: art/science/business/philosophy/politics/psychology and anything else that can be thrown into the pot. I believe that the more you let your worlds bleed into each other, the more opportunity there is to benefit from the cross-pollination of ideas.

What we can learn from property developers – or what they’ve learned from usI had a vivid example of this recently. I was having dinner with a friend of mine – who also happens to be a gifted architect and designer. We were talking about a project he is working on where he is responsible for handling design aspects of a large commercial property development. One of the things that struck him as particularly challenging on this project was the fact that the buildings were literally going up as the design was being worked on. This meant that many different activities were going on at the same time. Instead of going through a single pass of upfront design followed by construction, they were developing this project in a set of short cycles; each time through they pinned down the requirements for an aspect or area of the complex, did just enough design to get it built and then constructed it on the ground.

Sound familiar? What he was describing was iterative-incremental development – an approach to managing software projects that is the basis of agile approaches, IBM’s RUP (Rational Unified Process) and Microsoft’s MSF.

It’s interesting to note that the classic (i.e. older) approach to managing software projects was based on the how the construction industry managed its projects at that time: a single cycle of requirements analysis, design, testing and construction, known in the IT world as the ‘waterfall’ approach. That got me wondering whether the influence is now flowing on the opposite direction. Are managers of construction projects now learning a trick or two from their counterparts in the IT world?

These are not rhetorical questions. I’m expecting an answer – or at least looking forward to your comments, and maybe even instigating a little cross-breeding for those of you who have friends in the design or construction industry. To wit: Does anybody out there know when iterative development began to take off in the construction industry? For those of you with friends in the design, construction, or property development sectors: Do you know of any examples of iterative construction projects and, if so, what are the challenges and lessons learned?

By the way, I asked these questions of my friend, the architect, in order to see if there were any ‘lessons learned’ that could be applied to the IT world. He told me that the biggest challenge for the design shop, was to avoid making a decision they would later come to regret. This was a real risk, because they were designing while some of the requirements were still unknown. It’s a challenge BAs on iterative projects should all be able to appreciate. Asked how they were mitigating this risk, he summarized their approach as follows:

  • Don’t commit to something today that you can put off till tomorrow. In other words, if you can delay a decision without delaying the project, put the decision off. But if you have to make a decision, then …
  • Choose the option that least constrains the future. That way you minimize the impact of making a wrong decision.

Here’s an example of how the second principle works in his industry: The designers were required to put in a staircase before they even knew how the rooms on that floor were going to be used and what their individual sizes and layout would need to be. So the designers chose a staircase position that left them with the most flexibility for laying out the rooms later. In this case it meant rejecting a central staircase, because it would rule out options for room layouts more than a staircase off to one side.

You can see how these lessons can be immediately applied to IT projects. As to which sector originated the idea of iterative development, one thing is certain: Wherever the iterative idea started, everyone who is doing it – regardless of the sector they’re in – has a lot to learn from each other. Let’s get the conversation started.

Howard Podeswa, author of UML for the IT Business Analyst 

This entry was published on Dec 13, 2009 / Howard Podeswa. Posted in SDLC, Process, and Methodologies, Agile Methods, Rational Unified Process (RUP). Bookmark the Permalink or E-mail it to a friend.
Like this article:
  1 members liked this article

Related Articles

COMMENTS

Marc Thibault posted on Tuesday, January 12, 2010 7:37 PM
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?"

zarfman posted on Friday, January 22, 2010 1:24 AM
Hi:

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.

Regards,

Zarfman
Divya posted on Thursday, January 28, 2010 6:15 PM
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.

Cheers.
Howard Podeswa posted on Sunday, February 14, 2010 8:41 PM
(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

zarfman posted on Monday, February 15, 2010 5:48 PM
Greetings:

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.

Regards,

zarfman
Howard Podeswa posted on Friday, March 26, 2010 4:50 PM
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.
- H
Mendix.com posted on Wednesday, July 28, 2010 11:29 AM
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.”
Mayank posted on Wednesday, November 5, 2014 11:33 PM
A nice approach towards project development. I like specifically the approach taken for risk mitigation - which is to delay the decision, if it possible or pick the decision which brings least constraints in the future. Great learning...
Only registered users may post comments.


Blog Guidelines

» What is the Modern Analyst Blog and what are the Benefits of Contributing?

» Review our Blog Post Guidelines.

» I am looking for the original Modern Analyst blog posts.



ModernAnalyst.com LinkedIn Group ModernAnalyst.com on LinkedIn: connect with fellow business analysts in order to develop and expand your professional network.
Learn More...

Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC