Putting Together a Useful Project Plan for ITIL Configuration Management

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.

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.

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.

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

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.

It is crucial that you plan the life of your program in advance. All the phases should be known and understood from the onset. This allows you to plan which requirements are going to be implemented where. It is much more palatable for a stakeholder to hear that their requirement will be implemented in phase four than to hear it didn’t make the cut to get implemented in the first phase. It is also much easier to manage expectations around a series of incremental values than a single, large value statement. Note that it is also possible to satisfy a requirement only partially in an early phase, and then complete it in a later phase.

Each phase becomes a project of its own, with a separate schedule, a specific set of requirements to be achieve, a finite scope, and the entire rigor of project management and execution that your organization normally uses. Although all phases should be known at the beginning, you only need to plan and execute them one at a time. If the value is not proving to be adequate, you can embark on a new course by adding or removing phases as necessary. This significantly decreases the risk of implementing the overall configuration management program.

After you define the “big picture” in terms of the number of phases and their approximate content, you can begin the detailed work for the first phase. This is where you capture the actual project tasks and resources needed to meet the requirements specific to this initial phase. Simply parse through the requirements with the technical team, asking repeatedly “What will it take to get this done?” until the team agrees that you’ve captured all the tasks. Remember that you need only the details for the phase you’re currently planning. Future phases will be planned in detail in their own time.

Planning to Customize the Process

Configuration management is much more than just meeting a set of requirements, however well they are written. You also need to include in your project plan all the steps needed to set up and execute the configuration management service. This includes defining and refining the process down to the level that people can actually execute it day to day. This section describes the general set of steps you need to customize a configuration management process.

Process work should be done using an iterative model. Begin with the top-level configuration management defined in a single document. This document should include a top-level picture that most likely will look something like the one at the beginning of Chapter 4, “Customizing the Configuration Management Process,” where the whole process is captured in one diagram. In addition, your process document should include the relationships you envision between the configuration management process and any other operational processes, such as incident management, change management, and availability management. This high-level document is also a great place to document the enterprise policies regarding configuration management.

After documenting, reviewing, reworking, and finalizing the high-level process, you can begin working on the next level down, which many organizations call procedures. Take each of the process blocks and determine how they break down. For example, you most likely have a high-level block for controlling configuration items (CIs). Within this block, you might want to define a procedure for updating the CMDB, a procedure for batch loads of many CIs at a time, a procedure for updating relationships as the result of change records, and a procedure for archiving CIs after they have been retired. In defining and documenting procedures at this level, you might need additional policies, or even some minor changes, to the higher-level process. Go back and change those documents, review them, and when they are updated, continue at the procedure level.

In very large or very complex organizations, you might need additional levels of procedure work to further elaborate on the high level of procedures. Review Chapter 4 for a description of when to stop. Be sure to include tasks in your project plan to work at as many levels as needed.

After the procedures are reviewed and in good shape, have the actual people who must execute them look them over to determine whether they need more information to be able to execute. Many times you’ll discover that specific, detailed instructions are needed to fill in some gaps in the procedures, or to define how multiple procedures blend together into a single job description. These work instructions should be specific to the tools, techniques, policies, and procedures you want people to follow. If your staff is new, or is brand new to the discipline of configuration management, you will most likely need to define more work instructions at a deeper level of detail. For staff that has some experience or a better understanding, fewer work instructions will be needed.

Document all tasks that will be involved in this iterative approach to customizing the process, as shown in Figure 6.3. Remember to include review time, rework time, and plenty of time to gain the approvals you’ll need at the higher levels. Some of these tasks might intersect with the tasks to meet your requirements, but in other cases, these will be new tasks that must be accommodated in the overall project plan. If your organization is familiar with doing process engineering activities, you should have some experience to draw on to make your estimates. If not, you should be aware that process work always takes longer than you expect.

Planning Integration of All Data Sources

After getting all the requirements planned and the process work covered, it is time to consider the additional tasks required for integration of the data. As described in Chapter 5, “Planning for Data Population,” pulling data from multiple places into the CMDB requires integrating that data together. You should go through a similar set of tasks for each data source, so the tasks are considered in order here rather than separately for each type of data.

To integrate data into the CMDB, you need a map of that data. These maps go by the names “database schema,” “entity relationship diagram (ERD),” or perhaps “data dictionary.” You need to know the number, types, lengths, valid values, and description of each data element in the potential source. Where accurate maps already exist, this task can be straightforward. If you discover that no suitable maps exist, this task can take quite a bit of effort as you reverse-engineer a system to discover what data it manages. Don’t ignore the possibility that the data you’re mapping might have relationships that can be converted either directly or indirectly into relationships in your CMDB.

After you have the data map, the next step is to analyze the data in light of what you need in the CMDB. Match up fields to understand where the data will be placed. For fields that are of different lengths, determine whether you need to pad or truncate the incoming data to fit your CMDB model. If the external data source has a specific set of defined values, match those to the possible values in your CMDB model. For example, perhaps you’re dealing with an asset management system that has status values of “on order,” “in storage,” “deployed,” and “retired.” Your CMDB allows status values of “production,” “redeploy,” and “retired.” You need to form a mapping from the four values to the three values, which might include a rule which says that any asset with the status of “on order” is not brought forward to the CMDB. Complete the detailed design of exactly how the data will come into the CMDB.

The third activity is to actually create the import mechanism. Will you be loading the data with a SQL input facility? If so, write and test the SQL. Will you be pulling the data from one system, putting it into a spreadsheet, and then importing the spreadsheet into the CMDB? Whatever your means of moving data, the third set of tasks should define those things necessary to build the “road” on which the data will travel. Building and testing this transport mechanism enables the data to flow, either one time or repeatedly if that is necessary.

After the roadmap has been drawn, the trip planned and the road paved, it is time to actually make the journey. Transfer the data into your CMDB, starting with a small part. Test to make certain that the data you’ve sent has been stored just as you want it in the target database. When the tests show that the data movement is successful, repeat the process with all the data from your data source.

The project plan should include the preceding four steps for every data source you need to integrate into the CMDB. These tasks will encompass all the work needed to integrate the various data sources described in Chapter 5. Include all the detail in the plan for each different data source to ensure careful tracking of this vital part of the plan.

Putting All the Pieces Together

By now you should have a fairly long list of tasks. Your working set should include a set of tasks to define the scope, granularity, and span, all the tasks needed to meet the requirements, all the tasks needed to customize the process, plus all the tasks necessary to integrate the data. Add to these tasks any others necessary for project administration in your organization, such as hiring and training staff, communicating status regularly, producing project required deliverables, and any other tasks that your standards require.

While the list of tasks might seem like it is fodder only for the project schedule, this long list of tasks gives you all the raw materials to actually put together a useful project plan. For example, if you have a task calling for documentation of a CMDB audit procedure, it should remind you that part of your communications plan should include a briefing of your corporate audit or QA group so that they understand their role in auditing your processes. Likewise, a task calling for gathering software license information might lead you to document a project risk that software license information might not be available. Think carefully through each of the tasks and imagine any possible obstacles and ways you can reduce those obstacles. That will lead you to all the information needed for a complete plan. This section describes how to finish that plan.

Scope

The first piece of any good project plan describes the scope of the project in a clear, concise, and unambiguous way. For a configuration management plan, the scope should include the set of requirements that you intend to achieve, the procedures you intend to document, and the set of data sources that will be integrated. Architectural concepts, such as a system context diagram or a high-level use case diagram, are often appropriate in a scope document. Depending on your organization’s policies, the scope document might be an exhaustive, detailed description of everything you’re doing, or an executive-level overview of just the key deliverables and milestones for your project.

The scope should be understandable by everyone on your implementation team. The scope will serve as a guideline many times when in the midst of low-level details people ask what they really are supposed to achieve. Compare the full set of tasks you’ve documented with the scope and make sure that all tasks are necessary per your scope. You might need to change the scope document, or perhaps you documented tasks that don’t actually need to be done. Make sure the scope document is agreed by all of your sponsors and at least understood by all the other stakeholders. Nothing can torpedo a project faster than someone coming in at the end to question whether your scope was valid in the first place.

Schedule

Along with understanding the scope of the project, your list of tasks will also help you develop a reasonable project schedule. If your organization has little experience with configuration management, it might be difficult to get good estimates to schedule the project. To compensate, we recommend both a “top-down” schedule and a “bottom-up” schedule be built.

To build the top-down schedule, have someone at the top of the project do an estimate for every major block of work to be done. Perhaps this will be your sponsor or the project architect. For each major block, allocate what seems like a reasonable amount of time to complete that work. For example, it might seem reasonable that it will take three weeks to gather, analyze, and document a good set of requirements for the project. It might seem like six weeks is enough to analyze, map, develop, and import all the data you need from various sources. Continue doing those kinds of estimates for each major part of the work, and you’ll have a “top-down” schedule. Normally, a schedule developed this way will represent the absolute shortest time in which a project can be accomplished.

To build the “bottom-up” schedule, you need to assign each task to the person who actually has to do it. Determine your project resources and begin allocating tasks to those resources. Now ask each person to estimate the amount of time it will take to complete the tasks assigned to them. You’ll find that people who have done this kind of work before (if you have any on your staff) will give fairly close estimates and everyone else will overestimate the time needed. Put all of these times together, taking into consideration that certain tasks can be accomplished in parallel, but no one can work more than the normal hours per week. Blending all the estimates together will create a “bottom-up” schedule, representing the longest possible time it could take to accomplish the project.

To get to the actual schedule, take the “top down” and the “bottom up” and reconcile them (see Figure 6.4). This takes some practice and knowledge of the people who did the estimating. Determine which tasks are likely to be on your critical path and spend the most time refining the estimates for those tasks. This reconciliation will reveal the best possible schedule for the implementation.

No schedule is really complete without an accompanying budget or cost case. From the task list and estimates, you should be able to develop the labor costs for your project. Other costs like hardware and software should already be known from previous planning steps. Put all this together into a budget for your project, which can be included in the schedule, or maybe a separate document depending on the expectations of your sponsors.

High-Level Design

In addition to a scope and schedule, your project plan should also include some technical description of what will actually be built. Many organizations call this an architecture document or high-level design. This operational concept should include organizations involved, technology to be used, and a brief description of how things will operate after steady state is achieved. In most methodologies, the operational concept or architecture will lead to a high-level design, and possibly a lower-level design. This kind of information provides some confidence that the technical team has thought deeply about the issues of configuration management as part of the planning phase of the project.

The design is based primarily on the requirements document. That is, the requirements describe what is to be accomplished by the project, and the operational concept or architecture document describes how it will be accomplished. The operational concept need not be very detailed early in planning, but before the full plan is settled and implementation begins, a clear and precise design should be available. Don’t assume the design just includes tools, or should be drawn up by a software architect alone. The design should adequately describe which processes will be defined, what organizations will be created or modified to support the configuration management service, where hardware or networks will be augmented to support the CMDB, and data rules and validations that will be in place to facilitate accuracy. A good, solid design serves as a guardrail to the project team, helping them avoid making critical decisions independently later in the project.

Communications Plan

Finally, no project plan is complete without a communications plan. In general, we use a model that starts with the project team at the center, with the sponsors, the directly impacted stakeholders, the interested stakeholders, and the rest of the organization in concentric rings around that center. For each ring, decide and document how often you will communicate to them and what method will be used. Include any regular meetings to be held, training sessions to be scheduled, and news sources such as web pages or newsletters to be developed. The communications plan should tell everyone where to look for continuing information on the configuration management project.

Baseline the Plan

After your key project documents are all assembled, it is critical that you gain the approval of your sponsors, and then baseline the plan. By baseline, we mean that you establish a control mechanism for making changes to the documents, and insist that every change go through the mechanism you’ve described. If your organization is accustomed to this, you already know the benefits. If not, you will quickly learn that having control over the changes in your project plan documents can save hundreds of hours of rework and discussion about what you’re really intending to do.

After the plan has been approved and is under change control, take a moment to celebrate with the team. You’ve completed the hard part by putting together a careful plan. Now all you need to do is implement!

This chapter is an excerpt from the new book, Implementing ITIL Configuration Management, authored by Larry Klosterboer, published by IBM Press, December 2007, ISBN 0132425939, Copyright 2008 by International Business Machines Corporation. All rights reserved. For more info please visit the ITIL book page.