Kudos for Chrome
I have just downloaded and had a play with Chrome (Google's new browser). First impressions are:
- It is very fast. It opens quickly from scratch and it renders pages very quickly - much faster on both counts than IE and Mozilla.
- Having results-as-you-type for both web pages and Google search results in the URL bar is very nice.
- The layout is minimalist. Time will tell if they have hidden too much away, but so far I have been OK with it.
- So far, I like not having a set home page. Rather, the home page is a montage of your most visited pages... very nifty.
Using Chrome to browse around Aconex was great. I have found no issues so far with rendering of pages or the like. The only issue was if you wanted to use the online mark-up viewer (which is a Java applet) then you needed to reinstall the Java Runtime Environment. This is because when you install the JRE, it only installs the plug-ins for your current browser(s). Since I had installed JRE before Chrome, I needed to reinstall it to get the Chrome plug-in. That was very straightforward, and the online viewer worked just fine. Incidentally, I installed Java 6 (1.6.0_10-rc-b28 to be exact), which is a beta.
Of course, since most collaboration providers offer viewers that only work on Internet Explorer, it's not something their clients will need to worry about!
Labels: Technology
Service and some Software
OpSource has reported (as commented on already by Paul Wilkinson at Extranet Evolution) the use of a US data centre by UK collaboration provider Asite. No disrespect to the PR folk of the world, but isn't it amazing how much non-news we are fed these days? A data centre gets a new client. A company starts to use a data centre. Doesn't this happen thousands of times a day?
Almost any provider of online collaboration to construction already has at least two data centers. For example, Aconex has seven spread across five countries - with an always-ready disaster recovery centre as well. Adding a new one is hardly a big step in its own right. The decision to host client data in a new geography is often driven by performance and by the end-user experience. While the internet is global, and a SaaS business can theoretically host all of its operations from a single data centre, the reality is that the world is large, the speed of light is fixed and there are many things that can slow internet traffic across large distances.
Part of the solution can be to provide a local instance closer to the end user, giving higher and more reliable speeds. When you are talking about a mission critical application (not just a website), the users do not want to wait - even half a second for each data request can add up and become frustrating. There is an additional benefit: having more than one data centre spreads the risk across locations and provides additional levels of redundancy - if it is done correctly.
But probably the most important point is that adding data centers in new geographies is not challenging. It is a fairly straightforward and mechanical thing to do. The real challenge is in properly supporting those new, distant projects with local training and real local operations (not just fly-in-fly-out support). That comes down to people and management. It is complex and expensive and far more critical than simple hosting to the success of the projects and clients that use the software.
I sometimes think that SaaS (Software as a Service) is a misnomer. Perhaps Service and some Software (SasS) would be a better name.
Labels: Technology
R.I.P. The folder structure
Something our sales guys get asked in nearly every meeting is "Can you replicate our file and folder structure?" The answer is "Yes, but we have 5,600 projects with thousands of organizations taking part. 99.9% of them don't use this set up."
At this point there are usually a few raised eyebrows and a grumble or two. But, when you think about it, using a file and folder structure within a collaboration tool just doesn't make sense. Thankfully (on the Aconex system at least) keyword searching has made it redundant.
An analogy that comes to mind is to compare the Google search engine to the way the internet used to be. If you can remember searching using the original Compuserve, AOL and Yahoo! applications, you had to go all the way down a tree of folders, starting very wide, until you found what you were looking for. For example, if looking for information on Picasso. you would have to ascertain whether it would be held in the Entertainment folder or under Culture. You would then need to find The Arts, then Artists, then Painters, and then scroll until you found Picasso. Would we do that now? Of course not! We'd just tap "Picasso" into Google and wait for the results to appear, knowing the best matches would be near the top.
It's exactly the same with collaboration systems that offer keyword search. Why would you go through five levels of folders (and who would define the levels across your whole project anyway?) to find electrical drawings, when you can punch the word "electrical" into the search bar and get the files you need in seconds, sorted as you want them to appear? Effectively, a folder structure is still there, it's just behind the scenes.
As with the evolution of web-browsers, being able to search on meta data is far quicker than using a folder structure and it also clears up the inevitable confusion (and disagreements) over naming and categorization.
Also, as with the evolution of web-browsers, once they get past "but this is how we always do things", very few people can imagine going back.
Labels: Good practice, Technology
Different industry, same challenges (and same solution)
An article in Middle East technology publication ITP.net highlights an issue in the oil and gas industry that is proving costly, and yet has a tried and tested solution.
It reports that data storage provider EMC held an Energy Solutions Day in Abu Dhabi in June, during which IT management of oil and gas companies talked about managing growing information stores while minimizing downtime and enabling collaboration.
According to EMC, back-up and recovery of data is a key consideration for oil and gas companies due to the amount of information that is distributed around a number of sites or offices. Staff need to be able to store data securely and cost-effectively. They also need to be able to facilitate collaboration between knowledge workers in exploration and production, process safety, operations, and other areas.
To recap, the challenges are that the energy industry involves:
- Complex working structures involving dispersed, multi-disciplined parties
- The need for team members, across several functions, to be able to access and share information in real-time, even from remote locations
- A requirement to maintain a comprehensive and secure archive of data
- A robust, scalable and cost-effective system for data management that includes disaster recovery
Sound familiar? These are exactly the same factors encountered in construction; and the construction industry has been using collaboration tools to overcome them for much of the past decade.
More specifically, the challenges highlighted above all point towards the need for the energy sector to adopt web-based collaboration tools that are delivered using the SaaS model.
Although the resources and energy sectors are progressive users of IT, they are a few years behind the construction industry in their uptake of online collaboration. The gap may be closing, though - we are beginning to see more engineer-led industries (such as mining, oil and gas) recognize the benefit of implementing these tools.
Labels: Global trends, Technology
Not so Excel-lent: six reasons to use a collaboration tool instead
Labels: Good practice, Technology
NCCTP: Flogging a dead standard?
The collaboration providers who are members of UK-based industry group NCCTP met on Wednesday to discuss progress towards an industry-wide technical standard to support data exchange between collaboration technology vendors. This was a follow up meeting to that discussed in Paul Wilkinson's blog post last month. The attendees were Aconex (me), Asite, 4Projects, Business Collaborator, Causeway and Sarcophagus. Cadweb and BIW were not present.
The aim of the meeting was to ensure that all NCCTP members were compliant with the data transfer standard (or, at least that they would be by September 1st). As Paul mentioned, there is a difference of opinion on whether the standard is worth pursuing or not. The meeting also discussed whether the standard should be enhanced and whether we should move to one that uses web services to transfer data.
The original rationale for the standard came about several years ago when the collaboration space was relatively new. Vendors were recently established and, in some cases, not yet financially secure. A common question from potential clients during the sales process was "What happens if you guys go out of business? Can I transfer my data to another provider easily?" We simply do not hear that objection any more and this is due to a number of reasons:
Firstly, the collaboration market has matured, and so has the attitude of clients. They have confidence in the delivery of software as a service (SaaS) and now trust that their data is backed up and secure. (In fact, data is almost always more secure under SaaS than if managed using the client's own IT infrastructure).
Secondly, the leading collaboration providers are now established businesses with strong revenue streams and future order books. Financial viability is no longer a major concern. Now the only question a client may have is whether a provider has the leadership and financial clout to continue to invest in product improvement and platform performance (but that is a separate issue).
Thirdly, many providers have already done scores of data transfers between respective systems - and these transfers have been done predominantly without the use of the technical standard. In fact, one of the key objections by members (including me) is that the standard is a "lowest common denominator" and that the richness of data can be lost when the standard is applied to do the transfer.
The technical standard, taking Aconex as an example, touches only a small proportion of the functional and data set. Even if the NCCTP technical standard was available, many collaboration providers would choose to not use it. Aconex falls into that camp and I know of at least one other provider that has expressed the same view. Rather, we would look more closely at the respective data sets involved and come up with a transfer method that maintains as much of the richness and functional utility as possible. We know that if we used the standard to transfer data from our system to a competitor's and then took that imported data and immediately transferred it back (again using the standard), we would lose a large amount of data and utility in the process.
Finally, the technical standard was specified a number of years ago. Even at that point, it suffered from being a lowest common denominator effect. Fast forward three years and the functional offerings of most of the providers have progressed significantly - leaving the standard even further behind.
Improving the standard to be an all-inclusive and (at the same time) a one-size-fits-all data set would in my view be extremely complicated, difficult and costly. It would be like trying to make a single size, cut and style of jeans that would fit a dozen random people and at the same time make it suit all of their fashion tastes. For this reason, I sense the standard is ultimately doomed and destined for irrelevancy.
So, while the NCCTP has an important role to play in educating the market and in promoting online collaboration within construction, I cannot see the value in diverting development resource from improving our respective functional sets to getting a data transfer standard that gives us a poor cousin of what providers are already doing quite well already.
Labels: Technology
Bulk processing, taking document control up a notch
The feedback we receive from users has provided us with valuable suggestions for both minor and major product enhancements. Unsurprisingly, some of the best suggestions we receive come from the heaviest users of our online document management system, document controllers. Due to the workload they handle, many of their ideas concern speedier methods to get large amounts of work done in a minimal amount of time - any way to reduce the stacks of paper on their desk is a plus.
Some time ago, we introduced the bulk processing feature on our system. The option to upload, register and supersede a large number of documents has always been a key feature on collaboration tools but bulk processing is a way to take that concept up a notch. The number of documents a user could register and supersede went from hundreds into thousands.
Bulk processing takes advantage of the Excel spreadsheet, traditionally the most common medium to keep track of documents on any project. Spreadsheets are already in abundance on most projects, and bulk processing makes use of them to get documents up and registered fast. Using a metadata template, bulk processing allows users to upload, register and supersede as many documents as an Excel spreadsheet can contain (about 65,000 if need be).
Anyone who is familiar with the role of a doc controller knows the value of time and effort. Once a large number of documents are prepared, compiled, examined and verified for accuracy on a project they need to be constantly maintained and updated. In the paper world, as much time can be spent chasing documents and new revisions down through phone and email as it takes to actually handle the task at hand. New revisions need to be communicated back to project participants and this cycle continues for years at large volumes.
Anything that can streamline this task is of major benefit, provided all the data can still be accurately maintained and captured. Particularly for doc controllers, features on collaboration tools like bulk processing can help make the job easier and clear a little desk space for a much deserved coffee.
Labels: Good practice, Technology
You say tomato, I say...
A great thing about our industry is that, with projects becoming more internationalized, and team members based in many countries, you get an insight into other cultures, attitudes and work practices. It's fascinating to hear how other people go about their business and how they would tackle a particular challenge.
An example can be seen in Emmanuel Netter's blog post 'Aconex et la gestion des fichiers de CAO' (Aconex and management of CAD files), which is a response to my recent post 'Handling CAD drawing and Xref file exchange'. Emmanuel, a prominent figure at French collaboration provider Prosys, sees the method I laid out as 'Anglo Saxon and rigorous' and quite different to the more 'anarchic, Latin' approach.
His blog, CPLUSN, is in French so in case you don't read the language (or trust the Google translation), the main section of the post (roughly) translates as...
In tools developed for the French market, like Mezzoteam, additional modules automate the retrieval of related documents. In short, if I open an AutoCAD file, Mezzoteam will automatically retrieve the X-refs, even grabbing local copies to save on transfer time, if they are up to date.
The approach advocated by Robert is more consistent with what we see in generic tools, since file retrieval and the maintenance of links between files is done manually by the CAD Manager. You are building a local set of reference data, which the CAD manager works from.
We can see a "clash of cultures". On one side is a requirement for automation and high productivity, driven by the wish for quality assurance, but requiring everyone to play by agreed rules. On the other is a more flexible approach, less effective on paper but also less demanding in organizational terms.
So maybe the old stereotypes of Anglo-Saxon rigor and Latin anarchy have been played out in this case!
Based on the above, it appears that the differences are as much to do with the principles of the system as with how X-Refs are managed. The automated retrieval model described is interesting and suggests that there is local software being utilized that can manage downloads and cache files for re-use later. Also, it hints that users can access files (X-refs) that they have not been explicitly been given access to.
My initial thought is that, while Mezzoteam's system may be easier in some regards to the SaaS collaboration tool model, there may be security implications. Could firms be left open to unintended consequences if people can see things that the author did not want them to see? A thought-provoking post and I'll certainly look into this more. Has anyone else had experience of using both approaches?
Labels: Global trends, Good practice, Technology
Renewing Xrefs
In response to my post a few weeks ago on 'Handling CAD drawing and Xref file exchange', a reader asked us whether collaboration systems support the automatic renewal of the Xref file, or whether manual action is needed to select which Xref files have to be updated?
We asked a member of our Industry Consultancy team for his view on current industry good practice and here's what he said...
Collaboration systems are the tool by which the Xrefs are transferred and therefore are not linked to the update of the Xrefs in anyway.
That said, the creator of the drawing, and therefore the Xrefs, are responsible for updating the required organizations using the Xrefs within the project. This is where collaboration systems provide the perfect tool, as there is a function that allows a user to quickly and effectively update documentation (the Xrefs) stored within the register and send them to the same organizations that received the previous revision.
As Xrefs are usually stored/managed in folders, the best format by which to transfer the Xrefs are in 'eTransmit' zip files which are created in AutoCAD and simply registered on the collaboration system for means of transfer.
The receipt of the eTransmit zip file simply downloads and extracts the contents to the local drive. As part of the function of the eTransmit zip file, the contents are routed and stored in the correct paths within the local folder structure.
The creator of the drawing/Xrefs would have an agreed project protocol for creating and storing the Xrefs but the best practice way to manage the Xrefs is the ensure that the path is relative. A relative file path means the recipient doesn't require the same drive letter as the creator of the drawing. So when the eTransmit zip file is extracted, the folder structure is mirrored on the recipients drive using the drive letters on the local system. When the recipient of the Xrefs opens the drawing in AutoCAD the 'relative file path' Xrefs are then picked up from the local folders and viewed as part of the drawing.
That process is all well and good but the recipient must be confident that they have the most up to date Xrefs which is where the collaboration system is used. It provides a means of determining the current Xrefs by means of a register that holds the current files by default for the user to download. Therefore a user need only check the current file on the collaboration system is the one that they downloaded (usually determined by the date) giving them confidence that they are using the most up to date Xrefs available to them.
Labels: Good practice, Technology
Can you help me?
Something worth adding to the previous post 'Google Docs, a competitor to construction collaboration tools?' is that, in addition to the limitations of the product, Google Docs will never be able to compete with the leading construction collaboration vendors on customer service. Despite its success as a business, Google Inc. can't come close to providing the specialist support, training and implementation expertise that industry projects need.
A quick scan around the websites of some of the top collaboration providers shows that they all provide (as a minimum) phone and email support during business-hours as well as supplementary consultancy and implementation services.
I'm now looking on the Google site and.... I can't find a helpdesk number. Anywhere. Let alone the option to talk to someone who is specially trained in the Google Docs product and understands the construction industry.
The expert human touch when the users have a problem is the main reason why specialist construction collaboration vendors will trump generalist tools like Google Docs.
Labels: Global trends, Good practice, Technology
Google Docs, a competitor to construction collaboration tools?
We received a comment earlier this week asking our thoughts on the merits of Google Docs. As the author said, Google Docs is a free tool that can perform some of the functions of a construction collaboration system. It provides easy indexing, searching, automatic versioning and live editing whereby multiple users can edit documents at the same time, with a built in chat function for users to converse while editing.
I'm sure many software providers live in dread that Google will launch a free tool that is potentially a substitute for their product. However, although Google Docs is a good generic tool for the simple sharing of docs, it is not really a competitor to construction collaboration tools.
Here are some of my thoughts:
- Construction and engineering projects demand a system that is customized to the needs of the industry. Google Docs has some nifty features but it falls a long way short of providing the functionality and sophistication required for an industry project. There are some fundamental requirements that Google Docs can not perform, such as workflow reviews, web forms for correspondence and reporting for outstanding overdue items (or any kind of reporting for that matter).
- Having a system that allows docs or files to be deleted is bad for the audit trail and court-worthiness of a system.
- Google docs has limited storage capabilities - and you can delete items to stay within the storage limits - which is very bad for capturing the full history and audit trail of the project.
- Google Docs does not have an organization-employee and project structure, which does not suit large construction and engineering projects.
- Allowing users to share data while also allowing areas for data that are private to particular organizations is critical in wide adoption of collaboration systems on projects. If everyone can see everything, or even if the admin organization can see everything, then people will not widely adopt it. We have seen systems that have a similar security model to Google Docs being implemented on construction and engineering projects and they either fail totally, or the amount of data captured is a small percentage of what is captured by a system that supports collaboration while also allowing privacy (because people will go outside the system for anything that they want to keep private). And - ultimately - capturing all the data is the best way to reduce risk on a project.
So, while Google Docs is a good tool for people that want to share some docs in a very basic way, it does not suit collaboration on projects (particularly medium-large scale) that require industry-specific functions and workflows, indelible audit trails and reporting features.
Labels: Global trends, Good practice, Technology
Implementing EDRM: A long, old slog
There's an amusing post written by James Lappin on the TFPL blog entitled 'What you do once you have successfully implemented EDRM' (an electronic document and records management system).
The post starts off by saying, "Rolling out EDRM is a long old slog. You have to procure it; configure it; build your fileplan, your retention schedules and access rules; write your policies and procedures; pilot it; take it to every team, get their folders set up and get them trained. By the time you've done all that you are three years older than when you started."
Reading this reminded me why uptake of SaaS solutions - which include online alternatives to installed EDRM software - is growing at more than 20% per annum!
Labels: Good practice, Technology
iPhone on site?
A quick follow up on the previous post comparing the iPhone and Blackberry: a client and a colleague have both asked whether I think iPhones are suitable for using out on site. Firstly, I think that the iPhone certainly has the capabilities to be a useful tool on site - it works well with collaboration tools and it's easy to view files and type mail. The only practical issues I can think of are that the early models don't have any screen protection so you may need to be careful. Also, the battery doesn't last long when using WiFi heavily.
It's also worth mentioning that an early complaint about the iPhone has been a lack of 3G support. For me, this isn't a major problem as the phone has WiFi and uses the Edge network (the same network that the Blackberry uses). The places that I'm in most often - such as Asia and the Middle East - have good WiFi coverage. I can see how users might lose out where WiFi or an Edge network isn't available, but these places are becoming increasingly rare - and there is talk of future models featuring 3G.
Ultimately, these phones are far more useful on site than earlier products. They can help improve control and productivity on a project by providing faster access to data and reducing the inefficiencies associated with manual systems. Because of this, I expect to see the iPhone used on site a lot over the next year.
Labels: Technology
iPhone or BlackBerry?
I've been asked a few times lately about which phones are suitable for using with project collaboration tools - in one particular case the choice came down to an iPhone or a BlackBerry. Having owned them both, I believe that there is no contest. Although the BlackBerry is the business tool of choice for many, my view is that the iPhone is far superior, particularly when used with a web-based collaboration tool.
Without meaning to sound like I'm on the Apple payroll, I have to say that the iPhone is the best phone I've ever used. The main advantage is that it allows full-feature web-browsing. In contrast, the BlackBerry can't handle frames, SSL or AJAX, making it virtually useless for anything beyond static pages.
The iPhone user interface puts it in a different league to the BlackBerry and others. For example, when viewing a page or file, sweeping and pinching to scroll and zoom is very easy to use and looks great. Another nice feature is that when you want to view something in landscape you simply turn the phone from portrait to landscape and the image on the screen follows.
On previous products (the Nokia E61i comes to mind) an overlooked aspect of usability has been the key size. Having chunky fingers, I've found that some phones, with their toggles and tiny keys, are too fiddly for heavy use. The iPhone is easy to type into and is definitely suitable for the type of use that the mail module on a collaboration tools generates.
Email is one area that the BlackBerry does extremely well. But I think the iPhone matches it and, for me, this is the clincher. The iPhone goes toe-to-toe with the Blackberry on the BlackBerry's strongest feature and yet it's streets ahead in terms of usability. I think the choice is a no-brainer but, as always, I'm interested to know your thoughts.
Labels: Technology
Interoperability
Doing some research for a presentation, I read a report by McGraw-Hill Construction on interoperability of software applications in the building community, which found that interoperability costs add 3.1% to a typical project budget. Although this report has been widely commented on in industry sites and blogs already (it was published last October), it reiterated the value of online project collaboration solutions.
The president of McGraw-Hill Construction, Norbert W. Young, concluded that, "Interoperability, from a purely technology-based viewpoint, allows collaborating firms to share electronic data between software applications. The lack of seamless flow of information - or interoperability - is one of the primary factors holding the entire industry back from quantum leaps forward."
As anyone who has been even partly exposed to an IT integration project will know, workable system-to-system interoperability is a tall order. However, the market has already taken steps to circumnavigate this problem by using collaboration platforms. Because web-based project collaboration systems allow users to manage, view and exchange files, regardless of what program they have been created on, they by-pass the issue of interoperability. In the short term at least, this approach is far more productive than waiting for systems to start talking to each other - which is still some way off. In the mean time, innovation has enabled people-to-people collaboration before system-to-system compatibility is possible.
Labels: Technology
To Wiki or not to Wiki?
One of our marketing guys was talking to me the other day about whether we should create a Wikipedia page for our company. On the surface, it seemed like a good idea, but the arguments were pretty even in terms of for and against.
Not unlike construction collaboration technology solutions, Wikipedia can be viewed as a neutral, third-party, web-based platform for viewing and sharing information. But, unlike collaboration technology, the system is a blank wall in the public domain that is open to inaccurate information (albeit with some clear editorial guidelines).
Transparency of information, whether on a construction project or in the public domain, still needs mechanisms in place for effective collaboration. The systems in place on Wikipedia are pretty good, as they let the community revise content and block people who are causing trouble.
Ultimately, we're still wrestling with whether Wikipedia is an appropriate place to profile a company. Let us know what you think.
Labels: Technology
The balancing act of usability
In his comment on the previous post, Emmanuel Netter makes the point that construction industry expertise is more important than IT skills for document controllers. That's very valid. It points to the importance of usability, especially as systems gain features and become more and more configurable.
Construction has been quite slow to adopt technology and a common expectation is that new construction management systems will be difficult to use. In project collaboration, that can make it difficult to get everyone using a single system. So any construction document management application that hopes to get people on board quickly needs to think about intuitiveness and ease of use. For the larger vendors that can invest in this area, that falls to the User Interface (UI) team.
On one level it's important that online document management mimics the standard processes of the paper-based world. This reduces learning curves and encourages uptake. It lowers training and support costs later on, too. One of the challenges for a UI team - this is certainly true of ours - is to take these processes and see how technology can streamline them, while still keeping the system easy to use. For example, searching through 1,000 paper documents for a keyword would take hours; doing a Google-style search using a collaboration tool will get you the files you need in seconds. The interface (the simpler the better) belies the complexity of what is going on behind the scenes.
At some point, most people entering the industry won't even have been exposed to traditional document management methods. Ease of use, even more than features and functionality, may well determine exactly when project collaboration becomes the standard way to work.
Labels: Technology
4 immutable laws of collaboration: Part 2 of 2
The previous post covered why, more often than not, the collaboration process breaks down when using an information management tool that charges a per-user licensing fee or doesn't include training. Our two other 'rules of collaboration' concern data - how much is stored, where it is a kept, who controls it and who has access to it.
Rule 3: Don't pay extra for, or accept a limit on, data storage
For a Software as a Service (SaaS) provider, holding 100GB or even a couple of terabytes of information is nothing, just another cost. For the IT department of a construction firm that has purchased and is hosting document management software, this amount of data can represent a very high cost.
Because of this, some companies put in place limits on the amount of data each organization on a project can store, then charge for subsequent data. The inevitable outcome is that some data is stored, some isn't, which defeats the purpose of having the system. Also, how can anyone make a decision on what information is going to be required (potentially years) in the future?
Rule 4: Trust no one else on the project with your data
Is it any surprise that information management systems (therefore collaboration) can fail when firms are asked to hand over their valuable intellectual property to another organization on the project? With the installed software model, firms put their drawings and documents behind another company's firewall. The company with the software controls the data and controls access rights, which is not in the interest of project collaboration.
In contrast, most vendors using the SaaS model provide a third party platform for managing information. Each company owns its own data (the files it has created or been sent), creating a level playing field for everyone on the project. An archive of current and historical document versions is held on the system where it can't be altered or deleted.
The most used document management systems respect these four rules. They come from SaaS providers that, inclusive in their price, allow unlimited users, provide training to all participants and have no restrictions on data storage. What's more, data is stored independently with all parties having equal access rights to their information. Using tools that meet these criteria will support project collaboration and lead to successful projects.
Labels: Good practice, Technology
