This is a translated (and slightly modified) version of my article "Der Ball muss rollen!", which was published online at Projektmagazin in May 2014. If you prefer German, you can find the original article here.
Yet another sports analogy
Once I was with a company, where every conference room was soccer-themed. Not only were the rooms named after famous soccer clubs, but they were also decorated with "devotional objects" like jerseys, balls, pennants, etc. Of cours,e you would also find those funny quotes like "Soccer is like chess, only without the dice" all over the place.
I recall one meeting, where people were vividly discussing how effective software development teams should be set up. Probably influenced by the environment, I started thinking about soccer teams and what we could learn from them. Okay, sports analogies are not really new in software development, but let‘s give it a shot...
How (not) to manage a soccer team
Let‘s start with the composition of a soccer team. We‘ll find a goalie, defending players, midfielders, and of course the strikers. Looks trivial at first glance, because in order to win a match, there are "tasks" that need to be done in each of these areas. And obviously, a goalie needs completely different skills than a striker.
But wait a minute! If we think about it a little bit harder, we‘ll find an incredible waste of resources here! Even if midfielders support the defense every now and then and strikers fall back occasionally, it‘s very clear that all players are extremely poorly utilized! What‘s the ball possession of an average striker? Two to three minutes? And if we look at the goalie, it‘s even worse! It looks like he‘s just standing there and waiting for something to happen at least 99.9% of the time. Now think about the ridiculously high salary level of professional soccer players and you‘ll probably be close to a nervous breakdown.
Needless to say, that we as experienced project manager instantly understand the disastrous management we‘re dealing with here! If a striker is only needed, let‘s say, 30% of the time (we also calculate things like zone defence here), then why not have him play three matches in parallel? We would still have a 10% buffer if something goes wrong. Looking at the goalie, we‘ll find even more to optimize, because he‘s "needed" even less often. So he could easily play ten matches simultaneously. That‘s good, because our amateur teams are desperately looking for a better goalie...
Now let‘s take a quick look at the substitution bench! Here we‘ll find plenty of great resources that are not utilized at all. They are paid for doing nothing! So let‘s reduce the number of substitutes dramatically. How many of them do we really need? Three should be more than enough. All the others could be used way better outside of the bench: They could play in other teams, train our junior teams, give out autographs at the mall, etc.
How (not) to manage a project
All this is, obviously, nonsense! Nobody would even consider optimizing a soccer team in the way just described. But why not? Why exactly is it common in professional soccer teams to under-utilize extremely expensive "resources", while it scares us to death to do the same thing in knowledge work? One major difference lies in the fact that in soccer it‘s really easy to see the damage that‘s done, when a player is not at the right spot at the right time: the other team scores! In professional soccer, the difference between scoring a goal and allowing the other team to score, is probably worth a 6- or 7-digit number. Given this order of magnitude, who cares if a player is not fully utilized?
And a second point comes into play: In soccer, it‘s clear to everyone, that what the coach can do is to train the team and provide them with a viable strategy. What he can
not do, though, is to come up with a detailed plan for the whole match - or even the first ten minutes. If this would work, we could indeed create plans for every individual player, and we could even have them play several matches simultanously. The plans then would read something like: "At 15:53 pass the ball to player 8...At 15:57 prevent the ball from being lost on field 3...At 15:59 score a goal on field 2..." Of course it‘s ridiculous to even try this, because we know a soccer match is way too complex to even try to plan at this level of detail (1). And we all know that not everything goes according to our plan in a soccer match, and we have no chance of predicting what the opposing players will do at any time.
Comparing projects to soccer?
Let‘s summarize what we‘ve got so far: When it comes to professional soccer, we‘ve long accepted the fact that the high degree of uncertainty makes it useless to come up with detailed plans upfront. In addition, it‘s relatively easy to access the risk of a player not being at the right spot at the right time. This enables us to make reasonable trade-off decisions: How high are the costs of under-utilized players compared to the cost of a delay, because the team has to wait for a player, who‘s not ready to take-over the ball or block an opponent? In soccer, this cost of delay is so enormous, that dramatic under-utilization is accepted even for players who earn millions of Euros.
If we keep this in mind, perhaps the comparison to project work is not that absurd after all! Just as in soccer, in many projects we have to deal with great uncertainty, that often renders our beautiful plans useless. Also, in project work cost of under-utilization and cost of delay are factors that should be taken into consideration (2).
A fresh view on resource planning
Just to be clear: under-utilization of people and machines does matter, because it can lead to lost opportunities: When a highly skilled expert is idle, she might do something of great value elsewhere instead. That‘s the reason why it seems totally normal to us to come up with plans that make sure this person wil never be idle. What we ignore, though, is the fact that costs also occur when a project (or even a supposedly small milestone) is blocked, due to an expert, who is not instantly available.
If we would have more clarity on these two different types of costs, we would certainly make different decisions and our resource planning would appear in a different light. For instance, in some contexts it now might make a lot of sense to build and keep stable, cross-functional product teams, consisting of developers, testers, analysts and designers. There might be times when a designer or a tester is not fully utilized. But when she is needed, she will be there to help the team immediately (just like the soccer player when a ball is passed to him). This is a major advantage and solves a lot of problems we witness in our daily project work: low quality due to frequent context switches; rework due to long feedback loops; poor transparency on our project‘s progress, because all work packages are "80% done", just to name a few.
It‘s true in project work as much as in soccer: We must keep the ball rolling (3)! If we manage to do this, it‘s way less relevant, how many players are moving at which pace. This, by the way, is the difference between
resource efficiency and
flow efficiency: When we focus on resource efficiency, we make sure that everyone is busy; when we focus on flow efficiency, we make sure that we make progress on the most important tasks at any time. For several decades now, we only took resource efficiency into account. It‘s time to give flow efficiency priority now (4)!
P.S. I‘ve just learned that there‘s an old song called "Keep the Ball Rollin‘" by a band called Jay & the Techniques. Looking at the lyrics, I don‘t think the song has much in common with this blog post;-)
(1) Funny enough, I‘ve just finished reading the book
Team of Teams by General Stanley McChrystal. To illustrate one of his points, McChrystal
describes, how the coach of a fictional basketball team tries exactly
this level of detailed planning and fails miserably, despite the fact that the team comprises of
the world‘s finest athletes.
(2) For more details on cost of delay, look into
see the brilliant analyses of Don Reinertsen.
(3) The idea is not new, neither is explaining it with sports
metaphors:-) Years ago, Don Reinersen coined the phrase: "Watch the
baton, not the runner!"
(4) Niklas Modig brilliantly illustrates the difference between resource efficiency and flow efficiency in his book
This is Lean: Resolving the Efficiency Paradox and in
this Ted Talk.
_______________________
Like this post? Then you should check out my post Utilization as a proxy and my more recent post Seriously, what is a Pull System?