Copyright © 2006, SAS Institute Inc. All rights reserved. “Words at SAS” Quality at the Source A Case Study – Dee Stribling, SAS.

Copyright © 2006, SAS Institute Inc. All rights reserved.

“Words at SAS” Quality at the Source

A Case Study – Dee Stribling, SAS


Quick Context

SAS develops software – products and solutions across a variety of research and business areas, globally. (And, yes, it’s a great place to work!)

I’m a project manager, I’ve served in various management and development roles over 20 years at SAS. (Read between the lines “patient, persistent, can discuss gardens as well as sports” – this all comes in handy)

“Terminology management” is too long a phrase, so Sue Kocher (our terminologist) invented “T19T”


This presentation covers

How a very small project team has been able to have a positive effect on global business processes

How this team decided on the software, people, and processes needed to begin implementing terminology management

How this team identified needs, issues, and encountered and capitalized on the “unexpected” in implementing our first terminology management system.

How you can start doing the same thing…


“Whole Product Life Cycle” (for terminology?)

Words are the building blocks of an organization’s conceptual framework. The quality of terminology directly relates to an organization’s presence in the global community – words are an essential corporate asset!

Terminology management involves the whole product life cycle – from a new product idea, through design, development, support, and delivery.

This includes quality across all phases of all content development and management.

Such management also includes terminology associated with the product production framework – Internal as well as customer-facing external terminology.

Goal is to reduce risk throughout the whole life cycle for the words supporting a product (or deliverable).


Why is this important?

“Terminology has to be managed within a language… before it can be translated between languages” (Kara Warburton)

45% of global companies find it difficult to deliver a consistent global message (SDL, from The Economist)

Incorrect and inconsistent terminology frustrates customers and breaks down trust in an organization and that organization’s deliverables.

“Trust is built on reputation and reputation is generally NOT built on advertising or looking smart” (Elise Bauer)


SAS Stats…

SAS is the world’s largest privately owned software company

Produces software for business intelligence and analytics

10,000 employees worldwide; 4000 at headquarters in Cary, NC USA

Annual revenues about 1.9 billion Customers in 113 countries


Global Reach & Local PresenceConnecting with Customers

More than 400 offices globally in 52 countries

10,094 employees

More than 400 alliances

Hundreds of local user groups globally

Approx. 43,000 customer sites in 111 countries

Americas 45%, Europe, Middle East & Africa 45%,Asia Pacific 10%


Localization

Localization centers in Copenhagen and Beijing

European localization center recognized by LISA for their workflow

Proprietary tools

In 2006 translated over 2 million words, across 32 products, in 21 languages.


Terminology sources at SAS

Product manuals

Education & training

in Multiple Languages…in Multiple Languages…Product

help

www.sas.com

Marketing collateral

White papers

E-learning

Russian:

プロパティ

Eigenschaften

內容 / 摘要資訊 / 屬性

Propriétés sww.sas.com

z

Chinese:

German:

Japanese:

Свойства

French:

Hungarian:

Polish:

Finnish: Ominaisuudet

Właściwości

Tulajdonságok

English: Properties

User interface labels

System messages

Syntax error while parsing WHERE clause.


Challenges What is terminology? Why do we have to manage it?

How much will this cost?

My staff doesn’t have time to do this, and no you can’t have any more resources

My release deadline trumps your project deadline

I don’t care about noun phrases, gerunds, or what the darn word’s derivation is, just show me what the right word is and how to use it...

I’m a developer – of course I can write

I’m a writer – of course I know the correct term

Whoa, developer and writer disagree - process?

Hey, it’s just a database, we can build that (oh…it can do what? Concepts? Multiple languages?)

Wait – there are multiple terms for one concept?!


EDITOR

Tracking Application

Dev Mgr to Developer:

Moving this to Defects for later release and update our project

tracking application

Defects

DEVELOPMENT MANAGER

WRITER

VIRTUAL UI TEAM

UI ANALYST

UI Design Tools

Change Tracking

Processes

Communication FlowWriter to

Developer: term is in use

Question for UI Analyst re:

term use

Editor to Writer: term not meaningful to product audience

UI Analyst to Virtual UI Team: need term help

Tester to Developer: term not consistent

with previous release

Ad-hoc Tools

Developer to Writer: the

following terms are new with this release

DEVELOPER

TESTER

Ad-hoc Tools: email, phone, informal

discussion

BREAKDOWN


Our Goals Improve customer experience by using

consistent and correct terminology

Improve software and documentation delivered to a global audience

Establish one recognized corporate resource for terminology

Elevate efficiency and effectiveness of terminology-related processes

Establish terminology management as an initial and integral part of the product development cycle


What was (and is!) our Game Plan?

1. Analysis

2. Buy-in

3. Communication

4. Design, develop, and just do it!


1. Analysis - How we determined need

Terminology users and terminology their terminology needs are often ill-defined and not well-understood within an organization.

Terminology and content are carried along by rivers of processes within and between organizations

Understanding these processes and related terminology issues is critical to optimizing terminology management work flow.

We used Contextual Design to determine need, untangle process issues and create terminology management solutions.


Steps in Contextual Design

1. Discover and model current needs across customers

2. Consolidate to form a single picture

3. Design a better way to accomplish the work

4. Provide a framework for trying out the new work model – software plus process = the application


2. Buy-in

Rule # 1

Must have an

EXECUTIVE CHAMPION

Rule # 2

Must have a

Passionate visionary!


Summary: http://pubsweb.na.sas.com/eds2/edittest/projects/TMS/JDEdwardsSummary.htm

Getting Buy-in- Rule #3: Money Talks – Note the Costs of Not Controlling Terms and Clarity (An example from JD Edwards Co.)

Documentation activity UncontrolledEnglish

Controlled, Single-sourced

Development of field definitions in English, revised from programmer’s specs to textbooks, hardcopy doc, Help, etc. (avg. 17 variations)

$645 per field definition x 1000 definitions

Total: $645,000

$260 per field definition x 1000 definitions

Total: $260,000

Translation of 17 variations of 1000 field definitions@ .23 per word, into 7 languages

$13,048,000 $770,000


Getting Buy-in Rule #4 Appeal to Corporate Pride

(um, many of our competitors are ahead of us…and we do want a consistent brand!)

User Interface Text UIs are where most terminology

problems surface earliest and most prominently.

Clear, consistent language (not just terminology) is an important component of usability (customer satisfaction!)

UI labels and messages are where lack of clarity is most likely to lead to calls to Tech Support.

And confusion for translators…

Mergers and acquisitions• Financial reporting

(product names)

• Documentation (different terms)

• Software (different message and UI label conventions)


3. Communicate, communicate, communicate!

Promote T19T Services:

• Internal web site, blogs, articles

• Offer to consult with other groups

• Gather and publicize “success stories”


The Other Half of Communicate – Listen!

Really hear what people are saying

Take next step – ask questions in order to understand what they are trying to communicate

Become a skilled communicator yourself, be sure people on your team are also good communicators.

“Facilitative Leadership” classes helped us immensely (See “The Facilitative Leader” by Roger Swartz)


4. Design and Do!

T19T is a development project, you must recognize this and manage accordingly..

Use best practices for component design, development, testing, documentation, delivery, and support

Deploy in phases – create small, but visible and significant successes

Get creative, knowledgeable, can-do people on board – work with vendors who are willing to start small and scale up.


Design and Do Rule #1Cross-Division Teams!



Success! Developers quoted as saying over 50% of their

messages needed significant changes and were improved by applying T19T editing processes

Single canonical resource for terminology across the company is in place

Publications and some development groups using the new T19T system

Processes are in place to manage basic terminology events with existing (and familiar) tools

Greater corporate awareness of the importance of T19T

Green light to proceed to the next phase(s)


Lessons Learned – Basic Steps

1. Analysis, Advocate, Awareness

2. Buy-in, Background, Bridges, Borrow

3. Communicate, Communicate, Communicate

4. Design, Develop, Do!


The rest of the story…or, what’s said on headset stays on headset…

Money talks – justifying T19T is difficult, make it as quantitative as possible, multiply by the consequences of not doing it…globally

If an executive advises you – listen.

Keep it simple – people think they know about words, but they usually don’t. They want to learn, but not from a detailed point of view

Remember your neighbors – if you know implementing T19T will cause your testers to have to re-bench, tell them – be up front

Exhibit extraordinary patience – you’re changing business processes, this takes time.

Copyright © 2006, SAS Institute Inc. All rights reserved.Copyright © 2006, SAS Institute Inc. All rights reserved.

Copyright © 2006, SAS Institute Inc. All rights reserved. “Words at SAS” Quality at the Source A Case Study – Dee Stribling, SAS.

Documents