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 ...

How do you make progress on your roadmap in the face of firefighting?

This is an ongoing question from the moment that you have a product and even a prospective customer. Real-time requirements for assistance, demos, features and bugfixing are common diversions for many engineering groups. So how do you handle this natural competition for resources?

The first thing you need is a roadmap. Without clear plans and goals you won't even know what you are not doing. Time can slip by easily in fire-fighting mode and along with it market opportunities.

The next thing you need is a budget. You need to legitimize the time spent on diversions from the roadmap. Do not expect your developers to handle a full development load along with a second development load for bugfixing. Another key to successfully managing resource competition is to firewall resources for new development (see Christensen's 1997 book The Innovator's Dilemma).

The next thing you need is some process. Decent schedules which represent all of the activities engineering is responsible for is a must. If new opportunities arise, do not assume the team can just lump more work on. I like schedules to be aggressive but accomplishable -- where the key word is accomplishable. Put a process in place that allows for change. If a new feature is needed, will you fund it with new resources, re-target resources working on some of projects, etc. ? Outside influence can begin to look like a fire-fight. Changing directions too often will be inefficient and depress developers.

Finally you need leadership. Understand your team's capacity. Understand your company's financial and competitive situation. Aggressive but accomplishable.

More later ...