This post originated from an RSS feed registered with Agile Buzz
by Laurent Bossavit.
Original Post: Projects beyond repair ?
Feed Title: Incipient(thoughts)
Feed URL: http://bossavit.com/thoughts/index.rdf
Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different.
In the latest software project horror story to have crossed my screen, the words that sent a chill down my neck were these:
CSTARS "hasn't failed," Cooke said. "It's in test."
This guy is in denial. There comes a point during the course of some projects when you can say with certainty that the project will never be a success in any sense of the term. At that point, it's time to scrap the project, gather key people to collect lessons learned, and move on. (I discussed killing projects in my article, "Project Management: the Movie").
My intuition is that the more you push on beyond that point, the less of the project is salvageable. From personal experience, I know that key people on projects of this kind can become so utterly disgusted with the mere memory of the project that even a "post mortem" will become impossible. Past a certain point, the more sensible people on these projects will often have resigned or taken early retirement or something - anything to move on.
I wonder how early one can spot a project "beyond repair". Again from experience, on many projects there is a point where the people actually working on it will stop keeping even the pretense of hope: they will start openly discussing their individual plans to move on, or what they think the major problems with the project were, and so on - the point being that when people still working on it start discussing the project in the past tense, it's already beyond repair. But not, perhaps, beyond salvage.
An attempt at defining terms: a software project is "beyond repair" if the only conceivable course of action, to get the benefits originally intended from the project, is to start a replacement project from scratch, redoing all the work and with an entirely new set of people involved: new team, new management, and so on. Whenever we see a project where that actually happens, we can look for the point when the project became "beyond repair". The "beyond repair" distinction should be somewhat flexible to allow for "salvage", for instance if the replacement project can use some or most of the work done on requirements we'd still term the original project "beyond repair".
A project doesn't have to be in production to be "beyond repair". It doesn't have to be in test. You can probably spot such a project as soon as the early implementation efforts. Possibly, it doesn't even have to have gotten past the requirements stage.
A project that is not beyond repair could still be terminated, if it no longer seems economically viable. The narrative in this case is entirely different: rather than "There's no way this project can *ever* possibly work", management are saying "We could eventually bring this project around, but it would cost more and be a greater risk than scrapping it and starting over." In particular, in the latter case you can probably still keep some of the people involved in the original project. Suppose, for instance, that a project was killed because it turned out that it had recruited C++ developers who were not up to speed on Java (or the other way around), you would still have a range of options: retrain the developers and restart with the same team; switch to the better known technology; retain the non-developers on the original team and hire replacements; and so on.
By contrast, and this might be a key characteristic of a project beyond repair, there are some cases when just having worked on the original project is such a taint that you can no longer be trusted with any further effort. This loss of trust seems to go hand in hand with projects beyond repair, and to be a kind of chicken and egg phenomenon - did the project get to that state because of the loss of trust, or was trust lost as it became apparent that the project spiraled out of control ? I believe that both are true, and aspects of something deeper that characterizes projects beyond repair.
Unfortunately I don't (yet) know what this "something deeper" is.
Previous Topic
