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.

I 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