Tip: Know what's a showstopper

A Project Management example from our book - "Project Management in the Real World".

A showstopper is something that has stopped or threatens to stop your project today. You will not need to be told how to recognize one: it will be clear from the panicked look on your team's faces and the unspoken question 'What do we do now?' that hangs silently in the air.


Eric Spanitz has over 16 years of practical project experience, is a professor at Lake Forest Graduate School of Management in Chicago on their MBA programme and once trained over 2,500 people on project-management techniques for the Canadian military. He is not someone his colleagues would associate with missed milestones. However, even experienced project managers sometimes find it hard to realize initially what could be a showstopper. Spanitz explains: 'I was managing a project for a medium-sized paper company here in the Chicago area.' The company had around 300 employees and was split across two locations. Spanitz was working with the IT programmers. 'Now, by saying I was "managing" the project,' he continues, 'in hindsight I would say I was cracking the whip, being more of a manager rather than a project manager.'

The project deadlines had been set by senior management without the involvement of the IT department and without a full understanding of the complexity of the project. 'Getting a project done "by Christmas" just had a nice ring to it,' Spanitz says. 'There was no consideration that I knew of about how realistic this deadline was.' The deadline was particularly tough, as between 80 and 90 per cent of the paper company's orders happened during the Christmas season. This put additional pressure on the IT department, which had to cope with business-as-usual problem solving and fire fighting. 'The programmers were all working 14- to 16-hour days, with pretty much everyone coming in on the weekends, myself included, just to even attempt to keep up with the schedule,' Spanitz, now president of the management consultancy Synergest, says.

One Friday, Spanitz came into the office at 8 a.m., late by his normal standards. He had been to see his doctor and was becoming increasingly aware of the ill-health spreading throughout his team. 'I walked by the printer, only to see the résumé of our lead programmer printing out at least 100 copies,' he says. 'On my way to my office, I passed another programmer, a very proper gentleman in his mid-fifties, with his head on his desk sobbing - no, more like a low wail. Being the emotion-avoider that I was, I ducked into my office to avoid getting pulled into some messy emotional issue. I looked at the clock and realized I had to do something and at this point really had nothing to lose.'

Spanitz realized that he had to take drastic action or he would end up losing his entire team. The deadline was completely unachievable, and the IT department was falling under a black cloud by trying to do the best they could. 'I loosened my tie, messed up my hair, took a couple of deep breaths and walked down to the conference room, where the senior management was having their weekly meeting,' Spanitz says. 'I walked into the meeting high on adrenalin and just started yelling "You guys are killing us back there. The whole department is sick and getting ready to quit. To Hell with your unrealistic deadlines! I'm giving everybody today off and we're not coming in this weekend!" I stormed out of the conference room still seeing red and made a beeline to the IT department. I quickly whispered loudly to the programmers to grab their stuff and get out - not to come in this weekend, and we'll figure stuff out on Monday. It was like an airplane evacuation as we all ran out the door.'

However, Spanitz did work that weekend. He used the time to put together a rough project plan for the work, which detailed how it could be completed in a reasonable timeframe. His calculations showed that the project could be delivered by the following April. 'I figured even if I was fired, I would still give it to my boss to show why I knew the deadlines were unreasonable,' Spanitz explains. 'On Monday, I went into the vice president of operation's office, who was my boss, and handed him the schedule.' Spantiz didn't know how to read his manager's behaviour. 'Then he said, "Oh good, I thought you were quitting" and looked at the schedule. He said: "You put on quite a performance - we didn't expect that from you." Before I could say anything, he said: "I think we need to include you in our planning meetings, so you can tell us, with your inside voice, how realistic our proposed deadlines are."'

Spanitz came to the realization that morning that the unrealistic deadline and the decreasing morale of his team was a showstopper. 'If the project manager does not speak up for his or her people, nobody will. Part of a project manager's job is to be an advocate and liaison between the project team and the executives,' he says. Monitoring his team's behaviour allowed him to identify just how low things were getting. 'Extended periods of overtime are counterproductive,' Spanitz adds. 'At that point, morale is destroyed, people will get sick, people will quit and productivity plummets. Sitting in front of a computer for longer time periods does not equal more work getting done.'

Since that impromptu meeting with the senior management team, Spanitz has found that on new projects, executives rarely try to force an unreasonable deadline, as long as he can explain why the deadline is unreasonable.

'Sometimes, theatrics are necessary to emphasize a point,' Spanitz concludes. 'I have never done a similar "performance" again, yet whenever I think back to that situation, I have no doubt that what I did was necessary and appropriate. The senior management team included me as the project manager in all future planning sessions involving the IT department. They listened to our discussion about project schedule feasibility, and over the next six months they reworked the pay structure for the programmers to increase pay and to introduce pay for weekend work. I am almost embarrassed to admit that sometimes I wonder if I should have performed sooner.'

Anecdote Icon 

You cannot work to resolve or get round the showstopper without first understanding exactly what it is. 'This involves investigation work to determine the dimensions and extent of the problem,' says Richard Murch in his book Project Management: Best Practices for IT Professionals.[i] 'Broadly, we define a problem as a deviation from an expected level of performance whose cause is unknown.' Getting to the bottom of the cause is essential, so call a crisis meeting with your team to sit down and work out why the situation has happened and what exactly has gone wrong. There will be a huge temptation to jump in immediately and suggest solutions and a plan of action for what to do next. However, bring your facilitation skills into play and make sure that everybody has the same understanding of the situation and its result before you allow the discussion to move on to analysing options for action.


Don't be tempted to simply accept the first plan of action. With a little bit of time, you and the team may well be able to come up with several alternatives. However, of course, in some situations there will be only one alternative: stop the project. In any situation where it is possible to continue the project, stopping it should also be analysed along with the other possible alternatives. This level of consideration is necessary because you and your project team need to be 100 per cent behind the decision. You need to understand why you are implementing this showstopper management plan and, more importantly, be able to explain it to your project board. As the project manager, you may have to take a bullish attitude to move the plan into action as, by their very nature, showstoppers don’t often give you a lot of time to sit around and deliberate. Some of the most rewarding moments of project management can be in response to this kind of fire fighting.

Hint Icon 


You will know when a showstopper threatens the success of your project. Keep a calm head, analyse the problem and come up with a robust and effective management plan.

Golden Rule Icon 

[i] Murch, R. (2001) Project Management: Best Practice for IT Professionals. Prentice Hall, Upper Saddle River, NJ.