The Beer Game: When Delayed Feedback Derails Your Decisions
You make a decision today – but the consequence doesn't show up for weeks. Meanwhile, you've made five more decisions, all built on outdated information. That's how some of the most stubborn problems in projects arise: overreactions, oscillations, and panic fixes that make the very thing they were meant to solve even worse.
Few have demonstrated this as clearly as John Sterman at the MIT Sloan School of Management. In a famous 1989 study, he had people play the so-called Beer Game – a beer distribution simulation – and analyzed why even sharp, motivated people make systematically poor decisions when feedback is delayed.
What does the research say?
In the game, each participant runs one link in a beer supply chain: retailer, wholesaler, distributor, and brewery. Each link orders from the one behind it, and deliveries take several rounds to arrive. The task sounds trivial: order just enough so that inventory neither runs out nor grows needlessly large.
The result is anything but trivial. A small change in customer demand gets amplified back through the chain into wild swings – first everyone orders too much, then everyone sits on mountains of unsold beer. The phenomenon is known today as the bullwhip effect, because a small movement at one end becomes a huge swing at the other.
Sterman's most important contribution was the explanation. Participants systematically misjudged the delays: they forgot to account for what had already been ordered but not yet delivered. When inventory dropped, they ordered more – and more again – until all the old orders suddenly arrived at once. He called the pattern misperceptions of feedback: people are simply bad at managing systems where cause and effect are separated by time. It's not a knowledge problem but a thinking error that affects almost everyone, including experienced decision-makers.
What does this mean for you as a project manager?
Projects are full of delayed feedback. You staff up today, but the effect shows up in two months. You skip a review now, but the defects surface in the test phase. Before you react to a deviation, ask yourself what's already in the pipeline. Which decisions have you made whose effects haven't yet had time to appear? Often the right action has already been ordered – it just hasn't landed.
Be suspicious of your own impulse to do more when things look bad. Sterman's participants made their problems worse precisely by acting forcefully on old numbers. A small, early adjustment almost always beats a big, late one.
Make the delays visible to others. When the steering committee wants to see quick results from a decision, explain how much time the system actually needs – otherwise you risk piling action on top of action until the overcorrection becomes the next crisis. A simple trick is to always present two things side by side: what has already been decided but hasn't taken effect yet, and what is being proposed on top of that.
How to practice this
Systems thinking can't be learned from reading alone – you need to feel it hands-on, just as in the Beer Game. Project-simulator offers scenarios built on the same principle: your decisions today have consequences that only appear several moves later, and in the debrief you see exactly where you overreacted to delayed information. Try it free for a week and train your eye for what isn't visible yet.
In Project-simulator you practice these conversations against an AI counterpart and get feedback grounded in research like this.
Try free for 7 days