New Webinar: Modernising Without Destabilising: How Bread Financial Is Building Confidence Through Change

Learn more

New webinar with Bread Financial

Learn more
Contact us

Capacity Planning

10 Mistakes Organisations Make When Capacity Planning

<span id="hs_cos_wrapper_name" class="hs_cos_wrapper hs_cos_wrapper_meta_field hs_cos_wrapper_type_text" style="" data-hs-cos-general-type="meta_field" data-hs-cos-type="text" >10 Mistakes Organisations Make When Capacity Planning</span>

Date 29 June 2026

Author Dr. Manzoor Mohammed

Capacity planning can be problematic for organisations who don't have experienced capacity planners. From our experience, these are the main capacity planning mistakes that organisations make. 

10 Mistakes Organisations Make When Capacity Planning

  1. Ordering hardware without understanding the existing utilisation
  2. Treating all CPU utilisation as the same.

    There are different types of drivers of CPU utilisation, e.g. 'hum', iowait, OLTP and Batch. I have seen people assuming the business is going to see a doubling of demand and assuming the CPU utilisation will also double. In this calculation they may include 'hum' and batch CPU utilisation.

  3. Including iowait in CPU utilisation when it is usable CPU capacity and excluding it when it isn't.
  4. Not understanding the workload characteristics before ordering new hardware.

    Sounds unlikely, however this does happen. I worked on an engagement some years ago where the organisation purchased brand new Blade servers for their application only to realise that their application was disk I/O intensive. The new Blade hardware didn't provide any increase in the disk I/O throughput capability.

  5. Forgetting about Moore's law when doing a hardware refresh.

    This is also related to the previous mistake. I have seen organisations doing a count of the number of servers for CPU intensive applications and then ordering the same number of new servers even when the new servers have a fourfold increase in CPU processing power.

  6. Looking at the busiest core rather than the average utilisation when setting a threshold for capacity utilisation.

    It’s quite common for many servers to have a core imbalances, e.g. linux, sql-server. In the case of Linux severs this can be because the interrupts are done on the core which is closest to the cache for that particular driver. As the server gets busier the load will be distributed over the remaining cores.

  7. Trending on short period.

    I have witnessed organisations who have tried to trend data on only several months' worth of data. In one case, the service was very seasonal. The volumes tended to drop over the Summer period before climbing back up in the Autumn.

  8. Using percentiles on summarised data.

    You can’t apply a 90 percentile value to averaged hourly service or component data. You’ll miss out the busy hour traffic for the week.

  9. Trending resource consumption for batch workloads.

    Batch workloads don’t increase in CPU utilisation over time – in general they just take longer as the transaction volumes increase.

  10. Treating all disk I/O as the same.

    There are different types of disk I/O operations. There is read – random, read – sequential, write – random and write – sequential.

To learn more about capacity management and how it can solve your capacity planning mistakes - download our capacity management primer

Introduction to Capacity Management

Dr. Manzoor Mohammed
About the author

Dr. Manzoor Mohammed

Manzoor co-founded Capacitas and pioneered its core principle and methodology – treating performance and cost as inseparable. His work has delivered quantifiable impact and value for clients, including Tinder, Qualtrics, Ancestry, and Cegid. He now leads the firm’s thinking on AI infrastructure, applying proven optimisation principles to a new generation of computationally demanding workloads.

FinOps and AI: Building the Financial Discipline for the Next Wave of Enterprise Intelligence

AI FinOps represents an evolution rather than a replacement of traditional FinOps. It extends the model into a domain where financial, technical, and product decisions are tightly interconnected.

Read insight

Confidence Under Load: How We Verified AKS Readiness for Peak

How Capacitas verified AKS readiness for peak demand by validating workload performance, autoscaling, cluster capacity, monitoring, and incident response.

Read insight

Building Cloud Resilience: Lessons from the AWS Outage

Learning from the Latest Outage. Events like this week’s AWS disruption highlight one clear truth: resilience must be designed, not assumed.

Read insight

Bringing Order to Chaos: A Practical Guide to Chaos Testing in the Cloud

In today’s cloud-native environments, resilience is not optional—it’s critical. Chaos testing has emerged as a key practice for validating system behaviour under failure conditions.

Read insight