How do you do capacity planning?

The biggest issue that most development organizations face is deciding what projects to do and what projects not to do. A large part of this process is doing resource capacity planning. It is relatively straightforward and easy to do but is often overlooked.

So here are the basics:

• Determine the projects you want to consider
• Roughly size the effort per first line group per month
• Treat bugs and other overhead issues as projects
• Make priority decisions

The majority of the list of projects comes from product management. They collect requirements from multiple sources including standards, customers, sales, etc. Make sure these stay at the functional level. The projects should be complete solutions you deliver to customers or internal infrastructure projects. Stay away from listing components of a solution as projects otherwise you stand to not invest in all of the pieces that are required to deliver real functionality to customers.

You need to make rough estimates for the identified projects by group by month. This will let you know (or get close to knowing) whether you have the right skillsets to accomplish the projects. Check out the blog entries on schedules to see how to come up with numbers. Limit the time people spend on the rough sizing (do not go and create full schedules). You will build this skill iteratively. Set your sites on being aggressive but accomplishable.

Teams get in trouble by not legitimizing the time they spend on items like bug fixing, estimating, standards committees, vacation, etc. You should make the bigger efforts like bugfixing actual projects. You can create a miscellaneous or overhead bucket for smaller items. Allocate real time for these projects.

Once you have the data, you have to make some decisions. Do not allocate much more that 100% of your capacity (and less if possible) because you will run into unknowns and you need some flexibility. You can run people harder for short amounts of time but it is ineffective to do so for long periods of time. You must learn how to say no to some projects. Pick fewer items and spend more on them and finish them as opposed to work on lots of things at the same time -- context switches are expensive and you should attempt to not have people work on many projects simultaneously. Have a strict ordering for projects and releases so your team knows how to make tradeoffs.

Without planning your team will get frustrated and your customers will lose confidence. So plan and gain confidence of your team and customers!

More later ...