Google wave in 2 minutes
Labels: Global trends, Technology
Getting F1 to the checkered flag...
I don't like to talk specifically about Aconex (this is not a marketing blog, after all!), but the Yas Island project is one that I mention, purely because of it's size and the volumes of information that were generated and managed on that project and this information may be interesting to some of you.
Some background: Yas Island is a US$40 billion, 25 km2 development located off the city of Abu Dhabi in the United Arab Emirates. The development includes the Yas Marina Circuit that will host the Abu Dhabi Formula One Grand Prix in 2009, as well as world-class hotels, theme parks, golf courses, shopping malls, marinas, apartments and villas. Highlights include the Warner Bros. Theme Park, the Yas Island Water Park and the world's first Ferrari theme park. The developer, ALDAR, is the premier property development, investment and management company in Abu Dhabi.
With the track and related infrastructure needing to be completed by race day on November 1, the pressure was really on. The project team was (typically for a project of this scale) widely distributed across the globe (around 95% of the organizations engaged on Yas Island have their head office located outside of the Middle East). Turnover of staff (and even organizations) is quite common, so having continuity of documentation and information is a challenge that (if not handled well) can cause projects like this to quickly come unstuck.
The sheer scale of documentation and information flow on this mega project is quite amazing. Some of the amazing stats include (and keep in mind that this is only 2 1/2 years into the development):
- More than 5,700 users
- From 380 companies
- Located in 29 countries
- More than 8 million documents and correspondence items.
- Within the first six months of the project, more than 1,000 people from 80 companies had been trained and were using the system.
Would projects like Yas Island be possible without a web based collaboration tool? I would say quite emphatically - no! The coordination and approvals alone would be mind blowing and the handover process would have taken months longer.
Labels: Global trends, Good practice, Project profiles, Technology
Improving transparency, accountability and efficiency on ARRA projects
Continuing my US government theme... Earlier today we released a white paper called, "Three critical challenges on any ARRA construction project, and how to overcome them with online collaboration". Although it's written for firms engaged on economic stimulus projects in the US, the content is relevant for anyone involved in construction/infrastructure works.The paper references an interesting post by Jim Till on his Just Sharing blog called "ARRA Stimulus Funds and Your ECM Project?".
Labels: Global trends, Good practice, Technology
US Government embraces SaaS
Technology is moving fast, and by using technologies from the 90's, Goverment agencies (and many private companies) have been missing out on the advantages of SaaS. This is something that was acknowledged, with the blog contining to say "Our policies lag behind new trends, causing unnecessary restrictions on the use of new technology. Past practices too often resulted in inefficient use of purchased IT capabilities across the federal government. We are dedicated to addressing these barriers and to improving the way government leverages new technology." Wow. That is a great forward step in policy.
It will be interesting to see how effectively this initiative works, or whether procurement managers will revert to their own and familiar ways?
Labels: Global trends, Good practice, Technology
Google wave and construction collaboration tools
Labels: Global trends, Technology
Lower your project's blood pressure - use DWF
Rob looked at some of the time savings that online collaboration systems can bring to a project in his previous posts here and here. This got me thinking about efficiency, and how even choices about the small things like file formats can make a difference. Using DWF (Design Web Format) over PDF for drawings is one that comes to mind. DWF is a secure file format, typically used when issuing drawings for review or approval, as they are non-editable, and much smaller in size than a PDF.
Bit of a gory analogy, but I like to think of the circulation of drawings on a project as its 'life blood'. If we think along these lines, we can say that the there are two ways to increase the flow of blood. One (very expensive) way would be to increase the size of the veins and arteries. When related to the use of an online collaboration system, this would be the equivalent of increasing the size (bandwidth) of everyone's internet connection. The second (and free) way to increase the blood flow would be to make the blood thinner. This is the equivalent of using DWF instead of PDF.
The benefits of DWF over PDF are well understood by design consultants, so you would think that DWFs would be the industry standard. Yet it's amazing how many project professionals prefer PDFs. Perhaps it's because virtually every computer has Adobe Reader pre-installed, or it could be the misconception that DWFs require expensive software to view them.
It's important to remember that DWF is not a replacement for native CAD formats such as DWG. The sole purpose of a DWF is to allow designers, engineers, project managers, and consultants to easily view and comment on drawings, without the need to change the drawing or to own AutoCAD software.
So, how much time and bandwidth is saved using DWF over PDF? I read an interesting post by Shaan Hurley on his Autodesk blog where he found that DWFs were 11 times smaller in size than PDF files, with no discernable difference in quality. Therefore, when you consider the enormous volume of drawings created and distributed over a project's lifecycle, it makes little sense to still use PDFs.
Any thoughts? Have you noticed increasing or decreasing acceptance of DWFs in the industry?
Labels: Good practice, Technology
Retrieving your project information faster than a Google search
A manager from our product engineering team told me today that our average system response times are now faster than Google. Nice analogy! Basically, over the past 18 months, his team have worked hard to improve response times when a user is searching for data, getting the results right down to around 0.1 of a second. This is despite the load of information on the system more than doubling over this period. When doing a Google search and checking the response time at the top right of the screen, I have rarely seen one lower than 0.1 of a second (although I'll stand corrected if you can beat this consistently!).
In the context of the efficient running of construction and engineering projects, this is great news, and a good illustration of how far collaboration systems have developed over the past few years. Factors such as faster server response times and web acceleration technology give the entire project team a better user experience. Perhaps as much as features and functionality, this is what drives adoption and usage, helping those on the project to capture as much information as possible.
Labels: Technology
A SaaSy Salesforce.com video
Over the past few years, Salesforce.com have undoubtedly been the leading lights in furthering awareness of the Software as a Service (SaaS) model and, more recently, Cloud Computing (this article explains the subtle difference between the two).
Yesterday, one of their sales reps sent me a link to an excellent video which, in just a few minutes, clearly lays out the benefits of using applications delivered using the cloud computing (and SaaS) model, compared to self-hosted software.
Their arguments are as applicable to our business (web-based collaboration for construction and engineering projects) as to theirs (customer relationship management solutions). We often get asked by companies why they should use a SaaS-delivered project collaboration system when they (or their head contractor) already have a document management system. So, if you want to get a fun and easy-to-digest overview of why SaaS-delivered systems are the best way to go, this video is a good place to start.
Labels: Technology
A good night for Aconex
Pleased to say that our company, Aconex, won three categories at the 2009 iAwards, Australia's main awards for the information & communications technology industry. Having made it through our state round, we won the best Industry Application, Exporter of the Year and the overall 'best of the best' award (which has the nice title of 'Inspiration Award'). Great for our business and a good reflection of the high demand for construction collaboration technology globally.
I was in Dubai at the time so couldn't attend, but company co-founder and Built On Collaboration blogger Rob was there to collect the awards. Our video, which was played when we won, has been posted on YouTube and can be viewed below (in case you're wondering, a definition of "multi-tenanted SaaS" can be found here!).
Labels: Technology
Managing project correspondence: Want to save 25 seconds per mail?
Along the same lines as my recent 'Man vs Machine: The Race to Revise Documents' post, one of our clients has taken out their stopwatch and done some research into the time it takes to perform common information management-related tasks using an online collaboration system compared to using their internal document management tool and email.
The results make interesting reading and (unsurprisingly) reinforce the greater efficiencies of using a collaboration system. When comparing how long it took to file a project mail (e.g. an RFI, advice, notice, instruction, variation, etc.) using each system, here's what they found...
| Internal document management tool & Email | Online collaboration system | |
| Step 1 | Read email in Outlook | Read email |
| Step 2 | Read attachment | Read Attachment |
| Step 3 | (Switch to document management system) | - |
| Step 4 | Navigate to the folder the email should be stored in | - |
| Step 5 | Select to import email | - |
| Step 6 | (Switch back to Outlook) | - |
| Step 7 | Drag email from Inbox into document management system folder | - |
| Step 8 | Delete email from Outlook | - |
| Time Taken | 32 seconds | 7 seconds |
Table: Filing a received mail using an internal document management system and email compared to using an online collaboration system
Because collaboration systems automatically index and archive all incoming mail through one central platform, the process is six steps and 25 seconds lighter. When that is multiplied across dozens of mails a day and an entire project team, it's easy to see where the gains in efficiency lie.
A couple of our clients have done other 'side by side' comparisons on tasks such as drawing review and searching for info, so I'll try to track down the data and add one or two more. Anyone out there heard about or done similar comparisons?
Labels: Technology
Information 100 times faster
Following on from my post last month about the impact of internet speed on construction project productivity, I was pleased to hear last week's announcement that Australia's federal Government will lead the build of a national, fibre-to-the-home broadband network. At an estimated cost of up to AU$43 billion (making it Australia's largest ever infrastructure project), the new service will deliver speeds up to 100 times faster than currently available.
On a national level, it's estimated that, when fully operational in 7-8 years, the new service is likely to increase Australia's gross domestic product by 1.4 per cent over a 5-6 year period, adding about AU$15 billion to the economy.
Naturally, my main interest is in the impact it will have on construction collaboration technology and project delivery. The new service will mean that users of online document management and collaboration tools in Australia will potentially be able to access, download and share their files up to 100 faster, leading to significant efficiency and productivity gains. This is an exciting prospect and should help to further drive uptake of these systems.
Labels: Global trends, Technology
Managing mails: Outlook v Collaboration Tools (revisited)
I read an interesting blog post from the folks at 37signals that got me thinking again about the age-old Outlook vs. collaboration tool debate. Fellow Built on Collaboration blogger Leigh Jasper has previously discussed this in three parts (here, here and here), and it seems that we're not alone in the struggle to get users converted into appreciating the value of web collaboration over email.
For those that don't know them, 37signals has a pretty cool (and openly basic) project management/collaboration tool called Basecamp. They built their web application with the view that email doesn't cut it as a collaboration tool for people involved in projects (any type of project not only construction).
In the article they say that one of the common issues their customers face with their application when trying to get other project team members onboard is the fact that they keep using email instead because it's what they understand. Unlike the larger collaboration tool vendors, 37signals don't have the luxury of a large team of Customer Service staff to help projects get over this hump so it's obviously going to be harder for them. Having said that, all collaboration tool vendors will have faced a user (or 500) that can't get past the fact that they have to login to the system to send correspondence rather than just firing off another email from Outlook.
There is no easy solution to this whole issue but I think it starts with a greater awareness and appreciation of the power of how collaboration systems manage mail. The searching/reporting/tracking built into these systems easily beats anything you can do with Outlook. Email also doesn't offer the threading capability to easily track the history of a discussion. And clearly the ability for collaboration tools to transmit an almost unlimited number and size of files between parties far exceeds the standard email capability.
Most of our key clients get the power of our Mail module and mandate the use of the Aconex system for all project-related correspondence. They value the openness and visibility, the concept of filing upon sending (rather than relying on filing/archiving upon receipt) and also the searching & tracking capabilities built in. I'm sure there are many other companies in the construction world with a similar view. Is this correct? I'd be interested to know your experiences with managing mails using a collaboration tool instead of Outlook. Also, what's missing from collaboration tools to help kill the Outlook debate?
Labels: Good practice, Technology
Raising the speed limit on the Web
There was an interview in yesterday's The Australian newspaper with my colleague [Aconex CTO] David Chatterton, about our recent adoption of web-acceleration technology called Akamai.
I'll save you the techno-detail about exactly how Akamai works (sighs of relief all round), but it's explained here if you are keen to know. In a nutshell Akamai uses a number of advanced techniques to drastically speed up the delivery of web content. They basically have their own, alternative internet that is a lot less busy than the one we all use day-to-day. For the end user, the experience of browsing, uploading and downloading data is completely unchanged - except that it's noticeably faster than before. Some big-hitters like Amazon.com, Apple, Adobe, Cathay Pacific, MySpace, Toyota and Yahoo are already using the technology to improve the online experience for their customers.
So what does this mean for Aconex users on construction and engineering projects? Well, not much if you're working on a local project, with all the team members in the same location. Where it really comes to the fore is when organisations are based in different countries. For example, we did some tests sending a 10MB file between Melbourne and London and on average it was about 30% faster when using Akamai. That's quite a time saving for an architect or Doc Controller working with large files all day.
The benefit is even greater when transferring information between countries that have poor or instable local internet connectivity - in some cases we saw an improvement of 300%. Leigh mentioned in a post recently that we were doing some projects in Libya where the head contractor was based in New York, so these guys are really seeing the difference. For them, it's almost like sending a file across town.
So what's the impact on real measures like time and cost? A few weeks ago, Australia's largest telecoms provider launched what it claims is the world's fastest mobile broadband service, with a peak download speed of 21Mbps, increasing to 42Mbps later this year. To coincide with the launch, they released the results of an independent study which concludes that faster mobile broadband could add 0.7% to GDP.
Transposed to a construction project, it's reasonable to say that, by boosting the speed of accessing and distributing information by 30%, you can increase productivity. No hard-fact case studies on this yet, but it's exciting to think about how advances in the speed of managing information can impact the project bottom line.
Labels: Technology
Hot and sunny, but the forecast is cloudy
In Melbourne, where I'm based, we've been in the middle of the city's biggest heat-wave in 100 years. The mercury topped 40c most days last week and we're told to expect more of the same. Aside from the restless nights and the transport system going to pieces, this has meant more time than usual being spent round the water cooler. Something that nearly everyone's been talking about is Google's reported (but not confirmed) GDrive and the implications it could have on collaboration in the workplace. If you haven't heard about this, then this article 'Google Plans to make PCs history' in the UK's Guardian newspaper provides a good overview.In a nutshell, Google plans to launch a service that would enable users to access their personal computer from any internet connection. A person's files and operating system would be held on Google's servers and accessed via the web.
Thinking in terms of the construction and engineering industries, my initial reaction is that this is yet another resounding endorsement of the Software as a Service/Cloud Computing model (as favored by the leading collaboration vendors), and another nail in the coffin of installed, self-hosted software.
Although the Guardian's title will draw in readers, its message may be somewhat premature. Until internet connections become ubiquitous, the PC will not die. There are still going to be situations when people need files offline (like on a plane). Besides, a PC needs a hard drive and an operating system of some sort, so even if people use something like GDrive, it will not mean that PCs are dead - they will just have less installed software (admittedly the headline "Google plans to reduce the amount of installed software on PCs" wouldn't quite pack the same punch).
In the short term, people may use systems like GDrive for backups or places to share or send information. On the (unfortunate, and decreasing number of) construction projects that don't use a specialized project collaboration tool, GDrive might allow team members to access files whenever they need them and from wherever they are located. But - like Microsoft's SharePoint product - this is of necessity a mass-market application without the industry-specific capabilities that are demanded on construction projects.
As with Google Docs, I don't see it being a competitor to construction collaboration tools. But it will be interesting to see how GDrive - if and when it appears - is adopted in the wider computing community.
Labels: Technology
When widgets make the difference
Hi readers, this is my first post on this blog, so let me know what you think and what you'd like to hear more of. I'm the product manager at Aconex so tend to split my time between talking to clients about the needs they have around managing information on their projects, and talking to our tech guys to see if we can make it happen.
Something I came to realise pretty quickly in this role is that in terms of the development of collaboration technology, it's not always about the ground-breaking new modules that revolutionize industry practice; sometimes it's the smaller 'widgets' that can really make a difference and just make life easier for people on their projects.
A good example of this is a new bit of functionality we added onto Aconex today that improves how you view and search for Attributes. Attributes are the meta data fields, usually relating to a works package, area or phase of the project, that can be attached to documents and mails so that they are easier to retrieve. The new functionality rapidly filters the list of attributes available for selection when running a search or creating a new mail or document.
This new feature was added because a client of ours involved in large-scale engineering projects came to us recently looking for a solution to an issue that many of their staff faced many times a day.
Because of the scale of their projects, they have hundreds of options in the Attributes fields - I think the figure was about 280 in total - and trying to find and select one from these long, drop-down lists was very frustrating.
When we did some research into some other projects on our system, we found that this client was by no means alone...
- 122 of our projects had an Attributes list size (in the Mail or Documents module) in excess of 100 long
- 22 projects had an attributes list in excess of 200
- 4 projects had a list in excess of 300 attributes (ouch!)
Having set up a dummy project with 300 attributes to test it for ourselves, it was immediately obvious how frustrating it is to scroll down and scan through a list of 100s of options (which all look pretty similar) to find the one you want and select it.
The solution our guys came up with - an auto complete text box at the top of the Attributes list - should make things much easier. It's a simple, fast and intuitive approach that instantly shortens the list of options based on the filter criteria you enter. So, for example, if you're looking for an attribute containing the word 'Cement' from a list of 150 possible options, you start typing "Cem" and the list will immediately shrink to only display the attributes containing those letters. Sure beats scrolling down a list of 150 trying to find the one you need.
If a simple tool or widget like this has made life easier in an application you use regularly, I'd be interested to hear about it.
Labels: Technology
Marking up drawings
Coordinating the review of drawings between parties on a project is challenging and needs to be planned and controlled. Delays can affect the production or construction of related elements, so it's important to get it right.
One of the most common activities in document review is the marking-up or redlining of drawings. In case you use another term, this is the practice where project team members provide feedback by getting out a red marker and drawing clouds, comments, annotating and sketching over a design drawing.
Recently, web collaboration tools have provided the functionality to perform this process electronically and, in theory, this should offer a far more streamlined way of doing things. If instead of team members having to print the drawing, manually redline it, scan it on the system and then send it to the next person, they can simply open the file on their PC, perform mark ups on screen and click 'transmit'. Collaboration technology can also provide virtual 'review rooms', where participants can join a session to perform a coordinated review from their computer. Sounds easier, right?
Well, not everyone agrees. A complaint I've heard more than once is that electronic mark-up is neither user friendly nor practical - for example, trying to view an A1 drawing on a 15inch LCD monitor just isn't realistic. And many believe that nothing can beat having the copy in front of them.
The solution isn't necessarily clear-cut. I've seen online mark-up work extremely well for companies by speeding up their review cycles and improving coordination between disciplines; and I've also seen manual mark-up work for firms who prefer to stick with what they know. I'm seeing more and more projects use electronic whiteboards as well, which provides a more accurate imitation of the paper-based world.
So, the solution may not be just one product or application, it could be a case of picking from a menu of tools that best support the project's working practices and culture.
For the time being at least, some people will prefer to just get out their red pen!
Labels: Good practice, Technology
In the news... Aconex closes $107.5m growth funding deal
We announced last week that Aconex has secured a AU$107.5 million (US$85m) growth funding deal with US-based private equity firm Francisco Partners. As far as we're aware, it's the largest ever private equity capital raising by an Australian technology company.
As you can imagine, we're all very excited about what this means for the business and are looking forward to using the funds to develop our product and grow the business.
A few things about the deal are particularly significant in the context of the collaboration technology market:
Acceptance of construction collaboration tools
The investment indicates the market's acceptance that web collaboration tools are on the fast track to becoming standard on construction and engineering projects. We've seen global uptake of our system double each year for the past five years and even the most mature markets, such as the US and the UK, are experiencing strong growth.
Excitement around SaaS
Without exception, all the private equity firms we met with had high expectations for the SaaS (Software as a Service) market. A report I read by International Data Corporation estimated that the overall SaaS market will grow at a compound rate of 32.0% annually. As discussed in previous posts, this mode of delivery is by far the most suitable for the collaborative environment of construction and engineering projects.
It's not all doom gloom!
Despite the current turmoil in some financial centers, many of the world's key construction markets - the Middle East, North Africa and SE Asia for example - have so far been unaffected. Firms operating in these boom markets will be considerable less exposed over this tumultuous period, and can still experience strong business growth.
If you want to find out more about the deal, there's a podcast of an interview I did with ZDNet here. Also, our next task is to hire about 50 software engineers, mainly in Melbourne Australia, so if you know of any suitable candidates, please push them to the Aconex website!
Labels: Global trends, Technology
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 web 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 web 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 an online document management 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 online document management 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 web 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 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 web 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 web 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 online document management 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 online document management 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 project 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...
Project 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 project 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 project 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 project 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 project management 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 project management 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 management and reviews, web forms for correspondence management 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 web 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 form of risk management 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 web 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 web 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 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 for correspondence management on 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
