Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2


March 2nd, 2006 · 1 Comment

Is your project team stuck? Have you ever been on a project that just couldn’t seem to get going? Why? How did you overcome it?

Here is a simple test. Look at the picture below, and answer the following question: Which project team is furthest behind?
Did you say team C? They seem to be going away from their goal. Does that really mean they are furthest away?

You probably didn’t say team B. They are making progress towards their goal, which is a good thing most of the time.

What about team A? They aren’t moving at all. So which is worse – taking off in the “wrong” direction or not going anywhere at all?

Guess what I’m going to argue? That’s right. Not moving is worse than going the wrong way (90% of the time). Let me give you some reasons why:
1) Not moving DESTROYS morale and perception.
2) It takes less energy to STEER a project team than it does to MOVE one.
3) Not moving doesn’t decrease the likelihood that you’ll take off in the wrong direction once you finally get going.

One of the reasons that project teams can’t seem to get started is because they seem to think they have to plan the whole project before they do anything. I have seen this time and again, and here’s a few examples:

  • Postponing the start of a project to implement a “process improvement” initiative.
  • Attempting to define a software development methodology prior to beginning requirements
  • My personal favorite: building a portable iron boat to sail down the western side of the Rocky Mountains (Lewis and Clark did this, resulting in months of delays. They hauled the boat to the continental divide before they pitched it and made canoes out of trees)
    I sometimes think of planning and not moving as the same thing, at least if you stop moving in order to plan. I prefer to plan on my feet – get things rolling, evaluate direction, and adjust. Then roll along for a while and do it over, and keep repeating until the project is complete.

    Does this approach make you nervous? I know firsthand that it makes many managers nervous. They want to see a project from beginning to end, even if the plan you’re showing them is based primarily on your imagination. Somehow the project plan that shows the whole road from initiation to close out just makes them feel warm and fuzzy inside. Not me. When I look down a project plan to the “horizon”, I can almost see the probability of missing dates increase the further out they are, like mountains rising over the desert in the distance. It’s just too complicated.

    Here’s the simple truth about managing software projects: the probability of missing a date grows exponentially the further out the date is. Why? Because of all the factors that cause variability in a software project. The longer you are exposed to them, the more they accumulate.

    So how to deal with this? I don’t really know. I’m just here to complain about it!

    Just kidding. I think the answer is pretty simple: Don’t build monolithic plans. Adjust the level of detail based on how far out you’re looking. You should always have a very detailed plan for the next two to three weeks. It’s a very reasonable thing to know exactly what’s going to be done in that sort of time frame. That’s your “six sigma” range.

    Activities that are more than three weeks out but less than three months away should be planned in a general sort of way and should seem more like goals. “Start UAT the week of August 1,” for example is one that you can shoot for. Pin it down to a more accurate date it once it falls in the three week range.

    Anything more than three months away should have an extremely general timeframe with a fairly broad range associated with it (like “Go live sometime in October.” I prefer to avoid putting dates on these at all – it makes more sense to me to just list them in the order we’re going to do them and then get there as fast as we can. That is almost always impossible though, so give it a broad range instead. Once these activities fall in the three months window you should start to plan them.

    Think I’m crazy? Let me know: post a comment or send me an email at

    If you enjoyed this post, make sure you subscribe to my RSS feed!
    Stumble it!
  • Tags: Job Advice

    1 response so far ↓

    • 1 John // Mar 6, 2006 at 10:39 pm

      This is good and no-nonsense. The illustration made me think of the advice on brainstorming in my business process management traing at Cap One. This is it: one of the best ways to kill a brainstorming session is to stop to evaluate comments, etc.

      Keep writing (and working on the dragon).


    Leave a Comment