Finding a Content Management System Solution – Part 2

Last week in part 1, I talked about selecting a content management system (CMS) (which has many names like records management or knowledge management) from a technical perspective. However, just as with any productivity-enhancing tool, the process does not end with getting the tool. Rather, the process begins by understanding the value of content management to the organization and ends with training, acceptance and implementation. If your organization truly wants to benefit from content management, there must be changes in “business-as-usual”.

Your organization will need to have all of the stakeholders participate in any project to implement a CMS so you should be prepared to involve business units, legal, finance, contracts, marketing, operations, human resources, PMO and any other groups who have a stake in the information flow of your organization.  You will also need a plan for the implementation project so that you can achieve outcomes that are beneficial to the organization.  To quote Lewis Carroll, “If you do not know where you are going, any road will get you there.”

In 2006, Dr. Karen McGraw, CEO of Cognitive Technologies, suggested 10 questions decision makers should answer before committing resources to content management system solutions (Dr. McGraw’s complete white paper):

  1. What content do we need to manage better or use more effectively?
  2. What types of content management initiatives are we involved with already?
  3. Where is the greatest impact for content management efforts?
  4. Where are the best opportunities to achieve business value and ROI?
  5. Where are we in terms of content management maturity?
  6. What kind of technical infrastructure is required to support content management?
  7. Are we prepared to implement and manage the cultural changes that may be required for content management to be successful?
  8. What are the characteristics and competencies our employees will need to succeed with content management?
  9. Does our content management initiative support our strategic business objectives?
  10. Am I providing the required leadership and support to ensure the success of content management initiatives in my organization?

Dr. McGraw emphasizes the point that implementing a content management system should not be undertaken lightly or perfunctorily if benefits are to be achieved. In my experience, the key to success is user acceptance. If staff members see value — or potential value — in content management, they will expend the time and effort required. If users do not anticipate gaining any direct benefit, they may perform only the minimal tasks needed to comply with the process. Worse, they may sabotage the system through inattention to detail, refusing to use the system or discouraging others.

Getting User Buy-in
The value of implementing a content management system may not be intuitively obvious to all employees when considered in light of their current job tasks. In addition, seasoned veterans of other management initiatives may sigh with foreknowledge that they will have to do something more and different. Therefore, it is up to management to sell a vision of the content management systems benefits to the organization and to individual workers.

Here are seven tips that will stimulate employee buy-in:

  1. Get a representative group of users to participate in setting up the CMS — identifying the source documents and agreeing on the tags and taxonomy — classification scheme — that they would find helpful when searching for information
  2. When rolling out the CMS initiative, use stories and examples of time saving and quality improvements that tie directly to the work being done by individuals in the audience
  3. Offer incentives for early adoption
  4. Ensure that managers and leaders serve as role models in using the CMS
  5. Provide training
  6. Make sure the tools provided by the CMS offer easy-to-use mechanisms for the employees to add and describe content
  7. Plan and implement a process to keep content updated and well organized (read that as tools, responsibilities and information). Nothing turns off users like outdated materials or hard to get to information.

Managing Change
Implementing a content management system across the board yields many benefits to the organization in capturing and accessing knowledge. However, a CMS based system requires changes in business-as-usual. Your organization can learn from other successful change management strategies to successfully transition to effectively using your new CMS.

In the past I have talked about change management and you will find some helpful hints and practices here: Role of Project Managers in Change Management, Project Management PMBOK – Monitoring and Change Control, and Planning Your Organizational Change. Best practice suggestions for change management include:

  • Have a plan
  • Involve key stakeholders and keep them informed
  • Use small projects or departments to test the CMS and polish any rough points before rolling it out over the entire organization
  • Expect resistance — because some people just fight change of any kind. Understand the source of their concerns and address them:
    • The known is comfortable
    • Change requires thought; many current work behaviors have become automatic and require no conscious effort
    • Some people resist change in principle
    • Change is scary—you don’t know what you will win or lose
    • You may fail in the new world order
  • Develop outcome measures to evaluate the CMS
  • Seek assistance from change management experts either in your own HR department or ask for outside training or coaching
  • Offer training
  • Reward effort

If you and your organization have implemented a CMS, please share your experiences and suggestions to facilitate success.

Next, in part 3 of this discussion, I will address one of the most important aspects of a content management system – what do you do after the implementation to maintain the effectiveness and use of the CMS?

The Importance of Project Planning – PMBOK Chapter 3

OK, it has been a while since I talked about the PMBOK and I wanted to continue a series of posts on PMI PMBOK areas (started with “What is the PMBOK all about”.  This week we look at one of the critical areas that many PMs shortchange in managing projects – planning

“No battle plan survives contact with the enemy” is a bit of wisdom about the world alternately attributed to Helmuth von Moltke the Elder, Erwin Rommel, Carl von Clausewitz, Colin Powell and Murphy’s Laws of War. Yet, military leaders continue to develop plans for every imaginable contingency. If plans are destined to fail in the real world, why should we as project managers bother with planning?

Plans rarely fail entirely. Rather, details of a plan require changes as factors outside the control of the PM require responses that deviate from the original plan. However, a project plan provides a roadmap of key destinations (milestones) and a timeline to reach those locations, even when detours become necessary.

Of course, the PMBOK addresses project planning in detail beginning in Section 3.4. It suggests that a project plan encompass:

  • Scope
  • Activities
  • Resources
  • Schedule
  • Quality assurance
  • Risk analysis

In the discussion, PMBOK acknowledges that, “as more information is gathered and understood – which is their way of saying contact with the enemy — additional planning may be required.”

Types of Plans
Creating a project plan is not a trivial exercise. The project manager needs to spend time gathering requirements from a variety of stakeholders and working closely with key technical staff to identify strategies and risks. For large or complex projects, creating even the initial plan may take several weeks. However, not all projects are “created equal” and some may not justify this amount of effort. Sometimes a project plan can be created on the back of an envelope (and, of course, captured in more detail during documentation – MS Excel is probably the most popular way many of you do this.)

  • Exploratory Plans: these often begin with a conversation and some, “what ifs.” A creative developer has an idea for a potentially useful software tool or an alternate approach to solving a vexing problem. What makes these thought exercises a project that requires planning is the need for resources. It is one thing to have an idea. However to try it out and test its utility, someone has to approve the objective and the allocation of hardware and human resources. Even exploratory projects need a statement of the problem, a sequence of steps, a schedule and a method to evaluate outcomes.
  • Agile Development Plans: I discussed Agile Development methodology in “Project Management and the Agility Factor” as a style of project development that focuses on short iterations of feature development. Kent McDonald, writing for ProjectConnections, suggests that a Project Plan for Agile Development would only cover a period of two to four weeks. “During those iterations, all of the necessary work to take features from an idea to a working product is completed …” Each iteration begins with a feature-based plan that includes detailed tasks, schedule and deliverables.
  • Traditional Waterfall Plans: When waterfall development method is used on a project, the project management plan covers the life cycle of the project in discrete steps beginning with requirements analysis followed by design, implementation, test and maintenance. Because plans developed for waterfall method projects may cover months or even years of activity, these plans are more likely to require re-planning driven by external events.

Characteristics of a Good Project Management Plan
Here are a few tips to help you make a better project plan:

  • Cover all the bases listed in PMBOK
  • Clearly defines the scope of the project
  • Show dependencies between tasks as part of risk management
  • Comprehend resource loading and realistic levels of effort
  • Reflect awareness of project risks and allow time to understand and mitigate them
  • Accompany the plan with a communication plan that explains goals, tasks, schedule and performance information with key stakeholders
  • Include qualitative measurement of deliverables tied to project requirements (Focused on outcomes and not just widgets)
  • Help developers, team leaders and users understand the project and their role in its success
  • Make sure the plan is sized appropriate to the scope and size of the project (“Not too big, not too small but just right”)
The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management


Pushing the Edges Out ...


Just another site