Last week's O'Reilly Tools of Change (TOC) event in New York had a theme of Change/Forward/Fast.  Based on the keynote presentations, I think the publishing industry heard loud and clear that they need to change....and now!  However, the other underlying theme for the conference was also articulated by the hosts as "we are confused."  Needless to say, these two themes are in conflict with one another.  How can you change if you are confused?  Confusion generally leads to paralysis and that is what I have seen with publishers over the past few years. 

While publishers heard success stories about building audiences before publishing a title and on-going interactions with that audience, what was suspiciously absent was how publishers are delivering content to the various devices.  Maybe it was the wrong venue, but I suspect many of the success stories started once content was in a sellable format rather than how easily the content was created and published in their content management system.

I also suspect that many in the audience were from the business side of publishing and the TOC event makes them pause and think about their business.  TOC did not, for me anyway, tackle the more difficult challanges of multi-channel publishing using home grown or antiquated technology.  Sadly, that is what many publishers are wrestling with today.  Once they are able to get content in ebook format, they can do really cool stuff with it.  Until publishers address the content management side of the equation, I don't see how they will efficiently meet time-to-market demands.  The reality is that most ebooks today are created by publishing services vendors because they are converting various flavors of legacy files.  Most publishers today are not multi-channel publishing but sticking with the print paradigm and then, through various publishing services vendors, creating ebooks for distribution.  Publishers who are stuck with this publishing process need to "change/forward/fast."

I will say that overall the TOC conference appears to be rejuvinated.  Two years ago the conference seemed to have run its course, but I believe it is back to being an event that publishers will want to attend to learn how the newbies are doing it without the "burden" of print.  Pushing the envelope is what TOC is best at and I hope they continue to push the industry's thinking along the way.

As publishers transition workflows, tools, and organizational structure to reshape revenue streams so digital revenue exceeds print, I’ve identified the four phases of digital publishing transformation. The  following image captures the phases and the intersection of print and digital revenues.  The four phases comprise---planning, realization, survival, and new world.  As a publisher moves through these phases there are specific events within each phase that cause the publisher to either remain stagnant or move forward to the next phase.

Planning phase. This is a low stress phase where a publisher is just starting to experience a low erosion of print revenue and is experimenting with digital products.  There is a general feeling that something is coming and resources are allotted to begin a digital strategy plan.   Publishers must plan for the move from a tactical content management system to a strategic content management platform  that  can create, package, and distribute content in a highly automated fashion.

Realization phase. A publisher in this phase is beginning to see print revenue decline pretty quickly while electronic product experiments start to gain momentum and generate revenue.  There is a crisis underway in this phase and cultural issues start to emerge across product and editorial teams.  It is in this phase that publishers should look to invest strategically in technology because time-to-market pressure in a multi-channel scenario will be the priority over just the print channel.  In this phase a publisher must look at people, process, and technology to meet the necessary demands of the new publishing environments.  Those who are slow to adopt or embrace change are unlikely to survive.

Survival phase. If the publisher has adequately planned for the transition to a dominant digital revenue stream, this phase will not be as onerous.  If there is an extended realization phase, the survival phase may be short because the publisher just won’t make the transition.  It is during the survival phase when digital revenue numbers get exciting and begin to challenge print revenue. Publishers who enter the survival phase and begin to produce more digital products will move onto the next phase.  These publishers have taken a strategic view of content management.

New world phase. What publishers must embrace in the new world phase is a solid strategic content management platform, production processes that minimize manual intervention and emphasize automation, and a culture of continual improvement.  No longer can departments operate in a vacuum, systems be built on home grown technology, or processes remain stagnant.  The new world phase embraces change and rapid publishing to new channels and devices.  The reward in this phase is the successful transition of print and digital revenue streams. Publishers will see digital sales eclipse print sales and in some exciting cases, digital products can be used to drive print sales. It is in this phase when publishers and product managers can experiment with audiences to understand how the customer is engaged and tweak the delivery of content to customers any time, on any format, on any device.

While certain segments of the publishing industry have moved through this digital publishing transformation, many are still in the planning phases.  Tools that support digital publishing have evolved immensely over the past decade. In fact people and processes tend to take more time to transition to the new speed of digital publishing than the implementation of content management tools.  We developed RSuite, a content management system for publishers, to serve as the core foundation of a digital publishing strategy. Some of the world’s leading publishers and media companies use RSuite---Oxford University Press, Nature Publishing Group, Triumph Learning, Audible, and many more. 

Want to see how RSuite can transform your digital publishing process?

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 ran across an interesting blog post by Stephen Arnold who is a longtime industry analyst and consultant that spells out the hidden costs of a SharePoint implementation.  The post is here.  While free always looks better than paying for software, I think Stephen hits the spot with his assessment.  A free software framework such as SharePoint is great if you plan to keep requirements very simplistic.  As we all know from our own experiences with implementing content management, that is easier said than done.  If you have more complex requirements, maybe a packaged solution such as RSuite makes sense.  Your company's approach to projects, culture to build versus buy, and several other factors need to be considered before selecting a technology and embarking on a content management project.  Whatever approach you take, just be cognizant of hidden costs as Arnold pointed out.  Free software does not always mean it will be cheap to implement and maintain in the long run.

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.

"Push-Button Publishing System” for Print, Web, and eBook Production in 70 Languages

We are pleased to announce the availability of RSuite Cloud - a complete end-to-end hosted editorial and production system for book publishers.  If you are looking to shorten your book production time to market, want to publish to multiple channels (print, HTML, eBook) at once, and publish in 70 different languages, I suggest you take a look for yourself.  Online demo here.

Here is what one of our clients said about RSuite Cloud:

“We saw the time to produce PDF proofs drop from a week to just a few minutes. This improvement in productivity allowed us to dramatically shorten our production cycle and even recognize revenue in 2010 for a book that was originally scheduled for 2011," stated Stephen Driver, vice president of production services, Rowman & Littlefield Publishing Group. “We are excited about our ability to scale with this solution and the new scheduling flexibility that we could never have dreamed of in our old environment."

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.