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.

Some projections for ebook revenue over the next 5 years are promising for publishers. In the Gilbane Group's "Blueprint for Book Publishing Transformation" respondents indicated that the majority of ebook revenue book publishers currently see is less than 5% of gross revenues. In contrast, expected revenue from ebook efforts in 5 years’ time runs high, with the majority of book publishers expecting 15% or higher of gross revenues to come from ebooks:

The big picture for book publishers is very positive. Revenues are growing. Readers are excited by the new devices and are demonstrating their excitement in fast-growing device and ebook sales.

Find out how the leading publishers are using content management to move ahead quickly across a broad front of process improvement and technology investment.

Download your free copy of "A Blueprint for Book Publishing Transformation" and stay ahead of the digital revolution. [click here]