« Fibre is Good for You | Main | Curious »

February 22, 2004

Flailing and Failing

Note: this is a post recovered from my old blog, before it died of an insufficient backup. Any comments/trackbacks on it have not been brought over, but can be seen with the original. The date is that of the original posting.


I have a small desk ornament, which describes the phases of a typical project, and goes something like this:

  1. Enthusiasm
  2. Disillusionment
  3. Panic
  4. Search for the Guilty
  5. Punishment of the Innocent
  6. Praise and Honors for the Non-Participants

I've see a lot of IT projects fail, and a few succeed, and it comes down to this: bad management kills IT projects. There is no other significant cause. (Note: I was a manager for five years, before I gave up and went in to consulting. Between consulting and permanent employment, I've worked on or around something like 35 major ($5M+) projects.)

In general, there are more good managers than bad managers. However, in an enterprise computing project, there will be many managers with a piece of the project under their control. In a typical multi-group, multi-city project you might have 25 or so managers, project managers and executives with a direct influence or control over all or part of the contract.

I'd guess that two out of five managers are good personnel managers, and two out of five are good project managers, and when you put them together you get about one out of five that are good at both. Most failures of projects, though, come from the bad project managers . (Bad personnel managers can cost you good employees, but that won't be the most likely cause of project failure.) On the other hand only about one in ten are wholly incompetent or truly terrible personnel managers, and only about one in five are wholly incompetent or truly terrible project managers.

This means that you will have as many as 5 of various managers and executives involved in such a project who are incompetent or terrible.

Here are some ways to help a project fail, most taken from my current project. Accumulate enough of these (and there are many more that can be added), and you will fail.

  • Six months before you start gathering requirements, and a full year before you start the implementation, set an arbitrary timetable.
  • Stick relentlessly to that arbitrary timetable; add additional arbitrary dates (milestones) to meet; punish ruthlessly any indication that such a date won't be met. Ignore the completion time of tasks on the project's critical path, particularly if failure to complete a given task will cause an arbitrary date to be missed.
  • Do not gather requirements. If you accidentally find yourself with requirements, ensure that they are vague, unmeasurable and contradictory.
  • Be sure to submit further requirements after the design phase is completed. Do not change any dates to accomodate this.
  • In case dates are in danger of actually being met, ensure that your subcontractors' hours are capped at a certain number, so that they cannot work overtime to cover up the problem. Require them to work overtime anyway, but quibble about paying them.
  • When an arbitrary date is in danger of being missed, redefine success. Continue doing this until success consists of not actually catching the building on fire.
  • Do not distribute the software install media to your engineers. When you do so, be sure to distribute the wrong versions. Make sure that all software is ordered by people who are neither technical, nor involved with the management side of the project, to maximize the chances of getting the wrong software. Never distribute the licenses through the same channel as the software, or they might end up arriving together.
  • Be sure to tell a key group in advance that if they mess this one up, their jobs will be outsourced. Then take primary responsibility away from that group, make the newly-responsible party dependent on the first meeting timelines, cut the first group's funding and, to cap it off, give them a plausible scapegoat. Then, they'll be sure to do their worst work, as slowly as possible, while not cooperating with the scapegoat, without whose success the project will fail horribly.
  • Question in detail, at length, and with clear malice the most minor and reasonable decisions. Ignore massive problems with strategic decisions; those can be papered over by the engineers, if only they work 90+ hours per week for six months straight.
  • Document nothing that is difficult to reproduce, and concentrate critical knowledge in the heads of a few people. Give them reasons to quit (like working 90+ hours per week). If all else fails, call your most rare talent when they are home with the flu, and demand that they dial in to work.
  • Hold as many meetings as possible, with as many participants as possible. Not only does this diffuse responsibility, it ensures that time which otherwise might be wasted on advancing the project is instead employed updating everyone on why the project is not being advanced.
  • Whenever possible, make sure that the project managers are non-technical, so that they cannot explain anything that is happening. This will result in the technical people both explaining the concept multiple times to the project manager, and also in their explaining the concept at multiple meetings as well, thus making sure that they have no time to actually work on the project.
  • Distrust your employees. This can best be shown by demanding they tell you the real reason for things slipping, then punishing them for not having requisite faith in the project when they do. Bonus points are given for complaining loudly to other managers about how your staff isn't honest with you...in front of other managers.
  • Establish control measures which are not subject to political tampering. Ignore them for political reasons.

There's more, but I'm too tired to deal right now.


The schedule before requirements policy always amuses me. "If you don't know where we're going, how can I tell you how long it'll take to get there?"

In my MS program we actually got a recommended method for dealing with that--just do a spiral development with rapid iterations adding one feature at a time, so when the milestone is hit you hand over a working program with whatever you've had time to implement. Meanwhile I just got an email about management graciously allowing the structure team to take valentine's day off as they work frantic overtime to meet the scheduled CDR date. I suspect giving them all copies of Peopleware wouldn't help. Sigh.

Posted by: Karl Gallagher on February 11, 2004 01:47 PM
Post a comment

Posted by jeff at February 22, 2004 12:00 AM

Trackback Pings

TrackBack URL for this entry: