We all know about firefighting – spending unplanned time and resources on unanticipated problems. We’ve all been there, done that – the back end of many projects seems to consist of nothing more than one fire after another. We all know it’s a Bad ThingTM – there’s any amount of research showing that having a plan, following it, and doing the upfront homework to avoid back end disasters pays off. So why is it so difficult to avoid?
I’ve just run across a series of papers by Nelson Repenning at MIT which go some way to explaining why. Repenning uses system dynamics (the application of control theory to social systems) to model organisational processes. One of his models [44, 45] looks at what happens when we balance tasks between multiple projects according to urgency (i.e. put all the effort into the project that’s about to miss its launch date). It’s a very simple model – pulling resource to firefighting on the current project takes them away from upfront tasks on the next project, which means that you’re more likely to need to firefight on that project, and so ad nauseam – but what it shows is an eye-opener, to me at least: it’s a bi-stable system.
In this model, a temporary shock to the system, – such as an unexpectedly difficult project – either results in a bit of a panic followed by a return to business as usual, or, if the shock is large enough, causes a permanent descent into a state of ongoing firefighting which spreads across projects. To get back out of the permanent firefighting mode, you need to apply a large shock in the other direction (i.e. a big dollop of extra resource or time). The less resource slack you have in the business-as-usual mode, the less of a shock it takes to get you into permanent firefighting, and the more of a shock it takes to get you out.
Repenning & coworkers have also modelled the descent of a system into disaster due to the effects of interruptions and stress [46], and shown that random variations in workload can combine with the effects of stress to drive a positive feedback effect that causes the system to collapse. Sound familiar? The case he’s actually looking at is short-term crises such as air traffic control or miltary situations, but I think the inverse-U shaped stress/performance curve which drives this model is probably similar to what you get in a project environment by combining the effects of labour flexibility (overtime), time pressure, and multitasking effects – I’m going to try modelling this myself and see if I’m right.
The other interesting thing about these papers is the discussion of what can be done about it. Repenning points to studies which show that people consistently screw up when asked to manage nonlinear systems with big delays and tradeoffs between short-term and long-term consequences, and argues that reactive practices just won’t work: a “fire-resistant” PDM system must involve leading-indicator based resource management and a fierce determination to have and protect a healthy degree of slack. In pursuit of the latter, he advocates a strict and non-negotiable project cancellation policy at the concept-development boundary; if it’s late or inadequately developed at that point, it dies, period.
The resource management system from hell I think is an interesting possibility for small businesses – when the number of people and the number of projects is relatively small, it seems within the realms of possibility to keep close enough track on what everyone’s doing to see firefighting building up before it hits crisis point. Requires some sort of reporting system that’s low enough impact that people will be prepared to use it though.
And as for slack, there’s any number of reasons to think it’s a good thing – for a list of them read Tom De Marco’s book. Getting and keeping it are a different matter though. I like the idea of a hard rules-based system for preserving slack; I think the chances of getting the players to agree on a set of rules when there’s no crisis on are pretty good, and when it’s hitting the fan it’s easier to say “sorry, we agreed….” than to explain a thousand times why we can’t squeeze in “just one more thing”. Plus when you’re chin deep in it yourself you won’t necessarily be thinking strategically (which is the core of Repenning’s argument), so having a set of rules to force you to act strategically makes a lot of sense.
