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
