Legacy Data Conversion to S1000D

Mike Cook

SDL Senior S1000D Analyst

November 17th, 2015

2

Caveats to this presentation

○ This will NOT cover graphic or multimedia conversion

○ This will address most of the important issues associated with textual content conversion

○ This will touch on the psychological aspects of how to attempt a conversion effort (yeah, really)

○ This will deal heavily with project planning requirements

○ This will address analysis and design concepts

○ This will get boring

○ This will get tedious

○ You are not free to sleep (drowse a little, but not sleep)

3

What constitutes a conversion effort

○ Any time the content of a publication must undergo a wholesale change from one format to another

○ Legacy data conversion is a term reserved for the conversion of content created for an existing product and is in either a sustaining state or is static (not actively being updated or republished)

○ Legacy data conversion implies there is a requirement to study the content and its existing format to identify how it can be effectively (both with respect to cost and accuracy) transmuted into the new format or paradigm

○ With respect to S1000D, data conversion implies the addition or implementation of new data presentation methods and use capabilities – as defined by the specification

○ Wiring or part data moving from a database format to S1000D XML is a conversion effort but is not commonly considered “legacy data conversion”

4

When Do You Need to Do Conversion?

○ New project where legacy data must be moved forward to support new capabilities

○ Mid-stream upgrade where a project may be using an earlier issue of S1000D

○ Customer demands a move to S1000D

o Current process costs too much to continue doing it the old way and S1000D provides cost benefits

○ Move from a different specification or standard (DITA, iSpec 2200, etc) to S1000D to support new requirements or customer needs

o Wiring or part data exported from a CAD/CAM system for use in wrngdata.xsd and ipd.xsd based data modules – a form of data conversion which is not part of the mainstream view

• Access to better electronic data exchange

5

Worst Case Scenarios

○ Continual conversion from various source systems that do not use S1000D or any form of structured content (SGML or XML)

– It’s not uncommon for upstream source systems to be in one format and your project must deliver using S1000D in XML. In this scenario, continual conversion of content may be necessary. Many businesses are silo’d such that wiring data, part data, engineering data, and training information use different data formats.

○ You do not have control of the source data

– When making a move to S1000D, it is always a good idea to try and leverage the change to S1000D and identify if any of the upstream systems can adopt changes to make improvements to their processes.

– In cases where you need to work with active data coming from something like iSpec 2200 and convert it on a continual basis to S1000D (can’t get the authors to convert to S1000D but they will work in ATA iSpec 2200)

6

Worst Case Scenarios (cont’d)

○ Graphics must be converted

○ Introduction of multimedia

○ LOTS of multimedia and graphic files and various file formats

○ Introduction of hot-spotting if not used previously

○ Introduction of a very new presentation form factor (iPad, Android, Tablet) – First off, be aware that NOT all form factors support graphic and multimedia and

many have no drivers for CGM or 3D rotatable objects

– You need to lean toward Windows 7 and above for higher level graphic and multimedia support (sorry, I don’t care what you’ve heard about iPad or Android tablets, the horsepower just isn’t there yet and neither are the drivers)

– The only iPad or Android support for 3D and graphics must happen over the web through an internet viewer - currently

7

Analysis of the data and environment for conversion

○ Taking inventory – Know what you have to work with – in other words, what are your resources

– Talent

– Hardware

– Software

– Time

– Money

– Precedence of resources (limitations, if any, to your resources)

– Training

– Constraints – such as: • Politics

• Legal challenges

• Regulatory requirements

• Adverse personalities

8

Design of a conversion “system” or hybrid solution

○ Evaluating the sources (publications, files, support data, storage locations)

○ Knowing the source content format (RTF, SGML, XML, TXT, DOC, etc)

○ Leveraging source content format tools (if any, automation, macros, a programming language, API)

○ Evaluating the target format (output – IETP, Print, raw XML)

○ Will it be XML aware (.NET or Java accessible)

○ Mapping the relationships (SGML to XML, RTF to XML, etc)

○ Automating what you can

○ Identifying augmentation points (what’s new that needs data to turn on the capability)

○ Cost estimates of augmentation to implement new capabilities

9

Feature Poor to Feature Rich

○ Moving from one format to another isn’t done just for the fun of it

○ Upgrading from one data format to another is usually due to specific requirements to mitigate significant problems

○ Generally, a move to a new format or specification is to support the desire to enable new capabilities for authoring, editing, publishing, and end use

○ Moving the data to a new format generally means the current data is in a “feature poor” format and must be augmented to add in new capabilities

○ Moving and augmenting data puts that data into a more “feature rich” format which usually provides new capabilities – generally for leveraging automation to reduce costs and increase speed of publishing

○ Getting to feature rich almost ALWAYS requires augmenting the data to conform to the new format so the “information” can be manipulated to support specific display/use requirements

10

Project planning for a conversion project

○ Analysis – People (internal, external, and those in the hierarchy of the business)

– Resources (people, information, hardware, software, money, time, etc)

– Dependencies (availability of any and all resources if restricted in any way due to time, money, or

other factors)

○ Design – Tools (software, hardware, vendor supplied, built in house)

– Inputs (sources of content from all areas)

– Outputs (consumers of all content, both internal and external to the project)

○ Implementation – Environment (physical, cultural, legal, corporate)

– Psychology (of end users)

– Limitations/restrictions or adherence to legal requirements (regulatory agencies, contracts, etc)

○ Sustaining (if applicable) – Budgeting for future enhancements

– Measuring success

– Measuring entropy (this is so important that I can’t express to you its overall value)

– Identifying soft spots

11

Knowing your options

○ Contractually, what are your boundaries?

○ How much can you spend?

○ Who has the talent, knowledge, time, money, vision, etc?

○ When must it be complete?

○ When can it start?

○ When are the evaluation points to report on progress?

○ Who are the real people you have to please (it’s not always the boss)?

○ What is the expected outcome (not always obvious)?

○ What degree of success is acceptable?

○ What are the measurement criteria for each evaluation point of the project?

○ etc

12

Talent base

This is all dependent on the nature of the project and how large or small it is:

○ Project manager

○ Project planner

○ Authors/Technical writers

○ Editor

○ Illustrators

○ Engineers (as Subject Matter Experts (SMEs))

○ IT staff (publishing and tool makers/sustainment processing)

– Programmer

– XML experience

– CMS/CSDB support

– Publishing and deployment of IETP process support

13

Discussion

○ Who is facing an upcoming conversion effort?

○ If you had to rate your project effort size, is it: Small

Medium

Large

○ What’s your biggest fear?

○ How much time will you be allowed? Enough

Not enough

○ Is the conversion effort practical?

○ Is your upcoming conversions a pilot effort for something bigger?

○ Are you converting to S1000D or something else?

14

Knowing the specification

○ Nothing is a substitute for knowing the specification

○ You must have the talent on staff or as a contracted resource to know what you can and cannot do with the specification

○ You must know where to put data from the source content into the target S1000D content schemas (mapping data points)

○ Push through the business rules and narrow down what your project will or will not use of the specification (this may be the most important piece of the puzzle)

○ Understand the intent of each schema and the interrelationships of various internal schema structures between schemas (referencing/linking points)

15

Knowing your customer and their needs

○ Just because you’re moving to S1000D doesn’t mean you’ve solved all your problems with respect to creating content and publishing it

○ Business rules (the process of making decisions on what you’re going to do with the specification) by themselves are meaningless if you don’t take into account the needs of the customer

○ Data conversion requires understanding where you want to go with the data and how it is meant to be consumed by the end user

○ This includes how graphics and multimedia are to be implemented/used

○ Also, is the solution web based, an independent IETP, or an integrated IETP/Help/Training system embedded into the product?

16

Return On Investment (ROI) – will there be any?

○ ROI is “iffy” when it comes to a legacy data conversion

○ It is dependent on many factors, of which the remaining longevity of the product the documentation supports is a crucial piece to identifying the worth of the effort and its overall cost

○ Added capabilities provided by the new format of the data, combined with newer authoring techniques (which come with pros and cons of their own) can provide much needed new uses of the data, however the effort may never be cost effective

○ Sometimes the effort is mandated by the customer purely because they need the new capability and there is no other way to obtain it. In this case, ROI is subjective to the needs of the customer

○ A legacy data conversion may never be valid from an ROI perspective and re-authoring from scratch may be the best solution (yes, I know, it sounds like heresy, but the truth may set you free)

17

Conversion Options

○ The most common options available to project owners are:

– Automated conversion

– Manual conversion

– A mix of both automation and manual

– Contract it out

○ Each of these are driven by the current conditions of your business. Automation, if you have an IT department capable of handling the creation of conversion software, can be a huge benefit. There are some COTS software solutions capable of managing some forms of data conversion to S1000D.

○ Manual conversion has significant benefits too. You can train your authoring and editing staff to create data modules correctly by converting the source data manually. This only works for one time conversion projects (no continual conversion requirement).

○ Depending on where your source data is coming from, there is a high probability source data will need to be converted continually. For example, wiring data and part data are commonly in upstream systems that have nothing to do with S1000D data structures.

○ Contracting out your data conversion is generally going to fit into the same space as a manual conversion – it’s as if you’re doing it internally but you’ve brought someone else on board to do it – someone who already has experience converting content to the new format.

18

Automated Conversion

○ What makes sense to automate

– Picking your fights is just as important as picking what can be automated. Just because you want to use automation doesn’t mean you can. In many cases you are limited by the structure of your source data.

○ Figure it out on your own or out source it

– If your IT department can handle it, start there. If not, examine potential COTS solutions (there are a few). It is very hard to provide an automated solution if the original content is in Microsoft Word, free form text, or a non-structured file format. If you are already using a structured content methodology – like DITA or iSpec 2200, then you stand a much better chance of converting your content.

○ Performing QA

– Just because you think you’ve successfully converted your content, doesn’t mean you did. You must go through each data module and validate the content was properly inserted into the element and attribute structures.

– In many cases, boilerplate content was used in much of the <identAndStatusSection>. You’ll need to find the data modules that need tweaks to the values in the status block and update them as soon as possible, since these elements and attributes tend to be overlooked after conversion.

19

Manual Conversion

○ What makes sense to do manually

– In most cases, anything that can’t be done using automation must be done manually. However, you may choose not to use automation at all, purely due to time constraints or costs. If you have a small project, for example under 2,000 data modules, it might be more timely and cost effective to manually convert everything instead of using automation. The reason is, automation commonly does not put all the new information in for the new features you want to take advantage of (going from a feature poor to a feature rich environment).

○ Do it yourself or out source it

– Manual conversion is usually done in house. It can serve as both a training paradigm, QA pass, and upgrade all at the same time. Regardless of which method you choose, you must have every data module touched by someone at some point in the process. If you do it as part of the manual upgrade, you’ve solved three problems all at the same time and possibly saved a considerable amount of time and money (in the long run).

○ Performing QA

– QA is generally less of an issue if a conversion is done manually – since you’re more likely to use existing QA (workflow or edit promotion cycle) processes you have in house. Or, as part of the conversion, you add in new editing processes as part of your workflow.

20

A Mix of Both Automated and Manual

○ There is rarely a complete automated solution for conversion

○ It is more common to have a mix of automation and manual processes

○ Mixing has the advantage of leveraging the best of each method

○ Automation can be used for the “coarse” conformance of data being pushed into a data module. For example, creation of a data module, insertion of boilerplate into the <identAndStatusSection> pushing the bulk of the data into the <content> section of the data module.

○ Manual conversion can then take over and massage the content into the appropriate places within the data module that automation could not do. Applying new information into the appropriate elements and attributes is next allowing for leveraging of new capabilities. Such as enabling applicability, change markup, reason for update, acronyms, etc. This allows for further automation once converted for use on the backend of the publishing system to generate front matter.

○ Knowing how much to convert using automation and what to leave to manual processes is the key to success

21

Contract it Out

○ Depending on your project, company size, need for advanced capabilities, etc it may be more beneficial or cost effective to contract out the conversion effort.

○ Companies with expertise in conversion of content from various file formats to S1000D may be better at getting the job done than trying to do it yourself. Especially if it’s the first time you’ve tried to implement S1000D.

○ In this case, you have two alternatives: 1. Train some of your staff in S1000D.

2. Go straight to a conversion company and learn as you go.

○ The problem with going straight to a conversion company is you don’t know if you can save any money doing it yourself. What you don’t know can significantly affect the outcome of your project. It is best to have a fundamental understanding of S1000D before you get too far down the road. Therefore, training is highly recommended for key individuals prior to any RFP, RFI types of work. Without in house talent, you’re basically giving a conversion company the opportunity to exploit your situation. Know what you need before giving the green light to any work.

22

Integration Concerns

○ Augmenting the data

– Generally, a conversion means “I’m adding new capabilities to my content”. This means you’re going to need to add information to various elements and attributes associated with your data – beyond what you probably already authored in your previous data format. Metadata supports how data can be used, therefore, you have more data to add for how to control or leverage the information.

○ Dressing it up for the ball

– In most cases, you need to have a specific plan regarding what new features/capabilities of S1000D you want to leverage for your project. Enabling these features takes extra effort that a conversion isn’t going to help you with. Someone usually must touch each data module and add the necessary information to make it more useful (and rarely is there any automation to support this). Use business rules to document and communicate this information to the entire team.

○ Publication integration

– After your information is in S1000D data modules, you can now repurpose your information to fit into any publication structure you choose. Because non-S1000D implementations tend to use publication structures that are more closely tied to physical books, you’ll potentially need to consider the three way data organization structure allowed by S1000D. Master TOC (based on the SNS – tends to be used for IETPs), Publication Modules (manual hand built structure – tends to be used for printed publications and PDFs), and Graphical Navigation (alternate IETP navigation to content).

23

Integration Concerns (cont’d)

○ In S1000D there is no page-block paradigm (kind of like “No one can hear you scream in space…”)

○ You can emulate page-blocks using Publication Modules

○ There is no such thing as a “sub task” paradigm (like you will find in iSpec 2200)

○ S1000D is prescriptive – it tells you how to use elements, attributes, and schemas

○ S1000D is not just for aviation/aerospace – it can be used for almost anything requiring servicing/maintenance – but the nomenclature is still bent toward aerospace vernacular

○ Conformance to the SNS and Information Code paradigm is critical to successful implementation of S1000D, which means creating Data Module Codes (DMC) is highly dependent on a DMC coding strategy

24

What You Can Do to Reduce Source Control Chaos

○ Open a dialog (aka TALK, communicate, converse) with data source owners – Sometimes it’s as simple as getting everyone to the table at the same time. If they

all agree the current content development process is not what it could be, it’s easier to implement change

○ Define audit trails and use data source ownership to push for changes – Psychological pressure can work too. Pushing the potential failure of a project

upstream into the source data supply chain can affect change. Though this isn’t a nice thing to do, if it’s true and everyone upstream knows it, if the conditions are right, you can affect positive change.

○ Renegotiate contracts with customers – This may be necessary to offset costs – passing some of the cost of development

work off to your customers for increased functionality that helps their ROI – increased funding improves chances of paying for upstream changes

25

Making converted data pass QA using the BREX Data Module

○ Now that you’ve converted your data, how do you find out whether or not you made any gross errors? You can eyeball all of the data modules, but is that feasible for a large project?

○ The BREX data module is a great tool for performing some forms of quality assurance. However, it can’t find everything – and it tends to be a little slow.

○ It is suggested you create and use a .NET application to validate data module content in a wholesale approach. You can build more complex test relationships using a simple VB .NET application than you can with a BREX DM. In fact, you can create automation to correct predictable errors (similar to a search and replace scenario). You’ll also have a more flexible programming environment to do bigger and better things with.

○ Creation of Front Matter Data Modules, using a VB.NET application is actually very easy to do and highly recommended – if you’ve used the appropriate elements and attributes within the data modules. Make sure you know which elements and attributes enable specific features/capabilities you need to leverage for automation features.

26

Discussion

○ Who is new to S1000D?

○ What are the key benefits or capabilities you are expecting

to gain from S1000D?

○ What do you NOT see in S1000D that you believe you

need?

27

Data Module Coding Strategy (iSpec 2200 as a source)

○ Moving content from one place to another isn’t always a single file to single file process – sometimes a single file makes many data modules

○ Sometimes small files are aggregated into a single data module

○ Page Blocks and Sub Tasks may cause you to think hard about how the information gets pushed in to a data module

○ Generally, a sub task is a data module (usually a one to one mapping)

○ The SNS is just like the AMTOSS Code (or ASN AMTOSS Standard Number)

○ The task code can relate to the Information Code, but you’ll need to map it out (providing an information code exists for the task code)

○ Disassembly code and disassembly code variant are unique to S1000D and are file level “product configuration” methods. Generally not something you want to use if you’re going to enable applicability (but that’s another subject and separate presentation)

28

Data Module Coding Strategy (iSpec 2200 as a source) (cont’d)

○ The DMC is: – DMC-Model ID-System Difference Code-SNS-Disassembly Code and Variant-

Information Code and Variant-Item Location Code

– Model ID is easy – set it and forget it (just make sure to register it)

– System Difference Code – if you use applicability, set it to “A” and forget it, if you don’t use applicability, identify all the sub models of your product and create a reference to each one in a table

– SNS – chapter, section, and subject, but broken out as System, SubSystem, Sub-SubSystem, Unit/Assembly

– Disassembly Code and Variant – if the unit/assembly can be decomposed further or is made by different manufacturers, you can define that here

– Information Code and Variant – what the type of content is in the data module (introduction, remove, replace, parts, fault, testing, etc)

– Item Location Code – where the work will be done (actually, this is really beneficial to the end user – it lets them know if they’ll be working in the rain)

29

How Publishing Concerns May Drive Conversion Requirements

○ Do your homework

– Go through the business rules – knowing what you intend to do by the time all the data is converted is a key target. Knowing how to leverage the various capabilities of the schema structures goes a long way to meeting your objectives.

○ What do you expect all this data to do?

– Again, the business rules will drive out whether you can or cannot use the capabilities of the specification to facilitate your project needs.

○ Project Planning is crucial to success

– Planning and business rules are part of the same analysis processes. Be sure you know S1000D before you start doing your business rules.

○ Experience may be your best friend – call in a specialist

– Calling in a specialist to help you convert your data is a very good idea if you’re too busy working on other issues. HOWEVER, don’t expect a specialist to have ESP. You MUST have someone on staff who knows S1000D and how it is meant to be used. Without someone who knows the vernacular and how content is meant to be authored into a data module using the various schemas supplied as part of the specification, you stand a MUCH SMALLER chance of being successful.

30

Future modularization of the specification – will it affect future conversion efforts?

○ Due to upcoming potential changes in the specification, the idea of modularization may affect any future legacy conversion efforts

○ Will it allow for increased ease of conversion? Most likely not. And, if the current thinking/design for how to modularize the specification comes to pass, it may slightly increase what you will need to do.

○ Modularization is intended to support new projects – but not necessarily legacy conversion efforts

○ The idea of the modularization of S1000D is intended to simplify implementation, but will require an understanding of what each module provides as a feature/capability of the specification

○ Interrelationships between modules will need to be known to effectively enable each module. Related data structures are common across many schemas and their use requires knowing how each schema will need to be managed if there are interdependencies across your data set

31

Stakeholders

○ Stakeholders have expectations

○ Therefore, anyone who has expectations is a stakeholder in some way

○ Document expectations/needs/requirements/etc and identify what is “needed” versus what is “wanted”

○ Make sure there is an answer to supporting what is “needed”

○ Address what is “wanted” as augmentation of the core project effort AFTER the initial conversion effort is accomplished

○ If a “want” can be addressed simply and easily as part of the initial conversion effort without adding risk, then incorporate it – otherwise save it for a future upgrade of the data and CSDB

32

Risks and Mitigations

○ Legacy data conversion is costly, adds risk to a project, and can adversely affect a companies image

○ Risks generally are in the area of how successful the content can be moved from one format to another

○ Mitigating the risks require several methods: – Recording of each requirement that constitutes the final outcome of the effort. This

allows for signoff of a task/line item in a project plan and the ability to track utilization of resources and budget.

– Quality assurance analysis of each step, aka a review of each task, step, phase, or milestone in the project to measure the success of the effort and identify if the project is moving along as expected.

– Identifying the highest risk processes in the project plan to make sure they are monitored closely to know when to adjust the degree of effort

– In other words, use good SDLC project planning methods and good communication methods – like Agile, P+, or SixSigma (and let’s not forget ISO 9000).

33

Compliant versus Conformant

○ A common question asked by most S1000D adopters is, “Do we need to be conformant or compliant to the specification?”

○ Conformant means your project will be close to the intent of the specification. You may slightly (and the key word here is “slightly”) deviate on the use of various elements and attributes from their original intent. You’re still close, but due to various reasons, you needed to tweak the use of something to solve a business requirement. Creating custom enumerated attribute values does not constitute a definition of “conformant” to your project. You would still be compliant. However, changing an existing definition of an enumerated attribute value would push you toward a conformant definition of the specification. For example changing em01 from Bold to Bold and Underline would be a change that would make your project conformant and not compliant.

○ Compliant means your project will use all the elements and attributes as they were designed to be used (and as documented in the specification). This means you only need to use those pieces of the specification as required by the needs of your project but you will not use an element or attribute for purposes other than what it was originally designed to be used for.

34

Discussion

○ Do you feel you understand the Business Rules process

enough to successfully adopt S1000D for your conversion

effort?

○ Do you have any requirements to use other “S” series

specifications?

○ What worries you the most?

35

The Practical Side

○ What must you do first?

○ Find iteration possibilities (discovering patterns you can leverage consistently for automation)

○ Structured vs Unstructured – Structured: High probability of successful automation conversion (hi-fidelity)

• SGML – Highly structured

• XML – Highly structured

• HTML – Minimally structured

– Unstructured: Low probability of successful automation conversion (low-fidelity) • Hard copy paper – Somewhat “positionally” dependent structure readable by OCR

• MS Word – Minimal structure if a template was used or is highly bookmarked

• Plain Text – Very minimal structure (if any)

• Wang – Some structure but no guarantees

• Display Write – RTF like file format allowing for some structure but much like MS Word

36

The Practical Side (cont’d)

○ If converting SGML based content, identify which SGML ENTITIES/elements/attributes must now be turned into elements or attributes or remain possible ENTITIES

○ If converting from an XML based format, map elements and attributes to appropriate elements or attributes in the S1000D schemas

○ In HTML some elements are moving targets – for example a <p> provides no context of what it is, for example, a <levelledPara> followed by a <para> has meaning whereas in HTML there is no specific definition of what the <p> is in relation to anything in the content

37

The Practical Side (cont’d)

○ Sun-setting/Retiring an older legacy system

– Was it put to bed already and tribal knowledge is gone?

– Where is the documentation for the formatting?

– Is the HW and SW (aka the system) the content was created on still functional?

○ Expectations and scope

– Some projects do not put a value on what the effort is going to cost in time and money – you MUST identify what it’s worth to the company and what it will actually cost – including internal manpower since it will most likely divert efforts and support from ongoing work

○ Will the resultant conversion be defensible?

– Aka, did you design in a means of defending against gross mistakes

– It’s not always obvious up front, but a conversion may find out – very late in the game – that the effort was a total waste of time due to an oversight made at the beginning of the project

– Can you repeat the process easily, if needed?

– Designing, into the project plan, the ability to change a process and repeat it, isn’t a bad idea if you have a really tough conversion scenario

38

Let’s not forget, S-Series Specifications Influences

○ Will it affect or be affected by an LSA system or maintenance planning (scheduling) requirement?

○ Does it require implementing any of the S series of specs?

– S2000M – Material Management

– S3000L – Logistics Support

– S4000M – Developing Scheduled Maintenance Programs

– S5000F – Operational and Maintenance Data Feedback

– S6000T – Training

– S9000D – ILS Specifications

○ Is provisioning or scheduled maintenance a road block?

39

The Human Side of the Equation

○ Any human factors as an issue?

– The IETP, printed publication, or website must be usable by humans

– On occasion we tend to think S1000D is a solution when in fact it is not

– S1000D is a publishing paradigm with specific capabilities

– These capabilities require data, processes, and structured content formatted such that an IETP can display the content in a manner that is most beneficial to the end user. S1000D is not a solution, and in fact, is the central problem that must be understood in order to build the solution around

– A CSDB is the solution to authoring, editing, content management, and publishing (and the workflow supporting it)

– The IETP is the solution for accessing the published content

○ Addressing the fear of failure

– Project planning using tried and true methods is the key to success

– Quality control methods provide a modicum of assurance that a project is proceeding as planned

– Reducing the fear factor of employees and leaders to reporting bad news is a key ingredient to catching a problem before it gets bigger (employee reporting safety)

40

The Human Side of the Equation (cont’d)

○ Knowing when you’ve hit the “Houston, we have a problem…” point in your project

○ Classify what is a problem and what is just a glitch in your processes (yes, there is a difference)

○ Remembering (by documenting) why decisions were made and what if any options were available at the time of the original decision (this may save your bacon later)

○ Getting to the finish line is highly dependent on what the content is, how it is formatted, what it must be used for, and what features and capabilities must be available in the end product (IETP, Website, or printed publication)

41

The End

○ The End – or is it?

○ There are so many factors to identifying what needs to be “converted” that there is no way to adequately address everything you need to do

○ Much of what you must do will require knowing your data, the product it documents, what the customer is expecting for output, how S1000D is put together, and how to get the content into the format necessary to support the end user requirements of the final product

○ Knowing the specification and how it can be used is critical to your success and some form of education is your best bet to knowing what you really need to do to achieve a successful end to your efforts