DCL/Input and Input Providers

Coming to Terms With Input and Input Providers

By Barry Schaeffer, Principal Consultant, Content Life-Cycle Consulting

Advice on establishing and maintaining a productive process and relationship

Who your providers are may be less important than what they provide. In fact, in today’s increasingly connected world, providers are responsible for the raw material for nearly everything you deliver. Providers may be experts in a wide range of disciplines, may be anywhere in the world, and yet be expected to create something you can use to generate the products your audiences demand. Indeed, as the definition of “provider” widens, an increasing percentage don’t view feeding your systems as the highest and best use of their time and aren’t excited about changing their processes to satisfy you.

The upshot: providers can be your best partners or worst nightmare.

That wasn’t always the case. Just a few years back, most information products were created from input created by providers hired, trained for and expert in processes designed to meet the needs of system developers responsible for the final products. The change means that developers must be increasingly focused on establishing and maintaining a working relationship with their providers, often compromising to reach a consensus that will allow the effort to go forward.

What do you want from them?

If dealing with providers must be a part of your world, you must decide what you want from them and deal with the fact that you probably won’t get all you want. First and foremost, true in virtually every instance where data must be collected, processed and delivered, you want disciplined, consistent data, preferably with the necessary structure to create your output products.

You want that data delivered to you on-time so you can meet your schedules. This is especially true where peaks and valleys exist in production. Nothing is more frustrating that receiving the previous quarter’s input all in the last two weeks of a publication schedule… except perhaps receiving that late content with unacceptable inconsistencies and errors that must be corrected.

You want providers to be willing to embrace, and meet, your needs, demands and schedules and to trust that you won’t do them in.

What do they want from you?

With some exceptions, providers want to be left alone to do what they have always done.

This is especially true if they have become used to doing their work in a particular fashion and you are about to change that to meet the demands of higher level information products. While there are ways you might take whatever they create, correct it, finish it and create the final products with no impact on the providers, this is almost never justifiable from cost or complexity perspectives. So assume that when you walk in the providers’ door, you are bringing change with you.

What do they need from you?

Once everyone agrees that there will be impact, you and your provider community can get down to the often dirty work of figuring out how to meet your needs without turning their world—and working lives—upside down. One way to begin that process is to develop a “needs” analysis from both sides: what must you have in order to do your job, and what can they deliver without destroying their productivity.

Let’s look at some specifics they need from you.

They need you to accept their data as close as possible to the way they are comfortable creating it. It won’t be exactly the same as they are used to, but it shouldn’t change beyond their ability to create it.

They need you to work hard to cushion the changes to their procedures and tools. It’s likely that many of the changes you will impose will create increased complexity and discipline in their processes. They may have been using Word to create input, worrying not much if at all about the logical structure of what they are creating, focusing instead on what it looks like. You will likely be asking them to change that; to work more logically; to inject more discipline into their work and to give you a more predictable content stream. You can cushion that blow to a great extent by developing authoring applications to soften the complexity and to help them discipline their work… even if they continue using Word.

They need you to provide at least some funding for any changes you want them to make. If your new processes and systems require that they upgrade their training, hire more people or get new software or hardware, their management will want you to shoulder the cost burden. It usually doesn’t work that way and providers usually end up paying for the changes you force them to make… that is one of the reasons why systems and provider groups usually have testy relationships. So if you go in with an offer to pay for what you can and to help them minimize their costs, you will go a long way toward avoiding a split between you and the providers.

They need you to give them plenty of time to change… and a fall-back plan if it doesn’t go well. Once you reach some consensus on how things will function in the new world, you must go off and develop your systems and they must learn how to use them productively. Most provider communities are willing to take this responsibility, but are adamant that their entire world can’t change in a week. They need, and you should give them, time to get used to using the new procedures and tools; achieving the needed level of productivity and getting beginner errors down to an acceptable level.

If the changes are significant, most providers also want a fallback procedure in case they run into trouble implementing the new systems in production. In every group, there is a range of capability from early adopters to slow learners, and both must have the opportunity to move at a pace they can support. This means a fallback procedure you hope you never need but they need to know is in place.

How should you approach them?

Start early: whatever happens, it will take some time, and mandating dates they can’t make doesn’t help the project succeed.

Be transparent: if they sense they are being conned or patronized, they will push back… hard.

Respect their current methods and tools: they may be neophytes to the world of systems development, but they are probably expert in fields that your audience needs and wants.

Plan for minimum impact on their world: If you act like a bull in a china shop, they will push back and the entire effort will suffer. Remember, input providers are often the largest expense organizations face and any improvement you can bring to their productivity will pay off handsomely… every year.

Show them strong software support up front: The systems graveyard is full of projects that sought to impose a new software environment on providers, installing it out of the box, thinking that it “could be enhanced later.” The ones that survived this egregious error faced months of frustration after the providers panicked and turned their backs on the entire effort. If you are going to change the tools, show the new tools to their best advantage up front, making sure that the users know there is more to come if they need it.

Include them in the design effort: it will reassure them, and they often have great ideas.

Don’t assume you can tell what to do: if you try it, you will find yourself under a counterattack that may have more management support than you expect. If the fight gets to the executive office, providers often if not usually win.

What are your Input Options?

Take their content as-is and convert/rework it:
Any content can be converted: the difference is in the amount of clean up and completion required… sometimes virtual re-authoring. This is lowest impact on the providers, but the highest cost to the system and the maximum limitation on the quality of resulting content. And unless you plan to stay with this approach, don’t start it. Once in place, it will become the providers’ method of choice and you will have to pry it away from them.

Change their authoring tools to fit your needs:
They are probably using Word or Word Perfect and want to continue it. If you decide to (and can) push them into an appropriate authoring tool, they will resist, so:

  • Set up an authoring lab where you can show them tools you are considering for them and enhancements you are willing to put in place to cushion the blow.
  • Make the software you choose as comfortable as possible up front (never show it out of the box first.)
  • Give them time to adapt; focus on early adopters; and always provide a fall back for those who need it.

Enhance their current authoring environment to simplify conversion and minimize cleanup:
Even word processing can be disciplined to make it easier to convert, especially if you are working with a capable conversion firm like DCL. Authoring applications can simplify complex structures, validate input and impose value lists, etc. Select your conversion method early so you know how close you must be to convert successfully, and will have plenty of time to perfect and tune the chosen process before you must go live.

So… what about revisions?

If the content changes after publication, you may have to revise and republish your deliverable product. If you have converted the source to something else… what do you revise? You have several options:

  • You can revise the original, but you must ask your providers to prepare, convert and cleanup each time. If revisions are significant, may affect the same area of content and occur often, this may be the best method, allowing the providers to keep the source up to date as they go, but you must look carefully at how it will impact your production process.
  • Convince the authors to revise the final form (XML, etc.) using the appropriate editing tool. If revisions are infrequent and normally occur only once in an area of content, this may not only be the most efficient, it may be acceptable to your providers.

Getting from source to deliverable successfully is seldom a matter of black or white, but finding the right shades of grey. Remember, your providers live in a different world from yours and are just as committed to it as you are to yours. You will do it best if you understand and respect each portion, function and participant going in.

Starting right and including every participant as you go will help to insulate you from mutiny by the authors, never a pretty sight.

Keep your wits about you, get help where you need it, tread carefully and you can be successful.

Barry Schaeffer, Content Life-Cycle Consulting

Barry Schaeffer is the Principal Consultant for Content Life-Cycle Consulting.