How to estimate and plan product capacity?

Question

I'm new to project management and I have till now followed the standard textbook principles in building a particular product. I'm now at a situation wherein, I need to perform the capacity planning for this particular product. The product will be an external facing product (public) and expected to raise a good demand. We plan to launch in a phased manner in different markets. I'm clueless on how to plan the capacity for the same.

I understand that in terms of capacity planning, we need to look at cpu, memory, storage and network connections. But, how to estimate the demand for the product and how to concretize the same. Any leads on this will be helpful.

Answer 1

Capacity planning can mean two things - in Project Management it can refer to the work capacity that your team can handle, but elsewhere in IT it can refer to the load or capacity that your system can handle. It's easy to confuse the two.

If you are looking at the capacity your system can handle, then this is a question for your technical experts as stated by another poster. They should be able to provide estimations or maybe specific figures depending on the nature of the project.

However, your job as the PM is to focus on the phased rollout of the product and set a schedule according to both the needs of the market and the recommendations of your tech experts. Learning to partner with your developers or other resources will be key in your long term success as a project manager. Best of luck!

Answer 2

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.