Requirements analysis

This chapter discusses the following aspects:

• How do you make an assessment of the user requirements?
• Can I use ODF everywhere in my IT environment? Even in online applications?
• How can I find existing integrations with scripts and such things?
• Do I have to migrate everything to ODF immediately?
• Can companies and organisations that do not yet use ODF still read my documents?

Assessing existing use

How do you go about it?

In order to determine the best way to deploy ODF in your IT environment, you first need to have good insight in the current situation. Therefore ask the key users in your organisation the following questions:

1. To what extent do you currently use word processors, spreadsheets and presentation programmes?
2. Is there other software involved that generates or processes documents (or parts of documents) that you work with? Which?
3. On which platforms and operating systems (also mobile) do you currently create and view documents?
4. How straighforward or complicated are your documents?
5. Can you share some of your special or often used documents with us?
6. Do you use templates? Do you create them yourself?
7. Do you use macros? Do you create them yourself?
8. How frequent do you share documents within your organisation and/or with third parties? And how do you share these documents?
9. Is the use of change tracking important to you? If so, on which platforms and operating systems (also mobile) do you use it? Do you know of other applications used by people you work with to edit and review documents?
10. What could stop you or others from using another application, desktop or mobile operating system in the future?
11. Do you publish office documents on the web? What are the main reasons for publishing the content in such a format on a website?
12. Did you participate in previous, similar migrations, for example from WordPerfect to MS Office, from Lotus SmartSuite to Lotus Symphony or from MS Office 2000 to MS Office XP? What was your experience?

If you get the answers from a representative group of users to these questions you are well on your way. In the following paragraphs, we will discuss a number of focus points per component of the office suite.

Do I need to start using different software?

These questions might have given you the impression that not only the file format, but also the organisational workflow or the software will need to change in order to support ODF in your IT environment. This is not necessarily the case, it mostly depend on the maturity of your organisation and how much you depend on certain software. There is a variety of different applications available that fluidly work with ODF 1.3 out of the box. In many cases you can also upgrade the regular behaviour of your application by means of a plugin, add-on or extension. But in order to know what needs to happen, you need to first understand where you are. We therefore recommend that you spend time to make a good analysis of your office environment with the aid of our questionnaires. Preparation is an important part of doing an efficient job.

Text documents

A number of guidelines to assess the use of text applications:

1. Determine which file types are in actual use. Also make an inventory of the different versions of a file type. For example, a .doc file can be in Microsoft Word 97/2000 format, in Microsoft WordProcessingML format or in a vendor specific dialect of either.
2. Do you often export documents to HTML?
3. Do you use special code, such as VBA, Java or Applescript? Do you use dynamically linked objects (OLE, D-BUS, DDE, ActiveX, OpenDoc etc)?
4. Do you use some form of links/shortcuts in documents to refer to other documents in your system environment?
5. Do you use templates for icons or graphs?
6. Do you use frames, text boxes, active content controls?
7. Do you use macros?
8. Is the word processor often used to send e-mail attachments?
9. Do you use fill-in forms?
10. Do you use automatic spelling correction? Dictionaries? Or modified dictionaries?
11. Do you use automatic word completion (sometimes called auto-text or AutoText)?
12. Do you rely on password protection for confidentiality (including opening, changing and printing files)?
13. Do you use custom fonts that need to be embedded for people outside of your organisation?
14. Does your organisation aim to be inclusive, i.e. explicitly require accessibility information to be present?

Better documents means easier migration

Please keep in mind that many possible hurdles in the migration to ODF or with the reuse of content elsewhere do not exist when you follow best practices when using word processing software. These five simple guidelines will make your life much easier:

• Avoid direct formatting. Use character and paragraph styles.
• Use paragraph settings to determine the space above or below a line or a paragraph, instead of hard returns (with the Enter key), particularly in lists.
• Use the text flow properties of a paragraph instead of manual page transitions.
• Do not use tabs or spaces to align text. Use specific tab-stops, or even better, a table.
• Avoid proprietary fonts that are bound to a platform or a product, for which embedding in a document is not allowed. If possible use only generally available fonts or choose fonts that can freely be distributed and embed these in your documents.

When necessary, do educate the people in your organisation to use these guidelines.

Spreadsheets

• Again, determine which file types the key users in your organisation use. Make a list and also specify the various file types that use the same extension.
• Do you use a lot of input from text files to generate data for spreadsheets?
• Do you use formulae for optional parameters?
• Do you typically write complex formulae yourself, or only use existing documents or templates?
• Do you use statistical, financial or mathematical functions?
• Do you use specific features such as Quattro Pro Pivot Tables, OpenOffice.org DataPilot or Microsoft Office PivotTables?
• How large are the datasets that you handle? How is this data managed with respect to versioning, data integrity and security?
• What type of diagrams do you use? For example, bar graphs, pie charts and/or block diagrams?

For example, a file that ends on .xls could be from versions of Microsoft Excel dating over twentyfive years back, or may in fact have been created by a content management system or mobile app just today. The large variety of different file formats and their problematic nature is a significant part of the reason to want to consolidate document work flows to ODF. If you have trouble determining the answers to this question, consult a document format specialist.

Presentation documents

• Again, make a list of the file types currently used.
• How important are special effects in presentations, such as gradients in 3 colours, double and triple borders, dotted borders?
• Do you use corporate templates for your presentation? Who maintains them? Is there anything missing you've added yourself?
• Do you use voice-overs in presentations?
• Do you use animation in diagrams?
• Do you use mouse-over functionalities?
• Are your presentations sometimes published on the internet? Do you embed copyright information alongside photo's and images?
• Does your organisation aim to be inclusive, i.e. explicitly require accessibility information to be present?

Hidden dependencies

When migrating a file format, you need to know what the current situation is to be able to choose the best course. With that in mind, it is important to track down the small hidden databases inside your organisation. These are often put into place ad hoc to solve an urgent problem. Unfortunately a quick and dirty 'temporary' workaround often ends up as a not so quick and increasingly more dirty 'permanent' workaround, which is bound to cause problems later on. Developers (often just power users) or maintainers disappear, or simply forget to inform others that they have a database running on their machine to support a specific task. In many cases there is no record of the application even existing nor is there any documentation of its functionality, until such time as unknown things start to break. If you are making an inventory, don't forget to ask if users collect their own data and for instance depend on small local databases to save address details, such as telephone numbers and e-mail addresses. Make sure to design towards a process that is more solid, both technically and from a maintenance point of view.

Are databases even included in the ODF specification?

It probably won't come as a surprise that the basic information needed to connect documents to databases is indeed specified in the Open Document Format standard version 1.3. The tooling for working with databases in your IT environment however is something that falls out of scope of this guidance on document formats. Probably you should facilitate the functionality in another way. Database design requires in-depth knowledge and the interaction with text documents, presentation slides and spreadsheets can become complex. It requires the professional skills of an IT department to sustainably and securely manage within an organsation. Therefore, we recommend that you check the extent to which this category of database plays a role in your IT environment, and consolidate these towards a more permanent solution.

All or nothing?

Evaluating functionality

Once you have answered the above-mentioned questions per type of document processing programm, you can make an analysis of the situation by - for example - assessing the functionality on a scale of 1 to 3. Do this for yourself, but also include the answers for key users in your IT environment in the final tables.

Value	Importance
1	I can live with this functionality not working, or having to adjust my working method to achieve this same functionality.
2	I would experience problems if this functionality does not work, but I could live with it if there is a work-around solution.
3	This functionality is of vital importance to my organisation.

Create those tables!

It is very important that you have a clear answer to all the above-mentioned questions. Do not assume that you - or a single user - reflect(s) the standard use of documents within your organisation. Each department and each group of users is different, due to historical developments, different policy makers per section of the organisation, different competencies or tasks, etc. Being armed with a thorough analysis of your IT environment will make the switch - described in the next chapters - a relatively easy job. We cannot put enough emphasis on the importance of a thorough preparation. Migrations failed because of the lack of an adequate preparation.

Types of users

There may be different types of users in your organisation. These users often work with a certain file type. An example of categorisation:

• The "average" user: The large majority of users needs an office package to write a text or a letter, the occasional spreadsheet for some simple calculations and perhaps some presentation slides now and then. These users do not require any special functionalities and are therefore easy to migrate.
• The accountant: this includes all users who do anything finance-related, so not only accountants, but also financial analysts, managers, logistical planners, purchase controllers, etc. This type of user often has his/her own, modified document templates and uses special functionalities in spreadsheets.
• The developer: not only software developers, but also those in your organisation who are responsible for creating and managing templates. These users often use "hybrid" documents: text files, database operations and spreadsheets that are linked and where input in one type of file is created by output from another.
• Scientists: often use special file types and complicated calculations.
• System managers: often disregard what the "ordinary" user does and work according to their own method, for example with scripts.

Try to categorise the users in your organisation into the various groups. See if you can find one or more people in each group who can help you with the testing and who can assist and train other users in the same group at a later stage.

Do the work step-by-step

In the following chapters we will look at the various types of programmes that support ODF. In preparation for this selection process, you can create three test files, one for each category. The first file lists all the functionalities used in your IT environment which you have assessed with Value 1. A second file contains all the functionalities that you have assessed as Value 2 and a third file contains all the 'unmissable' functionalities that you have assessed as Value 3. When we start testing the various programmes, we can evaluate which ones will cause the most problems and which ones the least. Based on this information, you can make a step-by-step plan for the final migration. To get some early progress, which helps to keep the focus on the process, you can for example decide to migrate the easiest file types in your organisation first.

Compatibility

Customers, citizens and suppliers

Of course you want to make sure that you continue communicating with documents with the outside world after the migration. As soon as you have created a list for your own organisation of all the functionalities that you really need, would like to have or could do without, then you probably also have a clear understanding of what is required to satisfy the needs of those people that will receive your documents outside of your organisation. Because you are moving from a vendor-specific format to an application neutral standard, it will not go unnoticed to the outside world. For many this will be a significant relief, as the switch to a standard allows them to stop having to facilitate the ideosyncracies of the legacy file formats and choose freely among the tools they would like to use. Others may actually notice - for the first time - that they are hardwired to the same vendor you have worked with until now. Perhaps your organisation or others like it even was one of the reasons they adopted this solution in the first place. These users will need to disentangle and resolve their dependencies in parallel with you. Communicating to your team about the reasons behind and the benefits of the move to ODF is therefore really important, because they will have to relay this explanation to the customers, citizens and vendors.

Application vendors

Beware of marketing traps

The functionality table that you have created for your own organisation also helps you to identify those documents that are created or consumed by applications from vendors you work with. For them the migration to ODF means that they can and should add adequate support for ODF. A number of specific points for checking the solutions providers come up with:

• Check if ODF support is not just something that is advertised with, but that it is fully supported as a native format for the purpose you are seeking. The new open structure of ODF is fully transparent, which is inconvenient to some vendors that like to veil their products in mystery. Some vendors will leave out certain (meta)information when you configure it to work with ODF, so that you still depend on a second file format. Others will conveniently loose information when importing or exporting data in order to make the use of ODF unattractive. Some will claim that it is okay to hardwire their software with some specific office application, and not support a standard. Deep integration is perfectly possible with ODF, be consistent.
• Request complete documentation about company-specific tags in relation to XML. XML allows for the insertion of any tag: even company-specific data tags that are difficult to migrate. If the meaning of the information in between the tags is not known, another application may not be able to use the information, even if the programme can interpret the reference schedule. In some cases suppliers have used illegible, company-specific, platform-specific, non-migratable tags in their applications. These obscure practices make it very complicated to read and manipulate files. You can test by opening documents you have created in multiple applications or in a tool that will help you assist with this. Use a validator to see if the document is actually technically valid.
• Expect surprises: If a file format you are migrating away from is owned entirely by a single commercial entity and there is no real control by users, stakeholders and industry peers, there is a significant risk that the specifications of that file can be changed without prior notification. This allows a single supplier to dominate the information and security architecture of many organisations.
• Ask about cross-platform operability: if you create a document in a certain platform such as Blackberry OS, Windows or Mac OS X, can you read, modify and save it on another platform? Is the functionality to modify, file and request the file complete for each platform? If you depend on a single platform to manage and access documents, what will happen when that platform falls out of grace of the users and disappears from the market?
• If you put the requirement for ODF in your procurement processes, the right things should happen automatically. If not, you can hold the vendor accountable.

Insist on ODF

Consolidation of various legacy office file formats into a single application-neutral standard that offers interoperability to citizens, businesses and the public sector is a huge step to optimise and secure information chains that run around across all of them. It should be clear to suppliers that the choice of ODF as a government standard means that turning on ODF support in their applications is no longer just a best practice or a feature that can be negotiated about, but a real change in the industry that requires immediate action in order to serve the interests of their customers. If you work for a government: governments have significant volume, and should be worth putting in the effort to make them more safe and efficient - especially since moving along with this imminent change in the industry will help vendors to continue being relevant in their field.

Technically it will be much simpler and cheaper to work consistent in one file format. Especially in software that automatically generates or processes documents the required changes in their software will often be trivial. This is due to the simple and elegant XML based structured and the flexibility of ODF on the one hand, and the limited complexity of such documents on the other hand.

In some cases existing contracts with suppliers will ask a little creativity in order to speed up the consolidation to ODF. Don't be afraid to steer towards support before a contract ends, and be public when your vendor dodges the responsibility.

In order to reap the benefits of the consolidation to open file formats as quickly as possible, consider the following:

1. Insist that suppliers support ODF, replacing fragile application dependencies with proper standards. Don't settle for partial support, it will reduce your overall chances to success and raise costs for everyone. If a vendor is not willing to make the change, confer with other stakeholders and get it fixed. Do not let inertia get in your way, but pool demand, resources and expertise.
2. Pass user requirements on to the ODF technical committee within OASIS.
3. Promote participation of interested parties - including users - in technical committees of OASIS, support and facilitate technical contributions. Consider an active participation in the evolution of the standard, so that your own requirements become part of the fabric rather than having to settle for what vendors think you should have.

If you practice good habits, you are on your way to simplifying the future operation of your organisation.

Summary

To ensure a smooth migration to a new format, you must know exactly what your current situation is. We have gained an overview of what the users within our organisation expect and need. We have set our first steps towards the actual migration: we know which file types are used in our organisation and who uses them for which tasks. We can use the answers from this analysis to make a thorough planning to ensure a seamless - or as smooth as possible - migration.