R.I.P. The folder structure
Something our sales guys get asked in nearly every meeting is "Can you replicate our file and folder structure?" The answer is "Yes, but we have 5,600 projects with thousands of organizations taking part. 99.9% of them don't use this set up."
At this point there are usually a few raised eyebrows and a grumble or two. But, when you think about it, using a file and folder structure within a collaboration tool just doesn't make sense. Thankfully (on the Aconex system at least) keyword searching has made it redundant.
An analogy that comes to mind is to compare the Google search engine to the way the internet used to be. If you can remember searching using the original Compuserve, AOL and Yahoo! applications, you had to go all the way down a tree of folders, starting very wide, until you found what you were looking for. For example, if looking for information on Picasso. you would have to ascertain whether it would be held in the Entertainment folder or under Culture. You would then need to find The Arts, then Artists, then Painters, and then scroll until you found Picasso. Would we do that now? Of course not! We'd just tap "Picasso" into Google and wait for the results to appear, knowing the best matches would be near the top.
It's exactly the same with collaboration systems that offer keyword search. Why would you go through five levels of folders (and who would define the levels across your whole project anyway?) to find electrical drawings, when you can punch the word "electrical" into the search bar and get the files you need in seconds, sorted as you want them to appear? Effectively, a folder structure is still there, it's just behind the scenes.
As with the evolution of web-browsers, being able to search on meta data is far quicker than using a folder structure and it also clears up the inevitable confusion (and disagreements) over naming and categorization.
Also, as with the evolution of web-browsers, once they get past "but this is how we always do things", very few people can imagine going back.
Labels: Good practice, Technology
4 principles of document revision management
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 information 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 collaboration tool is being used.
- 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. - 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...). - 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. - 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
Collaboration tool leads to 80% reduction in printing costs
I was talking to a project manager at construction firm Hansen Yuncken who said that, by using an online collaboration 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 technology.
If anyone else has tracked how much document management systems save in printing costs, we'd be very interested to hear what you've found.
Labels: Good practice
Not so Excel-lent: six reasons to use a collaboration tool instead
Labels: Good practice, Technology
Another paper cut
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 electronic document management with the reference copy being issued to site 'for use'".
Labels: Good practice
Paper cuts
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
Bulk processing, taking document control up a notch
The feedback we receive from users has provided us with valuable suggestions for both minor and major product enhancements. Unsurprisingly, some of the best suggestions we receive come from the heaviest users of our online document management system, document controllers. Due to the workload they handle, many of their ideas concern speedier methods to get large amounts of work done in a minimal amount of time - any way to reduce the stacks of paper on their desk is a plus.
Some time ago, we introduced the bulk processing feature on our system. The option to upload, register and supersede a large number of documents has always been a key feature on collaboration tools but bulk processing is a way to take that concept up a notch. The number of documents a user could register and supersede went from hundreds into thousands.
Bulk processing takes advantage of the Excel spreadsheet, traditionally the most common medium to keep track of documents on any project. Spreadsheets are already in abundance on most projects, and bulk processing makes use of them to get documents up and registered fast. Using a metadata template, bulk processing allows users to upload, register and supersede as many documents as an Excel spreadsheet can contain (about 65,000 if need be).
Anyone who is familiar with the role of a doc controller knows the value of time and effort. Once a large number of documents are prepared, compiled, examined and verified for accuracy on a project they need to be constantly maintained and updated. In the paper world, as much time can be spent chasing documents and new revisions down through phone and email as it takes to actually handle the task at hand. New revisions need to be communicated back to project participants and this cycle continues for years at large volumes.
Anything that can streamline this task is of major benefit, provided all the data can still be accurately maintained and captured. Particularly for doc controllers, features on collaboration tools like bulk processing can help make the job easier and clear a little desk space for a much deserved coffee.
Labels: Good practice, Technology
You say tomato, I say...
A great thing about our industry is that, with projects becoming more internationalized, and team members based in many countries, you get an insight into other cultures, attitudes and work practices. It's fascinating to hear how other people go about their business and how they would tackle a particular challenge.
An example can be seen in Emmanuel Netter's blog post 'Aconex et la gestion des fichiers de CAO' (Aconex and management of CAD files), which is a response to my recent post 'Handling CAD drawing and Xref file exchange'. Emmanuel, a prominent figure at French collaboration provider Prosys, sees the method I laid out as 'Anglo Saxon and rigorous' and quite different to the more 'anarchic, Latin' approach.
His blog, CPLUSN, is in French so in case you don't read the language (or trust the Google translation), the main section of the post (roughly) translates as...
In tools developed for the French market, like Mezzoteam, additional modules automate the retrieval of related documents. In short, if I open an AutoCAD file, Mezzoteam will automatically retrieve the X-refs, even grabbing local copies to save on transfer time, if they are up to date.
The approach advocated by Robert is more consistent with what we see in generic tools, since file retrieval and the maintenance of links between files is done manually by the CAD Manager. You are building a local set of reference data, which the CAD manager works from.
We can see a "clash of cultures". On one side is a requirement for automation and high productivity, driven by the wish for quality assurance, but requiring everyone to play by agreed rules. On the other is a more flexible approach, less effective on paper but also less demanding in organizational terms.
So maybe the old stereotypes of Anglo-Saxon rigor and Latin anarchy have been played out in this case!
Based on the above, it appears that the differences are as much to do with the principles of the system as with how X-Refs are managed. The automated retrieval model described is interesting and suggests that there is local software being utilized that can manage downloads and cache files for re-use later. Also, it hints that users can access files (X-refs) that they have not been explicitly been given access to.
My initial thought is that, while Mezzoteam's system may be easier in some regards to the SaaS collaboration tool model, there may be security implications. Could firms be left open to unintended consequences if people can see things that the author did not want them to see? A thought-provoking post and I'll certainly look into this more. Has anyone else had experience of using both approaches?
Labels: Global trends, Good practice, Technology
Renewing Xrefs
In response to my post a few weeks ago on 'Handling CAD drawing and Xref file exchange', a reader asked us whether collaboration systems support the automatic renewal of the Xref file, or whether manual action is needed to select which Xref files have to be updated?
We asked a member of our Industry Consultancy team for his view on current industry good practice and here's what he said...
Collaboration systems are the tool by which the Xrefs are transferred and therefore are not linked to the update of the Xrefs in anyway.
That said, the creator of the drawing, and therefore the Xrefs, are responsible for updating the required organizations using the Xrefs within the project. This is where collaboration systems provide the perfect tool, as there is a function that allows a user to quickly and effectively update documentation (the Xrefs) stored within the register and send them to the same organizations that received the previous revision.
As Xrefs are usually stored/managed in folders, the best format by which to transfer the Xrefs are in 'eTransmit' zip files which are created in AutoCAD and simply registered on the collaboration system for means of transfer.
The receipt of the eTransmit zip file simply downloads and extracts the contents to the local drive. As part of the function of the eTransmit zip file, the contents are routed and stored in the correct paths within the local folder structure.
The creator of the drawing/Xrefs would have an agreed project protocol for creating and storing the Xrefs but the best practice way to manage the Xrefs is the ensure that the path is relative. A relative file path means the recipient doesn't require the same drive letter as the creator of the drawing. So when the eTransmit zip file is extracted, the folder structure is mirrored on the recipients drive using the drive letters on the local system. When the recipient of the Xrefs opens the drawing in AutoCAD the 'relative file path' Xrefs are then picked up from the local folders and viewed as part of the drawing.
That process is all well and good but the recipient must be confident that they have the most up to date Xrefs which is where the collaboration system is used. It provides a means of determining the current Xrefs by means of a register that holds the current files by default for the user to download. Therefore a user need only check the current file on the collaboration system is the one that they downloaded (usually determined by the date) giving them confidence that they are using the most up to date Xrefs available to them.
Labels: Good practice, Technology
Keeping the paper trail
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 collaboration 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 web-based document management as being in risk reduction.
If anyone has a horror story about lost documents on a project, we'd like to hear them.
Labels: Good practice
Can you help me?
Something worth adding to the previous post 'Google Docs, a competitor to construction collaboration tools?' is that, in addition to the limitations of the product, Google Docs will never be able to compete with the leading construction collaboration vendors on customer service. Despite its success as a business, Google Inc. can't come close to providing the specialist support, training and implementation expertise that industry projects need.
A quick scan around the websites of some of the top collaboration providers shows that they all provide (as a minimum) phone and email support during business-hours as well as supplementary consultancy and implementation services.
I'm now looking on the Google site and.... I can't find a helpdesk number. Anywhere. Let alone the option to talk to someone who is specially trained in the Google Docs product and understands the construction industry.
The expert human touch when the users have a problem is the main reason why specialist construction collaboration vendors will trump generalist tools like Google Docs.
Labels: Global trends, Good practice, Technology
Google Docs, a competitor to construction collaboration tools?
We received a comment earlier this week asking our thoughts on the merits of Google Docs. As the author said, Google Docs is a free tool that can perform some of the functions of a construction collaboration system. It provides easy indexing, searching, automatic versioning and live editing whereby multiple users can edit documents at the same time, with a built in chat function for users to converse while editing.
I'm sure many software providers live in dread that Google will launch a free tool that is potentially a substitute for their product. However, although Google Docs is a good generic tool for the simple sharing of docs, it is not really a competitor to construction collaboration tools.
Here are some of my thoughts:
- Construction and engineering projects demand a system that is customized to the needs of the industry. Google Docs has some nifty features but it falls a long way short of providing the functionality and sophistication required for an industry project. There are some fundamental requirements that Google Docs can not perform, such as workflow reviews, web forms for correspondence and reporting for outstanding overdue items (or any kind of reporting for that matter).
- Having a system that allows docs or files to be deleted is bad for the audit trail and court-worthiness of a system.
- Google docs has limited storage capabilities - and you can delete items to stay within the storage limits - which is very bad for capturing the full history and audit trail of the project.
- Google Docs does not have an organization-employee and project structure, which does not suit large construction and engineering projects.
- Allowing users to share data while also allowing areas for data that are private to particular organizations is critical in wide adoption of collaboration systems on projects. If everyone can see everything, or even if the admin organization can see everything, then people will not widely adopt it. We have seen systems that have a similar security model to Google Docs being implemented on construction and engineering projects and they either fail totally, or the amount of data captured is a small percentage of what is captured by a system that supports collaboration while also allowing privacy (because people will go outside the system for anything that they want to keep private). And - ultimately - capturing all the data is the best way to reduce risk on a project.
So, while Google Docs is a good tool for people that want to share some docs in a very basic way, it does not suit collaboration on projects (particularly medium-large scale) that require industry-specific functions and workflows, indelible audit trails and reporting features.
Labels: Global trends, Good practice, Technology
Handling CAD drawing and Xref file exchange
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 collaboration 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:
- Drawing author uploads and registers drawings and X-Ref files to the system.
- Author transmits files to relevant consultants.
- Author transmits X-Ref files to relevant CAD Manager.
- 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.
- 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.
- 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 collaboration 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 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
Implementing EDRM: A long, old slog
There's an amusing post written by James Lappin on the TFPL blog entitled 'What you do once you have successfully implemented EDRM' (an electronic document and records management system).
The post starts off by saying, "Rolling out EDRM is a long old slog. You have to procure it; configure it; build your fileplan, your retention schedules and access rules; write your policies and procedures; pilot it; take it to every team, get their folders set up and get them trained. By the time you've done all that you are three years older than when you started."
Reading this reminded me why uptake of SaaS solutions - which include online alternatives to installed EDRM software - is growing at more than 20% per annum!
Labels: Good practice, Technology
Collaborating with competitors
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
Email vs collaboration tool: Part 3 of 3
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
Email vs collaboration tool: Part 2 of 3
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
Are the right people in place?
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
Email vs collaboration tool: Part 1 of 3
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
Document numbering: less is more
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
The paperless project
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
Vendor docs
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
New year resolutions (again)
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
Wet signatures
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
The doc controller: from admin to lynchpin
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
4 immutable laws of collaboration: Part 2 of 2
The previous post covered why, more often than not, the collaboration process breaks down when using an information management tool that charges a per-user licensing fee or doesn't include training. Our two other 'rules of collaboration' concern data - how much is stored, where it is a kept, who controls it and who has access to it.
Rule 3: Don't pay extra for, or accept a limit on, data storage
For a Software as a Service (SaaS) provider, holding 100GB or even a couple of terabytes of information is nothing, just another cost. For the IT department of a construction firm that has purchased and is hosting document management software, this amount of data can represent a very high cost.
Because of this, some companies put in place limits on the amount of data each organization on a project can store, then charge for subsequent data. The inevitable outcome is that some data is stored, some isn't, which defeats the purpose of having the system. Also, how can anyone make a decision on what information is going to be required (potentially years) in the future?
Rule 4: Trust no one else on the project with your data
Is it any surprise that information management systems (therefore collaboration) can fail when firms are asked to hand over their valuable intellectual property to another organization on the project? With the installed software model, firms put their drawings and documents behind another company's firewall. The company with the software controls the data and controls access rights, which is not in the interest of project collaboration.
In contrast, most vendors using the SaaS model provide a third party platform for managing information. Each company owns its own data (the files it has created or been sent), creating a level playing field for everyone on the project. An archive of current and historical document versions is held on the system where it can't be altered or deleted.
The most used document management systems respect these four rules. They come from SaaS providers that, inclusive in their price, allow unlimited users, provide training to all participants and have no restrictions on data storage. What's more, data is stored independently with all parties having equal access rights to their information. Using tools that meet these criteria will support project collaboration and lead to successful projects.
Labels: Good practice, Technology