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.

Firstly all the products just mentioned require a significant degree of buy-in both in terms of financial outlay and training. All of the products are vast in their functionality and are primarily targeted at management of large, long-term construction projects where all participants (architects, contractors and engineers) have extensive and long-term relationships. These long-term relationships provide justification for the considerable learning curve involved in implementing the products. A few years ago I saw I demo of a piece of New Zealand developed design/construction management software for a large spec-housing company that satisfied the same economy of scale argument as these management tools. However there is a large untapped market of very short-term, small scale architectural projects that could benefit from online collaboration but cannot justify the costs of implementing a large management system. This is the target market for my research and ultimately this is the ideal Internet experience, allowing participants to converse directly with one and other unrestrained by the forces of centralised management. The Cluetrain Manifesto touches on this concept from an advertising and marketing perspective but it has also been termed 'talking to an audience of one'.

All the of the products use a centralised management approach requiring a dedicated server or hosted service which in turn have their own ongoing maintenance and support costs. The emphasis of my research is identifying a means of achieving distributed project knowledge sharing to remove the presence of a centralised server and re-utilise existing office resources such as their email and web-hosting services. Most if not all offices now have access to an email service and probably a web-host as well. Coupled with this is the wide variety of online mail services offered with huge storage capacities and very little cost (GMail, Runbox, Yahoo for example). Yet these centralized tools do not take advantage of these services, in fact most of these programs began development in the late 90's well before these services even existed. Buying into online collaboration should not involve buying into an expensive server or service, the most expensive purchase should be the bandwidth and even over time the price of this is going down (though there are some concerns related to how the Net will evolve in the future).

These document management products also emphasize the word management. To a certain extent all these products are aimed at top-tier managers with the end-users (builders, CAD monkeys and client) coming in a very distant second place. Even the reasons promoted for implementing these systems revolve around how useful these tools are for management to keep their employees up to date and keep a watch on how their projects are progressing. I personally think I am aiming for the 'Google Architect' of AEC document management arena; who's emphasis is on ease of use and flexibility for the end-user to both interact with and understand how their work fits in to the big picture.

Just like Google there should be zero buy-in and buy-out in the system for users. Google does not make end-users pay money to search or limit the search scope based on economic needs (though sometimes political demands have forced some changes). However most of the AEC project management products emphasize the creation of a brand silo that tightly integrates with and rewards the use of company supported products. Consequently migration between product silos is made very difficult as the document management meta-data is proprietary and stored within databases housed on the server or on the hosting provider. My work is looking to find a way of adding value to existing data (through the creation of meta-data enriched RSS feeds) whilst preserving the independence of the underlying information from a corporate silo. Through sticking to industry standard email (SMTP,POP3), web (HTML) and RSS technologies the mechanisms put in place would in no way lock users into to any particular brand.

Rather than championing the use of a central server my work is trying to distribute tasks and re-utilise the existing email and web hosting services already present within the infrastructure of an architecture practice. Through reusing these resources and the spare CPU cycles of increasingly powerful desktops the requirement for a dedicated and costly server should no longer be required unless in situations where it economically makes sense. This will significantly reduce buy-in and heighten adoption vertically throughout the industry from small two person practices right through to large organisations as decisions can be made without significant outlay of time or money. Plus following this strategy the emphasis would be on a bottom-up adoption model rather than a top-down strategy for implementation.

Most importantly the emphasis of this research is on creation of an AEC decision & conversation management tool, not simply a document management framework. Obviously CAD and image files play a crucial role in this conversation but email, schedules and eventually blogging are just as important. This is especially true as time passes and the personal relationships and decisions that helped form the design are forgotten or the people that were associated with development transfer project documentation off to others. Exactly how this conversation is (or isn't important) to the evalutation of the project is important and most probably the crux of my thesis. Determining whether or not the preservation or re-evaluation of project conversation can play a beneficial role is the end-game conclusion for the work. My hypothesis is that the advent of such a tool would greatly improve not only collaboration and understanding but also the long-term success of a project. Proving this hypothesis is what the testing phase is all about.

An old but still very interesting Cadalyst article I read recently touched on the importance of conversation and collaboration in the evolution of the Building Information Model. The article even suggested that the success of Industry Foundation Classes may hinge on the failure of proprietary silos and collaboration tools (what need is an open model if most of the value comes from a proprietary means of collaboration?). This is an interesting point of view and quite logical when the true value of collaboration and conversation is factored into the life-cycle costs of a project.