You've read Dilbert? Then you may have thought Scott Adams was joking. He wasn’t, and Phil fleshes out the details. From contract programmer to IT Director, Phil spills the dirt on them all, not to mention recruitment agencies, for whom a special place is reserved in hell.
This book was originally published as a series of articles on the Simple-Talk website. Take IT projects now, a subject close to my heart at the moment - they have a reputation for failing, especially the big ones. Phil thinks it’s a well-deserved reputation. Nonetheless he suggests a few things you can do to actually succeed in getting an IT project come in on time, under budget, and actually do something vaguely resembling whatever it’s supposed to do.
Start by doing nothing until everyone agrees what is to be done. Then any improvement, any change, has to go through a strict change control process. (You may see already why there are so many failures).
Don’t be a pioneer - use only boring proven technology. If the programmers want to play with the latest TLAs (three letter acronyms) and put them on their CVs then fine, set up a sandbox to muck about, but do the real work using last year’s release.
Code then recode. Sling the first version and write it again properly. It will take half the time and effort, and run twice as fast as the first tentative fumblings. (I can see his point, but I'm not sure that I would be brave enough to sling a working program and then rewrite my code. Nor am I sure I could get it past my manager - "Yes, I'm finished, but now I'm going to rewrite it").
Allow no virtuoso programming - if you can’t understand it, it’s no good. He mentions elsewhere the joy of documented code. Oh, so true. I like to put comments in my code because I haven't a clue what I've done otherwise when I look back at it three months later. I know some people believe that their code is so clear that they don't need to bother - to them I say "Phooey" and Phil would probably agree.
And encourage results by rewarding deadlines met.
Fortunately it doesn’t matter if your project is abandoned or dies a painful unpleasant death. Here I refer you to Dilbert’s The Joy of Work. Suppose you design jet engines. You may only ever have designed one of them, and on its first flight it crashed in flames and destroyed a remote logging town. What matters is that you can put “Jet Engine Designer” on your CV.