Capacity Review

What you'll get

• Scope - exactly what resources are being reviewed.
• Current utilisation snapshot - measured, not estimated, with source.
• Historical trend - last 3/6/12 months of utilisation.
• Growth drivers - headcount, product launches, policy changes, retention periods.
• Projection - next 12/24 months, with confidence range and assumptions.
• Threshold analysis - when utilisation hits 80/90/95%, what happens.
• Scenarios - do-nothing / optimise-first / scale-up / scale-out / replace - each with cost and risk.
• Recommendation - one option, named trade-offs, why this over the others.
• Risk if not funded - explicit, dated, quantified.
• Budget ask - specific figure, breakdown, funding window.
• Exec-friendly one-pager - at the top for the decision-maker.

Clarifying questions I will ask you

1. What resource are you reviewing? (WAN bandwidth / storage / compute / seats / licences / DC power / cooling / rack U / VPN concurrent sessions)
2. Current utilisation? (% or absolute - with timestamp and source)
3. What threshold is considered "concerning" in your environment? (80% is common for many resources; different for bursty ones)
4. Historical trend? (Last N months of same metric)
5. What's coming that drives growth? (Headcount, customer growth, retention policy, new product, regulatory data retention)
6. Seasonal patterns? (End of month, trading hours, back-to-school, Black Friday)
7. Technical options known to you? (Upgrade existing / migrate / add capacity / optimise / retire demand)
8. Commercial reality? (Contracts locked in, upgrade paths priced, vendor negotiation possible)
9. Timeline? (Must decide by / must deliver by)
10. Budget envelope? (Opex line / capex / unfunded and asking)
11. Decision-maker? (Line manager, IT Director, CFO, board)
12. Previous capacity decisions for this resource? (What have we done before - helpful context)

Output template

# Capacity Review: <resource> - YYYY-MM-DD

**Memo ID:** CAP-<slug>-<YYYY-QN>
**Prepared by:** <name>
**Prepared for:** <decision-maker, role>
**Date:** YYYY-MM-DD
**Decision needed by:** YYYY-MM-DD

## One-page summary (for the decision-maker)
> **What we're reviewing:** <resource - one line>
> **Current state:** <utilisation, condition>
> **Forecast:** <headline trajectory - e.g. "will exceed 90% threshold by Q4 2026">
> **Recommendation:** <option name>
> **Cost:** <figure> (<opex / capex>)
> **Risk of not acting:** <1-2 lines>
> **Alternative considered:** <name>, <why not>

## 1. Scope
- **Resource under review:** <what>
- **Timeframe of analysis:** Past <N> months, projected <N> months forward
- **Population affected:** <users / sites / services>
- **Measurement source:** <monitoring tool / vendor report / manual>

## 2. Current Utilisation
| Metric | Value | As of | Source |
|---|---|---|---|
| Utilisation | <% or absolute> | YYYY-MM-DD HH:MM | <source> |
| Peak last 30 days | <%> | YYYY-MM-DD HH:MM | <source> |
| Avg last 30 days | <%> | <period> | <source> |
| 95th percentile last 30 days | <%> | <period> | <source> |
| Threshold: concerning | <%> |  |  |
| Threshold: critical | <%> |  |  |

## 3. Historical Trend
| Period | Peak | Avg | 95p | Notes |
|---|---|---|---|---|
| YYYY-MM (12 months ago) | <>% | <>% | <>% | <event if any> |
| YYYY-MM (6 months ago) | <>% | <>% | <>% | <event if any> |
| YYYY-MM (3 months ago) | <>% | <>% | <>% | <event if any> |
| YYYY-MM (last month) | <>% | <>% | <>% | <event if any> |

**Observed trend:** <e.g. "Linear growth ~3% per month, consistent with headcount trajectory">
**Anomalies:** <e.g. "Spike in October correlates with product launch; sustained, not transient">

## 4. Growth Drivers
### Confirmed
- <Driver - e.g. "Hiring plan Q4 2026: +40 staff, +40% per-user bandwidth">
- <Driver - e.g. "Data retention extension from 3 to 7 years, +X TB/month">

### Probable (planned but not committed)
- <Driver - e.g. "New customer onboarding Feb 2027: +2000 users">

### Possible (contingent)
- <Driver - e.g. "Regulatory change may require regional data duplication">

## 5. Projection
| Horizon | Low estimate | Central estimate | High estimate | Threshold breach? |
|---|---|---|---|---|
| 3 months | <%> | <%> | <%> | No / Yes (central) / Yes (high only) |
| 6 months | <%> | <%> | <%> | |
| 12 months | <%> | <%> | <%> | |
| 24 months | <%> | <%> | <%> | |

**Key assumptions behind projection:**
1. <Assumption>
2. <Assumption>
3. <Assumption>

**Sensitivity:** If <driver> happens earlier / larger, central estimate moves to high estimate.

## 6. Threshold Analysis
### If utilisation reaches 80%
- Symptom: <e.g. occasional user-visible slowness, no hard failures>
- Lead time needed to remediate: <weeks>

### If utilisation reaches 90%
- Symptom: <e.g. consistent peak-time degradation, queue build-up>
- Lead time needed to remediate: <weeks>

### If utilisation reaches 100%
- Symptom: <e.g. service denial, hard failure, SLA breach>
- Recovery time: <hours/days from order to operational>

## 7. Scenarios

### Scenario A - Do nothing
- **Action:** None
- **Cost:** 0
- **Capacity head-room:** Runs out by YYYY-MM
- **Business risk:** <e.g. "User complaints during peak; SLA breach risk Q3 2026">
- **Verdict:** Not recommended unless <condition>

### Scenario B - Optimise first
- **Action:** <e.g. "Remove dormant accounts, archive cold data, compress">
- **Cost:** <figure, mostly staff time>
- **Capacity head-room:** Buys <N> months
- **Business risk:** <e.g. "Delays the decision but doesn't remove it; frees up <X%> that growth consumes in <Y months>">
- **Verdict:** Recommended as complement, not substitute

### Scenario C - Scale up (vertical)
- **Action:** <e.g. "Upgrade existing appliance to next size">
- **Cost:** <figure> (capex <X>, opex delta <Y> per annum)
- **Capacity head-room:** <N years>
- **Business risk:** <e.g. "Commits to current vendor; single point of failure remains">
- **Verdict:** <>

### Scenario D - Scale out (horizontal)
- **Action:** <e.g. "Add second unit, active-active">
- **Cost:** <figure> (capex <X>, opex delta <Y> per annum)
- **Capacity head-room:** <N years> + improved resilience
- **Business risk:** <e.g. "Higher ongoing complexity; implementation window required">
- **Verdict:** <>

### Scenario E - Replace / re-platform
- **Action:** <e.g. "Migrate from on-prem to cloud / newer platform">
- **Cost:** <figure> + migration effort
- **Capacity head-room:** Structurally different
- **Business risk:** <e.g. "Large-scale change; potential savings long-term; short-term disruption">
- **Verdict:** <>

## 8. Recommendation
**Recommended scenario:** <letter - e.g. Scenario C>

**Why this over the alternatives:**
- <Reason 1 - evidence-based>
- <Reason 2 - evidence-based>
- <Reason 3 - evidence-based>

**Trade-offs accepted by this recommendation:**
- <Honest list - shows the decision-maker we've thought clearly>

**What would change this recommendation:**
- If <trigger> happens, reassess and consider Scenario <X>

## 9. Budget Ask
| Line item | Amount | Funding type | Timing |
|---|---|---|---|
| Hardware / licences | <amount> | Capex | Q<N> 2026 |
| Professional services | <amount> | Opex | Q<N> 2026 |
| Ongoing support / subscription | <amount> | Opex | Annual recurring |
| Contingency (15%) | <amount> | - | - |
| **Total** | **<amount>** | | |

### Cost justification
- <Anchor 1 - e.g. "Current cost per user is X; recommendation preserves that">
- <Anchor 2 - e.g. "3-year TCO compared to do-nothing + emergency remediation estimate">
- <Anchor 3 - if applicable, savings or avoided cost>

## 10. Risk Register Update
| Risk | Current residual | If recommended action taken | If do-nothing |
|---|---|---|---|
| <Capacity breach> | <score> | <lower score> | <higher score> |

## 11. Decision Log (fill after meeting)
- **Decision:** Approved / Approved with changes / Deferred / Rejected
- **Approver:** <name>
- **Date:** YYYY-MM-DD
- **Conditions / changes:** <>
- **Next review:** YYYY-MM-DD

Example invocation

User: "/capacity-review - WAN bandwidth at our London HQ. Currently 500Mbps symmetric, we're averaging 310Mbps peak, 95p is 380Mbps. We're hiring 30 more staff over the next 6 months. Video use is growing about 10% a quarter."

What the skill will do:

1. Ask whether the WAN is a single circuit or dual-carrier, what the upgrade path looks like (contract terms, next-tier cost), and whether remote working split-tunnel policy is in play (affects HQ bandwidth growth rate).
2. Project: 310Mbps peak + 30 users x avg-per-user + 10%/qtr video growth -> 450Mbps projected peak within 9 months -> 90% threshold breach in <12 months.
3. Scenarios: do nothing (breach late 2026), optimise (split-tunnel policy, video QoS) buys 3 months, scale up to 1Gbps adds 12-18 months runway, scale out with SD-WAN adds resilience.
4. Recommend scale-up with a note that SD-WAN is the right 24-month answer - this buys time for the right design rather than a rushed one.

Notes for the requester

• Don't forecast from averages. Forecast from 95th percentile. Users experience peaks, not averages.
• Growth drivers trump trend extrapolation. A clean linear trend can be broken by a product launch that's already signed. Include named drivers.
• Always present "do nothing" honestly. The decision-maker must see the cost of inaction to value the cost of action.
• Name what you'd reconsider. A recommendation that never changes isn't a recommendation, it's a preference. Triggers for reassessment build trust.
• Cost anchors matter more than absolute numbers. "£60k" lands differently as "£20/user/year" vs "20% of annual network opex."
• "Good" looks like: the decision-maker approves or defers in one meeting, not three. The finance partner signs off without asking for a rebuild. Six months later, the forecast tracks within the low-central range.