scope of the project - ITIL Concepts

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.


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.


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. 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.


The most accurate plan will incorporate two kinds of estimates.

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.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

ITIL Concepts Topics