An important part of Capacity Planning is expectation setting up front.
Whether it be team or system, estimating capacity will always be wrong. It's literally a law, Hofstadter's law states "It always takes longer than you expect, even when you take into account Hofstadter's Law."
So the very first thing you need to ensure you do, is to over communicate that the estimates for capacity are estimates. It's a sad trap we've fallen into these days, to take estimates as commitments and not as what they are, educated guesses.
That is not to say it's just doom and gloom. There is a way to make it all work.
Even in my current role at AOL, where we are a full agile shop, I still call on my old PMI project management learning around "Order of Magnitude". The concept here is your initial estimates are likely to be no more than 50% accurate. So you don't just rely on the one estimate, you build on it with real data.
After the initial estimate, you plan contingencies based on that. Then you work with real data. For example, when building a product, the initial estimate will be 50% accurate (note: it will never be sooner. It's a 50% chance of hitting this date instead of a later date). Then you take checkpoints into the project and see how much work is really being done. One quarter of the way into the planned project time you see how much work has been done and then project out a release date with probably 60% accuracy. You keep doing regular checkpoints to see where you're going.
For capacity planning for a system, the first thing you can do is setup a virtual environment to test loads. This will get you an idea if the estimates were even close. Then you setup contingency plans to bring in more capacity as you ramp up your service.
This is why agile development cycles tend to work so much better. When you're checking in on your progress daily, you will see when things are going pear shaped a lot faster and be able to respond.
