There's an undiscovered market out there for how to books that take the contrarian view. As a trial of this idea I thought I'd do some pieces on how to make IT projects fail. This is the first one.
They say "write about what you know", and, trust me, I've made a few projects fail.
There are lots of good ways, but a personal favorite involves under powering the server and then spending as much of the budget as possible on consultants hired to make it work.
The point here is that you usually get exactly one chance to make a favorable impression on a user facing change - because that person will start out resentful and all you really have to do to capitalize on this is to make sure that the initial screen loads fail or just take absurdly too long. Add the usual random down time, reporting delays, maybe some network issues to force lots of desktop reboots, brush off the loss of some user entered data as unimportant, and that project's deader than a doornail -and not just with the current project manager either: forever and ever.
The risk in this strategy is that the senior people will want to know what's going on and you just know they're wondering whether replacing you will fix the thing. So to make sure that doesn't happen, hire expensive consultants and give them the job of making things work -but pay them on a per diem so their incentives work for you.
I know a senior project manager, for example, who did this because he really wanted to displace a CIO with a long career in data processing behind him. "John" got both the application vendor and his CIO to sign off on Oracle on Sun for the server end of a major business intelligence project and just ran with it from there.
First he "saved millions" for the project by resurrecting a Sun 6500 that had been decommissioned (and had most of its memory stripped) in 2002. That was brilliant enough, but his masterstroke was to request the services of a gentleman DBA the CIO trusted because of his years of "progressively more senior" DB2/System 390 experience to install and tune the Oracle software under Solaris.
When the project faltered amid user complains about the server bottleneck, he followed up by bringing in two Oracle guys to help. They put on a tremendous show for him, swaggering about with laptops and muttering just loud enough to be heard about tuning SQL-net and actively managing the cache on the T3s.
Taken together these measures let him assure user management that he'd put a two million dollar machine at their disposal and was draining his budget at $3,000 per day for two of the finest, Oracle trained, on-site database experts ever to walk the earth.
I had a post mortem lunch recently with two of the senior user side managers affected, and tried to explain what he'd done - but they think he's on their side, and blame both Sun and the application vendor.
The project failed, but he succeeded -and their belief in him is a measure of that success.