Built on Collaboration

We have split into project teams (construction, decoration, catering and fundraising).










We have to raise AU$3,000 to buy the construction materials we need to complete the project. We need all the help we can get if we are to get these children the classroom they need!

Labels: Good practice

posted by Robert Phillpot View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

• 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.

Labels: Global trends, Good practice, Project profiles, Technology

posted by Robert Phillpot View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

Labels: Global trends, Good practice, Technology

posted by Robert Phillpot View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

Labels: Global trends, Good practice, Technology

posted by Robert Phillpot View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

We recently ran a competition within Aconex, asking staff to send us their best stories about why clients said they used a collaboration system. An iPhone was at stake so competition was fierce. Here are a few of my favourites, starting with one of the more sensible entries...

"A client that implemented our system on a high-rise office tower development in Australia recently told us that, over a three year period, no variations were paid due to incorrect documentation - a first for them. They said that they typically paid variations as high as 1% of project value due to poor document management. They also said that by managing their project information online, they saved around 2.7 tonnes of paper."

Good to hear! However this one, from one of our US-based client service team, takes this biscuit for most compelling reason...

"My latest trip to Columbia was an interesting one. The day before I flew in, the client for a pipeline project had their office robbed. Some employees were tied up and all their computers were stolen. So, as you can imagine, you can't implement a system with no computers! The client said to us how they wish they had our collaboration system before the robbery, as they wouldn't have lost all their project information. I guess you really never know when your data could vanish!"

And finally, also found this one quite amusing...

"A document controller in the UK once told me why he enforces the use of Aconex across his organisation. He said he once went to retrieve some important hardcopy documents in a box, and when he opened the box all that was in there was an old paper plate and a chocolate bar wrapper, NOT the very important documents that were needed."

Labels: Good practice

posted by Leigh Jasper View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

Front page of Australia's main business newspaper, The Australian Financial Review, last week, was the story that, to help state governments deliver high-risk infrastructure projects, Treasury officials are developing a national set of principles for 'alliance projects'. This would mean that, on publicly funded works, governments would share the burden of cost blow-outs and delays with contractors.

Often called a "pain-share/blame-share" arrangement, alliance projects help both parties to pull together towards the common goal, without the commercial barriers, red-tape and finger-pointing that can slow things down. Without question, this is a positive move and should fast-track the complex projects needed to boost the economy, while ensuring optimum use of public funds. Whether other countries that are also in a hurry to push through stimulus package-driven infrastructure projects follow a similar path remains to be seen.

With an alliance project, it's only logical to use an online collaboration platform. In line with the spirit of the contract, parties working together with common goals should use common systems. Using a project collaboration system facilitates a culture of trust, supported by transparency and information sharing – both major contributors to project success.

On top of this, I can think of at least three reasons to use an online collaboration system on projects of this type...

1. These are large, complex projects that will involve dozens of companies, sharing hundreds of thousands of documents and mails. They should be using a collaboration system anyway!
2. As well as streamlining communication between parties, both entities (and indeed everyone on the project) benefit from the gains in efficiency. What would be the point in one party using a best-in-class online collaboration system to manage their project information, while the other gets buried in paper documents?
3. In the event of dispute, the audit trail on a collaboration system can often help to resolve the matter quickly, without souring the relationship by resorting to litigation or arbitration.

Has anyone (successful or unsuccessful) worked on an Alliance project? Be interested to know your views regarding the client-contractor relationship.

Labels: Global trends, Good practice

posted by Kim Au View 1 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

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

posted by Edward Surgeon View 3 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

We obviously talk a lot on this blog about the benefits of using collaboration systems during projects, but what about at a project's end? The Handover process - where all the documentation relating to the built asset is transferred from the project team to the client/developer ready for operations - is an important process when a project draws to a close.

A comprehensive handover is essential as it provides operators and those responsible for defects liability with the data they require for asset management - from where electrical cables and gas pipes are positioned to the specifications of door frames and lighting fixtures. If there are flaws in this process, clients can end up wasting time and money trying to source or reproduce documentation, and can be exposed to risks relating to health and safety and other compliance standards. Over the years, I've heard numerous horror stories about this data being missing, and new fit-out contractors drilling around live utility cables - not good!

We're working on a large, multi-faceted development in the Persian Gulf at the moment which involves several separate packages as part of one master development. Combined, the project teams have generated several million drawings, documents, tenders and correspondence items, which, under the developer's insistence, have been stored and managed using a collaboration system. Now that contracts are coming to an end, this is looking like a very smart move.

Because all data from across the program has been managed using a collaboration system, the developer is finding the usually fraught handover process a relative breeze. For the first time, they are sure that all the participants are able to contractually complete the formal handover. For them, this means three things: 1) All contractual conditions are met, 2) All documentation, from as-builts to variation requests, is stored in one secure, online archive, and 3) Document retention regulations are followed in a very cost effective manner. And this has all been done at the click of a button, with no need for vast paper archives.

Labels: Good practice

posted by Leigh Jasper View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

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

posted by Stuart Watson View 3 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

For any organization with more than one employee, you can safely guarantee that its staff are going to have different approaches and levels of discipline towards filing their communication and documents. More often than not, this places inter-team retrieval of information somewhere between difficult and impossible. This week I was pleasantly surprised to hear that one of the largest developers in the Middle East is tackling this challenge by creating a key performance indicator for their project management staff which measures usage of their online collaboration tool.

The point here is that at a corporate level they realize the only way to ensure they are building and maintaining a complete and accurate project record is to insist that their people use the collaboration system. As far as KPIs go I reckon this one really makes sense for all concerned. For the company, they're ensuring that they have a full audit trail which reduces their risk exposure. For the individual, it's no extra work, and all of their filing is done in "real time" which arguably reduces their workload as well.

Labels: Good practice

posted by Ed Surgeon View 1 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

In response to my previous post, Emmanuel Netter, a senior figure at a French collaboration provider Prosys, made the comment that, rather than being stored on drawing racks, drawings have been archived on diskettes for 20 years and that electronic sharing media such as FTP and email were the real competitors for collaboration tool vendors. Both good points, so worth discussing further.

I think Emmanuel and I may be talking about slightly different things with regard to the archiving of drawings, so I'll clarify what I meant. The 'putting new drawings on rack' replicates the process of taking the current new document and putting it on the plan rack in the construction site office. In a consultant's office, this may not be the case (most consultants' offices do not have a live physical plan rack), but construction site offices usually do. Although most people put archived (superseded) drawings on diskettes, in my experience the current drawing is nearly always on a live rack somewhere in the site office.

As an aside to this, I've always felt that archiving drawings to diskette is only marginally faster, and no safer (from a long-term archiving and retrieval point of view) as physical rolls of drawings on a shelf. Both can be lost and damaged and are difficult to locate when you need them later.

On the second point, Emmanuel is right that FTP and email are often seen as competitors to collaboration tools (as are paper documents). As evidence of this, you only have to consider that more than 90% of projects globally don't use a collaboration tool. However, hopefully sooner rather than later, these tools really shouldn't be regarded as genuine competitors to collaboration systems, for a couple of reasons:

1. FTP and email are just way of distributing information - not revision control or audit trails - so if they are used, they are only part of a solution and need additional components (a database or spreadsheet for revision management, something to capture the audit trail, some way of archiving and retrieving superseded information, a workflow engine, security and permissions, etc, etc).
2. Across the world, traditional offline systems (and remember that an internal electronic document register is offline) still outnumber online systems (of all kinds) - although the trend is fast moving toward online document management.

For a future post, I'll look at comparing the time it takes to perform a task using online collaboration to using, say, an in-house document management system. Something tells me that the online method might win!

Labels: Good practice

posted by Robert Phillpot View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

Revising documents - the process of replacing an existing document with a new or updated version - is a core part of project information management.

When using an online collaboration tool, revision of a document on the system automatically causes the old version to be archived, and the new one to become the default available version.

For many, this is one of the best features of an online project collaboration system, as it virtually eliminates the chance of someone working off an old version - and the savings in re-work costs (and heated disputes) are welcomed all round. Plus, there are the risk management benefits of having a complete, documented archive of every transaction.

All well and good. But what really got me thinking was the time difference between revising a set of, say, 100 drawings the traditional, paper-based way, and doing it online. I started thinking through the steps pitting man against machine, here are my calculations...

Table: Time taken to revise a set of 100 documents

About 53 times faster using a collaboration tool. As one of our first clients said to us, "This will save me about ten hours a week!"

And this doesn't even take into account the fact that, when using the traditional methods, this update would only get done weekly or even fortnightly (and in the meantime, you have people working from out of date documents). With a collaboration system, you run this process a few times a day and files are updated instantly.

Kind of speaks for itself doesn't it?!

Labels: Good practice

posted by Robert Phillpot View 7 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

The more reminders I can get to do something the better. Chances are, even with a calendar, a Blackberry (and a wife) there is always a task or two that slips through the cracks.

For people like me, the reminders feature that some collaboration systems provide is an invaluable tool to help manage and coordinate tasks on a project. Crucially for the project environment, it can be used both as an individual task management tool and as a collaborative tool to help keep teams on top of deadlines.

Although task scheduling can seem like such a small, mundane thing to be thinking about (not to mention writing a blog post about!), the impact of missed deadlines can be considerable and costly. Here are some simple examples of common scenarios on projects that the reminder feature can be useful for:

For individual use:

• When reports are due
• When to evaluate and prepare payment certificates
• To follow up a team member on an issue

For collaborative use (assigned to project members within or outside your organization):

• Reminders to attendees about upcoming meetings
• Assigning 'action items' from meetings to appropriate project members for action
• Reminding subcontractors when deliverables are due (such as O&M manuals, insurance certificates)
• Requesting consultants to conduct site inspections

Task management is a skill that requires a degree of discipline and organization from the individual. When used effectively it keeps you focused on what you and your team really needs do, which will, in turn, help keep the project on track.

Labels: Good practice

posted by Robert Phillpot View 1 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

The industry as a whole has become pretty good at following document numbering conventions for drawings and other consultant-produced documentation. But when it comes to clients, PMs and head contractors, some tend to scratch their heads when thinking about how to number the documents they produce.

When you think about it, it shouldn't be a problem at all. Whether building a hospital, sports stadium, office tower or hotel, there will always be the same types of documents: monthly reports, OH&S reports, PCG meeting minutes, weekly design meeting minutes, project plan, master programme, risk register, budget and so on.

A strategy I've found useful to de-mystify numbering to Clients/PMs/HCs is to get them to produce a list of all the documents that they produce on a project. The list can then be categorized into document types (e.g. report, meeting minutes, programme, register, etc.) and numbered sequentially from say 001.

At this point the variables within a document number have been established. The rest is easy! The other typical elements of the number should be relatively constant, such as project code, organization code, zone (usually a 'site-wide' code for management companies), discipline (normally something like PM for project management), then document type, then sequential number.

The final step is to pre-register these documents. If companies can get all (or close to all) of their standard documents onto the collaboration system as early as possible then, when they actually produce that monthly report, they don’t have to face that fear of not knowing what the document number will be. They simply supersede the existing "place holder" and update the revision date and status.

Other benefits to pre-registering place holders for standard documents include:

• Improving organization within the team
• Having a defined set of deliverables
• Ensuring consistency
• Ensuring that the most important documents can be easily retrieved from a secure system
• Ability to marke sensitive documents (such as budgets and contracts) as confidential so that only the people nominated can see them.

These are real benefits, of the time-saving, efficiency-improving, protocol-complying and confusion-eliminating kind!

Labels: Good practice

posted by Ed Surgeon View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

In my previous post '(Re)learning to communicate', I wrote about how simplifying correspondence and communication can help determine what mail types to use on a project. For this post, I thought I'd turn my attention to documents.

Documents form an important part of any collaborative environment be it offline or, more importantly in our situation, online. Most web collaboration tools allow a team to create a series of document 'types' that are used when documents are added to the system. These are fields in the database that allow a user to 'tag' each document with the appropriate type. The document can then be searched for using this tagged information. For example, commonly used doc types include: drawing, report, schedule, specification and so on.

As with mail types, the difficulty comes in getting a project team to agree on the set of document types. It's very easy for the list to become long and confusing, which can result in documents being incorrectly tagged, making searching a problem. To help avoid this, here are a few pointers to get the list of documents right...

Think high-level
It's important not to make the document types too detailed. The type should only broadly describe what the document actually is. We often see things like Report - Weekly or Specification - Electrical. This is too specific. The exception would be when large volumes of the document are expected, such as drawings. Here we would often want to separate regular drawings from say, shop drawings. But for most other types of document, unless the numbers are going to be high, life is a lot easier when the type is as general as possible.

Don't include information in the document type that should be somewhere else
Okay, so that recommendation is a a bit of a mouthful! The point here is that, with a collaboration tool, we can break the data relating to the document into smaller chunks (e.g. type, status, revision, title etc.). These chunks can then afford us very powerful cross-referenced searching and reporting abilities.

For example, imagine you were searching for a house for sale online. If all the information had been included in just a couple of database fields, it would make locating a property next to impossible. Instead each property has a whole host of data associated with it (location, number of bedrooms, price, car park spaces, etc.) in separate chunks. All of this can be searched on in any combination. It's the same idea with web collaboration tools.

Avoid ambiguity
When creating the list of document types, the names should be obvious to everyone in the team. I find a good rule of thumb is that if a user spends more than 10 seconds looking at the list of deciding which one to pick, the list is either too long or too confusing (or both). If users are confused, there's a high chance they'll end up selecting the wrong type and this will result in searching and reporting capabilities being compromised.

So, the document type is one distinct field in the database. Keeping the various pieces of information that describe a document in separate fields is the secret to an efficient and well used system. On top of this, keeping the information in each field high level allows for more powerful and flexible searching and reporting.

Labels: Good practice

posted by Chris Hudson View 1 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

It's always confused me why some online document management systems have an 'open filing' approach where all project files are available at point of upload. A better model is one that requires the user to create a 'transmittal/transmission' of the documentation.

Whereas the open filing model is straightforward to use, it doesn't include the audit trail that a transmittal provides, where key transmission metadata can aid reporting and tracking (not to mention reduce the likelihood of disputes).

The second model also more closely simulates the paper-world view. Although having an open filing system provides an effective 'dumping ground' for documentation, this isn't what really happens on a project. There still needs to be an environment where each organization can store and manage its own data prior to release to the required project team. Because of this, there needs to be a location for all project documentation with the ability to selectively distribute them as and when required.

This is my view, but I'd be interested to hear examples of where open filing systems work.

Labels: Good practice

posted by Stewart Stead View 2 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

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 web 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 web collaboration system is how the project team uses it to communicate. Most web 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:

1. Question or Request - Asking for or requesting information from someone
2. Information or Advice - Providing information or advice to someone
3. 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

posted by Chris Hudson View 1 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

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

posted by Kim Au View 1 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

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

posted by Robert Phillpot View 2 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

One of the things we like to use this blog for is to share some of the good practice processes that we've identified through working with clients. These can help projects run better and avoid the cost and time impacts of poor document management.

The control and revision of documents is one area where establishing good procedure between participants can really help a project. Areas to focus on include the numbering, revision and status of documents, the control of transmittals, and the maintenance of a document issue register.

Use of an online document management system can ensure a best practice approach to the generation and management of document registers. We've identified four principles of good revision management that should be agreed between the collaborating parties - whether or not an online document management tool is being used.

1. The document numbering system should be agreed at the start of the project
   Clients may insist on implementing their own document numbering system, or participating organizations may combine to create a new system. Whichever way is chosen it is important to make a clear statement about the system and to ensure all parties are aware of it and use it.
2. The revision coding system should be agreed as part of the above numbering system
   The most common revision systems are based on a numeric (1, 2, 3 ...) or alphabetic sequence (A, B, C ... AA, AB, AC ...). In some cases, numbers are used for revisions up to the 'For Construction' issue of documents, with letters used for revisions from that point on. Alternatively, letters and numbers can be combined, with the sequence reverting to a letter at agreed points in the revision process (A1, A2, A, B1, B2, B, C1...). Some organizations develop more complex coding to reflect their own internal review stages (e.g. A1-01, A1-02, A2-01...).
3. The revision code must continue sequentially from the first issue of a document through its entire life
   This allows all participants, including those not involved in the creation of a document, to understand how versions of documents relate to each other. There can be exceptions to this rule if predefined. For example, the revision code may revert back to A or 1 at the completion of each stage of a project. This is a complicated requirement and requires careful management and quality control.
4. Revisions must be clearly identified within a document
   In the case of a drawing, there will normally be a revision cloud around the area of change, with a revision letter placed inside a triangle attached to the cloud. CAD drawings would have this on a revision cloud layer, with a new layer created for each cloud.

We see these four principles as being essential for effective document revision management. Let us know if there is anything you think should be added to this list.

Labels: Good practice

posted by Robert Phillpot View 6 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

I was talking to a project manager at construction firm Hansen Yuncken who said that, by using an online document management tool, his project has reduced its printing costs by 80%.

That is really quite an amazing stat. It was easy for him to calculate because they pay a monthly fee to a print centre, so he simply compared his costs to a similar sized project that wasn't using the collaboration technology.

If anyone else has tracked how much online document management systems save in printing costs, we'd be very interested to hear what you've found.

Labels: Good practice

posted by Robert Phillpot View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

Labels: Good practice, Technology

posted by Leigh Jasper View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

Following last week's post 'Paper cuts', one of my colleagues who used to be a doc controller sent us his thoughts:

"Design documentation is increasingly being managed on an A3 scale with only the co-ordination drawing being larger than that. This allows for drawings to be viewed more easily on screen for markup purposes - with less contained in each drawing, it is easier to review (a comment from Tiago Neves suggests that interactive surfaces, such as the whiteboards commonly used in schools, can further support this process).

"However, this can lead to an increase in the number of drawings, as CAD systems allow the full document to be broken into reviewable elements.

"Drawings are then 'issued for review' in PDF, so that no changes can be made to the underlying document - apart from mark up on a new layer, and the addition of the reviewer's information for approval purposes.

"You will never, not for long time anyway, do away with hard copy documentation 'on site' as there will always be a requirement for user groups to have the plan in front of them for reference during construction/fabrication of the pre-fab units. The only time that I see this changing is when everyone on site is issued with a hand held viewing device (see comment from Paul Harding of Brookfield Construction) linked to central servers beaming the information to them as required. So, until then, document control can phase into online document management with the reference copy being issued to site 'for use'".

Labels: Good practice

posted by Robert Phillpot View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

We had an interesting comment from Emmanuel Netter, a senior figure at French collaboration provider Prosys, regarding Leigh's post 'Counting the cost'. Emmanuel highlighted two factors that would make banishing paper on construction projects a tough challenge: 1) A drawing is generally a large document and so is difficult to review on a screen; and 2) People need to use documents in the field.

I absolutely agree that we will never completely banish paper from this industry (although our post 'The Paperless Project' discusses one project's attempt at this), but we can reduce it where possible.

Paper is often necessary during review. While we have many projects now doing review and mark-up online, many still use paper to do mark-ups (while still tracking the documents electronically after each review step). It also does make sense to do reviews using A3 versions of the document - although one needs to consider the scale and detail of the particular drawing being reviewed. This not only saves paper, but makes scanning the document back into electronic storage much easier.

And, yes, the most current document does need to be physically present on site in most circumstances. But there is no need to print or re-print for archiving or wider distribution. That can be done electronically and is where a lot of the savings lie. One of our projects claimed that, compared to a similar project using traditional methods, they saved 80% of their printing costs. Considering that printing costs on a project can easily be in the tens or hundreds of thousands of dollars per month, this can be a significant saving over the duration of a project.

Labels: Good practice

posted by Robert Phillpot View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

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

posted by Robert Phillpot View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

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

posted by Robert Phillpot View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

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

posted by Robert Phillpot View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

An article in the latest issue of US-based Constructor magazine entitled 'The Electronic Paper Chase: What You Don't Save Can Hurt You' outlines why companies need effective systems for document retention in order to meet new 'e-discovery' laws.

Two key points I took away are that businesses must act now to set up systems and policies for document retention; and that failure to comply with the new rules by not providing electronically stored information will likely see firms lose any legal case.

The issue of document retention has huge legal, as well as operational, implications for construction projects. And the larger the project, the greater the exposure to risk resulting from not maintaining a complete archive of documentation and correspondence.

Most online document management tools provide detailed audit trails and don't allow files to be deleted for any reason. One of our clients, a senior project manager on a multi-billion dollar hotel development, was recently asked by a journalist how important the document collaboration system is for his project. He said:

"Although it is often understated, a very significant feature of Aconex is that deletion of records is not possible. This means that we have easy access to critical information that may result in significant benefits such as cost savings, for example. In addition, access to important information means that certain issues can be clarified factually quickly and easily."

This wasn't the answer I was expecting - his project has any number of operational challenges. However, considering the litigious world we all operate in, perhaps it's not surprising that he sees the real value of online document management as being in risk management and reduction.

If anyone has a horror story about lost documents on a project, we'd like to hear them.

Labels: Good practice

posted by Leigh Jasper View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

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

posted by Robert Phillpot View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

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:

1. 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).
2. Having a system that allows docs or files to be deleted is bad for the audit trail and court-worthiness of a system.
3. 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.
4. Google Docs does not have an organization-employee and project structure, which does not suit large construction and engineering projects.
5. 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

posted by Robert Phillpot View 2 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

An experienced architect that has also been a colleague of mine for several years has suggested a procedure for handling CAD drawing & X-Reference file exchange. Although the text was written for users of the Aconex system, it can be applied to most online document management tools.

Two points to note is that the author of the drawings should have a logical drawing numbering system (hard & softcopy matching) and should also have a logical reference file or X-Ref numbering system.

Here is the suggested procedure:

1. Drawing author uploads and registers drawings and X-Ref files to the system.
2. Author transmits files to relevant consultants.
3. Author transmits X-Ref files to relevant CAD Manager.
4. The CAD Manager downloads X-Ref files to a specified folder on the organization's local server, for storage of X-Ref. Note that, using the 'CAD Standard' and the 'Config' functions in AutoCAD, it is possible to define a standard set of X-Ref folder structures to be used by all project participants.
5. Relevant consultant designers download drawing files to their PC or network and open them in AutoCAD. The related and current X-Refs will be automatically extracted from the local network folder location. This is likely to already be set up.
6. When an X-Ref file is updated the drawing author simply needs to upload and supersede (replace) the previous version of the file and run an Auto-Update-Transmit which automatically identifies the previous recipients of the file and sends them a transmittal. All they need do then is simply download as before and overwrite the previous version of the file with the latest working version (most online document management tools store all historical versions so users don't need to manage this aspect).

The advantages of using this process are that:

• Consultants do not need to change the way they work internally with CAD files - they will not be required to modify their existing folder structures.
• X-References can be sent independently from the Drawing files either on a scheduled milestone basis or an 'as updated' basis. This will mean that X-References do not need to be uploaded every time a drawing file is uploaded. This reduces the impact on upload/download speeds (compared to uploading the X-Refs each time).
• All project information is maintained and managed on one central platform, from where it cannot be deleted.
• There is a full audit trail of document updates and transmittals. Because the web collaboration tool stores all historical versions of all documents, users no longer need to manage this aspect internally.

I'd be interested in your thoughts on managing this type of issue. Is there a better way?

Labels: Good practice

posted by Robert Phillpot View 2 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

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

posted by Leigh Jasper View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

I'm writing an article on what happens when some of the companies collaborating on a particular project are direct competitors in the 'real' world. It's an interesting topic, with no shortage of contentious areas, such as how competitors share intellectual property and who controls it.

To achieve successful project collaboration, I strongly believe that companies must have complete control and clear ownership of their intellectual property. One drawback of using installed software on a multi-company construction project, for example, is that firms can be required to store their drawings and documents behind a competitor's firewall. In a litigious world, this does little to encourage collaboration! In contrast, most project collaboration vendors that deliver their product using the SaaS model provide an independent platform that allows each company to own and control the files it has created or received. This creates a level playing field for everyone on the project - and encourages collaboration.

I'd be interested to know your experiences in this area. Have you ever collaborated with a competitor? What were the implications regarding control or ownership of project information?

Labels: Global trends, Good practice

posted by Leigh Jasper View 1 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

This is the final part of my argument against relying on email as a project communication tool. To summarize, email is fine for what it's intended for - personal communication - but it is completely insufficient for project correspondence management. Thankfully collaboration tools, although not perfect, offer a superior, more sophisticated alternative. Here are some of the main benefits of using a project collaboration tool to manage project mail:

Assured delivery - The sender can be sure that every intended recipient has access to the mail. There is no uncertainty about spam filters or oversized attachments, and no room for excuses or disputes.

Retrieving mails - All incoming and outgoing mail is indexed so that it can be searched for using project-related criteria such as status, keywords (subject or body text), attributes, date ranges, sender and recipient details, organization and mail types. This is far more relevant to the industry's needs and means people can find what they're looking for in a fraction of time it would take using a standard email program.

Transparency - All project mail can be accessed by any authorized team member. This is particularly valuable when people leave projects as mail cannot be deleted or lost. Individual email inboxes are the enemy of good collaboration!

Configurable to the project - Mail types, auto-text, standard forms and being able to attach attributes save time by automating tasks and making it easy to retrieve and categorize project mail.

Data storage - Many online collaboration tools provide unlimited data storage to encourage widespread use, so there is no risk of mail bouncing due to excessive file size. Email's limitations on attached file sizes make it an impractical tool for an industry that routinely transmits massive drawings and other documents.

Security - With the best collaboration providers, project information is stored and backed up in independent data centers and there are multiple physical and technical measures to protect the integrity of the information. Anyone who has had a laptop stolen is only too aware of the flaws in the email security model.

Reporting - Collaboration tools can generate reports on correspondence to aid decision making and provide accountability. For example, within a few clicks, a list of all outstanding RFIs can be generated. Managers can run reports on all mail sent and received so there are never any doubts around what has been committed to or requested by each company.

Some other benefits of online project collaboration over email include:

• Automatic filing of all outgoing & incoming mail
• Enforcement of agreed communication protocols (how often is an email sent with no subject line?)
• Use of approval functionality to control the issue of mail e.g. by junior staff.

Looking at the bigger picture, the real benefit of using a collaboration tool instead of email can be measured in terms of peace of mind. There is much better risk management with reduced exposure to disputes, information loss, delays and litigation, any of which can derail a project by impacting on time, cost and quality.

Labels: Good practice

posted by Leigh Jasper View 2 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

This is such an extensive topic, that I've split it into three parts. The previous post put forward my belief that email is not a suitable tool for project correspondence management. This post will highlight some of its limitations, and the third part will compare email capabilities to what project collaboration tools deliver.

Many of the projects we work on don't allow email to be used for formal project correspondence. Clients see it as uncontrolled, untraceable, unable to handle large files reliably and severely lacking as a filing mechanism.

Uncontrolled - Email gives a manager on a construction project no visibility what his staff has sent to contractors, vendors, consultants and clients. He doesn't even know what has been received by members of his own team. As he can only see into his own mailbox, he has no control over what others have sent and how his staff has responded, meaning a loss of control and ineffective management.

Untraceable - As email uses standard http protocols, users have no idea whether sent mail was ever received by the intended recipient. They also don't know whether they have received mail that was intended for them, as email does not provide any delivery guarantees. This also means that email is of limited value in an arbitration situation, as it is difficult to prove beyond doubt that a mail was ever received.

Inability to handle large files - Even if a company's mail server can handle 5 MB attachments, can the recipient's? How can the sender be sure that the drawings were received? When drawing transmittals contain 10, 20 or even 100 drawings, each at least 500 KB in size, email struggles to cope. In many cases this means that formal correspondence (letters, drawings, RFIs, etc) are handled in different systems and are not logged or tracked in real time.

Unsafe - Email is an open, non-encrypted protocol. Almost anyone can intercept, read or alter outgoing and incoming email. Retention of data can be an issue, too. In Outlook (for example), mail is saved in a .pst file, which has a default limitation of 1 GB. A typical project manager or doc controller will hit 1 GB after a few months. Most users are unaware that MS Outlook then starts to delete the oldest mail, to keep the .pst file to the 1 GB (or whatever their default setting is). When a company doesn't back up its .pst files (and most don't), this is information lost forever.

There are clearly some considerable downsides and risks to using email for managing critical project information. Project collaboration tools provide an industry-tailored alternative. The next post will look at what they can do that email can not.

Labels: Good practice

posted by Leigh Jasper View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

In response to my post 'Skill shortage just part of the jigsaw' on the importance of good recruitment, a reader sent a comment asking how you can be sure you've got the right people already in place.

Good question. We've found that, even if employees have the right skills, people that don't fit with our culture and values don't operate well in the fast-moving environment of our business. So we try to make sure they're a good fit before they join - prevention being better than cure. To do this we make sure every prospective employee is interviewed by at least three people, and that they show signs of what we look for. In our case, things like flexibility, a can-do attitude and the propensity to take risks are on the list, but each company will have its own culture and its own list of behaviors.

When these people are in place, their manager tracks not just their performance, but how they rate against a list of defined values - including innovation and contributing to the working environment. We've found that employees that can do well on these measures (and not just in achieving their targets, though that's important too) tend to be the 'right' people and bring the most value to our organization.

Labels: Good practice

posted by Leigh Jasper View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

People tend to associate collaboration tools with managing documents, but they're equally used to manage project forms and correspondence such as RFIs, advice notes, variations, and so on. In this way they replace project team members' email accounts (MS Outlook and Lotus Notes).

People often ask about the advantages of using the collaboration tool rather than email. This is understandable - after all we use email every day, almost without a thought. Why add another application?

Email is a standardized business tool, widely used for communication. But it's not capable of being configured to a project, a company, or for an individual project participant. It's simply an electronic post-box with either a person's name or project/company name as a point of delivery. Collaboration tools, on the other hand, have been created to deliver a project-centric correspondence management platform that is tailored to the AEC industry.

It's important to make the point that collaboration tools are not intended to be 'super' email programs; they are specialized systems for exchanging project forms. Because they have been created for this purpose, they can deliver features specific to industry needs - improving speed, accountability and reporting.

In the next post I'll consider why web-based collaboration tools beat email when it comes to project correspondence management.

Labels: Good practice

posted by Leigh Jasper View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

In an early planning meeting, someone on a project we're working on requested a 65 digit number for a document! This code wasn't just numbers, it included letters and symbols as well. There's no doubt that this system was super-organized, but is it practical? It's worth remembering that the doc number has to be understood by everyone, including external suppliers and subcontractors. Plus the longer the number, the greater the risk of human error.

Whether they are paper or electronic, documents are the foundation of a construction project. Clear labeling is essential, both for initial storage and later retrieval. But using a document number of 50+ characters really isn't necessary. Most of the information contained in the doc number is in the document itself - which the user will read anyway - or in the attached metadata.

A concise numbering protocol can contain all of the required project information, and can be more than adequate for search, retrieval and reporting purposes.

So how long should a doc number be? There's no hard & fast rule, but a document number can be as short as 5 digits, with a simple discipline descriptor and a sequential number assigned to certain project elements. Most projects can benefit from a numbering protocol that is under 15 digits in length. When broken down, it only needs to hold Author-Discipline-Project Location-Sequence. This is far easier to understand for everyone on the project and, most importantly, its simplicity means there's less chance of someone, somewhere, making a mistake.

Labels: Good practice

posted by Robert Phillpot View 1 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

There's an interesting feature on Innovative Projects in the December 3 issue of McGraw Hill's Engineering News Record magazine. The project profiled in this issue was a shopping mall and hotel development in New York state, where the developer, Cianbro, is challenging its contractors to go Green to the extreme by using 100% biodiesel fuel, recycling up to 97% of construction waste and being paper-free.

Unsurprisingly it was the paper-free part that interested me the most. On this project, drawings are replaced by whiteboards, wall-panel displays and 47-inch desktop monitors showing models of geometry, schedule and cost as well as architectural models and other modelling software. An online document management tool is used and on site paper is being replaced by pen-sensitive tablet PCs.

Although implementing this practice on all projects is still a long way off, it's a great aspiration. In the mean time, we can see projects gradually moving towards being as paper-free as possible. At the moment, most people still want to use a paper drawing out on site for the final build. But reducing the use of hard copies of drawings during the shop drawing review process significantly cuts the printing volume on a project, reducing cost and waste. This is where online document management tools can play a big part - for example, a client recently told us that they'd reduced printing by 80% on their project.

The paperless project was dismissed as a pipedream when collaboration tools first went on the market. Just like the paperless office, it seems we are not quite there yet, but online document management systems do seem to be helping the industry move in the right direction.

Labels: Good practice, Project profiles

posted by Leigh Jasper View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

We recently received feedback from an engineering manager about the use of online document management on an oil storage terminal development in Singapore. His comments about how his company was using our system highlighted some key differences between how construction and engineering projects use collaboration technology.

This project still enjoyed the usual benefits of collaboration technology (finding and sending files quickly, reduced admin costs, a strong audit trail, and so on), but the main benefits were in managing vendor documents and in the tendering and procurement processes. To build their oil facility, his organization needed to source components from specialist suppliers around the world. In fact, about half of the total value of their project was allocated towards purchasing equipment and materials, which were to be sourced from vendors across Europe and Asia.

Particularly for the complex, high value items, a huge amount of documentation is generated with each purchase, including drawings, data sheets, specifications, maintenance manuals, quality docs, and certificates. So, for this person, the main benefits of using online document management were in streamlining the tender process by being able to create, issue and manage tenders electronically, and in managing downstream communication with suppliers and contractors, by controlling thousands of documents more efficiently.

Labels: Good practice, Project profiles

posted by Robert Phillpot View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

At this time of year, many of us are ready for a holiday, or at least a short break - there's a lot to be said for taking some time to physically and mentally recharge for the year ahead. Last week e-magazine Smart Company asked me for some tips on keeping motivated and avoiding burnout. Here's what I came up with...

• Delegate
• Spend time with family (especially kids) to put things in perspective. Often shows how easy running a business is!
• Prioritize time or, if you can't, find someone who can do it for you
• Try to take at least a one day a week off - don't let work encroach on both weekend days
• Surround yourself with positive people, and avoid whingers and moaners
• Have a strong support network of people inside the business and outside that can offer advice and be neutral sounding boards
• Keep the brain sharp e.g. by spending some days outside the business to do a training course
• Try to think of business as a marathon not a sprint (although this is rarely applicable on a project!).

So, on that note, we're both taking a few days off. We hope you've had a good year and we'll be back in 2008.

Labels: Good practice

posted by Leigh Jasper View 1 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

It may be because it's Monday morning, but a bit of a bugbear of mine in terms of industry practices is the insistence on having a wet signature at all costs. In some markets, all project correspondence and documents have to be printed out and hand signed, occasionally as a legal requirement, but more commonly because that's how things have always been done. Talk about needlessly slowing things down!

This stamp of approval can be applied just as effectively, using the same process and with no loss of security, using an online project management collaboration system. When sending a piece of correspondence or a file using a collaboration tool, it is tracked on the system. Secure login ensures authenticity and authorization is done at the click of a button rather than having to go through the print, sign and send routine - speeding things up infinitely.

No doubt there are plenty more transactions like the wet signature that still lurk on projects here and there. Surely it's only a matter of time before they migrate to the digital world?

Labels: Good practice

posted by Robert Phillpot View 0 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit

Something we're big on is championing the role of the document controller. Traditionally the role has been seen as an admin position, often filled by a fairly junior recruit. However the increase in size and complexity of projects has elevated this role to be something far more important. They are now a crucial, integral part of the team that can improve efficiency, manage risk and help drive change. In some ways, I think the growth in online document management systems has allowed this progression to take place.

It has meant that document controllers need to be experts on the system they are using. With their knowledge of the system, they are relied upon to provide input into good practice document management processes and then oversee implementation. This requires in-depth industry knowledge, IT savvy, consulting ability and no shortage of communication skills, as they coerce and cajole team members into good document management practice and good use of the system.

As the project is underway, the document controller becomes the custodian of the flow of information, essentially the lifeblood of the project. In today's climate, with smaller margins, tighter timeframes and greater risks, this role has to be performed to the highest standard. If there is a dispute, parties rely on the document controller to have implemented procedures that capture all correspondence and documentation, with an audit trail of what happened and what was agreed upon. They essentially become mediators in settling disputes and if their job hasn't been done properly throughout the project, it can be expensive for parties involved.

Despite this general re-rating of their stock, it's clear that the value of the document controller is viewed very differently from one country to another. I'll discuss this more in a future post.

Labels: Good practice

posted by Robert Phillpot View 2 Comments and post your comment

Add to Del.icio.us Digg this Add to Reddit