To a Web Site, and Beyond!

January 1, 2001

After the number of years I have been in the ITbusiness, I should have realised that there would be a price to pay for the verynice lunch I had with a Lovells’ partner. We had spent the morning talkingabout a Web site we had been thinking about for a while, and by the end of theday I had a much clearer idea about what we needed. In October 2000, we launchedwhat has become a very successful site, and this article describes the processwe went though, our lows and triumphs, and the obstacles we overcame along theway.

The Strategy

The concept underpinning the site grew out ofthe work Mark Huleatt-James, a Lovells’ partner, had carried out in authoringa book on international arbitration. Mark is also the Group Manager of a Lovellspractice area which depends heavily upon technology, and therefore he hasexposure to the various possibilities offered by Internet-based tools. As I runthe small group that provides the IT tools and support for Mark, I was thelogical choice to oversee the emerging project. Mark had identified that hiswork could evolve into a site which provided an informed view on the drafting ofinternational arbitration clauses. As well as a comparison of the various setsof arbitration rules, provision of commentary on various country’s arbitrationstatutes, and advice on what factors to consider, Mark had also thought of threeunique offerings. First, he felt that there was a potential to ‘automate’the construction of an arbitration clause. Second, a facility could be providedfor the individual comparison on international arbitration rules. Third, a‘cost calculator’ could be created to give an idea of some of the feesinvolved in the arbitration process.

As far as we could tell, this site would be afirst in the legal world, and certainly unique amongst the other LovellsWeb-based offerings. Therefore we decided that we needed to follow a strategywhich kept the implementation as flexible as possible, so we could react to anychanges along the way. We also quickly realised that, because of othercommitments and priorities, the coding work could not be completed within ourtimescales by Lovells internal IT resources, and therefore we would need tobuy-in assistance. This added to our tasks, as we had to plan how best to clearthe funding for the development work.

At this point, Mark had created a significantamount of paper and a handwritten ‘decision tree’, guiding users through thevarious facets of arbitration and the drafting process. We decided upon athree-stage approach. First, I would turn the design into a more IT-focusedspecification. Second, we would build a prototype to confirm our ideas and actas demonstration tool to the various internal funding committees. Third, wewould implement and launch the Web site.

Design and Tool Selection

As a firm believer in the power of pictures allied with words, Icreated a flowchart of the route through the site, with links to the textproduced by Mark. Once this was completed, we could describe the concepts wewanted, in what became a well rehearsed 20-minute briefing. At this point we hadour first round of discussions with Lovells IT group. As well as establishingthe manpower requirement, we determined which technology we would use. Wequickly realised that there was enough programming work to take the projectbeyond a standard HTML publishing tool, but not enough complexity in thedrafting element to require the integration of a product such as Hot Docs. Thisled us to the selection of the SilverStream technology already used by Lovellsfor both their internal and external web-based offerings. In turn, the selectionof SilverStream clarified the resources we needed, leading us to bring inexternal support to build the prototype.

As ever, we had to balance the advantages of availability andspeed in using external people, against the costs and the possibility of losingcontrol. However, we felt that our phased approach, coupled with standardproject management techniques, meant that the advantages far outweighed therisks.

Prototype Phase

The aim of this phase was to produce a ‘mock up’ of thefinal site. We wanted to look at the various elements of the site in theiron-screen incarnations, and also clarify how the site would operate. It wasimportant to bear in mind that we specifically only built the front-end ‘façade’at this point. Though the end product looked very much like the final version ofthe real site, it was all example screens linked by HTML code rather than beingunderpinned by a database or programming code.

We met with the external team on a weekly basis, and spent eachsession working through the mock-up, confirming the concepts behind what we wereseeing on-screen, and also exploring ideas and avenues thrown up by the groupdebates. The iterative process fleshed out our technical requirements, but alsohelped us determine some wider strategic issues.

On the technical side we considered building all the pages inPDF format, but in the end decided against it. The purpose of the site is toprovide online reference, but not a formal legal opinion, so we did not needoverly to concern ourselves about the quality of printed output. If users wantedto download the reference pages then they could do so, but we wouldn’t spendeffort freezing them into a standard Lovells style. Similarly, the eventualarbitration clause was deliberately left in ‘plain’ ASCII format, as weinvited users to cut and paste it into their own WP environment, presumably withtheir own house style for contract formats.

Strategically, we decided that we wouldn’t charge for the useof the site, but that we would impose a log-in process requiring individual’se-mail addresses. We split the site into those elements which would be ‘hardcoded’, such as the drafting engine and costs calculator, and the contentpages, which we would add and administer via a user interface. Finally, withinput from the Lovells’ intranet team, we adopted the ‘look and feel’ ofthe existing Lovells’ developments, giving us a clean and spacious designstandard to work to. Alongside the prototype, the external developers alsoproduced a clearly defined Functional Specification which became a jointlysigned deliverable at the end of the phase. With these two elements in place, itwas also possible for the external team to provide a fixed price for thedevelopment phase.


Armed with our working model we were able to demonstrate thesite concepts to a number of different parties within Lovells. We started withthe International Arbitration Practice Group, who became enthusiastic championsof the idea once they could see what we were trying to deliver. We showed it toTechnology who endorsed the technical approach and design, but confirmed thattheir tasking priorities meant they couldn’t develop it within our timescales.Finally, we used it to obtain funding approval from the steering group taskedwith examining all of Lovells’ electronic offerings.

The development phase itself went smoothly. The time and effortwe put into the previous stage paid dividends here. The programming team knewexactly what they had to do and our feedback during the regular progressmeetings was mainly confirmatory. However, what was dawning upon us was theeffort we were going to need to add the initial sets of content pages and forthe on-going maintenance of the site. We had secured the services of a paralegalfor three months as part of the build-up to developing the site, but it wasbecoming obvious that it was time to bring on board additional resource. We haddesigned the site so that the content could be managed via a user-friendlyinterface and soon Jo, Mark’s secretary, was putting it through its paces. Thebig advantage here was that the technology allowed us to use someone withoutdetailed technical knowledge of HTML and Web design. The SilverStream interfacehid all of that behind relatively friendly screens. Once Jo had got over herinitial butterflies, she was soon adding, amending and linking pages with hardlya support call at all.

Marketing and Launch

Before too long we started to plan for the launch of the site.It was decided that the ‘big day’ should coincide with an Arbitration Groupevening in the middle of October. With our audience identified, all we had to dowas prepare to ‘go live’. This was the most hectic period of the project. Insequence, we had to formally test and accept the site from the externalsuppliers, oversee the transition to maintenance by Lovells Technology group,complete all the content loading, linking and changes, move the software fromthe development environment to the server on the outside of thefirewall, co-ordinate all the pre and post-launch publicity, and arrange for thesetting up of a demonstration environment on the night of the launch. To achieveall of this involved pulling together a number of disparate groups withinLovells and a number of traditional late nights and weekends. In order to makethings really interesting for ourselves, we threw in a server crash on the bigday, which tested our disaster recovery planning a bit more exhaustively than wewould have liked, but we brought it all back up with time to spare. Well 30seconds, but that is another story.

Post Launch

We had tested the site in as many ways as we could, particularlyusing the current versions of the two main variants of Internet browsers,Netscape and Explorer. The development had used generic HTML code as much aspossible, though there were the usual minor differences in display between thetwo browsers. However, we knew that we couldn’t test the variety ofenvironments that exist, so we made sure we built an easy means for users tocontact us into the site. Sure enough, within a few days of the launch we had acouple of people with problems. SilverStream identified that there were issueswith users coming in via proxy servers and applied a code fix which resolved theproblem.

We are currently considering where we go next. Our first stepswill include the imposition of more formal version and release control. Beforethe launch we could just change material as we wished, now we need to formalisethe quality and legal checking we do before we publish it to the live site.Other than that, we are receiving an amount of feedback from users and theirneeds will be fed into the ongoing maintenance and development process.


In the main, the project went according to plan. The length oftime for obtaining internal clearances and co-ordinating the various Lovellsfunctions took longer than we had initially planned, but the effort in gainingthe right levels of support was repaid once the project got into full swing.Having thought about it, my ‘Ten Commandments’ for a successful Web projectare:

  1. Have a clear aim that is articulated by a business sponsor.

  2. Implement the project in a phased, flexible manner, with an early view of the concept so you can gather internal support.

  3. Capture the requirements on paper, and then on screen.

  4. Choose a tool that does what you need; don’t make it too complicated.

  5. Consider the pros and cons of internal versus external development. If you use external people, find a partner, not a supplier.

  6. Use a prototype to confirm your requirements, and be prepared to throw it away. Time spent defining your needs is repaid ten times downstream.

  7. Don’t underestimate the amount of internal marketing you will need to do.

  8. Content is king! Putting it in takes time and effort, and is an ongoing task if you want to keep your site fresh and visited.

  9. A Web site is ‘just’ another IT project. The physical infrastructure needs to be as robust and secure as any other business crucial application. Back-up cycles, stand-by servers, disaster recovery all need to be considered and implemented according to the business requirement.

  10. If you are successful, then the Launch is just the beginning of more time and effort. But unless you plan to maintain and develop the site, why bother in the first place.

Andrew Haslam is an independent IT consultant specialising inthe legal sector, currently working with Lovells as a Project