Demanding

To paraphrase Tolstoy “All successful Supply Chain teams look the same. All struggling Supply Chain Center of Excellence (COE) teams suffer in their own unique way.” One problem I’ve seen many times is a successful Supply Chain COE team, one which is successful in strategy, process optimization, streamlining – “transformation” – tends to have demand which very quickly outstrips their ability to perform work. Our team at HP grew in demand from 4 to 10 to 20 to 200 (sound of a faint explosion in the distance). Even with a well-performing team of 10-20 people, before there was a huge demand, we struggled with one critical thing: planning.

What is “planning” for a COE teams? First, let’s answer the question “what’s planning”. Most people confuse planning with scheduling. Scheduling is determining a set of tasks with fixed start and end dates, and potentially allocated resources to each task. Planning is looking at a set of goals or demands and identifying how they will be achieved, for example what resources are needed. Kind of like scheduling, but without the calendar. Planning usually (in fact always) has four processes: what is a demand on a resource (Supply Chain Issues), what is the supply of resource (COE Team time), what is the balanced relationship between the two (for example a “year plan”), and what is the communication of the balanced plan.

With this simple model, how did we go about planning the COE team? First we looked at what the demand looked like over a year – how many COE projects of various sizes were likely to hit us. We also segregated the demand by function – supply chain, sales, design… Since we were starting out, we were quite conservative. Based on experience, we also had certain assumptions about average size (time) of a project based on the business scope. That gave us a “raw demand” picture for the Supply Chain COE team. Think of it as “number of team days” of work – we looked at roughly 3 months per project on average, 3 people per project, and 10 projects per year = 3x3x10 = 90 people/months per year. At 70% utilization in time, that becomes 128 people-months, or 10 people working continuously, 3-4 in each focus area. We communicated this plan, and our sponsor (HP’s former CIO Bob Napier) gave us the budget.

This worked for a while (year 1 of our team). In year two, we came to a deep understanding that not everyone was interchangeable. That’s when we looked at the specific model of a team doing projects, and identified four key roles, and assessed how many people we had who had capabilities in those roles – leader, modeler, analyst, and program support. You don’t need an analyst for an entire project, nor a modeler. You do need leadership and program support for an entire project. Not everyone could be an analyst. Everyone could be a modeler. This gave us immediately a more sophisticated planning view. We also knew we had a more significant demand on our second year, with more than 20 major programs heading our way. We had so many “analyst months”, and so many “modeler months”, and so on. Suddenly we didn’t have enough people, and not enough of the ‘right people’. Furthermore, the variability of the projects (they overlapped messily!) meant we needed lots of resource sometimes, and very low numbers other times. Just like manufacturing!

We took two actions: first, we established a base of contract modelers through an agency who were trained in our frameworks and process tools (which would become incredibly helpful later). Second, we established a base of contract program managers through a second agency who were trained in our methodology and standard program schedule and tools. Our core team was then established as the lead, and lead analyst focus for all projects. We were able to handle all projects very flexibly through the second year, for about 6 months. But demand kept ramping up up up! Our team took over Sarbanes-Oxley 404 compliance for HP, which blew demand up to dozens and dozens of process modelers, and several program managers. Second, the high variability in the size and scope of programs kept increasing, and teams were fighting each other for resources.

The final adjustment we made was to differentiate resource plans based on the average sizes of programs instead of functional area. We called them “Unit specific”, “Strategic”, and “Corporate” programs which had size rations of roughly 1:2:4 in scope and resource demand. Supply Chain, Sales, and Design programs we ignored, because we found in practice that our teams were in fact interchangeable across domains. Not process skills. Within 2 months in the final planning adjustment the team resource fighting ceased, and we formed a nice balance with the demand we experience. Happily, we also got more budget again from our sponsor.

Then we began to enter year 3, and our demand increased 10x over the prior year. At that point, the team began absorbing all independent process individuals and teams across the company – Six-Sigma, process improvement, and so forth. The team grew to over 40 people, and then grew again. We developed a team in our India consulting organization. We developed a second team within our services division of over 100 people globally to provide some support to internal projects. It was a monster! It was the COE Team that Ate Tokyo! Godzilla vs COE was up next. We were way beyond our original sponsor base at this point of staffing, and were managing a large, complex global staff. But planning fundamentally was the same: whom we communicated with began changing.

So back to earth and some simple ideas from our experience in creating teams:

First, and foremost: Over and over I’ve seen that you need to plan on roughly ½ of 1% of total revenue as a budget for Supply Chain Research and Development, with the COE as a focal point. Whether it’s a distributed COE (like ours was), or a massive central supply chain organization, it doesn’t matter. The most effective organizations seem to have roughly that ratio of spend on continuous supply chain improvement to revenue.

Second, for detail planning:

For small teams (1-10) it’s easy to plan your staff base with an assumption that most people are interchangeable (usually true in small teams).

Fig. 1: Small Team Planning

Fig. 1: Small Team Planning

Where P = Number of Projects projected for year

Psize = average size in a time unit (day, week, month)

Pstaff = average staff per project

Util = average time they can spend (70% is a norm).

For middle size teams (10-30), you should probably look at numbers of people per resource type, because you’re probably hiring by differentiated skill set. You could also add a factor for variability in the starting time of project (difference between low and high demand) but I’ll keep it simple.

Fig. 2: Medium Team Planning

Fig. 2: Medium Team Planning

Where P = Number of Projects projected for year

Psize = average size in a time unit (day, week, month)

Pstaff = average staff per project

Util = average time they can spend (70% is a norm)

skill = each of your team skill sets (analyst, lead) etc.

For large teams (40-200+) with a complex mix of BPM program sizes, you need to add a final variable, which is the number of people per program types.

Fig. 3: Large Team Planning

Fig. 3: Large Team Planning

Where P = Number of Projects projected for year

Psize = average size in a time unit (day, week, month)

Pstaff = average staff per project

Util = average time they can spend (70% is a norm)

skill = each of your team skill sets (analyst, lead) etc.

     type = each of your defined project size categories.

This is all a bit overkill, and was what my team used to do detailed planning for growth, but I can’t tell you how often over the years I have had calls from successful organizations, in a panic, who have a sudden spike in demand for supply chain improvement skills – “Hey, how many people worldwide do you know have SCOR-P certification!” Plan, ahead for big demand for successful organizations!