How to Fail at Software Development

15. Do folks talk about finishing the project, or just talk about continuing work on the project?

Score from 0 to 20
This is the most difficult symptom to describe, and the most difficult to detect, because it shows itself in subtle ways. You may think you are detecting symptoms of this problem when you are actually viewing a normal conversation about general procedures and policies. This could be the most severe problem of all, but to pick up on it you will have to pay very close attention over a period of time. The extreme level of subtlety is part of the reason this is such an insidious problem.

You've heard motivational speakers and writers say things like, “You can do anything if you just believe that you can do it.” Well, the opposite is even more true. You will never achieve anything that you are convinced you cannot do. If the general feeling on your project is that it is a process instead of something that will ever actually get done, then it will never actually get done. But when this attitude is present in a working group, its presence is subtle and hard to spot.

Every year thousands of software development projects are simply cancelled in mid stride because the whole thing has simply gone on too long and seems to not be getting any closer to completion. On this sort of project everybody is paddling like crazy. The whole crew is working like beavers to get stuff done. The programmers are all programming at a furious pace, the managers are managing, the documenters are documenting, and memos are flying around everywhere. Great gobs of code are being added to the archives. Some people are even working overtime to get things done. But even in the face of all this, the whole mess runs over schedule and over budget and then just keeps on running. And running.

Large projects—some of them very large projects—have reached the point of being ninety-five percent complete and stayed there for a year. Or more. One day at a time.

This is the most destructive of all possible directions for a software development project because it eats up the maximum possible amount of both time and money. It ruins careers and destroys the self confidence of otherwise very capable people. And it’s so subtle that many of those hurt by it don’t know why or how.

Okay. That's the manifestation of the situation in the long term. But you need to be able to spot it in the short term so you can figure out the course of the project.

Here's how you do that. After every meeting, and after any other discussions dealing with the work being done, make a quick analysis of what was actually discussed. Was the discussion about forward motion of the project, or was it about the process itself? If the discussions are about the ongoing process, then the process will go on. Of course, on every project, there will always be discussions about the process, but to succeed there must also be serious and animated discussions about what is going to happen after the completion of the primary purpose of the project. Completion must be a clearly in sight and appear to be achievable.

Notice I said, “appear to be.” This whole problem is a matter of perception on the part of the team members.

The difference between a forever project and one that will complete is subtle and a bit hard to spot at first, and it could take you several days before you get to the point where you can actually tell the difference. If you’ve never thought about this before, don't jump to a quick conclusion. If you listen hard enough and long enough, the state of your project will begin to make itself known to you.

The score on this one is high, but even on a project that has everything else going for it, this one thing can kill it.

Previous Back Next