Five problems with SaaS construction collaboration?

QICpostAug14London-based Quality in Construction blogger Paul Inglesis has written a post entitled “5 Problems With Online Collaboration and Document Management Tools in Construction Industry” (19 August) which is worth a read. The article (which mentions this blog) suggests some major obstacles that are “holding the market back”. Drawing on his contractor experiences working on projects in Greece, Qatar and in east London, Paul (who I’ve met for a couple of beers) sees the following (summarised) problems:

  1. Partial collaboration means… no collaboration – Paul cites contractors’ suspicions over client-mandated systems that they don’t control, and where they are reluctant to add new users.
  2. Need for speed – poor network performance and slow cloud downloads
  3. Changes halfway through the life-cycle of a project – Changing from one Software-as-a-Service (SaaS) system to another midway through a project
  4. “Simplicity is the ultimate sophistication” (Leonardo Da Vinci) – The need for tools to be well configured and well implemented so they work simply and reliably from day one.
  5. Windows ’95 – Not the operating system, but a reflection that, in Paul’s view, aesthetically many of the solutions are ugly and so visually old-fashioned.

I have tried to summarise his points (read the original article to get his full view), but I have observations to make on them all. Let’s take a more detailed look at them….

  1. Partial collaboration or dual systems – First, these problems are not the fault of the systems, but of the contractual mindset – too often based on adversarial, risk-averse and/or litigious attitudes. The issues can be avoided if clients and teams work more collaboratively, in a spirit of mutual trust and co-operation, rather than adopting a “Knowledge is power” approach. Second, there will always be parallel systems, not least because firms will publish information originally authored on separate internal systems. Further duplication and issues with version control can, though, be overcome if firms can integrate the SaaS platform with their internal systems (using Revit plugins, for instance – see previous post) and if they enforce robust project protocols. Third, where a SaaS platform is licensed – as most UK ones are (excluding Asite) – on a project-based license, there is no additional cost for new users to be created.
  2. Speed – Paul admits network speed is becoming less of a problem, but the speed of a SaaS platform will only be as good as the end-user’s connection to the internet. Most of the SaaS vendors’ experience predates broadband, and they are expert at optimising information delivery through a browser even over slow connections (building information models can be viewed in seconds as SaaS platforms stream just an image of the file). The upload and download of native files will always be more time-consuming if the internet connection is poor or over-contended (one reason that many firms schedule file transfers out-of-hours); the YouTube comparison is inappropriate – uploading the initial video file will be just as slow.
  3. Half-way changes – Again, such changes can be avoided if the client and project team work collaboratively and agree on one system for the duration of the project (better still, if the platform incorporates a tendering system so that users from successful bidders can then be added). In my experience, a midpoint change is very rare – most project teams recognise the training and learning curves involved in switching during an ongoing project. Also, major contractors are increasingly entering into enterprise agreements with SaaS vendors so that the chosen system becomes standard for all their projects and across all their supply chains, reducing issues when people move between projects.
  4. Simplicity – Adoption is more likely when a system is intuitive to use and its interface reflects common industry terminology and workflows (including those specific to a company). Paul is right to highlight the need to carefully plan and ensure sufficient resources during the configuration and roll-out of technology; most reputable SaaS collaboration vendors will focus on the ‘service’, not the software, and work with project teams to ensure it works how they expect it to so that “work-arounds” are avoided.
  5. Old-fashioned – I would agree with Paul on this, though an outdated interface may not be solely the fault of the vendors. The typical document register column-based interface reflects the spreadsheets and forms commonly used for many years in the construction industry, and vendors also test the acceptance of new designs extensively with users before roll-out. While the interfaces might not win awards among the web-savvy, they provide familiarity and continuity to many current users, and have been incrementally improved over the past decade or so. However, there are companies that are breaking the mould and developing almost radical new interfaces which adapt approaches from mobile (even wearable) devices and from social media – see my recent posts on Bridgit (21 August), Avollio (1 August) and on Plangrid (18 June), for example. The current crop of collaboration providers will need to adapt if they are not to see their market taken by the new generation.

 

Permanent link to this article: http://extranetevolution.com/2014/08/five-problems-with-saas-construction-collaboration/