Putting Together a Useful Project Plan for ITIL Configuration Management

The core of the IT Infrastructure Library (ITIL) is configuration management. This book chapter explains how to manage the project for achieving those goals.

Thus far we've looked at parts of an overall configuration management project. We've seen how to gather and analyze requirements, how to document the scope, granularity, and span of your Configuration Management Database (CMDB), how to customize the configuration management process, and what you need to understand to plan for data population. But thus far we haven't actually done anything. Now it is time to put all of this knowledge together into that most tangible of documents—a project plan.

Excerpted from Implementing ITIL Configuration Management by Larry Klosterboer Published by IBM Press ISBN-10: 0-13-242593-9 ISBN-13: 978-0-13-242593-3

Never get fooled into thinking a project plan is the same as a project schedule. The specific tasks, resources, and dates that make up a schedule are only a small part of a complete project plan. Each organization has slightly different requirements, but normally the overall plan is comprised of a communications plan, some sort of plan for supporting the system, and some kind of budget. You also want to document the outstanding issues that you know the team will face, and create a way to describe the architecture or design of the service you're planning. Although this isn't a book about project planning, this chapter at least examines the typical deliverables that make up a complete project plan and gives you some perspective on how these can be critical to a successful configuration management deployment. Expert project managers should still find enough content here to help hone the configuration management project plan.

Figure 6.1: The project plan brings all the elements of planning together and adds important plan documents.

In general, project planning should be about synthesizing the information from Chapters 2 through 5. We begin by reexamining scope, requirements, process, and data population from a project planning perspective. In the second part of the chapter, we pull together the other deliverables needed for a full plan. Figure 6.1 shows a visual outline of the chapter.

Documenting the Project Tasks

The first step in building a project plan is to gather together all the tasks that must be accomplished. For configuration management, the list consists of requirement tasks, scope definition tasks, process customization tasks, and data population tasks. The following sections serve as a reminder of the tasks involved with each of these activities and give some hints about the duration of the tasks and the dependencies between them. The intention of these sections is to give you a solid base for building a realistic project schedule.

Planning for Scope, Granularity, and Span

The first thing that should go into your project plan is the scope and granularity that you documented in Chapter 3, "Determining Scope, Span, and Granularity." Setting the scope and granularity comes even before defining and analyzing the requirements because without a solid scope, it will be very difficult to structure your requirements gathering sessions. Those early requirements gathering sessions with your stakeholders must be based on some already derived work, and the scope documentation is a perfect starting point. Just be careful that you don't set the expectation that scope is completely finished—at this stage, it is really just a working model that will be shaped through the requirements gathering. Upon understanding even the basic concept of configuration management, most people will be eager to start talking about scope, so this is the first part of the plan.

Begin by defining the set of steps necessary to get a solid scope. You can go about this exercise in essentially two ways. You can start with a pre-existing scope document, such as the Desktop Management Task Force's (DMTF) Common Information Model (CIM). This model defines a set of objects that encompass a typical information technology (IT) environment. The model is very rich and extensible, and it's probably much more detailed than you want for your initial implementation. So, the best way to use the model is to understand its use, and then begin to choose pieces of it that you will implement in the scope of your project. This is the "subtractive" method of defining scope. Typical tasks that you would add to your project plan when adopting this method might be "analyze CIM model," "work through the application subset," and "review proposal for system subset." Eventually you should work through all the subsets of the overall model and determine which you will keep in your scope.

Figure 6.2: One way to build a schema is to subtract from an existing model; another way is to add based on brainstorming sessions.

The "additive" model for building a scope is to begin with looking around your organization, using any convenient framework you may already have. Perhaps your support teams are broken into a network group, a distributed server team, a mainframe operations team, an application development team, and a workstation support team. That's a framework you can start with. Meet independently with each team and quiz them on the key objects they deal with every day, and then use what you learn to define the scope of configuration management that will serve that team. If not from your organization structure, you might also find a useful framework from the categories used to classify incidents in your asset management tool or from the set of asset types in your asset management system. The two methods for getting at CMDB scope are depicted in Figure 6.2.

Regardless of the approach, your discussions on scope will frequently lead to conversations about span. Your project tasks should encourage this interplay and make time for it to occur. Rather than a sequential relationship between scope, granularity, and span, make these tasks overlapping, where span and granularity cannot complete before scope does. This will represent a much more realistic plan, although the total time taken for developing your complete schema will not necessarily be shorter. The iterative nature of the discussions will, however, allow you to create intermediate milestones. For example, you could create a task called "define scope for network equipment," another called "define span of network equipment," and a third called "define granularity of routers. This allows better project management than a single task for creating the network part of the schema.

After you have a framework, you repeat a cycle of interviewing people who are experts in each space, documenting what you've heard, sharing it with the domain experts for confirmation, and then reviewing it with your stakeholder team to make sure the framework will meet the defined requirements. Using the additive approach to setting scope will typically take longer because this cycle will need to be repeated several times in each area of the framework as questions are raised and thinking becomes more mature. The strength of this additive approach is that you will have a greater assurance that your scope will meet the needs of your entire organization because you've built is by consensus.

Whichever approach you choose for determining scope should then be followed by a set of tasks for gaining agreement on granularity. The best method here is interviewing the people who have the data (normally the support teams) and the people who will use the data (your stakeholders). Through a series of interviews and documents, you should help these two groups come to consensus on the right level of granularity, using the rules of thumb documented in Chapter 3. From a project point of view, these tasks for getting to granularity can be run in parallel with the start of getting requirements, assuming you have enough staff to do both things at once.

Of course, in all your discussions about scope, span, and granularity, you should never lose sight of the requirements you've defined. You should certainly include the tasks needed to define your scope, but those tasks should be interlocked with the tasks needed to meet the requirements as described in the next section.

Planning to Meet Requirements

The majority of tasks in your project plan should be directly related to the requirements you have committed to meet. In Chapter 2, "Gathering and Analyzing Requirements," we learned that requirements need to be prioritized because it might not be possible to complete all of them in a single project. Now it is time to revisit that idea. Most successful configuration management programs are implemented in a series of discrete steps or phases rather than as one single project, so you should be thinking in your project plans about what those pieces might be.

Here are some general guidelines for breaking up a configuration management program into workable pieces. If your organization is not starting from the very beginning, some of these phases may be less applicable, or could already be accomplished. For everyone else, the first phase will probably include some way to prove the value of configuration management to your organization. This might be called a "pilot" or a "proof of concept," but the idea is to implement enough of the organization, the process, and the tools to prove the value is real. In most cases, this will involve choosing a small set of IT decisions that have significant value and organizing a miniature configuration management system to help make just those decisions. If you're struggling to determine the correct hardware refresh cycles, for example, you might choose to implement configuration management for Sun servers as a first phase. Implementing all the processes and tools to manage these servers, including tracking incidents and changes associated with the servers, you can demonstrate the value of configuration management in deciding the larger issues of refresh management. This first phase, or pilot, is described in more detail in Chapter 10, "Choosing and Running a Pilot Program."

Depending on the successes and difficulties of the first phase, the second phase broadens the program to a wider set of data. Following the preceding Sun server example, you may want phase two of your program to achieve configuration management for all servers, and perhaps even for applications that reside on those servers. If the first phase was a tremendous success, or if your organization is small, you might want to tackle all servers, applications, and network components in the second phase. Again, the guiding principle should be value gained for effort expended. Each phase should demonstrate value and make the project sponsors eager to support and fund the following stages. Each phase will accomplish a piece of the overall span of your database until everything included in the total span is part of the CMDB.

Plan as many phases as are necessary to completely populate all of data envisioned in your scope, granularity, and span. Each population stage should feature enough new data to help support significant IT decisions, but not so much that the phase lasts more than six months. The rule for any IT project—and configuration management in particular—is that the value of a project decreases as the time to achieve that value increases. Smaller segments that show more specific value are better than larger chunks with more general (and hard to quantify) value.

Providing a firm estimate on the size of every situation isn't possible, but Table 6.1 offers a general guideline to determine whether your estimate of time to populate your database has the right order of magnitude.

Table 6.1 Magnitude Sizing for Populating a CMDB




Base for any population

Two months

The simplest possible population of a database requires at least two months.


Add one month for every100,000 CIs

More complex databases take significantly longer to populate.

Asset management

Add two months if you have no asset management

Subtract one month if you have a strong, reliable asset manage ment service

The practices and skills of managing assets are similar to those needed for configuration management, so if your organization has this discipline, you benefit.

Number of locations

Add one month for every ten countries past the first one

Geographically dispersed assets make the job more difficult, even if you centralize the team.

After the population of your database is complete, you might think the phases of implementation are over—but you would be mistaken. As more data gets populated, you will undoubtedly find ways that the processes defined in the first phase can be streamlined or improved. You're likely to find some better way to organize the people involved, and you're certain to receive suggestions for improving your tools. All of these modifications should be gathered up through the population phases, and only the most critical implemented. After the database is populated, it is time to kick off another major phase to complete as many of the "latent" requirements as possible. Knowing up front that this second round of organization, process, and tools changes is coming will help you to keep the intervening phases focused on populating the data, thus reducing their risk significantly.

1 2 3 Page 1
Page 1 of 3
7 secrets of successful remote IT teams