Special UB column on how to survive a CMS implementation: 6 tips from Brian Phelps, Web Manager at the University of the Pacific

Last July, I conducted several email interviews to prepare my column on how to survive a Content Management System (CMS) implementation for the October 2006 issue of University Business: “10 Tips for Surviving a CMS Switch”

Brian Phelps, Web Manager at the University of the Pacific, shared 6 tips of his own at this time.

Get more buy-in than you think you need.
Use a variety of communication channels—online, in-person, campus-wide “town hall” meetings, email, blog, survey, teleconference, video conference—to get input into the decision making process. Document who contributes to the process by whatever means. As the project progresses, the weight of buy-in from a larger number of participants and contributors will bring along others who are less excited about the changes. It will also demonstrate to management that you’ve done your best to involve a diverse audience and will legitimatize the results down the road.

Get Senior Management buy-in.
Communicate upward, through your own management if necessary, about the project. Solicit management’s specific input. Get in front of the Council of Deans or similar organization at least twice during the project life and brief them on the benefits of the project to their respective organizations. Let them ask questions. Get in front of the President too and formally solicit his or her blessing.

Keep the project process and progress open and transparent.
Develop a communications plan. Figure out what methods will be used to reach targeted audiences at specific way points in the project lifecycle. Create a website/blog that documents project progress and archives all relevant documentation. Keep it fresh. When dates slip, which they will, openly communicate the reasons why. Don’t stop communicating in one form or another, because people will start to think there are problems.

Document the rationale for your project.
Research and document the reasons for undertaking the project. Publish the results online. Publish an assessment of your current site and its challenges. Never point fingers at individuals or specific organizational units. Articulate how the project fits overall university goals.

Relentlessly emphasize the benefits to end users.
Think critically about the impact the change will have on end users and figure out how to communicate the changes as a benefit. Identify product features that will benefit the end users. Develop talking points that you can recite as needed. Downplay the changes affecting existing work habits and methods. Always focus on the benefits to the entire organization.

At the beginning of every meeting about the project with end users, first ask, “What can I do to help?”
They are meeting with you because they have questions. Identify their issues and concerns before you meet. Put yourself in the position as someone who is there to help them accomplish their goals. Communicate how the pending changes will help them.