Template draft. Replace everything in [square brackets] with your own decision,
delete what does not describe what you really do, and approve it through your own document control. It is not legal
advice and does not make an organisation compliant or certified.
1. Introduction
Demand rises and falls with customer activity, product launches, seasonal peaks and the Organisation's own growth. Capacity is what the services, infrastructure, suppliers and people can deliver in response. When the two drift apart, customers notice slow responses, queues and failures. This procedure joins the forecasting of demand with the planning and monitoring of capacity so that the gap is seen early and closed at a sensible cost.
The information security view of capacity, including protection of monitoring data and capacity as a security control, is in the Capacity Management and Planning Procedure; this procedure covers the service management process.
2. Purpose
The purpose is to make sure that the Organisation has enough capacity, of the right kind, at the right time and cost, to meet the agreed service levels now and for the planning horizon, and that demand for services is understood, forecast and where necessary shaped so it can be met.
3. Objectives
- Capacity requirements for every new or changed service are agreed during design, before the service goes live.
- Current use of every tier 1 and tier 2 resource is measured automatically and compared with the thresholds in this procedure.
- A demand forecast and capacity plan are produced every [quarter] and a rolling [12 month] view is kept up to date.
- Threshold breaches are acted upon within the response times in the thresholds table, and none leads to a breach of a customer service level without prior warning to the service owner.
- Capacity actions are costed and approved through the budget process, and surprise purchases are exceptional.
- Demand management measures, such as scheduling or pricing, are proposed when meeting forecast demand would be uneconomic or impossible.
4. Scope
- In scope: capacity of compute, storage, network, databases, application licences and cloud quotas, supplier-provided capacity, facilities such as power and space, and people capacity in the service desk and resolver groups.
- In scope: demand from customers, from internal users and from planned projects, for every service in the service catalogue.
- Out of scope: individual end-user device performance, and capacity of customers' own systems.
- Applies to: capacity manager, service owners, resolver groups, project managers, finance, suppliers who provide capacity, and the business relationship manager who brings customer plans.
5. Terms and definitions
| Term | Meaning |
|---|
| Capacity | The maximum throughput, volume or workload that a resource or service can handle while meeting its service level targets. |
| Demand | The quantity of service use that customers and users request or are expected to request. |
| Utilisation | The share of capacity in use, expressed as a percentage of the usable maximum. |
| Headroom | Capacity remaining between current peak use and the point at which service levels would be at risk. |
| Threshold | A utilisation or performance value that, when reached, triggers a defined action. |
| Pattern of business activity | A recurring profile of demand by hour, day, month or event, such as month-end processing. |
| Planning horizon | The period ahead for which demand and capacity are forecast. |
6. Roles and Responsibilities
| Role | Responsibilities |
|---|
| Process owner | Owns this procedure, approves the capacity plan and the thresholds, and takes capacity risks to management. |
| Capacity manager | Runs the process, builds forecasts and plans, tunes thresholds, produces the capacity report and advises on design and change. |
| Service owner | States demand expectations and quality needs for the service, reviews forecasts and approves actions for the service. |
| Business relationship manager | Collects customer plans such as launches, campaigns and growth, and passes them to the capacity manager. |
| Resolver groups | Operate monitoring, supply utilisation data, carry out tuning and expansion, and report constraints. |
| Finance | Provides budget and cost data and approves capacity spending within delegation. |
| Supplier manager | Obtains capacity commitments and lead times from suppliers and tracks them. |
| Top management | Approves large capacity investments and demand management policies that affect customers. |
| Activity | Responsible | Accountable | Consulted | Informed |
|---|
| Gather customer and project demand | Business relationship manager | Service owner | Capacity manager | Finance |
| Produce demand forecast | Capacity manager | Process owner | Service owner, Business relationship manager | Resolver groups |
| Monitor utilisation and thresholds | Resolver groups | Capacity manager | Service owner | Service desk |
| Create and update capacity plan | Capacity manager | Process owner | Service owner, Finance, Supplier manager | Top management |
| Raise changes to add or reduce capacity | Resolver groups | Service owner | Capacity manager, Change authority | Finance |
| Apply demand management measures | Service owner | Process owner | Business relationship manager, Finance | Customer representative |
| Publish capacity report | Capacity manager | Process owner | Service owner | Top management |
7. Capacity and Demand Management Process
7.1 Inputs and outputs
| Inputs | Outputs |
|---|
| Customer and business plans, launches, campaigns and contract changes | Demand forecast by service |
| Service level agreements and the performance targets inside them | Capacity plan with actions, costs and dates |
| Utilisation and performance data from monitoring | Thresholds and alerts, tuned |
| Incident and problem records caused by a shortage | Requests for change to add, release or tune resources |
| Supplier capacity commitments, lead times and price lists | Capacity report |
| Service design packages for new and changed services | Capacity requirements for design and transition |
7.2 Process flow
- Demand information is collected from customers, projects, history and the business calendar.
- The capacity manager builds or refreshes the forecast and agrees it with the service owner.
- Current and forecast load are compared with the capacity of each resource and with thresholds.
- Gaps are identified with a date by which action is needed (the lead time).
- Options are developed: tune, add, reschedule, shape demand, accept a risk.
- The chosen option is costed, approved and raised as a change.
- Monitoring confirms the effect and thresholds are tuned.
- Results are reported and the plan is refreshed on its schedule.
7.3 Demand management
Demand management understands what drives use of each service and how to influence it when capacity cannot or should not follow demand.
- Profile demandFor each tier 1 and tier 2 service the capacity manager records the pattern of business activity: daily, weekly, monthly and annual peaks, and the events that cause them. Source: monitoring history for at least [13 months]. Target: complete within [60 days] of the service going live.
- Identify driversLink demand to business drivers such as number of customers, transactions, campaign size or headcount, so forecasts can be based on plans rather than only on history. Owner: capacity manager with the service owner.
- Collect plansAt the start of each quarter the business relationship manager asks customer representatives and project managers for planned changes in volume for the next [12 months]. Output: demand inputs register.
- ForecastCombine history, drivers and plans into a low, expected and high case for each service for the next [12 months]. Output: demand forecast. Target: [10 working days] after the inputs are in.
- Agree and publishThe service owner reviews the forecast and records disagreements; the approved forecast is shared with resolver groups, finance and the supplier manager.
- Shape demand if neededWhere forecast demand exceeds what can be delivered within budget, the capacity manager proposes measures: moving batch work to quiet hours, throttling or queueing, usage limits, tiered pricing, or customer communication. These are decided by the service owner and the process owner.
| Forecast technique | Used for | Note |
|---|
| Trend of past data | Steady growth in stable services | Needs at least [13 months] to see seasons |
| Business driver model | Services tied to customers or transactions | Update with each plan change |
| Planned events and campaigns | Spikes with a known date | Taken from customer and project plans |
| Scenario with worst case | New services and acquisitions | Always include a high case at [150%] of expected |
7.4 Capacity planning
Capacity planning is done at three levels: business capacity (will the services meet the volumes the business expects), service capacity (can each service meet its targets under that load) and component capacity (can each resource carry its share).
- Set capacity requirementsDuring service design, the capacity manager agrees with the service owner the expected volumes, performance targets, growth and headroom required. Output: capacity requirements in the design package. Target: before design verification.
- MeasureMonitoring collects utilisation of each resource at least every [5 minutes] and keeps summarised data for [13 months]. Resolver groups confirm that every tier 1 and tier 2 resource is covered.
- AnalyseEach month the capacity manager reviews peaks, averages and trend per resource and per service, compares them with the forecast and notes where headroom is lower than [20%].
- ModelFor significant changes, such as a new customer, the capacity manager models the load, using tests or past data, and estimates the lead time and cost to meet it.
- Plan optionsFor each gap the plan lists at least two options with cost, benefit, risk and lead time, and recommends one. Owner: capacity manager.
- ApproveWithin delegated limits the service owner approves; above them the process owner and finance, and above [the investment threshold] top management. Output: approved capacity plan.
- ImplementResolver groups raise requests for change under the Change Management Procedure and order from suppliers with the lead time in the plan.
- ReviewThe plan is reviewed [quarterly] and after any incident caused by lack of capacity.
Note. A plan that depends on a supplier must state the supplier's lead time and the date by which the order must be placed. The supplier manager tracks that date.
7.5 Thresholds and responses
Thresholds are set per resource type from baseline measurements, tuned by the capacity manager and approved by the process owner. A warning threshold gives time to plan; a critical threshold means service levels are at risk now.
| Resource | Measure | Warning | Critical | Response to warning | Response to critical |
|---|
| Compute | Peak CPU use over [15 minutes] | [70%] | [85%] | Review within [3 working days] | Add capacity or reduce load within [4 hours] |
| Memory | Peak memory in use | [75%] | [90%] | Review within [3 working days] | Act within [4 hours] |
| Storage | Used share of volume | [70%] | [85%] | Forecast days to full; plan within [5 working days] | Extend or clean within [1 working day] |
| Database | Connections in use or query time | [70%] | [85%] | Tune or plan within [5 working days] | Act within [4 hours] |
| Network link | Peak bandwidth in use | [60%] | [80%] | Review within [5 working days] | Raise change within [1 working day] |
| Licences and quotas | Licences or quota used | [85%] | [95%] | Order within [10 working days] | Order within [2 working days] |
| Service desk | Queue wait or agent utilisation | [80%] | [90%] | Rota review within [5 working days] | Add cover within [1 working day] |
| Facility power and space | Share of rated capacity | [75%] | [90%] | Plan within [30 days] | Escalate to top management within [2 working days] |
Every threshold breach creates an event in the ticketing tool. A critical breach with customer impact is treated as an incident under the Service Incident Management Procedure, and repeated breaches go to problem management.
7.6 Capacity for new and changed services
- Service design must state capacity requirements and test them before go-live; a new tier 1 or tier 2 service is not accepted without a load test at [120%] of expected peak or a documented reason.
- A request for change that adds load, for example a new customer or feature, includes the effect on capacity, assessed by the capacity manager when the change is of medium or high risk.
- When capacity is released, for example after a service is withdrawn, the resource is returned to the pool or the contract is reduced at the next renewal.
- Cloud capacity is governed by budgets and automatic scaling limits agreed with finance, with alerts at [80%] of the monthly budget.
8. Interfaces with other processes
| Process | Interface |
|---|
| Service level management | Service targets drive capacity requirements; capacity breaches are reported against targets. |
| Business relationship management | Customer plans are the main source of demand inputs. |
| Service design and transition | Capacity requirements and tests are part of every design and acceptance. |
| Change management | Capacity additions and reductions are changes; the capacity manager advises on risk. |
| Configuration and asset management | Capacity data is attached to the resources recorded in the CMDB. |
| Incident and problem management | Shortages cause incidents; recurrent ones drive problems. |
| Supplier management | Supplier capacity and lead times are monitored through supplier reviews. |
| Availability and service continuity management | Recovery capacity at the alternate site is planned here too. |
9. Key Performance Indicators
| Measure | Target | Source | Frequency |
|---|
| Tier 1 and tier 2 resources with utilisation monitoring and thresholds | [100%] | Monitoring inventory | Quarterly |
| Critical threshold breaches with customer impact | Fewer than [2] a quarter | Incident records | Quarterly |
| Warning breaches actioned within target | [95%] | Ticketing tool | Monthly |
| Forecast accuracy against actual peak demand | Within [15%] | Forecast and monitoring data | Quarterly |
| Incidents caused by lack of capacity | Fewer than [3] a quarter | Incident records | Quarterly |
| Capacity plan reviewed on schedule | [100%] | Plan record | Quarterly |
| Unplanned or urgent capacity purchases | Fewer than [10%] of capacity spend | Finance records | Quarterly |
| New services accepted with capacity tests completed | [100%] | Acceptance records | Quarterly |
10. Records and evidence
| Record | Kept in | Owner | Retention |
|---|
| Demand inputs register and forecasts | Document management system | Capacity manager | [3 years] |
| Capacity plans and approvals | Document management system | Capacity manager | [3 years] |
| Utilisation data | Monitoring tool | Resolver groups | Detail [90 days], summaries [13 months] |
| Threshold list and tuning history | Monitoring tool configuration | Capacity manager | Life of the service plus [1 year] |
| Capacity reports | Document management system | Capacity manager | [3 years] |
| Load test reports | Release record | Release manager | [3 years] |
Annexure A: Capacity report template
| Section | Content | Entry |
|---|
| 1. Summary | Period, overall status, three main points for management | |
| 2. Demand | Actual against forecast by service; events in the period; next quarter inputs | |
| 3. Utilisation | Peak and average per resource; resources at warning or critical | |
| 4. Breaches and incidents | Count, impact and cause for each breach that affected a service | |
| 5. Actions | Capacity changes completed, planned and overdue, with owner and date | |
| 6. Forecast and risks | Expected, low and high case for the next [12 months]; risks and lead times | |
| 7. Costs | Spend against budget; proposals needing approval | |
| 8. Decisions requested | Items for the process owner or top management | |
Annexure B: Capacity plan action list
| Service or resource | Gap and date needed | Option chosen | Cost | Lead time | Change reference | Owner | Status |
|---|
| [Customer platform database] | [Storage full in 90 days] | [Add volume] | [amount] | [10 days] | [CHG-0001] | [Name] | [Planned] |
| | | | | | | |
| | | | | | | |
| Date received | Source | Service affected | Expected change in volume | From date | To date | Confidence | Recorded by |
|---|
| [date] | [Customer representative] | [Messaging service] | [+30%] | [date] | [date] | [High] | [Name] |
| | | | | | | |
| | | | | | | |
Annexure: Document history
| Version | Date | Author | Reviewed by | Approved by | Summary of change |
|---|
| [1.0] | [date of issue] | [Process manager] | [Process owner] | [Management representative] | Initial issue of SM12 |
| | | | | |
| | | | | |
11. Exception
Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.
12. Enforcement
Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.
13. Review
This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.
ISO/IEC 20000-1:2018 references
| Reference | Title |
|---|
| 8.4.3 | Capacity management |
| 8.4.2 | Demand management |
| 8.4.1 | Budgeting and accounting for services |
| 8.3.3 | Service level management |