Decline in Dubai?
The article 'Brakes on for Dubai Market' in Australia's Architecture & Design magazine is the latest to flag a "bumpy ride" for Dubai's property market. Written from the perspective of how a dip would affect international companies operating in Dubai, it quotes a director of design firm Woodhead as saying that the drop off in work would lead to significant lay offs. Of course the big question facing firms operating in the region is whether this is an inevitable and short-term cooling, or whether it's the start of a more dramatic decline.
Morgan Stanley didn't make themselves overly popular with developers in August with their prediction that Dubai property prices would likely fall by 10% after years of unrelenting growth. This was largely based on the consultancy's view that developers are relying too heavily on "high end" projects at the expense of more affordable housing (which, as anyone who's tried to find accommodation in Dubai will tell you, is hard to argue).
I was in Dubai a couple of weeks back and, based on how things are looking for Aconex and what our clients are saying, it's looking more likely that this will be an inevitable stabilization of a market that was booming at an unsustainable rate. Over the past 6-8 weeks we haven't seen projects being cancelled so much as people holding off making decisions. This is starting to change and, over the past week or two, projects are getting the green light again.
Whereas there may be fewer of the extravagant, showpiece developments that the city has become synonymous with, there is still demand for realistically-priced housing. This will, in turn, drive the infrastructure projects that population growth in Dubai (not to mention the wider region) is crying out for. I think we'll see that these factors, combined with the Dubai's solid economy and banking system, should ensure that Dubai is still a highly attractive market for AEC firms to operate in.
Labels: Global trends
Building a document
We've just been engaged on an unusual project in the UK - for a start, there's not a crane, brick or piece of scaffolding in sight. Our system is going to be used as the collaborative platform for members of the Sustainable Environment Foundation as they put together their 'green paper'.
This Green Paper is an interesting project. It's a private sector charitable initiative that will report on how the construction industry can minimize its impact on climate change. Companies like BioRegional Quintain, Savills, Lend Lease and even Greenpeace and the WWF are putting the paper together and its findings will be handed over to government next year. All in all, it should be a highly significant report.
The Foundation was keen to use a collaboration tool to cut down on paper usage. It's widely agreed that collaboration tools cut the need for paper (in the 2006 NCCTP study 'Proving Collaboration Pays', 79% of the collaboration tool users surveyed said it reduced their need for paper documents and 91% said they spent less money on couriers and postage), although I don't know of any independent, quantitative comparisons of paper reduction between a project that is using a collaboration tool and one that isn't.
That said, it's encouraging that organizations like those in the Foundation see how collaboration tools can support sustainable practices.
Labels: Global trends, Project profiles
(Re)learning to communicate
Hi there, I'm an Implementation Consultant at Aconex and previously worked for another collaboration provider, CTSpace (formerly BuildOnline). My role involves working with the lead organizations on a project to determine how the collaboration tool is set up and configured to best match their project requirements. Project communication and determining which mail types to use is something that comes up on every project (and nearly always causes conflict) so I thought this would be a good topic to cover - I welcome your views!
A core aspect of any collaboration system is how the project team uses it to communicate. Most collaboration tools allow the configuration of various project mail types to suit the requirements of the team and the project - most importantly this may involve certain contractual obligations when it comes to how these communications are named and distributed.
Typically, the correspondence the team uses will include things like: Architect's Advice, Site Instruction, RFI (Request for Information), Client Advice etc. Part of the challenge when implementing a new project is getting the team to agree on the various types they really need. Discussions can often become confused as various team members explain how they think the team should communicate. This can easily result in a very long list of mail types, therefore making it difficult for a user to decide which mail type to use and also difficult to locate the various pieces of correspondence after they have been sent.
One approach that works well, and enables a more productive discussion resulting in a more appropriate list of mail types, is getting the team to think about the basics of communication. Sound simple? Well it is. No matter how we communicate (talking, phone, email, SMS etc.) we really only use three methods:
- Question or Request - Asking for or requesting information from someone
- Information or Advice - Providing information or advice to someone
- Instruction or Direction - Telling someone to do something
You can probably see where this is going. So for example, an RFI is obviously a question. A Payment Claim would be a request. A Bulletin would be information. Thinking in this way can help reduce duplication, confusion and it also helps document the processes that are invariably involved.
A typical process often begins with a question (e.g. an RFI). Obviously, a question requires a response and so this may come in the form of advice (e.g. PM Advice, Contractor Advice) or a more formal instruction (e.g. Contract Instruction, Principal's Direction). Getting back to the basics also forces us to think about 'closing the communication loop'. So for every request or question, there should be a corresponding response to answer (close) the question.
Terminology is also important where certain words like approval or notice may have contractual implications. But, whatever words are used the team should always understand what mail types should be used and when. Closing the loop must be inherent in this understanding otherwise communication routes will fall apart, leading to mistakes, delays and cost overruns. All this must be documented clearly and concisely and this is where agreeing on processes at the start of the project becomes crucial.
We are all exposed to communications from a multitude of sources and it's all too easy to become bogged down and to suffer from the proverbial 'information overload'. Looking at the basics of communication focuses the team on what's really important and it may even help us communicate more effectively in the world outside our projects.
Labels: Good practice
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 tools, 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, 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 online 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
Seven heads are better than two
One of the best aspects of my job is being surrounded by a talented team of people that come from a range of backgrounds and bring an array of skills and experiences to the table.
Some of them have been itching to throw in their thoughts about the trends they see when out and about on projects and the feedback they get from clients. So, in addition to Rob and me, we have invited five guest bloggers from around the business to become occasional contributors to Built on Collaboration.
The new bloggers are...
- Kim Au, an industry consultant with a background in project management and QS
- Stewart Stead, a doc controller who travels the world advising clients
- Stuart Watson, our product manager
- Ed Surgeon, a project manager who specialises in Middle East mega projects
- Nathan Harrison, our helpdesk team leader
You can read their full profiles here.
Good to have you on board guys!
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
SaaS: flexible, scalable, affordable
Perhaps 12-18 months behind the UK and US in its adoption rates, but good to see that Australia is catching on to the value of the software as a service (SaaS) model. An article called "Software Engine at the Ready" (login needed to read it) in the 21/8 issue of Business Review Weekly magazine profiles a mid-tier construction firm's use of SaaS technology.
Like most mid-tier contractors, the firm, Ichor Constructions, operates on multimillion dollar budgets on paper-thin margins, and the sophistication of its project management software can decide success or failure. The prohibitive cost of purchasing the required software meant that Ichor was unable to tackle more complex, lucrative projects. The article explains how, by using a SaaS project management tool for its benchmarking and forecasting, they were able to grow from a $15 million company to a $50 million company.
Talking about the initial reasoning behind the shift to SaaS, Ichor's GM is quoted as saying, "Cost was the biggest factor. By running the software on a remote server it's a lot cheaper than owning and maintaining it internally, and I don't need to worry about finding someone with the technical expertise to make my server work."
Whether for tracking forecasting data or managing documentation, more and more construction and engineering firms are moving towards SaaS solutions due to their flexibility, scalability and affordability. In the online document management market we're already seeing the SaaS providers pull away from the pack as clients see the value of this model.
Labels: Global trends
