Really Strategies
RESOURCE CENTER
“Really Strategies provides us with the third-party expertise we need.”
USATODAY.com
Planning to Re-Use Content? Fasten Your Seat Belt and Get Ready for a Ride
Dec 2002As a publisher beginning to use the same or similar content in more than one product, you are immediately faced with process challenges and questions. How are you going to get all that content out of Quark XPress and into HTML? Should you begin authoring in a neutral format like XML? After you begin updating your content more frequently for the web, how will those changes get back into your annual book? Like most publishers, you are probably now savvy to the fact that changing publishing processes - how content is created, reviewed, and packaged into print and electronic products - not only requires planning, but is a significant factor in the financial success and quality of new products.
Changes in publishing processes also put enormous stress on the individuals and groups they impact. When people become responsible for new tasks requiring new technical skills, they often become less efficient and less able to focus on quality. Bottlenecks arise around the subset of people that "get" both the technology and the content. While the bottlenecks feel frustrated because they are overburdened, others are threatened because (typically) less senior staff have suddenly inherited new powers. Job responsibilities and lines of decision-making authority become blurry. Publishers are reacting to this stress by restructuring their editorial and production organizations[1] and by redefining job positions. Some publishers are even trying to change their very culture as a means to facilitate more rapid and ongoing change.
As consultants, we've witnessed our clients experiment with new processes and organizational change to meet new publishing opportunities, and thought we'd share some of our observations.
OBSERVATION 1: It's too early to talk about best practices, but these are the choices we've seen work well.
There's enormous variety in the processes and organizational strategies publishers apply to share content across multiple products. Some publishers get the content "perfect" first in a neutral format (e.g., XML) and then publish to both print and electronic products with a high degree of automation. Some publishers apply the same degree of craft (manual effort) in authorship and design to their web sites as they do to their print products. In some cases the same staff is responsible for content regardless of where it ends up. In other cases content is edited independently for various products, although there is still sharing of stories and facts among the groups.
We've seen each of these approaches work well and work poorly for different publishers. Of course, it's not the approach itself that's good or bad - it's whether the approach matches the characteristics of the publisher's business. Here are the primary choice categories we've seen work well.
CATEGORY 1 -
Print-Driven
Appropriate if this describes you: If your print content
makes it into electronic products, it mostly appears just as it did
in print and following the same print update cycle. Some content
might be modified or developed just for electronic products, but
for the most part this can happen independently of your print
processes.
Process: Stick with a print-first workflow, and afterwards
process the content into formats needed for electronic products.
Develop electronic-only content through a separate process.
People: Most authors and editors work like they always did
(thinking about print), and a separate electronic production group
is responsible to transform content and develop electronic
products.
Upside: This is a low-stress option because it involves
little change. New costs can be directly attributable to new
products.
Downside: Authors and editors often feel little ownership
for electronic products, slowing the evolution and improvement of
electronic products. If content is further developed for electronic
products, those updates either won't make it back into print
products or will get there through manual processes.
CATEGORY 2 -
Content-Driven
Appropriate if this describes you: Much of your print and
electronic content is very similar, and opportunities to re-use
content in new products or product derivatives are expected. Output
to print and electronic products can be partially or highly
automated[2] and content
typically isn't written to fit print layout (although some
occasional copy fitting might still be needed). Electronic products
might be published more frequently than print products.
Process: Use a single process and system to create content
for all products. Develop automated processes to deliver content to
products.
People: Authors and editors transition to thinking about
content guidelines rather than how content looks on a page.
Specialists are needed to ensure that both print and electronic
production (what it takes to get content to products) run
smoothly.
Upside: New products can be developed quickly and
affordably, with a focus on content quality.
Downside: Authors and editors often struggle to gain the
technical skills needed for this transition, and have difficulty
separating content creation from product development. Poor content
development tools can make this transition even more difficult.
Production processes become more dependent on programmers, which
can sometimes create bottlenecks if the programmers are not
integrated into the production workflow, as often happens with
IT/IS staff.
CATEGORY 3 - Multiple
Drivers
Appropriate if this describes you: Content for electronic
and print products vary more than for the other categories,
although sharing of content subsets happens frequently. For at
least some print and some electronic content, update cycles are
frequent (e.g., daily, weekly, or monthly). Electronic products
might be published more frequently than print products. Print
layout demands (e.g., a magazine-style layout) require that content
authoring for print products be integrated with print rendering
tools. Sophisticated functionality in electronic products requires
special metadata (e.g., content categories).
Process: Create separate processes for different content
categories based on content types (e.g., full-text articles versus
reference data), on how product requirements affect authoring and
editing (e.g., writing to line count for print or the use of XML
for electronic), and on the author/editor characteristics (e.g.,
internal versus external, highly technically skilled or less so).
Develop one or more systems customized to streamline each process.
Develop tools that enable content to be shared among these
processes and systems with an acceptable level of manual
involvement (the definition of acceptable varies widely). Ideally,
this implies a central content repository where all content is
eventually stored even if it isn't originally developed there.
People: Different groups of authors and editors will learn
different processes and systems. Another group understands all of
the processes and systems and their interdependencies.
Upside: Individual processes and systems can be modified as
necessary without the level of compromise needed if a single
solution were used for all content. As with category 2, the content
repository allows for rapid new product development.
Downside: The environment is necessarily complex, and it can
become difficult for one group to understand the impact it might
have on another. The evolution of processes and systems must be
carefully planned to avoid unnecessary inconsistencies or a
Band-Aid® approach.
Obviously, there are other factors to be considered than those listed here, such as whether your content includes a significant number of complex images and whether external authors or editors are involved. There is also another category, electronic-driven publishing.
Observation 2: Success is only possible when decisions are based on real product opportunities and real expenses.
Reading through the categories above, it would be easy to assume that categories 2 and 3 represent a natural evolution beyond category 1. Not so! It might make sense to stick with category 1 - a highly print-driven scenario - indefinitely. This is because the right solution isn't just a factor of process and people, it's also a function of business priorities, including the good old bottom line. You need to ask yourself: On which products do you make the most money now? How and when might that change? What's your competition doing? In other words, when will it (if ever) be economically viable to spend money on the transition to a new content-centric system? We have seen publishers working hard to "modernize" when there was no pay off in sight.
Of course, we shouldn't overstate this point. We see even more cases of publishers who haven't moved quickly enough, and whose competitive position has been weakened by a lack of or late investment in the processes, infrastructure, and people needed to support products. Either way, the lesson is to make sure your decisions are driven by real-world opportunities, not by unfounded excitement about new ways of working or by a too conservative approach.
Observation 3: Account for company culture and individual concerns during transition.
If you do find yourself working like a category 1 even though you have the characteristics of a 2 or 3, then you need to consider how to transition your processes, staff, and organization to the needed approach. Again, there's no right way to do this. Some publishers have chosen rapid change. Some have chosen to take slower, incremental steps. Either approach can succeed or fail. The key is to decide what is necessary for the business and then to build a plan that accounts for how the approach will be affected by and will affect your organization's culture and individual concerns. For example, if working on some of your publications carries more clout than working on others, then when staff are re-organized around content rather than around products, they might be disoriented because they can no longer tell where they stand in the company pecking order and they no longer know how to climb the corporate ladder.
If drastic change is unavoidable, you might need to ruthlessly change everyone's job description and accept that you will lose some staff. If that kind of change isn't needed (and it is usually isn't), you will probably want to establish scheduled opportunities for staff to give you feedback. Regardless, it is a bad idea to let yourself be taken by surprise by negative responses.
Finally, don't underestimate the need for and value of experiencing change as a group. Even if you are impatient for radical change, it might be worth taking a more gradual approach so that you can assimilate ongoing lessons learned.
Observation 4: Print and electronic publishing differ in significant ways that should be reflected in processes and organizations.
Managers and technologists often have trouble understanding why editorial or production staff resist efforts to consolidate electronic and print production processes, but in our experience their concerns are often legitimate and require learning from both groups.
For example, electronic products typically require a greater level of ongoing involvement by product development and design experts than print products. That's because it's possible, okay, and expected (by the audience) that electronic products will continually improve. This means more ongoing expense, especially because software development might be involved. It also means that processes and systems for electronic publishing must be able to be modified quickly and efficiently (so that, for example, a new metadata field can be tracked). Conversely, electronic products don't need to be as perfect or complete when they launch as print publications do. It takes time for print-savvy staff to become comfortable with this fact, and it takes time for technologists - including new media editorial staff - to understand why print-oriented staff are so reluctant to give control of their production processes over to programmers. Print staff know that page layouts often are not as predictable as we'd like them to be, and that last minute changes might be needed to make those pages perfect. After all, there won't be another chance once you've sent the pages to the printer.
We have observed a number of publishers go through this learning curve as they first introduced electronic products and the accompanying content management and publishing process changes. Bottom line success correlates directly to both the speed with which editorial/production staff differentiate between development processes for print and electronic products and the flexibility of the tools provided by technical staff.
Observation 5: Traditional publishing approaches are inherently in conflict with good software development practices.
Editorial and production staff are driven to perfection, and will work to the last minute of a deadline to achieve that perfection. Experienced software developers know that they must plan in advance and resist the impulse to add last minute changes that might introduce bugs. As editorial and production staff become involved in content management and electronic publishing initiatives - both of which involve software development - it's no surprise that they often come into conflict with the software developers who are trying to help them. Both sides need to give a little.
In our experience, software development methodologies cannot be sacrificed. However, this cannot reasonably mean that the burden of conforming to them falls entirely on the editorial and production staff who are defining requirements. Instead, it is absolutely essential that project analysts be experienced in publishing processes and in the content and product themselves so they can help editorial and production accurately express their needs. And, software development staff should consider rapid development approaches that enable editorial and production staff to get a look at what's being built as soon as possible.
Organizationally, we have seen some publishers react to this issue by establishing software development organizations that report directly to product development or editorial staff, or who are merged into existing print production groups. This group exists independently of the company's Information Systems/Information Technology department. Other publishers support product development, content management systems, and production systems through their IS/IT departments. Interestingly, the publisher's size does not play a role in this choice - we've seen large and small publishers make both. We've also seen both approaches fail and both succeed. It appears to us that the key to success is leadership. Managers of the software development teams and of the editorial/production teams must have strong relationships, a common vision of how technology supports the business, a common vision of the business's goals, a commitment to established software development practices, and a willingness and ability to communicate all those ideas to staff. In particular, we have seen the greatest success when the leader of the software development group gets excited about the business's products - not just technology - and passes that excitement on to his or her staff.
Another successful strategy is the creation of a group that serves as a liaison between development and editorial/production staff. Sometimes this group is a formal part of the organization and sometimes it's a looser grouping of individuals who happen to have the right skill set. Typically, the group comprises former editorial or production staff who have become programmers or something close to it. Regardless, these are people who are comfortable with technology and with content, who will vigorously fight for the best compromise among all factions, and who have the ear of leaders on all sides. While such a group is enormously helpful to an organization, it is often a difficult place to live. There are never enough of such people, and so they are always too busy. While they are usually recognized as being indispensable, they aren't necessarily financially compensated for their skills. Developers often see them as the representatives of those difficult users, while editorial/production staff might see them as the people that are always saying "No" on behalf of IT.
Observation 6: Outsourcing isn't always the answer.
Many publishers work with outside vendors or consultants to do most or all the work associated with new product development. Some do this temporarily; some do it as their permanent strategy.
In terms of process and organization, outsourcing advantages include:
- It's easier to experiment with new product approaches if you don't have to hire permanent staff to do so.
- Vendors can often recommend appropriate processes for new work.
- Internal staff are less stressed, and the number of internal staff needed is more constant.
But there are also some less obvious disadvantages:
- While there are vendors to fit almost any budget, outsourcing for newer types of work (e.g., web site development) can be expensive, even when compared to staffing up. (This is less true for well-understood processes like print production, which is highly price competitive.)
- It is difficult to effectively manage work you don't understand well.
- Internal staff miss the opportunity to learn valuable lessons about electronic product development (the corresponding lessons on the print side are already understood and so this isn't typically an issue).
- If one of your challenges is content re-use, then outsourcing doesn't solve the difficult problem of how to create content that works for all products and media. In fact, we know publishers who are so reliant on vendors to process content for various outputs that they are effectively held hostage, making it more difficult to transition to content re-use processes than it otherwise would be.
Observation 7: The biggest predictor of success is awareness at all levels of the organization.
The easiest process and organizational transitions come when senior management, hands-on management, and hands-on staff all understand why and how the transition is taking place. This seems like an obvious statement taken from Management 101, but we consistently see mistakes in this area, so it bears repeating. If there are misunderstandings about the purpose or expected outcomes of change, do your best to correct them through education and communication.
Observation 8: Even success is uncomfortable.
Finally, you should be aware that there are very few publishers who have implemented the processes that make it possible to go after new product goals and who would say that it's been smooth sailing all the way. The successes we've seen have all been accompanied by periods of pain. This only makes sense. Most people don't find change easy. But we can provide this encouragement: Publishers who resist change when it is overdue often experience even greater pain.
[1] Actually, they are frequently redefining sales and marketing roles too, but that's another story. [return]
[2] Analysis is required to determine whether print output can be partially or completely highly automated, but typically this is possible for products where layout follows predictable rules. [return]
