Financial Products Markup Language   Table of contents   Indexes   Building with XML
 Germany 
Hamilton, Jean
 Munich 
SPX Valley Forge
 		Jean Mercedes Hamilton
 Senior Project Manager, IT
SPX Valley Forge
  Gutenbergstr. 25 Munich  Germany (D-85748)
Email: jhamilton@vftis.com Web site:www.vftis.com
 Biography
 Jean Mercedes Hamilton, model year 1964, is Senior Project Manager for Information System projects with SPX Valley Forge Technical Information Services in Munich, Germany. She has lead SGML-related projects since 1995 and was devoted to the MCC project design and implementation through 1997. As a non-programmer, Jean sees her role in IS projects as an interpreter between the software users and the programmers, in addition to the necessary project management tasks. Since receiving her degree in Mechanical Engineering 12 years ago, Jean has worked for Valley Forge Munich in a number of positions on projects for various automotive manufacturers. Jean enjoys classic cars and peppermint ice cream.
 

Introduction

 This presentation is a case study which additionally presents the benefits of using a customer-focused incremental development life cycle for implementing XML/SGML for technical authoring and presents a summary of lessons learned.
 automotive 
 		The technical service information from Saturn Corporation, a division of General Motors, has been ranked by J. D. Power as the best in the service industry. Saturn attributes this success to their corporate philosophy and values which focus heavily on meeting the customer's needs. The Saturn Technical Publications group had 10 years of experience with Interleaf Desktop Publishing when they started hearing about the benefits of XML/SGML - reduced costs, higher efficiency, data reuse, web publishing. To support the technical documentation of a new second Saturn model, the "Tech Pubs" team leader had a choice: double the size of the team or transition to an XML/SGML publishing system. She chose XML.
Saturn Publication Management System (SPMS)
 		SPX Valley Forge Technical Information Services was first hired on in January 1998 as consultants to analyze the system requirements for the planned . One of the biggest challenges was to determine how to transition from the current process and system which produces award-winning documentation to a new XML/SGML system with more efficient processes.
 The analysis phase forms the basis of every successful software implementation project; it sets the tone for how the total project will be run. Data, process and system analysis are not the only aspects of this phase. More importantly, system users need to be involved from day one. The major issues surrounding user involvement include education on new technologies, introduction to the concepts of an incremental development life cycle, discussion of the users' hopes and fears concerning the new system and of course analyzing their current methods for getting their jobs done.
 Some of the technical questions addressed during the analysis phase including determining which past processes included best practices which should be maintained going forward, how to create a structured data system which could still be flexible enough to allow the authors to create exactly the type of service manual that the Saturn technicians want, and the selection of XML/SGML tools.
 As the design and implementation of SPMS began, both Saturn and SPX Valley Forge realized how the investment in a thorough and user-oriented analysis phase would pay off. User buy-in to the new system had been secured and most of the user's fears about the new technology had been stemmed. In addition, by talking with each of the 10 system users, SPX Valley Forge had gained an understanding of the often subtle process issues; this understanding would help us to create the ultimate system for Saturn. The Saturn philosophy of focusing on the customer's needs was indeed a critical success factor, not only in selling cars, but for creating service documentation and for developing a new XML/SGML authoring system.
 The presentation, a case study, will provide an overview of the approach taken during the analysis, implementation and roll-out of the Saturn Publication Management System (SPMS). The incremental development life cycle will be explained, including an introduction to the principle of results-driven incrementalism (RDI). The customer-focused approach will be investigated. The presentation is targeted at IT project managers and managers who are thinking of implementing a new XML/SGML authoring system or similar.
 

Saturn's Focus on the Customer

customer focus
 		Saturn Corporation, a division of General Motors, was founded 12 years ago with the mission to redefine, using best practices from other companies and industries, the way vehicles are marketed and manufactured. The Saturn philosophy and core values which developed include a strong and a partnership mentality between Saturn customers, members (employees), suppliers, retailers and neighbors. Saturn Chairman and President Cynthia Trudell stated it this way: "Saturn redefined product to include not only a high quality, reliable car -- but also the shopping, buying and ownership experience. And Saturn people developed this new definition in a systems context."
Saturn core values
 		Most large corporations today have a mission statement and core values hanging on the wall, but at Saturn, these values are so fundamental to their everyday work that even a software implementation project can be defined so that it supports the core values. Here is an excerpt from the Project Definition Document which lists the and describes how the project will support these values:
 

Commitment to Customer Enthusiasm

 We continually exceed the expectations of internal and external customers for products and services that are world leaders in cost, quality, and customer satisfaction. Our customers know that we really care about them.
 SPMS internal customers are the diverse system users. It is critical that SPMS be user-friendly; continuous feedback from all users is essential. The needs of external customers, the users of technical publications, i.e. technicians at Saturn Retailers, are also important. The quality of the technical publications which are the "output" of SPMS must remain at the current level (or improve!)
 

Commitment to Excel

 There is no place for mediocrity and half-hearted efforts at SATURN. We accept responsibility, accountability and authority for overcoming obstacles and reaching beyond the best. We choose to excel in every aspect of our business, including return on investment.
 SPMS must ensure that responsibility for the system design, system, processes, and data remains in the hands of Saturn team members, so that they can continue to remain in control and accept accountability for their performance. This in turn will lead to higher quality and lower cost while maintaining timeliness.
 

Teamwork

 We are dedicated to singleness of purpose through the effective involvement of members, suppliers, dealers, neighbors and all other stakeholders. A fundamental tenet of our philosophy is the belief that effective teams engage the talents of individual members while encouraging team growth.
 The input from all Saturn team members is important to the design and acceptance of the system and their feedback will be solicited and used throughout the project.
 

Trust and Respect for the Individual

 We have nothing of greater value than our people! We believe that demonstrating respect for our uniqueness of every individual builds a team of confident, creative members possessing a high degree of initiative, self-respect and self-discipline.
 SPMS must be a flexible system designed with and for the users and customers. Involvement in the project from Day One builds confidence in team members and ensures a comfortable working environment.
 

Continuous Improvement

 We know that sustained success depends on our ability to continually improve the quality, cost, and timeliness of our products and services. We are providing opportunity for personal, professional and organizational growth and innovation for all SATURN stakeholders.
 To uphold this value, the SPMS system must be extensible and flexible. It must be easy and cost effective to upgrade SPMS to include new but proven technologies and processes. Saturn is time line driven; deadlines are not missed. SPMS must ensure that processes can be run more effectively.
 To quote Saturn Chairman Trudell once more:
 "The people who founded Saturn were not just interested in changing the way we manufacture and sell cars. They also wanted to make a difference in the way people work with each other. Partnerships make it possible to harness the intellect and creativity of everyone in the organization, empowering all members of the Saturn family to fully contribute. To realize the full benefits, partnership requires a culture that is inclusionary and embraces diversity."
User Involvement
 		Thus "customer focus" at Saturn does not just refer to the customers who purchase Saturn vehicles. The "customer" for the Saturn Technical Publications team, which publishes all service manuals, parts catalogs and other service literature, is the mechanic at the Saturn retailer who uses these publications to service the vehicle. The "customer" for the new XML Publication Management System are the system users - editors, technical writers, graphic artists and publishing experts who create and store XML and graphic objects and publish to paper and (in the near future) electronic media.
 

"Customer Focus" - Another Term for in System Design and Development

 Many people have recognized that the roll-out of a new, complex IT system is an important factor in the successful adoption of the system by the users. Too often, new IT systems are introduced to users with insufficient documentation, little or inappropriate training and no help desk. But there is an additional component that can contribute to a more successful roll-out: User involvement in the system design and development. By focusing on the customers from Day One and getting the users involved early on, a valuable partnership between users and system developers can be created. The users can be introduced to the new technology, can express their hopes and fears of the new, future system and can contribute the best suggestions for how the new system should work. After all, this will be "their" system; it is meant to make their jobs more effective and easier.
Incremental Process for Software Implementation
 		Of course, not every company has such a long tradition of customer focus and partnerships like Saturn, but anyone involved in implementing a new IT system has the ability to get the end-users involved as early as possible to get their input, their buy-in and to increase the likelihood of success of the project.
 

 Various studies have shown that over 40% of IT projects fail. After spending millions of dollars the project is just thrown out. In many cases, the failed projects used a traditional software implementation approach which is characterized by a long period of development performed without user input followed by a "big-bang" finish - the delivery of the new software or system to all users at once. The alternative to the traditional method is an incremental process in which a large system can be delivered in increments, with each new version of the system adding more functionality.
RDI - Results-Driven Incrementalism
business results
 		 - is a new incremental method developed by Scott A. Moses, product manager for i2 Technologies and other implementation consultants. (The information presented here has been summarized from an article in "Sloan Management Review", Winter 1999 written by Robert G. Fichman and Scott A. Moses.) RDI takes into consideration that the introduction of a new software system must be accompanied by organizational change for the new system to be effective. The RDI strategy calls for delivery increments every two to three months which include a combination of software functionality and organizational change. Each increment should be defined so that business results are achievable, even if no further increments are completed. Instead of the normal software release, RDI introduces the concept of "business release" which result in a "series of releases of software-enabled ". The description of each business release includes (1) the targeted business result (e.g., improved due-date performance); (2) a list of the software functionalities to be implemented; (3) a list of the changes to organizational policies, procedures, measures, structure, and (4) a metric for measurement of the business result. The advantages of RDI include shortening the time before business gains are achieved, shorter implementation time, and an increase of overall project benefits.
 

Saturn SPMS Incremental Process

 Implementation of the Saturn Publication Management System (SPMS) was divided into seven deliverables. Each phase took between two to three months to complete and deliver to the users. Each deliverable included user training in the new functionality. After installation, the users could test the new functionality and submit change requests for improvements to the next release.
Project Definition
 

Development of and Analysis Documents

 A Project Definition document includes the following information: Mission Statement, Core Values (see Saturn core values and how they relate to the project above), Goals, Scope, Assumptions, Deliverables, Timing, Team Members, Alternatives and Potential Solutions, Unresolved Issues, Approval Signatures from "lead" user and implementor.
Analysis Phase
 		The types of questions which need to be answered during the include:
 
  •  Are there things that the customer does not like about the current organization/structure of its documents?
  •  Does an approved DTD already exist?
  •  If no final DTD exists then, (1) has any document analysis been performed? (2) How willing would they be to make changes in the formatting of the documents? (3) New structure/organization may be possible with XML, while some things they now do may not be. How important is it to match the current format of their documents?
  •  What is the current authoring/publishing process?
  •  Do they have published editorial guidelines or style guides?
  •  What languages do they need to support?
  •  What hardware do the authors currently use (e.g. PC, Sun Workstations..)? Would it be possible to change to a new platform?
  •  Is there any information that they would like to explicitly capture (e.g. key words or other indexing type of information which can be used to create dynamic links, automated indexes etc.)
  •  Quantify the amount of data currently managed? by number of pages? by number of mega-bytes? by number of graphics?
  •  Do they have a target percentage for the amount of reuse expected from a new authoring/publishing system?
  •  What are the bottlenecks in the current authoring/publishing process? If they could improve one thing, what would bring the most benefit?
  •  Which part of the authoring/publishing process today works really well?
  •  How many authoring languages?
Development of draft DTD
 

 The development of the DTD is the first step in developing an XML authoring system. No other work on the system can be done until the DTD is developed. It is often difficult for the user to test or check a DTD by itself, even if they have had an introduction to XML and are familiar with the syntax. Real DTD testing by the users can only begin after the FOSIs and the XML Editor have also been installed with the customer. It is important to realize that DTD changes will thus still be showing up in the later implementation stages. Some type of version control for the DTD, like source code management, can be helpful both for the DTD/FOSI developers and the system programmers.
 The Saturn SPMS DTD is based on J2008, the standard DTD for the automotive industry developed by the Society of Automotive Engineers.
Development of draft FOSIs/Stylesheets
 

 Example files generated with the DTD and FOSIs are the first real output of the new system which can be reviewed by the users. Not only will the user then request FOSI changes, but also DTD corrections will occur at this phase.
 The print FOSIs for Saturn SPMS were developed to match the old Saturn Service Manual format and to be used with ArborText's ADEPT Editor/Publisher. ACL programming was used to automate some features and to match the old format. The FOSIs also allow for some generated text which increases authoring efficiency.
Installation of XML Editor
 

with DTD, FOSIs and customizations

 Once the draft DTD and FOSIs are complete, the XML Editor can be installed with the users and a combination of training/testing can begin. This may be the users first exposure to XML, in which case they will need training which covers XML basics and the Editor basics. If the user population is quite large, the roll-out should be phased, allowing those volunteers with the most interest in adopting new technologies to receive it first.
Installation of XML Repository
 

with customizations

 Set-up of the XML Repository can be the most time-consuming phase of the project. Delivery of the repository after the editor gives the database administrators more time to complete their tasks, while at the same time allowing the users to adjust to the XML editor before being confronted with learning about the next tool.
 Saturn's SPMS uses Chrystal's Astoria as for XML Document Management. The tool was then customized to allow for metadata entry for each object. An object reuse check tool was also developed for SPMS.
 Saturn found an effective way for users to train/test SPMS after this installation: the asked their users to rekey some of the old publications into the ADEPT Editor and save them in the Astoria document management system. In addition to the training and testing time this provided, the data will be used as the basis for the publication updates.
 

Installation of additional system functionality

 In most projects, additional functionality must be added to the system before it can be used in a production environment. For Saturn, this included a special publishing process which automatically combines objects into a service manual based on the metadata of the objects. After the installation of this release, the Saturn SPMS system will go live. Approximately six months later, the old desktop publishing system will be turned off.
 

Ongoing additions of system functionalities, including new publication types

 Ongoing system maintenance includes adding additional user functionality to further enhance the efficiency of the new system and processes. Further releases are planned to be delivered every three to four months.
 

Lessons Learned

 The Saturn SPMS project has not only been successful, it has been a fun project for all team members involved. The project benefitted greatly from Saturn's focus on the customer and the use of incremental deliveries. Other lessons learned include:
 
  •  Establish a partnership between the users and the implementors.
  •  Keep the focus on the users as the customers of the system.
  •  Think out of the box.
  •  Be honest about the advantages and disadvantages of XML authoring.
  •  Educate all team members on new technologies.
  •  Just-in-time training.
  •  Incremental deliveries improve not only the success rate of projects, but also allow for more testing and feedback time.
  •  Version control should be used for DTDs, FOSIs and System source code.
  •  Additional functionality can be added later; stay focused on the priorities.
  •  40% of all IT projects fail, but success is still possible.
  •  Make it user-friendly and fun-to-use
  •  HAVE FUN!
Financial Products Markup Language   Table of contents   Indexes   Building with XML