Tuesday, 17 May 2016

The Shit Nightclub antipattern

You go to a fancy looking nightclub. It's on Leicester Square in London - it must be good. The thumping music carries with it on the evening air the magical lure and promise of good times, so you pay the £20 entry fee and the suited bouncers let you in.
Then you discover that there's no one in there. And as the minutes and hours slip by, the place doesn't really fill up - but it's sure to soon, right? One of you suggests going somewhere else, but you point out that you've all paid £20 to get in. We should stick it out a bit longer.

And this is what happens with large IT projects.

Now IT projects are hard. No two are the same due to the shifting quicksand of technology, and the particular perspectives of the myriad stakeholders involved.

IT projects are also time consuming. They usually take at least twice as long as anyone thought they would - mainly because of the first point; no one can hold all of it in their heads, or at least not in "working memory".

Lots of problems stem from these two things: Budgets get blown out of the water, businesses don't get to market quickly enough, a work-late culture develops, morale ebbs away...

But like any teacher will tell you, just because it looked great on your lesson plan, if it's not working abandon it!
And this is what businesses are often unable to do.

This is what happens:

  • Someone estimates the project as 3 months.
  • A team breaks down the work and adds up the estimates. It becomes 6 months. (If you break work down and add it up, the estimate will always grow).
  • Some things get de-scoped. Some estimates get squeezed. They arrive back at the 3 month estimate, and senior stakeholders are appeased.
  • Work begins, and in the early days it becomes clear that things are slipping. Badly. But the PM (yes we're probably talking about a non-Agile environment) sits on this information rather than put the cat among the pigeons - after all it's early days, we might be fine.
  • The three month deadline approaches, and the PM goes cap in hand to the stakeholders and makes a poorly thought through request for one more month.
  • Two months later the team is exhausted and miserable, and the backlog is still groaning with work (including the performance testing - everyone agrees we really should get going on that). 
  • The PM is secretly angry with the team - how can they have taken so long? Why is it always like this?
  • The stakeholders are angry with the team - they put money and reputation on this project, and these developers are obviously not up to the job. More developers are dragged (possibly literally) to join the team.
  • The developers are all talking about leaving (except the guy who isn't very good).
  • The system is now complex and buggy, and more worryingly, it's laughably far from the performance targets they set at the start. How can it take 20 seconds to return a page?
  • At 6 months, a senior architect or tech lead is parachuted in. The PM is changed. More and more money is sunk into the project. It can't fail now, otherwise everyone's wasted half a year and a scary amount of money. More importantly, the stakeholders will look like fools.
  • The project limps out the door at 9 months, performing poorly and riddled with bugs.
  • The business decides they need more rigid and formal processes to stop this happening again.

So if you find yourself in a shit nightclub, consider your options:
1. Stay. Then you'll end up having spent lots of money, and having had a shit night.
2. Leave. Then you'll end up having spent lots of money, and possibly having a good night.

Your choice.


  1. Fail Fast - Fail Cheap - Fail Safe

  2. ..or Proper Planning Prevents Piss Poor Performance

  3. 5Ps first. then tho oldest agile approach of all PDCA, Plan Do Check Act.
    Plan a small piece, deliver it, check you are still working on the highest priority given the shifting sands, update
    stakeholders on progress and estimates, repeat......

  4. Totally agree. Small steps, and lots of honest communication throughout.

    Warning bells always sound for me when someone says "we need to manage expectations". That usually means "we need to let people know things are running late, but lie about how late because they'll probably be angry."


  5. A very interesting comparison.
    I recently wanted to change something in my company and introduced solutions in the cloud ( Pro4People.com ).
    I hope that it will end up better with me than in your history