I don't think anyone would argue with the proposition that implementing a content management system, or even an intranet re-launch, needs to be managed as a project. Some businesses have well-established project management methodologies, such as consultants and engineering firms. However, in many other organizations, the concept of what it takes to manage a project—much less a full-scale CMS implementation—is not fully understood.
This was brought home to me recently when assisting a client in implementing an enterprise-wide content management system. The client had never undertaken any projects of this scale and complexity before. (Even when the company's IT department rolled out Windows 2000 it did so on a rather ad hoc basis, which showed.) To complicate things further for the rather laissez faire client, the CMS vendor had appointed a project manager to oversee the implementation and, quite reasonably, expected that there would be someone managing the project on the client's end. In another case, a client had clearly identified tasks, but had not allocated resources. Thus, they also had not recognized that there weren't enough staff days available to accomplish the tasks. In either of these situations, clear project management seems the natural solution. I thought it might, therefore, be useful to devote this column to setting out some of the basic principles of project management, using the implementation of a content management system as the context.
Managing Three Variables at Once
There are three variables in any project: the objectives, the schedule, and the resources (mainly staff time). These are all linked together; you cannot change one without reviewing the impact on the others. A frequent mistake made in project management is setting objectives without understanding scheduling and resource requirements. Worse is changing the objectives as the project proceeds. I've seen a company start to implement a CMS then realize that a crucial work process needs to be revised, which is then squeezed into the project without any assessment of the implications on the overall implementation.
Almost certainly, a CMS implementation will need to be phased in gradually, perhaps by individual department or even process. The implications of the phasing need to be considered very carefully at the outset and then incorporated into the objectives. This will require a knowledge of when key staff members may be away on business or vacation. There is no point in planning to deploy a CMS in a department if the senior manager is not on site to assist and encourage the process.
Once the optimum phasing-in has been agreed upon, the intermediate steps in the schedule towards this implementation, usually referred to as "milestones," can be set out. Keep in mind that, for a CMS implementation, the schedule is also dependent on the vendor's requirements.
All this is easy compared to the allocation of staff time. As I have remarked on many occasions, most organizations have no idea how much time staff spend creating intranet content and usually do not see this as a core business activity. The probability that they will then understand why it is necessary to allocate staff to the CMS implementation (for example, to develop metadata schemes) is very small indeed. There will probably be two views: One is surprise that additional work is required. The second is that this is work that the vendor should be doing.
Once the release of staff to the project has been agreed upon, you need to go back to review the objectives and the schedule and see if these still hold. Almost certainly, they will not and more planning will be needed. This process cannot be rushed. Without establishing a plan in which the objectives, schedule, and resources are in balance, the chances of a successful implementation are close to zero.
One final point on scheduling: Do not take at face value vendor claims that they can implement their CMS "in four to five weeks." In theory they may be able to, but that optimistic forecast is based on some assumptions about the level of preparation within the customer's organization that are rarely found.
Being a Project Manager
Project managers are often chosen in the same way that someone is asked to write up the meeting notes: "You'll do it, won't you." Note the lack of a question mark. Project managers need a specific set of skills, including excellent communication and negotiating skills, and the uncommon ability to balance attention to detail with long-term vision. Thus, rather than being conceived of as an afterthought, choosing a manager should be a primary component of planning and implementing a CMS.
Equally as important, the project manager has to have decision-making authority to keep the objectives, schedule, and resources in balance. In reality, this may be difficult to achieve, but a project manager should at least have a written statement defining his authority and which manager they should go to for decisions beyond the scope of this authority.
Though it might seem natural, in a CMS implementation, to put the Web master or the intranet manager in charge, they often have little authority. So, appointing them project manager without understanding what authority is needed can give rise to some serious problems. The process of implementing a CMS is going to be a voyage of discovery for both the customer and the vendor. Many organizations assume that because a scope study has been undertaken, all the requirements and risks have been established. The reality is that because of the way in which a CMS will (ideally) affect many, if not all, processes in an organization, there are bound to be unforeseen problems—and opportunities—that will surface during the project. Finally, accept that implementing a CMS requires a full-time project manager, or at least one who can make the project their absolute priority.
Beyond assigning one person responsible for managing a project, successful projects also need a project sponsor and a project board. The project sponsor should have the seniority and perspective to be able to understand and, where appropriate, implement changes to the project plan recommended by the project manager. However, the sponsor not only supports the manager, but also represents the board.
The project board should consist of no more than five individuals who have the most to gain from the CMS and, therefore, a keen interest in the project. There should be representation from IT and Personnel because whether or not they will be directly affected by the CMS, changes to staff roles and responsibilities will also need to be considered.
Without a consistent approach to project documentation, tracking the project roll-out against objectives, schedules, and resources is impossible. The emphasis should be on regular short reports that are circulated to agreed-upon staff members. Reports should highlight the input that is required from staff and deadlines for response. Care should be taken to track emails. There is reasonable justification with a project of this scope to use some form of collaborative platform and I have seen a Weblog used quite effectively to keep everyone on a project team informed and involved. Another aspect of documentation is ensuring that the organization is kept informed of the project's progress so that changes in dates or goals do not come as a surprise and everyone is able to start planning for a CMS-enabled future.
Waving a Red Flag
One final aspect of CMS implementation to be aware of is that you will be working with at least one external partner and maybe more. Often CMS software vendors, Microsoft, for example, do not sell directly, but work through a channel partner or systems integrator. Without careful management, problem resolution (or red flag issues) can be a nightmare. From the outset, it needs to be recognized that the integrator is responsible for managing the vendor. The moment three parties get involved, with the customer contacting the vendor directly over a problem, chaos will result. The only way to avoid this is to agree a procedure for highlighting problems as they arise, including a timeline for agreeing on who is going to take the actions to resolve the dispute.
Implementing a CMS is one of the largest projects many companies will undertake and it should be viewed as such. There are many books on project management on bookstore shelves and the investment in buying several is small compared to the risks to the business of a delayed or unsatisfactory CMS implementation.