This morning got a email from a colleague asking about capacity planning which is not exactly the Candlestick Charting Applied R&D I had scheduled for today, but he has an active engagement I’m helping him on as I have cycles to spare during my search for a new role. It seems the more things change the more they stay the same. Maybe this is why I decided to write the book. I keep on getting asked the same questions about “How-to” –not in not in the academic sense– design an IT Organization or a Marketing Function or Consulting Group, etc. It seems despite all the literature out there, there appears to be not practical hands on it this arena or if there is its disguised as something else.
His question was “how-to” calculate resources for an IT Organization. Several years ago I built a calculator that did part of this on a smaller scale; a limited set of services. I had wanted to scale the methodology up; part of my reason for rejoining Microsoft. The approach is actually very simple. Most of the methodology high level design is in my SharePoint Saturday presentations on Slideshare. The basic approach is a derivative of ITIL/ITSM concepts using the modeling techniques I’ve used for the past 25+ years of engagements reengineering business processes and functions when I get called in to fix failed BPR projects — a lot more than these large corporations would like to admit to. Usually the failures can be traced back to other issues –which is a post for another time. However, occasionally the technical design of the function, process or group has been just a fantasy of moving boxes in the org-chart or a swag as to the resources needed. After it becomes apparent the restructuring hasn’t worked as planned, maybe for the 2nd or 3rd try, management reaches out to find someone like me that has successfully done this multiple time over the decade and doesn’t plan on making this engagement his/her retirement home. The difference between a corporate raider (Chainsaw Al) and myself is I’m looking at how to reuse and remission resources effectively rather than cut staff to the bare minimum. I see reduced resource requirements as new capacity to apply to initiatives that were past over during the previous budget cycle because they didn’t have the capacity. Enough management philosophy.
On the technical design approach, I start out with value streams and business processes which are supported by IT Services. I use a loose definition of IT Services that are a mixture of People, Processes and Technology, a little bit more that as subscription to a computer transaction capability. From this root I decompose the activities and transactions down to IT Assets (People, Processes and Technology) needed to support the activities. With a little modeling, predictive analytics, and simulation a fairly robust set of scenarios [scenarios as in Scenario Planning – Royal Dutch Shell] can be created to define the range of capacity needs. The can be then translated into a capacity model for IT Planning. I’ve presented concepts before to people who somehow thing this is all academic theory. 
However, had they spent time researching they would have found this has been done for years. During my days at IBM I create a lot of capacity planning models for customers to forecast mainframe utilization and growth. The basic logic works and continues to do so. I’m not sure why the consulting field does not pick up on this perhaps because is more quantitative and the field likes to give more qualitative answers. Below is a portion of a capacity planning spreadsheet I create several years ago for a SharePoint Shared Services organization.
Your second sentence is a very old French proverb. Very true in Government as well.