Capacity Planning on the Cheap
Master operational capacity to scale your product development throughput
My business supports a diverse portfolio of clients from the Tech, Media, Manufacturing, and Pharmaceutical industries. The operational realities across these industries can differ substantially based on maturity, regulatory burden, and culture. Invariably, however, every product development org I walk into shares at least one challenge in common: Capacity Planning at the Executive Roadmap level.
Executive Roadmap Capacity Planning
Before we dive into the HOW on this solution strategy, let’s get together on the WHAT. When I say “Executive Roadmap Capacity Planning” I’m talking about planning that occurs below the level of enterprise strategy, but above the detailed execution through which the products actually come to life.
This is a critical juncture, at which planning turns the corner from aspirational to practical. Or at least it should. In my experience the conveyance of the Executive Roadmap down to the organization tasked with its execution is rarely endowed with adequate practical capacity analysis. The result is a C-suite constantly disappointed with the output of their product development team, and team members forever crushed by impossible expectations from the C-suite.
The result is a C-suite constantly disappointed with the output of their product development team, and team members forever crushed by impossible expectations from the C-suite
What follows is a basic methodology I have customized to help fill this gap.
IMPORTANT NOTE: Offerings from Planisware, Oracle, and other enterprise vendors are specifically engineered to address these needs — plus many others — at scale. If you have access to those tools, consider yourself lucky and get cracking.
However, for those of us who do not have those tools available, or who choose not to integrate planning data to the depth those systems demand in order to answer these questions, alternatives do exist.
For this example, I will be using Microsoft Project. This tool has been chosen for its powerful Resource Leveling functionality, and because it is easy to bastardize to get this job done. If you hold a PMP certification and recall the “forward pass” and “backward pass” math from your trusty PMBOK, you know Microsoft didn’t invent these concepts. They did, however, package them in a way that easily and inexpensively meets our needs for for this exercise.
I recognize that MSProject isn’t considered ‘modern’ in an Agile world. If you have walked away from this tool for that reason alone, you are missing out on a ton of powerful functionality. I’ve been running Agile projects since 2007 and freely pull from the Waterfall toolbox all the time to help my teams get where they need to go. You be you.
Critical Questions to Answer
This Capacity Planning regime creates a medium-high level model intended to answer the following questions in a transparent and visual manner:
- What is the list of products, provided in stack-ranked prioritized order, the enterprise aspires to construct?
- Who are the teams involved in construction of those products, including coarse volumes of capacity?
- What is the expected duration for each product build?
- What is the breadth and depth of resource engagement expected to be necessary to complete each product? How far can I stretch my workforce across this project portfolio?
- Based on a comparison between available resource capacity, resource requirements of each product, and the interplay of all products in the portfolio against each other, when can the execution of each product build be expected to occur?
Solution Components
The Capacity Planning regime described here requires five critical components:
- A backlog of desired products, provided in stack-rank, prioritized order
- Granularity-appropriate, high-level inputs about the capacity of each team to complete simultaneous work
- A Capacity Planning model, in this case utilizing MSProject, through which this information can be brought together for review, analysis and experimentation
- A team of leaders empowered with the knowledge and authority to speak definitively about expected duration and resource engagement to complete each product
- A regularly recurring cadence through which the Capacity Planning team gathers to review/update the existing model, a well as providing necessary inputs to absorb new incoming demand into that model
Bootstrapping Capacity Planning
This section describes the basic steps in my own Capacity Planning solution. It assumes a cold start with no prior information available. Once the team has moved through this cold start, maintenance of these materials becomes much more streamlined.
As a medium-high level model, this Capacity Planning regime does not track activity at the granularity of individual resources, tasks or tickets. Instead, each product build is represented by a single summary row on the Gantt chart, displaying target Start Date, Duration, and End Date
STEP 1: Defining Teams
A logical first step is to define all teams involved in construction of any/every product in the backlog.
Once the teams have been defined, high-level capacity must be provided for each. There are several ways in which capacity can be represented. Past experience with this model suggests that the most flexible is as a raw count of resources.
Note in the screenshot above, in red, the rough designation for the number of resources available on each team. This is critical for the calculations to come.
This approach, and the target granularity of this model, does not account for the differing strengths, skillsets, or specific expertise of those human resources. In order to create and maintain a model that operates at the desired level of detail, and provides information actionable to its chosen audience, this information is considered below this model’s operating granularity. We’re not thinking at the level of individual resources here, we’re focused on the capacity of teams.
STEP 2: Stack-Rank Prioritized Backlog
As discussed above, this model demands that prioritization be represented via a single stack-ranked list of desired products. Stack-ranking looks like an easy exercise until you’re the guy charged with juggling all those competing needs to get it done. While generating that list may be difficult, it is essential in support of this planning model. As a bonus, it also represents excellent business hygiene
STEP 3: Product Durations, Dependencies, and Effort Estimates
Arguably the most critical part of the process, the Capacity Planning team must, based upon whatever information is available, provide a high-level estimate of total duration for the product build. This is also a good time to model the dependency relationships between the products, themselves, as well as any internal or external constraints.
Once this has been provided, the Capacity Planning group must generate high-level estimates for the engagement of resources across teams throughout the life of that build. For example:
Note in the screenshot above, in red, the rough allocation of resources from across teams to this product build. This is critical for the calculations to come.
STEP 4: Resource Leveling
The magic happens when MSProject runs the arithmetic to compare resource demand, identified for each product, against available resource capacity. Based on this analysis, MSProject automatically repositions projects across time based on availability of necessary resources.
What this means in practice is that, based upon current prioritization, that product you had hoped for at end-April may not actually be available until the last week in May. The benefit of this approach, as coarse as it may be, is that it allows leadership to understand and contend with these scheduling constraints right away.
Note the red arrows in the screenshot above, representing specific product builds that are pushed out from original timeslots based on the resource leveling arithmetic
THIS IS THE PAYOFF. That resource leveled Gantt listing each initiative on the roadmap, calibrated to represent reasonable start and end dates based on team capacity, is the intelligence all of this effort begets.
Congratulations. Now the hard work begins.
“Let’s Make A Deal…”
When this Capacity Planning analysis spits out a narrative that is unacceptable to leadership, we have a few switches to throw in hopes of finding a more favorable outcome.
Reprioritize Products in the Backlog
The Capacity Planning model is configured to apportion resourcing against the products in the backlog in a top-to-bottom fashion. That means products at the top of the list will gobble-up the resources they need, leaving fewer available for those products lower on the list. When that scenario occurs, the model automatically delays start of each product build until all necessary resources are available.
The easiest way to adjust the model to create an earlier start date for a product that has been bumped by the resource leveling arithmetic is to move that product higher in the backlog. Of course, the stack-ranked prioritization methodology demands that for one product to move up in the list, another must move down. There can be only one product at position #1, one at position #2, one at position #3…
This practice represents not only a requirement of the Capacity Planning regime, but strong business planning hygiene. The fact that it can be so damned difficult to get a leadership team to coalesce around a single prioritized order isn’t a defect of this process, its a feature. Better the leaders thrashing through this labyrinth of competing needs than leaving the line resources to try to figure it out on their own.
The fact that it can be so damned difficult to get a leadership team to coalesce around a single prioritized model isn’t a defect of this process, its a feature
Adjust Scope of Individual Products
The duration values associated with the products in the model are based on the perceived size and complexity of each. In order to shorten the duration of a specific product build, it may be possible to adjust the size, number, or complexity of the features therein.
Thus, a product build that had been previously scoped to include twelve features and estimated at 8 weeks duration may be feasible at 4 weeks duration if only half of those features are included.
A useful technique is to break a larger effort into sub-products, each represented at its own position on the backlog and its own bar on the Gantt chart. Each of these sub-Products can be scheduled based upon the deadlines of its internal features, allowing space for other products to be addressed in between.
Examine Dependencies and Constraints
Resource availability is not the only factor in determining when product executions will occur. Two others are dependencies and constraints, both of which can be internal or external in nature.
Dependencies: There may be a relationship between two products in the backlog through which Product A must be completed before Product B can be initiated. There may also be scenarios wherein multiple product builds must begin at the same time, meaning none can initiate until all are ready.
Constraints: Constraints represent schedule impacts that are not dependent in nature. For example, there may be a moratorium against work on a platform due to a critical update, or as a risk mitigation over a holiday break. A platform or technical tool may become unavailable as of a certain date due to a contractual limitation. A product may be targeted for release to coincide with some event in the physical world, such as a trade show.
Examining, analyzing, and adjusting dependencies and constraints can be a useful way to tweak the model in order to gain more positive outcomes.
Engage more Resourcing
In _some_ cases, it may be possible to increase team velocity by engaging additional resources. Based upon the granularity of representation of different teams within the Resource Sheet, the model can provide useful insight into which teams are experiencing the greatest contention within any time period. Armed with that information, it may be possible to increase resourcing in a strategic fashion in order to gain the most speed-per dollar.
CAVEAT EMPTOR — as we all know, the engagement of resourcing, either FTE or consultant, is not a seamless process. Searching for, engaging, and training new resources comes with its own opportunity costs, none of which are particularly well represented in this project-focused model.
Given adequate lead time and the right circumstances, however, this model can help the enterprise to recognize resource bandwidth shortfalls with adequate lead time to address them in a calm, diligent fashion.
Truth First, Truth Always
It goes without saying that where all these mitigation strategies are concerned, alignment with truth is critical. The model only remains useful as long as its attributes are true representations of the feasibility, behavior, and engagement of resources in the real world.
It is easy — and dangerous — to twist the model into a narrative that is pleasing to leadership yet infeasible in reality.
Limitations of the Model
There is much to love about the Capacity Planning model presented here, but it isn’t perfect. A few known limitations are presented below. Most of these are not unique to the specific modeling strategy being presented here, and are a byproduct of many modeling regimes.
Coarse (for speed and flexibility)
In order to remain lightweight, flexible, and easily understood, this model exists at a relatively coarse level of detail. More granular detail is possible, but makes the model more clunky and difficult to interpret. The level of granularity described herein represents a ‘sweet spot’ between accuracy of detail and ease of use. When you apply this model in your own shop, you’ll find the sweet spot that meets your own needs.
All the Resources All the Time
One example of the limitation of this coarseness is in the allocation of resourcing to the individual products in the model: all resources are represented as involved in the product build during its entire lifecycle. This model provides no notion of resources rolling on/off a product build across time.
From an Agile perspective this may be considered a benefit instead of a drawback, as Agile espouses engagement of the complete multidisciplinary team throughout the entire product build lifecycle. However, not every enterprise operates that way. When resourcing gets tight, this limitation can have outsized importance.
As above, you can further complexify the model to meet this need. But you do so at the cost of speed, flexibility, and ‘at a glance’ interpretation. For me, this ‘all resources all the time’ structure works just fine for the Executive Roadmap level, and any associated discrepancies can be managed via the more detailed planning processes lower on the hierarchy.
Garbage In/ Garbage Out
Any model is only as good as its inputs. In order to maximize the value of the Capacity Planning regime described here, all involved stakeholders must be enthusiastically engaged and willing to provide best-possible estimates around duration and resource allocation based on limited information.
Leaders who are unwilling or intellectually unable to provide these services will erode the efficacy of the analysis. The utility and speed of the model break down when leaders fall into the “I don’t know enough to provide those initial estimates” trap. Providing services like these is simply the right and responsibility of modern technology leadership. We’re not etching anything in stone, here. We’re trying to gain directional guidance.
Shatter Under Pressure
This regime represents a three-dimensional model of an actual scenario with hundreds of variables. That doesn’t make the model useless, it just means we need to understand the level at which it operates most effectively.
Playing the “What about this detail? What about that detail?” game with this model will cause it to quickly shatter. The model is intended to provide a limited representation of reality, not encompass all of reality’s variables. A clear understanding of this model’s target granularity and the role it is intended to play in enterprise planning is critical for its effective implementation.
In return for that investment, we gain mastery over our Executive Roadmap and ensure that all downstream activity is informed by a well-calibrated understanding of actual team bandwidth.
Manual Engagement
Engagement of the Capacity Planning regime as described here really requires a ‘czar’ resource who owns the MSProject files, quarterbacks collaboration, and manages socialization of associated planning/change across the enterprise. This model can’t run on autopilot. It requires thoughtful and creative engagement by busy leaders in order to remain accurate and useful over time.
The Fast & The Flexible
Why bother with all this effort? To ensure that, from the moment we depart the aspirational brainstorming portion of the planning process, our expectations are calibrated to match our means. Why waste valuable leadership energy pining for a rate of delivery that is infeasible in our current situation? Instead, let’s challenge our leaders to make the difficult prioritization decisions necessary for the team to to focus on the products with the greatest benefit to our enterprise.
Why waste valuable leadership energy pining for a rate of delivery that is infeasible in our current situation?
We already have strong tools and processes for planning at the portfolio and sprint levels. But if we don’t force leadership to calibrate its expectations at the level of its Executive Roadmap, we’re already putting our people in the pressure cooker by the time those parts of the planning hierarchy roll around.
This methodology does not purport to solve all planning problems or provide automated traceability from the strategic level down to tickets and resources. If that is what you need, go buy Planisware.
Instead, this homespun approach is focused is on being cheap and fast to implement, while providing a flexible mechanism to model different scenarios so leadership can find the best path.
Whether you utilize my own hacked-together solution presented here or some spreadsheet, post-it note, and abacus-based monstrosity of your own design isn’t the point. The point is to put some capacity-aware mechanism in place way up at the top of the planning hierarchy where leadership assumptions and expectations are born.
It may seem counterintuitive that the best way to scale your team is by establishing a quantitatively-derived ceiling for the amount of work the team can metabolize. But that is the truth. If you want to hold on to the best resources and provide them with the breathing room they need to build with quality and creativity, throttling the demand from leadership to match actual team bandwidth is essential.
Originally published at https://www.linkedin.com.
