ITIL Capacity Management: Define and Manage Capacity Plans
- Scope of a Capacity Plan
- Format of a Capacity Plan
- Maintaining Capacity Plans
- Storing Capacity Plans
- Summary and Next Steps
One of the key pieces of information that should be stored in your capacity management information system is the capacity plan. The ITIL Service Design book offers a great high-level look at the contents of a capacity plan. It assumes, however, that you will create a colossal document that includes all the capacity details for all your services and components. Then the book goes on to say you should take the time to create an executive summary because the main document will be so large that very few will actually read it!
This chapter goes beyond the ITIL documentation to describe a working formula for capacity plans. It suggests that you create more customized plans for those areas that really need detailed plans and keep them current through a repeatable process. You will learn the details of what goes into a capacity plan and how and when to create your plans.
Scope of a Capacity Plan
As the name implies, a capacity plan is a plan for how to manage the capacity of a specific IT service. Although you could attempt to create a single plan that defines the current and future capacity needs for every IT service you manage, it would soon break down into a series of individual chapters by service. So why not create an individually managed plan for each service from the outset? The scope of each plan is thus the service that is defined in that particular plan document.
Service Capacity Plans
Throughout the preceding chapters, we've been using the geography analogy from Chapter 2, "The Geography of Managing Capacity," to describe the two types of resources for which you must manage capacity—IT components and IT services. You've seen examples of both, but now it is time for a more specific definition of an IT service. The ITIL framework describes an environment in which your IT organization creates an overall strategy and then designs, implements, and manages a set of services that you offer to the wider organization you serve. IT services offer specific business value to help your organization achieve its goals. Each service has a definition, one or more quality measures called service levels, and potentially a cost to those who receive the service.
Using this definition, the reason for capacity plans based on IT services becomes clear. If IT were a separate company, your IT services would be the way you made money. Running out of capacity to continue a service would restrict your ability to generate more revenue. So clearly you will want to have a concrete, actionable plan to ensure that your IT services do not run out of capacity. If you have no more service to offer, why should IT need to continue to exist?
You know you need to create capacity plans for your IT services, but how do you put some boundaries around what a service entails? A typical IT service blends hardware, software, data, and labor effort in a unique way to deliver the service that the organization needs. For example, consider an IT service that sets up a new workstation when an employee joins the organization. You either purchase a new workstation each time or have some workstations on hand, so that is one capacity pool. Each workstation requires several software licenses for an operating system, an office product, and maybe other applications, and those licenses can represent additional capacity pools to be managed. But to complete the service, you also need technicians who can unpack the hardware, install the software, and deliver the package to the new user. The overall service can get quite complicated, so knowing where to draw the boundary of the service capacity plan can be difficult.
As a rule of thumb, you probably want to exclude labor components and focus on the hardware and software pieces that make up your service. Labor capacity is the domain of your human resources team and not really the subject of IT capacity management until you have a very mature capacity management program and a very good relationship with your HR team. After you have identified the most important hardware and software components, you need to define the relationships between them in a way that helps you understand the capacity of the service. These relationships should already be available as part of your configuration management system. Stop when you get to components that are really not integral to providing the service you are considering.
Of course, many of your IT services are delivered using shared components. A single server might be part of multiple different IT services, and network components are likely to be part of almost every service you deliver. If you have a way to allocate the capacity of a shared component to the different IT services it provides, then you can include these shared components along with the IT service. Otherwise, you need to create capacity plans for shared components separately from the plans for your IT services.
Component Capacity Plans
If you create capacity plans for each of your IT services, you will have most of your components already covered. So why would you define component-based capacity plans? These plans are needed only when you have components that do not participate directly in any specific IT service or for those areas where a component is shared among many or all of your IT services. In Chapter 5, "Establish the Capacity Management Information System," for example, you learned about the capacity management information system. Although capacity management, incident management, change management, and other IT service management systems are vital to IT, they are not directly related to any specific IT service that you offer to the wider organization. Because these systems are shared across all IT services, you should define a specific component-based capacity plan for them separate from your IT service capacity plans.
The scope of a component capacity plan is only slightly different than the scope of a service capacity plan. A component plan is more narrow because it needs to consider only a single capacity pool, or for a complex component perhaps two or three pools. Because of this more narrow focus, a component capacity plan is also more specific. Many times the utilization and total capacity information come directly from measurements done by automated tools, so the predictions in the plan of when capacity runs out can be much more precise than those of service capacity plans. In general, component capacity plans tend to be more technical and detailed than service capacity plans.
Sometimes it makes sense to link component capacity plans to IT service capacity plans. If a component is shared only between three or four different services, you might want to mention those services in the component capacity plan. It helps when reading the plan to understand that the capacity defined in the component plan is being allocated to a specific set of IT services.
Table 6.1 compares and contrasts IT service capacity plans and component capacity plans.
Table 6.1. Comparing Service and Component Capacity Plans
Service Capacity Plan |
Component Capacity Plan |
Variety of measurements |
Single direct measurement |
Unknown total capacity |
Known total capacity |
Contains options for capacity growth |
Normally one known growth option |
Utilization trends are estimated |
Utilization trends are accurate |
Contains business details |
Contains technical details |
How Many Plans?
The description of service and component capacity plans may leave you wondering whether it wouldn't be better to just create a single capacity plan after all. It might seem that managing this plethora of plans will cause extra confusion and added work, but that isn't the case. If you have really committed to managing IT as a set of services, you will have many other documents aligned by service, and the capacity plan will just be part of the entire set. For a very large organization or one with a high degree of complexity, the service owner manages the capacity plan along with other documentation for the service. In that case the service owner relies on the capacity management team for assistance.
You should also be aware that not every piece of your IT environment necessarily needs a capacity plan. Remember that capacity planning is all about making better decisions. There are likely to be areas where capacity decisions do not need to be made. For example, many organizations find that local area networks seldom have capacity issues, so they choose not to define or manage capacity plans for the LAN components. Similarly, personal workstations probably don't need capacity plans because shortages of workstation capacity do not significantly impact the IT organization or its ability to provide services to the business.
Your set of capacity plans is likely to grow over time as you get more experience in capacity planning and expand the range of decisions that can be made with solid capacity data. You certainly want to create plans for your most frequently used IT services first. Next you should define plans for those shared components that are most critical or that would have the most impact if they ran out of capacity. Finally, work on the less critical components and the less frequently used services.
The bottom line is that you should create capacity management plans with an eye to their value. If there won't be value in having a plan, don't create one. On the other hand, don't hesitate to create plans if you think you might need them. There is nothing worse than telling the business they need to wait a week or more for an important service because you didn't think you needed to manage capacity for that service!