The ASP with a sting in its tail

For those who have not yet come across them, they are a closed network, with access limited to the project team members, which can be used to transmit documents, including drawings. Drawings can then be marked up and circulated via the extranet to all the relevant people. This should avoid anyone working to an out-of-date drawing. The latest version and the history of what changes have been made (and who made them) is immediately available on the extranet. It should save a fortune in copying and courier fees.

So, are there risks in using an extranet on your project? Several. Two of the most important are: what happens if/when the system crashes; what happens if the application service provider (ASP), who operates the network, becomes insolvent?

If the system crashes, there must be a back-up system that enables each of the participants – designer, contractor, subcontractor, client, to carry on working with minimal delay to design or progress on site. This may mean that whenever a document is uploaded onto the network, the person who has created or amended the document keeps a copy in their own electronic file, so it is available if needed. Everyone will, of course, revert to emails and faxes and circulation of hard-copy drawings until the system is back up and running, but there must be a procedure for updating the extranet as soon as it is back on line, so that everyone can have confidence in continuing to use it, and not resort to their own private back-up system.

This is usually achieved by devising a series of rules for the operation of the extranet, sometimes called a protocol, which becomes one of the contract documents for each of the organisations working on the project.

Some people go further than this, and keep a hard copy of all documents and drawings, with all their revisions. This seems to be a duplication of effort. If it is required for quality assurance purposes, then it is time that QA systems brought themselves up to date and accommodated the use of extranets.

The risk of insolvency is accentuated in the case of project extranets, as the market is immature, with over 25 competing ASPs listed on the AJ+ website (www.ajplus.co.uk). Although a smaller number of these may be considered serious players, it is clear that the market is likely to consolidate and there is a risk that your ASP may be taken over or, worse, become insolvent. What can be done to guard against this possibility? The most important step is to ensure that someone, probably the client, has a written contract with your ASP. This should provide:

• A right to terminate a contract and transfer to an alternative service provider in the event of any doubts about the ASP's ability to continue providing services;
  
• An obligation on the ASP to provide assistance on transfer of the service to an alternative ASP, by providing access to all necessary records and data. Assistance in the form of consultancy services may also be required;
  
• An obligation to make records available in specified formats that can be accessed by the ASP's customer.

If use of the extranet or the records it generates requires any proprietary software, then it will be necessary to obtain the source code for this (which most software providers will resist) or to provide for the code to be placed with a third-party escrow agent under an agreement that provides for it to be made available in the event that the software provider or ASP becomes insolvent.

Even with these protections, insolvency of the ASP would be likely to cause serious problems, and realistically, many provisions will become impossible to enforce in the actual event. So you may also wish to require the ASP to provide regular financial information, to try to detect early signs of any problems.