A big factor in ensuring that your IT team is able to meet changing business demands is having a firm handle on the capacity of your current infrastructure. You don't want to get blindsided with the news that your Web servers can't handle the traffic spike from a planned promotion; you also don't want to buy a bunch of unnecessary hardware "just to be on the safe side."
Capacity planning can be a complicated, subjective and, ultimately, flawed process if it is not governed by a set of pretty clearly defined standards. In the book ITIL Capacity Management, author Larry Klosterboer discusses best practices for capacity management as laid out by the Information Technology Infrastructure Library. The chapter "Define and Manage Capacity Plans," which details a granular approach to defining and maintaining these plans, is available free to IT Business Edge members here in the IT Downloads library.
Klosterboer's first point about the ITIL's advice is that the resulting enterprise-spanning plans will be massive - in fact, ITIL suggests a whole sub-project to create an executive summary of the master plan, which will simply be more than an executive can swallow. Klosterboer suggests creating specific capacity plans for two aspects of your infrastructure: services and components.
You can see the basic differences between the two plans laid out in the table, below.
In this context, a "service" is a value that IT provides to the rest of the business. Think as granularly as possible - "configuring a new client PC," and opposed to "setting up new employees." Defining the scope of a services capacity plan can be tricky, given that a service spans both software and hardware elements, all of which can be shared between services, making capacity something of a moving target. Hence, the table above lists the total capacity of a service as "unknown." Klosterboer suggests including shared resources in your service capacity plans, if at all possible (obviously, if you are using the cloud for compute resources, this all gets dramatically simplified).
Klosterboer also suggests that you omit labor and staffing from service capacity plans, which at first blush might seem odd. However, adding human resources often involves decision trees outside of IT - the capacity plans in this discussion are strictly for technology.
A component capacity plan focuses on a single tech asset, or, in some cases, a server cluster. Component capacity plans offer a more hard-and-fast view of what your backbone can handle, because the swags that drive service planning typically are replaced with hard data from a monitoring service. Component capacity plans won't see you through a budget planning session, but they are most useful when something goes wrong and you must shift vital services onto new hardware.
The book chapter goes on to discuss the review and versioning process for capacity plans, which of course must be managed carefully. It's a very informative read - be sure to check it out.