Partner Article

Principle #5 of capacity planning: Tolerance for incomplete data

The first four Principles of Capacity Planning start us on a planning journey to run a business more effectively. Here are the topics we’ve covered so far:

• The Team as the Resource Unit
• Getting forecasting efforts Roughly Right
• Matching Supply to Demand
• Using a Continuous Planning Cadence

This post addresses the value of tolerating incomplete data in portfolio planning—a principle that applies to both demand and supply. Here are some specific examples for each.

Demand Tolerance: Detail Initiatives Only As You Get Close to Scheduling Them

When we plan out 12 to 18 months, we’ll make decisions on less-accurate data than we’ll have for, say, the upcoming quarter. In other words, we’ll be less certain as our planning horizon moves farther into the future.

Experts and highly competent professionals strive for perfection. Big planning mistakes have ruined careers. Yet to be successful, leaders must make decisions using imperfect information. Strategic planners have to navigate uncertainty and risk as investment scenarios become plans of record. To have a reasonable chance of success, we must know something about the investments we select to execute on: the rest of the information is either knowable or unknowable. There is a huge cost associated with gathering this knowledge. On the other hand, tolerating incomplete data is no excuse for ignorance.

A prominent, former presidential cabinet member advised that you not take action if you have only enough information to give you less than a 40 percent chance of being right; but that you shouldn’t wait until you have enough facts to be 100 percent sure, either, because by then it’s almost always too late. This instinct is right: excessive delays in the name of information-gathering leads to analysis paralysis. Procrastination in the name of reducing risk actually increases risk. For example: one Fortune 500 organization was spending so much time to have 100 percent of the decision-making information that its approval process took years—longer than the time required to implement the approved projects and programs.

When applied to an annual cadence, expect to be on the low end of this information-gathering range (around 40 percent.) At this point you’re planning at more of the initiative level, maybe with some features identified. With roughly right estimates, we will set ourselves up for more accurate near term plans. Within a quarter, I expect to be closer to 70% because I should have more complete information. As you embark on continuous planning cadence, the ability to manage uncertainty becomes much more tolerable because you know you will have the opportunity to inspect and adapt at more frequent intervals. In today’s fast-paced world, the cost of delay can be so high you have no choice but to get comfortable with operating on good-enough data.

One of the proven benefits of Agile software development methods is that you can adapt to necessary changes in schedule and priorities, and avoid the misalignment of scheduling work far ahead of execution. In a continuous planning cadence, annual planning becomes part of long range business commitments, forecasting and budgeting, while scheduling becomes part of rolling wave prioritization and value delivery.

Ironically, traditional sources of guidance support the notion of tolerating incomplete data. According to PMBOK, “A Planning Package is a work breakdown structure component below the control account with known work content but without detailed schedule activities.” Each organization should determine its policies for when it’s feasible to refine details and schedule them. Our experience shows that this planning horizon for prioritization and value delivery in today’s fast-paced world is about one quarter (three months.) With these rhythms, we can get better at operating on “good enough” data.

Supply Tolerance: Fuss Only When You Must

When working with large customers, we’ve found that most managers have been burned by failing to pay attention to the scarce capacity of specialization areas. Examples include UX designers and DBAs, as well as expertise specific to a company technology environment, such as network or security engineers. The cost of not accounting for this scarcity of talent is an overly optimistic plan that does not match the reality of what can be delivered. This is one criticism of Agile methods to-date: they lack a good approach for handling exceptions to cross-functional teams.

The key to tolerating incomplete data is to plan at the delivery group level and, if necessary, the delivery team level. This respects the principle of the team as the resource unit and has the added advantage of simplifying the capacity planning exercise by a factor of 10 (roughly assuming 10 individuals per team.) Only when planning at the team level isn’t roughly right do we fuss more, usually because of the need to pay special attention to scarce expertise. Because managing expertise adds overhead to matching supply to demand, the goal is to fuss only where you must!

How do we fuss just enough? Let’s take the example of a fictitious company that has both retail brick and mortar stores and a successful online presence. Initially, this organization had a platform delivery group that provides all the backend services. Every other delivery group was dependent on the platform group. With so many dependencies, managers were constantly scrambling to remove bottlenecks and resolve schedule conflicts. The solution was to distribute the platform delivery group onto several of the other delivery groups so they could be made “whole” (each group had what is needed to deliver value with minimal external dependencies.) By designating “platform” as an expertise, and just a little extra fussing to account for platform constraints, we can match supply and demand and have better results.

Roles and Expertise

Expertise can be used to support flexible resourcing. Take, for example, an organization that has several delivery groups, with some aligned to specific products. Most of the time, each delivery group is self-sufficient in delivering their allocated work. When there’s an unusually high need for a given expertise, the delivery group can be augmented by providing additional capacity from other delivery groups for that expertise. One customer told us, “We rob teams from Peter to pay Paul all the time in order to deliver maximum value.” Expertise should only be fussed with when we must.

What about roles? Modern capacity planning strives to use role as an attribute of a team. Applying roles to teams helps identify team competencies and provide convenient capacity planning building blocks. A team’s role can be thought of as expertise. Although we value teams over individuals, we recognize that individuals are the basis of great teams (it’s commonly cited that a good programmer can outperform a mediocre one by a factor of 10.) When the team is the fundamental planning currency, the need to fuss about the roles of individuals diminishes. Thus, resist the urge to track capacity of individual roles within each team. For planning purposes, this would be artificially precise (read more about the capacity planning principle of “roughly right.”)

This blog rounds out the five principles of modern capacity planning that should help you have a less dreadful annual planning season.

This was posted in Bdaily's Members' News section by Rally Software .