Really Strategies Blog

Looking for acceptance

When implementing a new or improved content management system, I find that many teams don't have time or the staff to perform what is known as "user acceptance testing (UAT)". But let's face it: end users are going to either accept or reject the system components eventually, and it's much less painful to get through this process in a controlled manner during the project than during production.

During project testing, participants expect to find bugs and issues. The development team is still available to fix the issues. The team can take disruptions in stride, since issues only disrupt testing, rather than production schedules. Failures are part of the normal process.

After the system is released into the wild, system end users who were not involved in the project start working and expectations are high: "This system has been released, so I’m assuming that everything works", they're thinking. Newly discovered issues are upsetting and disruptive to production schedules. The project developers may have been reassigned to other work already, and a team may need to wait for fixes, which exacerbates the problem.

So how do we balance the realities of resource constraints with the obvious need to test?

Let’s look at it in terms of quality. A generally accepted definition of quality is that something meets specifications ("is it what we ordered?") and is fit for use ("is it fast and intuitive?").

The UAT process runs in a tightly controlled environment and excels in proving methodically that all specifications have been met. It helps in answering the general questions "how will we know we're done?" and "how will we know we're successful?" This is ideal from a systems vendor or IT department perspective; because it allows a neat line to be drawn between the project and handoff. The project is nicely wrapped and packaged for delivery. For the end users, the disadvantage here is that everything rests on how well requirements were defined in the first place. It’s very easy to miss something that can cause trouble later on.

A team can also release a system as a beta version or as a pilot. Instead of a few people running dummy content through test scenarios, a sub-set of actual system users can move through an actual workflow using actual content. This approach helps the group move forward on their production schedules, while maintaining a relatively controlled environment. And, because it's a smaller set of users, the group's expectations can be set so that issues don't freak them out. Since the team is operating in a live environment, they can identify critical issues that may have been missed during the requirements gathering stage. A live environment is ideal for proving fitness for use.

However, it may not provide a very thorough quality check against the stated requirements, since there may be exceptions in the process that won't occur during the beta period, such as an end-of-quarter rollup, report, or content delivery. The pilot approach works only if the end to end process is sufficiently short enough to get through within project timeline and cost constraints. 

Ideally, we’ll use both approaches. At a minimum, it’s smart to spend some time with at least a couple of team members to take the system for a "test drive" assuming multiple roles, to ensure that all specifications have been met and the pilot period starts smoothly. Then following that with a pilot enables the end users to determine fitness for use.

I'm always looking for the right balance. What's your experience?

Finalizing System Requirements - Moving Forward By Stepping Back

The process of defining requirements for a technology system can be daunting for a company, particularly when it involves the coordination of the voices from multiple business units or many different departments within a single business. Operational pain points, opinions, key business drivers, and priorities can vary greatly among the groups. Most companies spend time at top management levels outlining specific business strategies and those executives and top managers are able to articulate what they expect the technology to achieve.

Yet a disassociation can occur when the work to define the details for the technology begins. There are various reasons this disassociation can occur:

• The teams defining the functional requirements may have not had enough exposure to the high level business strategy.
  
• Top management may not document strategy and instead, only verbalize expectations in meetings.
• Business units or departmental groups may define the high-level strategy differently and, not surprisingly, filter the information as they believe it pertains to their area. 

All of these conditions can make it difficult for personnel to retain the big picture as they move into the detail requirements process.

"Stepping back" to clearly document high-level business strategy and problem statements is a good practice prior to diving into detail requirements. A referential roadmap that includes financial or efficiency targets allows the project team to identify how each functional solution area will roll up to the high-level strategy. The roadmap also gives the team a tool to use to determine valuation at a requirement level.

As an example, a company may define the inability to complete effective product planning and forecasting as the overall business problem. The company may have determined that they have multiple departments keying in the same product data into different systems. Perhaps these systems are not integrated and are not accessible to the multiple departments. The high-level strategy to enhance business planning and forecasting includes development of a central location for product information and the ability to reduce or eliminate data rekeying. This is the point where the company has decided to seek out technology to fulfill this need.

Assuring that the requirements team that is aware of and is invested in the high-level problem and strategy goals helps the requirements process move forward in a streamlined fashion. The project team is able to consistently review and document how well the functional areas fit with the business strategy and problem statements. For example, department personnel that will be able to add to or enhance product data using a shared system will no longer need to rekey product information from scratch. This may also allow a separate departmental database to be removed from the process flow. The amount of time personnel spend keying information and the maintenance of the database are all areas of specific improvement that should be collected by the requirements team and identified based on the functional area for the new solution.

Sharing business problem and strategy statements and goals at both a high level and detail level helps keep the project aligned. This practice allows the project team to articulate how the solution will meet the business goals specifically and is particularly helpful for defining value. Stepping back to constantly review documented business problem and strategy statements throughout the requirements stage helps a business move forward in an effective manner.

eMedia Professional Certification Program Raffle

Don't let anyone tell you there is no such thing as a free lunch...(in fact, we have them once a month at the office but I digress) or in this case...a free eMedia Professional Certification.

IDEAlliance just launched its eMedia Professional Certification (EMPC) program. This program is offered in four distinct blocks of courses. Each block comprises a series of webinars that covers a range of topics related to eMedia Publishing, including

• eMedia Workflows’ Impact on Organizational Structure and Partner Relationships
• Controlled Vocabularies, Taxonomies and Ontologies
• XML Under the Hood: What Everyone Should Know
• Which XML Workflow Really Works?
• Integrating DAM and Content Management

This program runs from March through November. All classes will be recorded so publishing professionals can join at any time. 

The entire session costs $1800 but Really Strategies is raffling off one free pass to any individual who provides the most compelling reason why he/she should win. Yes this is not at all scientific but that means you can be as creative as you want to be.

Either submit a comment below, including a valid email address so I can contact you OR send me an email with your contact information.

More info on the program is located here.

The eBook Challenge

Yes, it looks and sounds like a fun new game but it's actually quite a confusing landscape. And the image depicted here is a simplified version of starting points, formats, stores, readers, devices and their loose connections.

I'm still catching up from last week's Tools of Change for Publishing conference where the big takeaway was 2009 is the year of the ebook.

What I want to know is are publishers prepared? Which ebook format is best for you? Do you distribute to all devices or just one? How do ebooks fit into your multi-channel publishing workflow?

I can hardly wait for 2010 to see who comes out the winner. Stay tuned.

RSuite CMS provides loud and clear answer for Audible.com

We are often asked by publishers to describe the real business impact RSuite CMS has on our clients. Along with my previous post on Blood-Horse Publications, Audible.com is another client that has leveraged the power of RSuite to realize its business goals.

Audible, Inc., an Amazon.com, Inc. subsidiary, is the leading provider of premium digital spoken audio information and entertainment, on the Internet.

In early 2007 Audible.com launched an aggressive project to revamp their entire metadata program to better manage and process the metadata files they receive from their publishing partners.This program had the following business objectives to meet:

• Ensure error-free metadata by using publisher or publisher aggregators as the source of data, and by developing new tools to drive, search, browse, and publish to store functions off this sourced data.
• Ensure the ability to identify Audible products on partner sites by providing ISBNs that correspond to the downloadable digital binding with each product in feeds to partners, wherever and whenever possible.
• Reduce the occurrences of human error by automatically populating data into web site databases, from the sourced data.
• Improve findabilty, searchability, and marketability of products by standardizing keyword, category, authors, contributors, and publishers.
• Improve royalty systems by making contract entry a requirement for any product being pushed to an Audible site.

During a 4-week proof of concept (POC), RSuite was configured to prove out several use cases:

1. Leverage RSuite’s workflow tool to ingest ONIX feeds and audio files
2. Apply additional metadata (both manually and automatically)
3. Distribute the appropriate content packages to target delivery sites.

During this stage many business rules were also documented that were applicable to improving Audible's business opportunities. After a successful POC, Audible.com selected RSuite for its metadata and aggregation solution.

RSuite became the framework upon which Audible crafted solutions to meet all its requirements: workflow, business rules validation, content aggregation and delivery. In 6 months, RSuite was configured and implemented to become Audible's workflow tool, which enables seamless transfer of content from publisher feeds to web site-ready files.

Now after using RSuite for over a year, Audible has realized its goals of integrating a tool that would satisfy the business objectives and show a return on investment quickly. As Art Zegarek, director of data architecture told our team, “RSuite has become a very critical system very fast!" It is satisfying to know that RSuite is helping an aggregator such as Audible.com meet its business objectives every day.

Achieving automation: InDesign/InCopy to XML

InDesign and InCopy are built for desktop publishing - giving great power to design and editorial.  This is all great news.  However, it makes exporting XML rather tricky - particularly the development of fully automated XML exports.  Sure you can capture XML coming out of these applications, but can you really push that XML into your CMS without having text processing look at it? 

We've looked at this over many projects and the key issue is, of course, the discipline required by each group in the process.  If they don't follow the rules, then their content might not match what your CMS is looking for.  A deck must be labeled as a deck somehow.  Likewise, a B-Head or run-in head must be labeled appropriately. There are also customer or genre specific structures and metadata that must be maintained - with paragraph or character styles (or one of several other techniques).

The point is that you can't look over everyone's shoulder.  Styling and other structure related errors are bound to creep into your content on occasion.   If you only want to accept well structured XML, then you need the capability to automatically identify errors and only ingest acceptable documents.

While you can create scripts to QC the content during production, this poses a scripting update problem every time you want to change your format structure (every time you do a redesign, perhaps).  And while scripting is extremely powerful in CS2 & CS3, it is pretty low level stuff and time consuming to produce anything complicated.  It is also problematic if you don't have a specialist on staff.  Better to write scripts once and move QC somewhere else.

So what to do?  One solution is a Schema (or DTD) validation technique that allows this QC operation to proceed during an automated export.  The Schema will be more restrictive than just looking at Adobe structures - it will overlay structures specific to your content.  And while updating a schema requires some technical knowhow, it is more straight forward and much faster than updating scripting of any kind.  The reason, of course, is that this is what Schemas are meant to do well.

Using a Schema to validate InDesign/InCopy content can detect a surprising number of human errors with styling and other structuring techniques.  Not all errors, but it can do a solid job if your content is moderately complex.  Content flows into an interim format and is validated before being transformed into its final form in your CMS.  This means that valid content can be fully automated from InDesign to the CMS.  Invalid documents can be automatically siphoned off for review and correction by production.  Users can then be retrained if necessary.

Beats checking every exported document ad nauseum, doesn't it?  Especially at 2am.

Requirements, the publishing manager, and accountability

Senior publishing managers: do you have a clear idea of your role in publishing systems projects?  How about in requirements gathering for publishing systems projects?  (By senior publishing managers, I mean the publisher and direct reports or the equivalent - print or web).

BAs & PMs: How clear are the lines drawn between your business requirements, your functional requirements, and your system requirements?  Are you encouraging your senior publishing managers to take the appropriate project roles?

I'm thinking of two major projects I've come into contact with over the years where it was clear that the dividing lines drawn were wholly inappropriate to the intended constituencies, particularly for publishing managers.  I've also seen one major project where the requirements gathering was rigidly compartmentalized by the consulting company, probably as a means to ensure that each constituency was dealing with the appropriate subject matter. 

Some problem indicators:
1. Publishing managers reviewing quasi-technical diagrams in a functional requirements session (yes, we need to use XML; yes, we need a digital asset management system!).
2. Business/financial managers making top down decisions on specific systems. (Though there are cases where this could be appropriate)
3. Technical teams being left to determine how much time a task should take.  (What’s the matter? it only takes 10 minutes to process...)

Each to their own:
- Publishing managers should be concerned with functional requirements, which determine the effects of a system on staff work, including how work gets done by editors, etc.  They should also include setting standards for performance.
- Business/financial managers should be concerned with business requirements, or the overall financial effects of a system including related process changes.
- Technical teams should be concerned with systems requirements, systems, and architecture, to meet publishing manager needs (within financial constraints)

Publishing managers can have an important impact on a project.  My advice is not to get your hands dirty with specific technology.  Falling in love with a particular system or even a type of system, is a baaaad idea, trust me.  Falling in love with improvements in performance and ease of getting work done for your staff is a much healthier idea.

Senior publishing managers often consider the following:
    - We need to create this new online product
    - We approve doing this publishing technology project. 

They can more positively impact a project by making a few simple accountability statements and holding on to them like a pit bull.  They might sound something like this:
    - We need to create this new online product, and make content production for it take only this amount of staff time.
    - We approve doing this publishing technology project.  This project must reduce time spent on these non-editorial tasks, this amount, by this much, and decrease overall time in our production process, this amount, by this much.

This should set up a good interplay between subordinate publishing managers/staff and the technical team as they participate respectively in the creation of functional requirements and system requirements.

Print and web: one ecosystem?

Ah, content, what are you doing to our beloved work culture?  We were happy when the world was simple!

Print production, so well known, so comfortable in its methods of achieving uncomfortable deadlines.  It was so simple when 'this is how we do things here' easily fell from our lips. 

Web production, so comfortable in it's freshness and technical knowledge.  Yet it still had a world all to its own.

But now, maybe the idea of 'content' is just starting to bring each world into the other's focus.  The definition of content is not really tied to any medium - it lives outside of the reality of 'deployment', of paper & ink, or web browsers. 

Clearly the 'star' theory of content (circa 1999) is long dead, where content is produced centrally and sent seamlessly to different mediums.  Content cannot live completely outside of its context.  It must be edited to each medium.  It can start, end, and be stored centrally, in something like an RSuite (XML CMS), but it changes as it moves to print, or moves to web.

With today's tools, many publishers are living in a world where content flows from manuscript-to-print-to-web.  And where the most efficient content development ecosystem will only be achieved if upstream (print) production and downstream (web) production work to accommodate each other.  Its one ecosystem after all, where the same 'content' travels through both of these environments.

A content hand-off at the the dividing line between these worlds was the first step in fitting these two systems together.  Loosening and blurring that border seems to be the next step as we forge ahead.   A single content ecosystem demands it.

The future of production, the production of the future

Here's a thought -

Given the way things are moving - as we see more and more automation in publishing, for getting print content to the web for example, some changes are bound to occur in the industry.  The pace of change is different in each vertical, so it may happen at different speeds.  But some novel ideas may start to emerge about the role of "page production" in the organization.

4 big trends:

1. The link between print and web content is strengthening.  Print groups are starting to adapt their work to support downstream web content requirements.
2. Some production roles are moving toward system administration roles as editorial & production systems are adopted.
3. In general, technology is becoming more and more part of the print workflow environment.
4. While print production still tends to be the premier process at many publishers, the web versions of content continue to gain in importance.

The question is, how does this mesh with IT and technical management?  Is everything becoming grayer than it already is?  Will these two titanic cultures (print and web) converge into a brand new organism?

And as this trend continues to advance, will page production, in fact, end up reporting in through technology groups?  Exactly where are we all going here?   

Well, these thoughts are all interesting, but the future is a long way off. 

Or is it?

Get XML from InDesign & InCopy today

There has been a lot of activity in the XML-export-from-Adobe-area here at Really Strategies over the last year.  Over this time, we have developed a system with continually deepening capabilities for extracting XML from Adobe InDesign and InCopy.  The projects have been across several publishing verticals and have produced content to meet several XML standards, for text newsletters, and for the web.  The projects that I have worked on all manage content in the K4 Publishing System, and have used the K4 XML-Exporter aided by Adobe API scripting.

Here are a few thoughts that come out of this effort:

1. There is no significant technical barrier to getting XML from Adobe InDesign & InCopy today.  However, it does require clients to put away the notion of the magic export button. 
2. The major limiting factor is the practical limits of standardization required of print production staffs (in conjunction with support by web or text processing production staffs).  However, this limit is continually being reduced through our ongoing innovation efforts.
3. These projects inherently require process change.  Where text is already being manually processed after files go to printer, this is not very hard to achieve.  It may be more difficult for clients to envision and implement changes where no post processing currently exists. 
4. Because Adobe doesn't inherently require file usage standardization in InDesign and InCopy, standardization must be built into the use of the tools themselves - meaning print staff are required to modify their use of the tools - though minimally in most cases.   
5. Projects may also require some semi-automated application of metadata and linking information prior to triggering an export.
6. The K4 XML-Exporter (an add-on to the K4 Publishing System) is a great tool for this process, primarily because it adds some workflow automation as well as automated access to a good XSL processor.
7. JavaScript is now a standard element in these projects, as it can powerfully minimize any necessary changes for the print staff.
8. Integration with Web CMSes, by the way, is an achievable reality. 

We're excited as we continually press forward - its a great time when there is innovation every day.