Deployment of an XML Documentation and Training Project Across a Multinational Corporation

1. Introduction

This case study will present how Schlumberger managed a large-scale XML documentation and training project, from requirements to deployment. This $8 million project concerns 400 users (technical writers and technology-based training designers), located in 20+ centers worldwide. The technical documents and training materials are produced in XML and are published in HTML and PDF to an internal operational support portal that serves 14000+ Oilfield Services engineers and technicians worldwide.

Schlumberger is a worldwide leader in technical services with 50.000+ employees in more than 100 countries. Schlumberger is a global technology services company consisting of two business segments. Schlumberger Oilfield Services is the leading provider of technology services and solutions to the international petroleum industry. SchlumbergerSema is a major IT services company providing information technology solutions to the telecommunications, utility, finance, transport and public sectors, and is the leading supplier of smart card technology. In 2000, Schlumberger revenue was $9.6 billion. Oilfield Services is the leading supplier of services and technology to the international petroleum industry. It provides virtually every type of service to the upstream exploration and production industry.

2. The Doc-OLT EDMS Project

This project is called the Documentation On-Line Training (Doc-OLT) Electronic Document Management System (EDMS) project. It is part of a large Schlumberger Oilfield Services (OFS) initiative launched in 1999 called Operations 2000. Operations 2000 is an IT enabled Knowledge Management initiative to allow direct access to know-how in Technology Centers by the field in support of operations 24 hours a day, 7 days a week. The other main project of Operations 2000 is the operational support portal, called InTouchSupport.com.

2.1. Roles of the Users, Sponsors and IT Organization

Schlumberger is a very decentralized corporation. This project implied several stakeholders and teams that had each a very specific role.

2.1.1. Sponsors

The sponsor of the Operations 2000 project is the Vice-President of OFS. A sponsorship organization for Operations 2000 was put in place to manage the implementation of the various project (Doc-OLT, InTouch....) On the Doc-OLT side, the Documentation and TBT Organization was created to:

• Coordinate with Technology Center and Training Organization to define Documentation and Technology Based Training (TBT) needs ¹

• Budget and plan for resources to maintain service level

• Support Technology Center in creation and maintenance of documentation and TBT

• Provide tools, standards and methodology for documentation and TBT

• Manage and qualify external vendors

• Align OFS goals with NExT initiative ²

• Manage the process of obsolescence

• Sustain IT tools for production and publication of documentation and TBT

• Manage evolution/upgrade of IT tools

This Documentation and TBT Organization is composed of 10 persons, with the following roles:

• Regional TBT manager

• Support for the EDMS users

• Documentation standard manager

• Distance learning ³ manager and coordinator

For the EDMS project, the Documentation and TBT organization:

• approves the requirements gathered by the IT project team

• accept the deliveries

• communicates with the users

• is in charge of the change management process

• ensures that the main contractor, OFS IT, stays on budget and on plan

• is in charge of the non-technical deployment and of the training of the users

• provides expert users for the alpha and beta test ⁴

2.1.2. Expert Users

There are about 250 technical writers and training designers users of the EDMS system, located in 20+ Technology Centers and Training Centers worldwide. The distribution of the users is 41% in Europe, 47% in North America, 12% in Asia. Each Technology Center develops hardware tools and software for one or several Business Segment of OFS. For each Business Segment in a Technology Center, there is a group of technical writers, managed by a Documentation Manager, that documents the hardware tools and software designed by teams of engineers.

The technical writers produce mainly Operating manuals, Maintenance manuals, On-line helps, Software guides. The training designers produce mainly Tutorials, Lectures and Case studies. These trainings are being linked to a Learning Management System that assesses tests passed by field engineers.

Each Documentation Manager reports functionally to the manager of the Documentation and TBT Organization. There may be more than one Documentation Manager in each Technology Centers.

The users of the EDMS system publish to the InTouch portal their technical documents and TBTs.

2.1.3. Subject Matter Experts

The Subject Matter Experts (SME) are the engineers who provide the technical writers and training designers with the knowledge necessary to write the documentation and TBT. They rarely write the final documentation directly, although they provide the raw content as paper sheets or text files. They are located in the same Technology Centers as the technical writers.

2.1.4. Field Engineers

There are about 14000 OFS engineers worldwide in the field. They provide virtually every type of service to the upstream exploration and production industry related to oil and gas Reservoir Evaluation and Development. They utilize tools and software designed in the Technology Centers. They download from the InTouch portal the Documentation, Training, Best practices, Lessons learned that are necessary for their job. They interact with the operational support teams who are behind the InTouch portal and are located in the Technology Centers, the InTouch Engineers (ITE). Regularly, Field engineers are sent to the Technology Centers and some are providing the content for the Operating Manuals.

2.1.5. IT Project Team

OFS Information Technology (IT) is the prime contractor for the EDMS project. The Sponsor contracts to OFS IT the design, implementation and technical deployment of the EDMS solution. The role of IT is to:

• manage the contract with in-house professional project managers

• advise sponsors with the help of in-house and outside experts

• evaluate technologies

• outsource the development and integration

• test and approve the deliveries

• manage the budget and the plan

• write requirements and validate specifications

• write Request for proposals (RFP) and select contractors

The IT project team for the EDMS project is composed of 10 persons with the following roles:

• Program manager for the whole team

• Project manager for a sub-project

• Quality Insurance / Quality Control (QA/QC) manager

• Technical writer

• Application Support manager

• Database administrator

• Tester

The IT project team is disseminated into 3 locations, Houston, Tx, Austin, Tx, and Paris, France. Most of 100+ OFS-IT people are located in these 3 locations.

2.1.6. IT Datacenter

Datacenters host the servers where applications reside. The North-America Datacenter located in Houston hosts the worldwide Production server, whereas The Hague (Holland) Datacenter hosts the Staging server ⁵. The Datacenter does not report to the IT project team. Relationships are governed through Support Level Agreement (SLA).

2.1.7. Extensive Use of Sub-Contractors

The policy of OFS-IT is to keep a pool of core expertise in-house and to contract out other expertise for the duration of a project (development, technical expertise,...). Almost all contracts are fixed-priced, with implies the definition of a scope, plan and cost before the work starts. It allows to manage risks, cost and planning.

For the EDMS project, we would have liked to find a single integrator able to manage all the complexity of the project. Since we could not find anybody willing to work in our tight schedule, fixed-priced, with advanced XML technologies, OFS-IT became the integrator.

2.2. The Documentation and TBT Process

The process of creation and update of the Documentation and TBT is illustrated by Figure 1

The Product development team in a Technology center designs and builds a hardware tool or a software. This design phase triggers the development of the Documentation and TBT. When the tool of the software is ready, the documentation and TBT must also be ready. The hardware tool or software is shipped to the field and the documentation and TBT is uploaded in PDF and HTML to the InTouch portal.

The field engineer search for the material on the portal or is notified by an e-mail of its availability. He/she views on-line or download the material or, if poorly connected, order a CD-ROM or a binder. If he/she notices a problem in the material (error, missing content,...) he/she sends a problem request to the ITE in charge of the tools/software.

The ITE analyses the problem and if confirmed, sends a Document modification request to the Document manager in charge of the manual. The Document is then updated on Intouch, the ticket is closed and the field engineer is notified.

The technical support may also modify the tools/software following field experience. Then the related documentation/TBT is updated on InTouch while the updated tool/software is shipped to the field.

The engineer can also take a training on a TBT downloaded from InTouch. The result of the tests are then managed by the Learning management system.

All these elements and interfaces are critical in this information food chain. It leads to an evergreen documentation and TBT.

2.3. The Documentation and TBT Concepts

The concept behind the Documentation and TBT are illustrated by Figure 2. The main principles applied are "single source" and "modular XML documentation".

Each document is made of reusable XML fragments called Data Modules (DM) and other objects (graphics, multimedia objects...) The XML objects are edited in an XML editor (see Figure 3), following a Document Type Definition (DTD) ⁶. For any documents, such as a Maintenance Manual, the Document manager in charge of the document select the existing fragments that can de reused (say the Quality, Health, Security and Environment (QHSE) part or the disassembly of a sub-element), and assign SMEs or other technical writers to write the fragments and the other graphical objects (pictures, screen captures, exploded views...). The objects are then linked together and to a container called SLDoc.

All these objects are managed individually in the EDMS (see Figure 4). The links, the version numbers and the metadata are managed in the EDMS. The EDMS also manages the access control and the status of the objects (from "draft" to "obsolete"). The project manager and QA/QC manager in charge of the hardware tool or software are respectively the reviewer and the approver of the final document.

When all the objects that compose a document have the status "ready" for publishing, the Document manager publishes the container (SLDoc) on the EDMS server to the HTML (see Figure 5) and PDF (see Figure 6) formats. He/she then uploads the published content to InTouch (see Figure 7).

The advantages of this concepts for the Technology Centers are:

• Content focus, since they reuse single source XML documents (no formatting)

• Quicker and easier to update content (flexible DTD, XML content)

• Focussed and managed process (the EDMS manages the documents)

• Standard document types possible (few DTDs)

• Reduced cost of support (same authoring tools for all users)

The advantages for the Field Users are:

• Standard Web browsing (no specific reader/client software)

• Quicker updates (the evergreen process)

• Powerful search (metadata, classification)

• One stop shopping, InTouchsupport.com

• Standard look and feel (same user experience, whatever the origin of the content)

• Quicker downloads of just the module needed (when XML fragments in InTouch)

3. Commonalties of Documentation and TBT

The Documentation and TBT development process are very similar, as illustrated in Figure 8:

The TBT is developed after Documentation, because it reuses the XML fragments and graphical objects of the documentation, and it requires a longer phase of analysis and design. Once both of them are published on InTouch, a cycle of maintenance starts, in order to keep them evergreen.

TBT is different from Documentation...:

• Learning is a planned result of training or instruction.

• Content is structured to facilitate retention and application of information.

• It utilizes Instructional Design which is ... a technology for the development of learning experiences and environments which promote the acquisition of specific knowledge and skill by students. Merrill, et al 1996

• It tests if knowledge has been acquired

• It uses verified learning strategies that make learning more efficient, effective, and appealing.

...And yet similar:

• Audience: field engineers and technicians

• Development process, resources

• Authoring tools: XML editor, graphic and multimedia editors

• Data formats: XML, graphic and multimedia formats

• Document Management System: the EDMS

• Content experts: engineers in the Technology centers, field engineers...

• Common components: some fragments, say "Principles of Operations", can be reused in Documentation and TBT

• Distribution channels: both are in HTML and are distributed via InTouch

• Maintenance, obsolescence processes

4. Change Management and Technical Issues

4.1. Change Management for Technical Writers

It was very important to manage the impact of the change of technology and process for the users. The technical writers were used to author with their own tools (FrameMaker, Word...), producing mainly large PDF files with high-resolution graphics designed for print, with their own favorite formatting. There was little reuse across publications and between the documentation and TBTs.

The buy-in process started in Q4 1999, first among the sponsors, then the technical writer and TBT designers. OFS IT was able to persuade them that the right way to obtain "on-time user-friendly relevant updated Doc-TBT" was to go for:

• single source

• XML native authoring

• modular documentation

• reuse of fragments

• standardized structures

• central management of the fragments in an EDMS

• central publishing of the content to HTML and PDF

• new XML tools

• What You See Is One Possibility (WYSIOP) ⁷ instead of What You See Is What You Get (WYSIWYG)

• metadata and classification

• rationalized process by merging the Doc-TBT development process with the Product Development Process (PDP) of the Technology Centers.

No Return on Investment (ROI) was performed, since the benefits were "obvious" for the upper management: quality, evergreen process, and speed.

The technical writers are now convinced that the way that was selected in 1999 with their approval was the right one. On the other hand, technical issues (especially in Publishing) slowed down the acceptance rate of the EDMS system.

4.2. Change Management for SMEs

The next step of the change management process is to convince the SMEs to use an XML authoring environment, in order change the authoring process to the following:

• Capture of primary information from SME

• Exchange of such information during the information revision process between the SME and the technical writer

The new work process that we are introducing is one that makes the most effective use of the professional staff, and yields high quality documentation at a reasonable cost to the organization. This process enables SMEs to produce high quality content, and facilitates the loss-less transfer of this information between them and the editing environment as the information is revised.

This SME authoring environment looks and behave much like MS Word, although it is based on an native XML editor. A small self-training is required to use the environment. We evaluated other solutions, such as an XML plug-in to MS Word or a converter MS Word <=> XML. None of these solutions were satisfactory.

4.3. Technical Issues

Since this project was among the first large-scale implementation of XML for technical documentation and TBTs, we had to put with all the initial problems:

• End 99, very few XML-aware tools were available on the market, there was a lot of marketing hype from existing SGML vendors.

• Only two main professional XML editors existed, Arbortext Epic (the market leader) and SoftQuad XMetaL (the challenger). Although they claimed to be XML-aware, it was impossible to exchange an XML file between them. Epic was chosen, because it was the only XML editor to be integrated with sigmalink (see below).

• Very few XML-aware EDMS were available. After an RFP, two products arose: empolis sigmalink and Poet. Sigmalink was chosen because of its Oracle database and its scalability. It was a good move, since Poet cancelled its document management offering a few month later.

• The first publishing tools were Balise for HTML and FrameMaker + SGML for PDF. The output of the EDMS had to be converted to SGML to run on these tools.

• The EDMS selected, empolis sigmalink, revealed itself during the firsts test to be a SGML-only document management system, due to its SGML parser (Balise). empolis had to tweak it to make it XML-aware (sigmalink v2.1 it is still not fully XML compliant, since it does not handle Unicode).

• The administration side of the EDMS has been very rustic, with few tools to manage large databases (30+ GB on the production database)

• Performance issues popped up with our specific implementation, especially for remote users (in Asia mostly) with a high wide array network (WAN) latency (more than 0.4 sec.).

• The Publishing system was quite slow, which hampered the proofreading of the published material.

• The first DTDs were cumbersome to use and did not fit all the needs of the users.

5. Schedule and Lessons Learned for Phase II

5.1. Schedule

Since mid 1999, we followed a very tight schedule driven by the sponsors:

Aug. 99	Concept phase. The technology and principles of operations are defined: XML for the content, modular documentation, document management system, single source.
Oct. 99	Launch meeting with more that 80 users in Paris, France. The sponsor organization is created, reporting to the Vice President OFS. A budget of 5 M$ is allocated for Phase I with a deployment date of May 2000.
Q4 99	The 3 DTDs for TBT are created
Jan. 00	RFP and selection of vendor for the EDMS and publishing system. AIS (France) is chosen, in partnership with empolis (Germany)
Q1 00	First implementation of the EDMS sigmalink fails, because it is not XML-aware. The DTDs for Documentation are designed with the users, but are not accepted during the alpha test. Our contractor, AIS, hands over the project to empolis.
Q2 00	Redesign of the Documentation DTDs and acceptance by the users. The second implementation of sigmalink with the XML patches is alpha tested and accepted. The Publishing system is designed.
Q3 00	The DTDs are beta tested. All the elements (authoring environment, EDMS, publishing system) are integrated and tested. The publishing system is in development. The deployment is prepared (communication, roll-out, training, change management, support for authors, support for IT, tracking system for user feedback).
Sept 00	The full system is alpha tested, with partial publishing style sheets.
Q4 00	Publishing system is alpha tested. Minor changes of DTDs are required. The full system is beta tested.
Dec. 00	The deployment of the full system for Phase I starts, with the first group of users in December.
Q1 01	Deployment of the two other groups of users. The number of potential users is 200, although the number of concurrent users on the EDMS is 15 on average. Bugs in the publishing system are partially fixed. A budget of 3M$ is allocated for Phase II with a deployment date of September 2001 for the core components.
Q2 01	Design of simplified DTDs based on user feedback and alpha test. Design of interfaces with other systems. RFP of the new publishing system, based on user feedback. Design of extra administrator tools for sigmalink. The Phase I system is supported and bugs are fixed.
Q3 01	Beta test of new authoring environment based on new DTDs. Development of the new publishing system and first tests. Design and test of the SME authoring tool. Development and acceptance of extra administrator tools for sigmalink. The Phase I system is supported and bugs are fixed.
Q4 01	Deployment of new publishing system and new authoring environment. Migration to sigmalink 2.1. Conversion of existing XML content to the new DTD structure. Deployment of SME authoring tool. Conversion of legacy documents to XML. Design of a on-line help system that can be produced by the EDMS.

This tight schedule shows that it is possible to manage a large project, providing that the organization allows it and the plan is well managed. There was no budget overrun.

5.2. Lesson learned

A lesson learned in Phase I were that the system worked as designed, but was not totally satisfactory for the users. The sponsors then suggested some simplification and improvements of the System for Phase II. The issues brought by the users were:

• The DTDs are not flexible enough to accommodate the various business segments of OFS (from wireline tools to pumps to cements).

• The quality of the PDF produced by the publishing system is not to "our" standards and there are still some bugs.

• The HTML works better than the PDF, but there are still some bugs.

• The EDMS is slow for Asian users

• The Publishing system is to slow to be useful for proofread

• The EDMS server crashes from time to time

• Guidelines must be issued on how to use the DTDs and the system.

• The authoring environment must be easier to use.

Another lesson learned from this project is that in order to succeed, the right people must be brought on board with the right organization and the right process:

• IT project managers with a knowledge of XML, databases, publishing

• Sustaining of the system must be planned from the beginning (support team, hosting, admin tools...)

• Qualified vendors with the right expertise and the ability to manage project on a short time scale

• Separate sponsorship from IT, and behave with a client-vendor relationship

• Subcontract as much as possible

• Test the deliveries more than you think should be sufficient and appoint a QA/QC role to validate the testing and acceptance process.

• Managing a team and vendors spread on two continents is not easy, but good communication and the right collaboration tools are essentials. Regular face-to-face meetings are very valuable.

• Sponsors must manage the communication to the users, and especially manage their expectation.

• As users appropriate new technologies, they adapt their requirements and a upgraded system must be designed.

6. Conclusion

Schlumberger was an early adopter of the XML technology and that choice proved to be right. We accepted the technology glitches, put with all the initial problems, managed the expectations and delivered in Phase I a system that worked fine, but had some drawbacks. Phase II will finally deliver a system that corresponds more to the user needs and is more stable.

Design and Development by deepX Ltd.