RSI began as a consulting company for publishers. In that role, we were often asked by our customers to document their as-is workflows and recommend new ones that would drive electronic product development and efficiency. We spent a lot of time creating massive diagrams. A lot of time. These projects were sometimes useful, and sometimes not. They were useful when we and our customer stopped analysis and documentation before the point of diminishing returns and turned our focus instead to implementing real change and on breaking down barriers to it. They were not useful when our customer was more focused on the perfection of the workflow documentation than on what they could learn from it. (Like, “Whoa, do we really need three different people to perform the same review cycle?” or “Does the author really need a print-perfect PDF proof?”)

As we transitioned to becoming a software solutions provider, workflow analysis was one of the more interesting and challenging areas because we had to actually make those new workflows work in the real world. The timing of this shift for us was accompanied by a shift in perspective by many publishers. Most of our business sponsors no longer have patience (or budget!) for extended analysis projects. They want change, and they are willing to take on some risk to make it happen. Fortunately, what our customers want and what we’ve found really works align nicely. 

Bottom line: Most teams come to us already knowing what they want to change about their business processes (at a high level), can list their most obvious inefficiencies, and have no way of knowing about the other ones that lurk until they move to an environment where they can measure them. Sometimes this is because another consultancy has helped them plan, but usually it’s because they are smart people and they know their own processes because they live with them every day. (Sometimes teams don’t know these things, but that points to management and staffing problems and that’s a post for another day…)

Because most of the teams we work with already know, roughly speaking, what they need and want to do, our job is to guide them towards a workflow implementation that reflects their big goals for change (usually being digitally-driven rather than print-driven), works for every day users, is flexible, and provides enough reporting to inform ongoing improvement. And to get it in their hands quickly. 

Even though we and our customers are smarter than we were ten years ago, there are still plenty of pitfalls in implementing workflow. This is especially true of a system that enables automation of content transformation, product delivery, and other common publishing tasks. Everyone is looking for the Easy Button.

Here are the best practices we follow when implementing RSuite workflow.

1. Keep it simple, keep it loose. Our customers today are mostly willing to forego months of analysis, but they often still want to reflect hundreds of discrete steps in their CMS workflow. Unless you have a legal compliancy concern, this is a waste of effort and will make your team nuts. System workflows with a small number of milestone steps give human beings flexibility in working out the daily details of their jobs and avoid the feeling of a police state. Few publishing processes really follow the documented 500 steps, and often that is for good reason. Don’t hem in your staff with a rigid implementation.
2. Automate, but avoid automation dependencies for your workflows. A business process often has several predictable points at which automation is needed (e.g., conversion of a manuscript from Word to XML, generation of author proofs, delivery). It’s tempting to want to plug those steps tightly into your workflow. In the past few years we’ve taken a different approach. We give users tools to run or rerun automations whenever they need to, but don’t have the workflow engine itself initiate the conversion, delivery, and so on. This simplifies (read, cheaper, shorter) workflow implementation and also gives the publisher the opportunity to change a workflow on a one-off basis or permanently with minimal or no configuration changes. 
3. Don’t forget reporting! During a project it’s easy to get caught up in workflow process implementation and not spend enough time creating truly useful reports. Which leads to…
4. Remember that change isn’t a switch you flip. Rolling out your new CMS and workflows is the beginning of change, not the end. Expect that over time you will want to adjust not only the offline details of how you’re working, but also the workflow itself. Create a habit of reviewing reports and looking for bottlenecks and points of frustrations. Make sure you have a staffing plan that enables you to make small changes quickly. This best practice also means you have permission NOT to rationalize all your business processes on day one of CMS launch. Management often has the goal of getting rid of all the unnecessary inconsistencies among teams, and this is a worthy goal. But sometimes it makes sense to step into that level of change incrementally.

We’ve found that following these guidelines results in a system that enables immediate change but with the option for more change when you need it. Not following them can lead to user revolt and management disappointment. 

What do you think? What has and hasn’t worked for you when implementing business process changes?

 

 

The 5th Annual RSuite User Conference welcomed more than 150 publishing executives on Tuesday, October 25th in Philadelphia at the Chemical Heritage Foundation Conference Center. There were 41 distinct publishing organizations in the house as well as a handful of companies who service publishers.  The overwhelming consensus among presenters and keynote speakers was that content management should be used strategically in an organization to gain success in the digital publishing world.

We'll highlight other key takeaways over the next few days here. In the meantime, you can revisit the confernence via the Twitter hashtag #RSUC11.

Of course, if you're ready to learn how strategic content management will help you accelerate revenue and navigate the digital publishing environment...just click the button below!

At Really Strategies we are fortunate to work with a variety of publishers: journal, book, scholarly, trade, technical. Obviously each publisher has a different approach for navigating the digital publishing landscape.

What we often see are publishers who are creating loads of wonderful digital content yet their digital supply chains are heavily tied to the print medium. According to the American Association of Publishers,

“e-books have grown from 0.6% of the total Trade market share in 2008 to 6.4% in 2010. While that represents a small amount in the total market for formats, it translates to 1274.1% in publisher net sales revenue year-over-year with total net revenue for 2010 at $878 Million.”

This means content supply chains need to change in order to properly prepare for a digitally focused content marketplace. Download our latest whitepaper to understand best practices for a long-term digital publishing strategy.

Situation:  Publishers want a content management system to be flexible and adaptable at a low cost.

Reality:  Unlike desktop applications, enterprise content management systems change and sometimes pretty often.  Publishers are often surprised by the amount of changes a CMS requires after the initial implementation.  That is because a CMS changes to meet the way your organization wants to work, not force you down a path such as Microsoft Word.  Yes, Word can be customized, but a CMS can truly evolve as your organization evolves its processes and workflow.  In the pure definition of a system, it is one that never stops changing.  You can read between the lines here and either ignore the fact that a CMS will require a budget to make changes as your organization changes or you can budget the appropriate time and money to keep the system current and reflect user needs.  Systems don’t change by themselves and the flexibility you get with a CMS comes at a cost.  If you want a system that is inexpensive and inflexible, that is fine, but be ready for unhappy users.

Best Practice:  In our experience publishers who budgeted between 25% and 50% of the original project implementation costs for changes after the initial launch were able to respond to user change requests in a timely manner.   

Every publisher manages projects and budgets differently.  As a CMS vendor we understand that.  It is imperative for publishers to understand though that a system will require changes after it goes live and this is perfectly natural as a system is used by the staff.  Those publishers who budget for and plan out a period of time after CMS launch to complete user change requests will ultimately have higher user adoption across the organization.  Higher user adoption equals higher organizational efficiency. 

What are your experiences with system changes post-launch?

I've been working in content management for more than ten years, and thinking back over that time I realized that the dream of a true, standards-based, central repository for all of an organization's assets I naïvely espoused in the late 90s still hasn't become a reality except in the most narrow of applications. When I used to write and teach XML classes I was sure that open markup standards were going to revolutionize the way we created and managed assets. Around 2003 I started to become a bit disillusioned with my vision for content utopia. By 2008 I had all but thrown in the towel. Despite herculean efforts content kept worming its way into proprietary, tactical-level production systems and often was never seen nor heard from again, a victim of legacy of "fire and forget" publishing approaches common prior to the rise of the Internet.

Fortunately, just as I had resigned myself to living in a world of content silos, new strategic ways of managing content started to emerge that rekindled my ideals. The idea is more modest than my grandiose vision of pure standards I once embraced, but offers a new, more practical approach that can survive in the real world.

Rather than insist that every asset be centralized in a consistent, preferably open, format practicality may dictate that we instead work to build a centralized asset repository that shares common representations for all assets. The actual bits and bytes making up the asset (Word documents, InDesign files, photos, videos, etc.) can still be developed and stored in traditional systems where applicable, but a new system takes on the responsibility of cataloging relevant features and details about the asset in a centralized repository. So instead of insisting that every asset be physically managed in a central repository, we instead insist on the much more modest - and realistic - demand that all assets make relevant, common data and metadata available in a consistent format through a centralized system. This distinction means that rather than try to replace the tactical systems we use to create, manage or distribute content we instead develop a parallel, complementary content management strategy that reflects data in these systems and presents a common, consistent view of the asset regardless of type. 

So an image file may exist as a TIFF or PSD formatted file in a production system or on some hard drive somewhere, but the centralized repository maintains a record for this image with all of its relevant metadata and a standard image format readily accessible to any system (i.e. PNG, JPG in thumbnail and applicable preview formats). For a lot of applications, centralized lighter-weight representations of content is enough to create new products without returning to . For example, if I want to rapidly re-use images or stories on a new microsite, I don't have to resort to tracking down all of the content in its silos, but instead rely on these common representations to collect the assets together and send them into my Web CMS for the new microsite. Formats, conversions, and so forth can either be provided to the central system through traditional manual conversion or, preferably, through automated mechanisms built in to existing content workflows.

This sort of approach was attempted using search technologies at one time, but lacked an important ability to offer the depth of content management required to not just find the asset but also to be able to use and transform it. It gave us the ability to view the content but not any tools to do anything once we saw it. Search remains important, but a real central repository needs to actually have usable representations of content that can be managed, transformed and distributed as assets on their own. This requires a full content management system.

So my new vision of a centralized asset repository is not the end-all be-all "do everything" system that becomes impossible to design and build, it's a "do-some-things" central system that maintains some consistent, common format that can be readily transformed and transmitted and becomes an organization's strategic content reserve. It can answer questions like "what assets do we have about Egypt?" quickly, and serve as a baseline for those assets so that after finding them they can be used in our various tactical systems.

To build such a thing, consistent representations are needed. When looking for data standards we of course start with XML. When only a binary will do, ensuring that pointers are accurately maintained to the original assets and appropriate renditions of the binaries are created for things like the user interface of the central repository is an obviously useful model. Even if re-work is required the assets are already under active management. 

The RSuite Content Management System happens to be a great foundation for building shared, managed centralize repositories of content. The system is flexible, built on an XML standard database with a metadata model that can not only leverage existing metadata but also be extended in arbitrary ways to adapt to evolving requirements. It is built on open standards and is a good corporate citizen, ready to interoperate with existing systems. The native XML database and pointer management features ensure that consistent representations are available. This approach creates a solid foundation for a strategic, centralized asset repository. 

Part of my role as Product Manager for Really Strategies will be to focus on the ways that our existing clients have adopted XML-based content management. I'll be reporting in with our client success stories at building these content repositories here on the blog. 

Does your organization have a vision for managing content strategically? It’d be great hearing how others are working to address this challenge.

All of us have been involved at one point or another in our careers with that “death project” that just seems to lack any real conclusion and no one seems to know how or why it is in the state of limbo.  Vendors who serve the publishing industry have many reasons why a project is in jeopardy or has failed altogether including lack of proper resources, no project management discipline,  etc.   From a vendor’s perspective there are some telltale signs that were evident from the very beginning of the project but everyone overlooked them in the excitement of project kickoff.  Following are my top 5 reasons (from a vendor perspective) on why CMS projects fail at publishers:

1. Solution/Technology was not the right fit – Almost no one will admit to selecting the wrong solution or technology.  We all know that buying technology is sometimes a mystery.  Some vendors are really good at selling a vision only to have the publisher realize in the middle of the project that reaching that vision is going to cost three times more than they budgeted.  In other cases publishers already have a preferred technology or product and force that product on all groups.  On more than one occasion we were told point blank by a larger publisher that we love your RSuite technology but corporate is forcing us to use Documentum because we bought a site license.  Economically that makes sense. But functionally this may be trying to shoehorn a technology that was built to manage documents into a publishing environment that requires content management.  Different requirements, different solution required.  It is that simple.  It is no surpise when we hear back from the publisher 9 months later that the project failed or the system is not being used because the system does not meet expectations.
2. Buying a vision that is unattainable – Publishers get excited by vendor demos.  And they should!  What they are seeing in a demo is something they generally don’t have in place.  Some vendors are outstanding at selling a vision by demonstrating slick end-user applications.  The problem with this is that a publisher needs to ask the question “how much is it going to cost me to reach that vision?”  Seeing a technology vendor show really cool functionality does not mean there is a good business or production model behind it.  It is good to see demonstrations that push the envelope, but understand what it will take to implement such a vision (time, money, and business model changes).  I have seen several publishers purchase certain technology to build really cool end user applications only to have the technology sitting around because the vision was not attainable to begin with because it just cost way more than they could ever budget.  Investing in a vision is fine, just be able to break that vision down into logical, cost-effective projects.  Be realistic about what you would like to accomplish and what you can actually accomplish.
3. Poor project budgeting – Along with vague requirements goes poor budgeting.  If you went to a home builder and said "I want a two story house built, give me a quote." How much confidence would you have in the quote you would receive back when the requirements for the house were so vague?  Well, from a vendor’s perspective, we get this level of vague requirements for a CMS on a regular basis and are expected to provide a budget to implement the software.  It is generally couched with “we are only looking for a ballpark.”  OK, great, but if you are looking for a ballpark price that you would have a low level of confidence in, why are you putting that ballpark price into your next fiscal years’ budget?  Immediately you are putting the project at risk.  Again, vague requirements will lead to ballpark estimates that can be misconstrued in budgets. There can be pressure on the vendor to implement a solution based on an unrealistic budget.  Because the system does not operate according to some vague vision there is a real risk of project failure and unhappy customers.  See the chain of events?
4. Inherent conflict between IT and editorial  – My colleague, Lisa Bos, wrote several years back in one of our website newsletters that software development and editorial processes are in direct conflict with one another.  Think about it.  Software developers are used to an environment where they work up to the very last minute making changes on the fly and moving the system to production with an acceptable level of bugs.  The software is never 100%, but it is operational.  On the other hand, the editorial team has a defined process to complete edits on a deadline with the goal of 100% accuracy.  This inherent conflict between these operational approaches comes out during a CMS project implementation.  Understanding the cultural differences between the two organizations is important.
5. No definition of CMS project success – Why do publishers implement CMSs?  There are many reasons of course, but how often are the goals of the CMS project discussed: during the budget cycle, RFP stage, kickoff only, never?  If you hold a CMS project kickoff meeting and ask the group the definition of success when the system is operational and no one in the room knows the answer, you have a problem.  How can a CMS project be successful if the project team does not know the measurement of success?  Installing a CMS is not a success criteria.  Managing XML better is not a measurable goal.   Re-using X% of content in new derivative products, or reducing time-to-market by X days are real, measurable success criteria.  One exercise I like to do at the project kickoff meeting is to make the team draft a press release announcing the completion of the project.  After the team gets over the silliness of the initial request, most teams have fun with the exercise and actually contribute to the writing of the press release.  This simple exercise allows the team to verbally communicate among peers what their interpretation of success is for the project.  If you cannot articulate the definition of project success for the CMS project from the outset, you may be in trouble of ever meeting expectations of management.  Know the success criteria, communicate the success criteria, and celebrate the success with your team.

A  CMS project in most cases comprises a cross-departmental team with a varied set of personalities assigned to get the project done.  Over the past decade I've noticed some trends in the type of people who make up these teams and five specific types have come to the surface.  I thought I would have some fun and describe these team member personalities and how they interact with other team members.

Disclaimer:  The following is a characterization and does not reflect anyone in particular at any of our clients.  Any resemblance to a specific RSuite or DocZone client is purely coincidental.

In my experience the 5 people you will meet [in CMS Project] heaven include:

The Actor/Actress – For this person, everything is an issue above and beyond the comprehension of everyone in the room.  This person cannot believe the group just doesn’t "see it" and he/she will have to elevate the issue to higher authorities in order to provide yet another brilliant solution that the executive team can implement.  In general every meeting entails at least one outburst just to make sure committee members know he/she is present.

The Authority – A "seasoned professional" who has been with the company for as long as anyone can remember – probably since said publisher created content with chisel and tablet. This type provides a level-headed look at things and can recite quotes from executives who have passed through the hallowed hallways explaining why this is the exact strategy the publisher should take only to see that executive depart publisher for “other opportunities.”

The Thinker (#1) – Generally a meek and mild person sitting at the table who knows her/his stuff inside and out but does not like to be the center of attention.  Would rather be sitting in the row of chairs in the back of the conference room than sitting at the table.   Unfortunately (in their eyes) their boss made them sit at the table.

The Thinker (#2) – In general, this person thinks everyone on the project team or committee is stupid and if you would just leave them alone they would have a new system built in about a week (if an appropriate level of pizza and soda were supplied).

The Leader – This person can lead the construction of a sky scraper or CMS project, it just doesn’t matter.  They are obsessive about details, impatient, and can synthesize more information in 30 seconds than your iPad can download in an hour.  The leader is vocal but polite and can generally marginalize the Actor/Actress on the team.  He/She has the ability to manage up to executives and down to line employees.  In general this person may not always be embraced across the organization because they tend to get too much done and make other people look bad.

Each department at a publisher has its own culture and each person from these departments has their own unique personality.  Your success or failure as a CMS Project Team Leader will be dependent on how well you identify each personality type and know what makes them tick to best leverage their strengths and marginalize their weaknesses.

I often run across articles in various trade publications that provide best practices for evaluating technology and managing projects.  While I think these article are a great starting point for a company, I think they overlook the vendor side of running a project.  In other words, if you look at both the publisher's and the vendor's perspective, you're more likely to achieve a successful implementation, which is the mutual goal. 

So with that background, here are my top five best practices to implement a CMS at a publisher (from a vendor's perspective):

1. Assign one project champion to manage the CMS vendor (not a committee or group) – Content management projects touch many departments.  At publishers, this means that IT, Production, and Editorial will have a say in the project.  Publishers should assign a single project champion (not a group or committee) who has a solid understanding of the business, can manage through the political atmosphere, and is able to make decisions (technical, time, and budget) in a timely fashion.  As a vendor, it is best to have one person in charge who will be that single point of contact.
2. Whatever you budget for your CMS project, multiply it by 2 – The old saying “your eyes are bigger than your belly” rings true when publishers budget for a CMS project.  Content management is complex.  Systems are not plug and play, especially the enterprise scale systems.  Generally the CMS project is an excuse to throw everything anybody has ever wanted into the requirements specification.  Prioritize, delete, reorder, do whatever you have to do to get within your budget, but make sure you budget enough money and don’t try to beat-up the CMS vendor because your budget was too small to begin with.
3. Budget enough money for after the CMS launch – Too many times we have worked with publishers who do not think past the initial launch of the CMS.  When users begin to use the system, there will be changes.  Generally some requirements get deferred after launch because of complexity or budget reasons. Be prepared to have additional funds set aside after you accept the system and users begin to use it.  My rule of thumb has always been to budget between 25% - 50% of the original project for the follow-on phases.
4. Be organized and respect everyone's time – There is nothing worse, from a vendor's perspective, than kicking off a project and realizing the customer is disorganized and cannot fulfill their obligations in a timely manner.  When a vendor allocates resources to a project and has the green light from the publisher, the vendor is ready to start!  That means the publisher needs to be prepared to start as well.  If a publisher is disorganized, it eventually leads to poor requirements, timelines that extend, and cost impacts.  It will impact the time and energy of all parties, including the publisher's editorial and production staff. Don’t start a project unless you have your ducks lined up and are really ready to begin.
5. Tell the rest of the organization there is a CMS project – The acronym CMS in some publishing organizations is a bad, bad word.  In all honesty, we have been at some publishers where we were forbidden from using the acronym all together.  We had to disguise the CMS project as a “new production system” or “finished goods repository.”  We don’t care if you come up with a clever code name for the CMS project, but having a good internal communications plan will make the vendor's job much easier when we need to interact with other groups and derive appropriate requirements.  It is not good as a vendor to start a meeting with a publisher and get “what CMS project?” as a reply to a request for information.

I’m pretty sure you will not see this list of best practices for running a CMS project for publishers in a trade publication, but I thought I would share some of the best practices we would like to see publishers embrace to make projects run more smoothly.