Getting Your Organization to Embrace Content Management
In June 2002, I walked into my manager’s office; he had just seen a demonstration on a content management system (CMS) and was excited about the potential for our organization. I took the fateful step of asking questions, only to realize that I had just volunteered for a major undertaking.
For the next two years, I managed an organization-wide effort to evaluate and design a CMS. We employed a consultant (Comtech Services, Inc.) to help us in the process, used cross-discipline design teams, provided educational opportunities, worked closely with staff, management, and our Board of Trustees (BOT), and eventually purchased a Stellent CMS. An important outcome of our effort was an organizational culture that embraces CMS at all levels. This article describes how we got there.
The Awwa Research Foundation is a non-profit organization that manages research for the water supply community. With a staff of nearly 45, we manage information from over 800 research projects with approximately 350 of those projects active at any given time. Research is conducted by experts throughout the world, and a peer-review process is used to ensure scientific integrity. Therefore, over 1,000 people may be contributing or reviewing content at one time. Results of these studies are shared with our 1,000 member water utilities and other stakeholders. The Foundation is a broker of knowledge between the research community and water utilities and manages a large amount of content for an organization of our size.
Decisions about program direction and major purchases are approved through the Foundation’s BOT. Organizational changes are often initiated at the staff level with staff preparing recommendations for BOT approval. The BOT meets twice a year with decisions about major purchases occurring only at its January meeting.
Following the initial excitement about content management, we needed more information. The first thing we did was talk with our sister organization, the American Water Works Association, which had already implemented a CMS. We learned that they spent significantly more for their system than we expected. Thinking this was the end of CMS, I brought this information to my manager who, while dismayed at the cost, held firm to the idea that a CMS was needed by our organization.
Fortunately, an author of a recent book on CMS worked right down the street from our office. After getting an appointment, we brought a small team to her offices to hear more. While we expected a long discussion about the technology, what we heard was the need to analyze business requirements and instill an organizational commitment.
The Business Case
Our first major activity was to hire a consultant, Comtech Services, Inc., to analyze our business needs and answer the question, “Do we need a CMS and how can it help our organization?” To provide guidance for the project, we formed a leadership team that consisted of our senior managers and representatives from our various organizational units. We also formed an ad-hoc committee from our BOT to oversee the process.
A key component of the business case was the information audit. The consultants came into our office and met with key members of our staff. They evaluated how information was used and managed in our organization. Four major needs/issues were identified.
- Improved search capabilities/difficulty in finding information—The ability to find information was directly related to knowing the right person. Searching capabilities on the current computer network were limited.
- Workflow/multiple reviews—Documents often undergo multiple reviews, and there was no way to track where a document was in the review process.
- Version control/multiple versions—Multiple versions of the same document often existed, and it was difficult to know which was the most recent version.
- Reuse content/don’t reinvent the wheel—Content is often reused in many documents and for the web.
The business case clearly identified that a CMS could help us respond to these needs. The business case also identified goals for our system, implementation issues, and cost estimates. With this information in hand, we were ready to request approval to purchase a system.
A Close Call
In November 2003, we prepared a recommendation for our BOT for purchase of a CMS. Quite unexpectedly, we got word that there were budget problems and new initiatives were to be scaled back. The CMS was headed for the chopping block. Not wanting to lose momentum for another year, we began looking for alternatives. We finally decided to use the next year to build our information model and identify system requirements. These items would be needed anyway, require only a minimal budget, help us make a better purchasing decision, and allow us to keep momentum going for the CMS.
In hindsight, this additional time was key to our success. It gave us the chance to develop staff buy-in prior to the pressure of getting a new system up and running.
The Information Model and Gaining Approval
To develop the information model, we appointed a number of cross-functional teams to work on different aspects of the model. Items developed included use cases, file hierarchy, organizational taxonomy, scientific keywords, and workflow examples. This information was used to develop a detailed requirements document, develop cost estimates, and evaluate potential vendors. To build the organizational culture, we also offered a number of educational opportunities to all staff, including presentations by vendors, staff, and our consultants.
We found a number of “quick wins” that could be implemented immediately without new technology. We also developed a better understanding of our process and, most importantly, staff began to take ownership of the CMS. I knew we were on the right track when staff began providing unsolicited comments about how processes would be easier once we got the CMS.
Managers became strong advocates through serving on the leadership team and had a good understanding of the cost and benefits. We kept our BOT informed and I was surprised when the chairman promised benefits from CMS to our subscribers prior to our submitting a proposal to them. When the proposal was finally sent to our BOT in January 2005, we received their unanimous consent to move forward.
It took just over two years from the inception of the idea to the actual purchase of our Stellent CMS. This time was necessary to build both “top down” as well as “bottom-up” support for the CMS. We also learned a number of valuable lessons that are summarized below.
Lesson 1—Changing technology is easy compared to changing people and processes. In looking at technology solutions, we found that basically anything we needed could be done for a cost. Vendors were very forthcoming in helping us evaluate the cost benefit of potential solutions. We spent a lot of effort defining and modifying processes. Since we had a goal of avoiding customization, we needed to look carefully at how our processes could be accomplished using “out of the box” solutions.
Lesson 2—Changing culture takes time, a lot of it. Over the two years we spent developing the CMS, our organization shifted from resistance against the technology to frustration that it wasn’t currently available. Keys in our cultural change included:
- Education at every opportunity through formal presentations and demonstrations, as well as informal “water cooler” discussions
- Ownership of the system through involvement in the development teams
- Champions keep the ideas alive. While it was my job to keep us moving forward, a variety of other champions emerged. Each was essential to the success of our project.
- The CMS was tied to our organizational mission and our goal to exceed customer expectations
Lesson 3—Entropy and the vision. The vision of the project shifted over time as we learned more. We also found that there were numerous individual interpretations of the vision. To combat the differences, we needed continually to repeat the vision, revise when necessary, and then communicate to staff.
Lesson 4—Keep your eye on the target. Every time we learned of a new technology function or possible solution, folks got excited. I called it the technology expectations creep. If you’re not careful, solutions to small problems can divert effort away from solving the main business needs. It’s very important to always bring discussions back to the major business drivers.
Lesson 5—The voice from outside lends credibility. An outside voice is essential in instigating change within an organization. An outside observer offers an impartial, credible view that often meets with lower resistance. We’ve successfully used consultants, surveys of our customers, and benchmarking with other organizations to initiate change within our organization.
Lesson 6—There are never enough champions. Throughout our processes, a number of champions emerged. While I was the target, having someone else carry the message was a welcome relief and carried a lot of weight. Champions emerged among management, our board, our customers, and frontline staff. We conducted a stakeholders analysis to identify key individuals to involve.
Lesson 7—Design first, software second. You can better ensure that the product you’re purchasing meets your needs by designing your software first. Designing first has the added benefit of having individuals acquire ownership of the system before it is thrust on them. The one disadvantage is designing an unknown, so there’s some frustration from not knowing exactly how things will work.
Lesson 8—Address common misconceptions. A large number of misconceptions emerged that could have derailed our efforts. It was important to address these as soon as possible. Staff often needed an outside voice before folks could move on.
Lesson 9—Start small and be successful. We found that it was important to break the implementation down into small well-defined tasks. Our most successful teams were those that accomplished their task in a short time period. The longer the team went on, the more drift from the original task was noted. Nothing changes the culture more than success.
Lesson 10—There is a need for policy decisions along the way. We found it important to distinguish between design tasks and policy issues. We had the leadership team address all policy decisions. Addressing policy issues and providing guidance helped teams to move forward.
As We Move Forward
With all the effort up front, we now need to rapidly show benefits. Management, staff, and our BOT have many expectations about how the system will work and the potential benefits. As we begin implementation, it will be important to communicate the status of our project and our progress in meeting these expectations.