What makes this different to big-iron project management?

Recently Mike and I met with a couple of representatives from Bentley. It was interesting to talk to them, basically it boils down that Bentley has taken a hands off approach in the New Zealand market and now they have realised that does not really work, especially when they are up against very vocal ArchiCAD and Vectorworks salesmen and an industry entrenched in AutoCAD. The first reaction when I described my research was 'ProjectWise does this already'. This is in part true of any Internet-enabled, project documentation management tool such as the aforementioned Bentley ProjectWise, AutoDesk Buzzsaw, Constructw@re or Prolog (a glitzy Flash demo for is available here). However there are some significant differences between the approaches that I should go into.

Fluxiom - Digital File Management

Fluxium caught my attention the other day as browsed through the articles in my newsreader. Initially what brought me to the site was a posting by Geoffrey Grosenbach referring to what Thomas Fuchs was doing that was to sensitive to comment on publically until very recently. The Quicktime promo movie looks very promising indeed especially for someone in the photographic industry. I really like the way resources can be easily tagged and shared between other people in a manner that seems more graphical and targeted than Flickr's generic gallery system. The graphical interface was very slick and entirely web (html/css/javascript) based. Of real interest to me was the obvious role of RSS in the application. Prominent RSS feeds were in the demo but the extents  of their functionality was unfortunately not covered in the demonstration. Given the intelligence of the developers I would not be surprised if RSS functionality was extensive and well thought out.

Thinking things through

Before moving on I must say the last couple of weeks have been much better than previous ones. The once problematic client server is now behaving itself beautifully and I have even had a chance to document it all so I (or anyone else) can do the same thing all over again. Now back to more interesting things (if you do not consider SAMBA networking and Logical Volume Management boring)....

To recap this thesis aims to deal with the informal knowledge that slips between the cracks as an architectural project evolves. The process of architecture is very good at documenting the formal, whether is be in the form of a comprehensive brief or a set of working drawings. What I believe has been lost is the informal glue that holds all of these formal pieces together. Whether or not this informal glue ever existed is a matter for contention. The 1998 report by the UK Construction Task Force titled 'Rethinking Construction' sited major issues with the briefing process and the manner in which information from different strands of development failed to be applied in the final construction. The big issue here is that you have a lot of people doing many different things at the same time and most of it somehow impacts on the way others will be working or set-out to solve problems. When design or construction documentation is exchanged it forms the basis for a whole series of informal and formal discussions that in most cases remained contained within a particular group of people. At the moment, apart from sitting in on every meeting and listening to every conversation, there is no easy way of determining how the project is proceeding and what changes are taking place that my effect a particular aspect of the project.

A considerable amount of knowledge is also lost during transition phases like moving from design to construction or at the point of hand-over. At these times often documentation is paired down and tidied up to meet formal requirements (such as building handbooks). When applying a Building Life-cycle approach to this information it is only logical to consider how the informal discussions and decisions fit within this information puzzle.

In the late 1990's project intranets where targetted as a useful way of storing project pertanent information (Zarli, Richaud, Buckley. Requirements and Trends in Advanced Technologies for the Large Scale Engineering Uptake, 1998). Products like AutoDesk's Buzzsaw and CollaborIT. Given the amount of 'buzz' at the time very few projects adopted a project intranet style of approach. A primary reason for this limited uptake I believe is the potential productivity gains of using a centralised system are outweighed by the time and resources needed to setup the process. Tools like email can be easily applied within project groups as it is ubiquitous whilst more powerful groupware tools like Microsoft Exchange or Novell Groupwise could not.

A couple of weeks ago I talked with my supervisor Mike Donn about these things. In our discussions we talked about testing a pilot system out with students. The idea would be that a class would use an online information gathering system and then at the end of the process evaluate how their thoughts as recorded in the system influenced the outcome of a design produced by a second or even third person.

Mike also wondered what role the project schedule played in the system. This was an interesting angle that I had not considered. On thinking about it including the project schedule (both proposed and actual) made a lot of sense as much of the information gathered was time sensitive and related to the task at hand. The project schedule could also play a very useful role in passive data gathering. If a user's diary recorded they were working on a particular part of the building then any observations made by them at the time would more than likely be related to some aspect of that work.
He raised a number of issues related to my line of study and the potential outcomes of the research:
1. What are you trying to prove or demonstrate?
2. How will this change processes?
3. Where does Industry Foundation Classes and the Building Information Model concept sit in this picture?
4. How will this be tested and what will be tested? Obtrusiveness? Quantity of information? Quality of information?
5. What sort of numbers will you need to gauge a good response?
6. How will the relevance of any tests be proved in the real world?
7. What are people like Bentley and AutoDesk doing in this field?

I was not sure how to respond to many of those questions though I am pretty certain about a few.
I do not see Industry Foundation Classes or the Building Information Model playing much of a role in any of this higher level communication. For the most part I want to explore how RSS and the notion of intelligent blogging (blogging with a lot of passive meta-data attached) can effect the design and development process. In discussion between architects, builders and clients the applicability of complex, low-level data standards is almost zero. At this high-level text and basic images are about the lowest common denominator between the groups. When communicating this information I believe an abstracted IFC model just adds complications to what should be a simple process. Adam Bosworth (who works for Google) thinks the same way.

"As I said earlier, I remember listening many years ago to someone saying contemptuously that HTML would never succeed because it was so primitive. It succeeded, of course, precisely because it was so primitive. Today, I listen to the same people at the same companies say that XML over HTTP can never succeed because it is so primitive. Only with SOAP and SCHEMA and so on can it succeed. But the real magic in XML is that it is self-describing. The RDF guys never got this because they were looking for something that has never been delivered, namely universal truth." Adam Bosworth, ISCOC04

Pages