IT Project Euthanasia

  • Comments posted to this topic are about the item IT Project Euthanasia

    Best wishes,
    Phil Factor

  • I've read many of your blogs/articles, and for the first time ever, I actually laughed outloud on this one! Great job!

    SQL Babe

    SQL Babe

  • Yup, spot on, I could not do Spot when the time came, had to rely on the family while I sat teary eyed.

    On a more serious note there is a technique I use, it basically comes down to 90 days or drop dead. That's right, if you can't deliver something into Production in 3 months you've got a problem. This allows for a second, third, etc phase, yup more 90 day iterations, or a bullet, in either case you get a critical checkpoint that EVERYONE, users included, owns. AND it has to go into Production, not just be accepted for user test.

    If you try you can scope anything into 90 day parcels and put each into Production, or bite the bullet, your choice! Even 'Big Software' companies could do this if they were a bit more customer conscious.

  • Instead of SQL Server sabotage, I think dispatching the project in a manner similar to the "rifle while the dog is relieving himself" method would be better for projects. Just have the CEO swing by the boardroom during the morning project status meeting (or any of the other meetings that are always booked) and just shout "FAIL!". Perhaps he could then call the project manager over for "a little chat".

  • Ian, I have every sympathy for the Spaghetti-western approach to projects. My editorial was really about the extraordinary reluctance of companies and government to take the obvious step with a project. I've watched the progress of many a project in my time, and I've never been surprised in my prediction of the final outcome. It is obvious from very early on if a project is going to succeed.

    Greg, Your ninety-day approach is very reasonable. There was a glorious time in one large American company I worked for when projects were always done by two separate teams, one using innovative techniques in languages that tended to use a lot of curly brackets, and the other team with a conservative approach. Most of the time, they were unaware that they were being shadowed. After ninety days, the losing team was disbanded. Almost invariably, the conservative approach won hands-down and the innovative approach usually became so engrossed in the elegance of their programming constructs that they failed to even realise how far they lagged in real productivity.

    Bless you SQL Babe. I hope to keep you laughing for a while yet. I find the whole IT business a rich source of humour.

    Best wishes,
    Phil Factor

  • I don't know which got me laughing harder. The original post or Phil's response to Greg. I've been a "code spitter" long enough to see many forms of technology die {boring, very long, list omitted}. They call me a cave man due to the fact that I am able to do "brain surgery" with stone tools and a rap in the mouth as anesthetic.'

    I worked on a dental system that used a 16 bit integer to store dates. Each day was X days from the origin. We had a nagging problem that kept putting spaces in the date field. I put in a fix that killed any appointment with spaces in the date field. I checked and the day that was 8224 days from origin was on a Saturday. That won't hurt anybody, right? Then we put or software into a dental clinic that had 24 opperatories and was "all hands on deck" from 8 AM to 8 PM on Saturdays.

    The only way that software died (and it ran for almost 4 years after I left) was that somebody bought the company and killed it.

    ATBCharles Kincaid

  • Unfortunately, it is much more likely that management will look at the mounting costs of a long overdue project and set an ultimatum for the project manager like “If it isn’t in production by June 1, you’re fired.”

    You can be certain that something will go into production on June 1, but then it’s a giant mess in a production system that can’t be allowed to fail.

  • Great job Phil!

    I've got something similar in the works, or maybe I've published one. Can't remember now, but pulling the plug is tough.

    What's crazy is that if you can't salvage something, the costs spent don't matter. They're gone no matter what you decide.

  • Unfortunately, the costs spent do matter, because if they declare the project a failure, then all the costs of the project will have to be written off immediately, instead of capitalizing the costs and depreciating it over a period of years.

    If the project is large enough, it may be enough to overwhelm the operating profits and show a net loss for the fiscal year. With bonuses of senior management tied to profits, that makes cancelling a big project a tough sell.

    Maybe the service that Phil should be selling is taking the blame for the project failure. Imagine: He provides management with backdated memos showing that the whole mess was his idea, management makes a big show of blaming him, they add some notes to the financial statements, and the guilty parties go back to business as usual.

Viewing 9 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply