95% of IT Projects Not Delivered On Time

An anonymous reader wrote " The Globe and Mail reports that 'A new report conducted by market research firm Info-Tech Research Group says 95 per cent of information technology groups are not delivering some number of projects on time or to the full satisfaction of the business executive.' The article goes on to discuss the reasons for this pervasive (perceived?) problem. The article mentions Info-Tech's reasons: unrealistic time frames, staff shortages, and poorly defined project scope. However, the article's author lays the blame with vendors."

But...

[abeybaby]

Well, it is better to have a project late but stable than to have it on time and full of bugs. Microsoft et al, take note.

misleading headline

[wankledot]

There's a huge difference between 95% of firms not delivering a project ontime, and 95% of all projects being late.

Not projects

[Council]

Well, quite obviously, it's a problem with how deadlines are chosen, combined with peoples' natural work tendencies (where they work up to a deadline and get it done sometime soon after).

This isn't "oh no evidence of every company doing some particular thing wrong 95% of the time." It's a general property of this type of project.

To put it differently, if 95% of people are voted above 9 on hotornot, it means there are some parameters to the voting or the choices or the statistics. Not that the world is incredibly attractive.

The Truth?

[Anonymous Coward]

The only way to solve this is for IT folks to strangle the idealistic and unrealistic expectations of the suits. If they say they want it in a month, and you know that it will take more on the order of six weeks while supporting other day-to-day business, tell them they can have it in two months. If they are aggressive about the one month deadline, then tell them that other projects will have to halt or suffer, or that you need more staff even on a consultancy basis (ie. more cost). If they can't fit within any of these parameters, you are working for a jerk who needs to be assassinated and are justified in the following behavior:

1. Lower your work quality and apply those energies to a job search while at work
2. Find ways to make other systems fail in such a way that they are majorly inconvenienced by you having to pay attention to their pet project
3. Assemble as much ammo as you can to prove to the board that your boss is a clueless asshole

Simple really. I've done it before myself and it works wonders.

Re:Adding requirements

[Anonymous Coward]

You need proper change management. If they want something that isn't in the specification you both agreed upon beforehand, then that needs to be logged as a change, approved by your boss, inserted into the specification, and time estimates adjusted accordingly.

Too many clients seem to think that just because the project isn't finished, that they can add features for free after the initial estimate. It's a variant on the "if I don't see it happen, it doesn't exist" mindset (it's been shown that even some gorillas are smarter than that).

In my experience ...

[johnhennessy]

(Stolen shamelessly from someone else...)

A Product can be:

1) On time
2) On budget
3) Feature complete.

Pick any two.

"Business Executives" and their ilk...

[IdJit]

My experience with the "business executives" (or at least the sales managers who usually are the first ones to complain about late projects) has been that they just loooove to make the client happy and will do ANYTHING to keep them that way.

This most often includes them telling the client things like, "Absolutely, we can include that feature with the current development. I'm sure it's not a big deal". Then going back and telling the PM or even the programmers themselves that "I've already told them we could slip that feature in there so let's just go ahead and do it. It's not a big deal, right?"

[Greedy|stupid|sycophantic] sales guys will sink a project faster than you can say "let's do lunch".

Re:This is why (back when I was a contractor)

[Maxo-Texas]

The important thing was to GET the contract and then work out the details.

When I first started, I lost a lot of opportunities to others who quoted 1 week for a 4 week project and then took 4 weeks to do it.

And management bit EVERY TIME. It's like they have that short term memory problem from "50 First Dates" and "Memento."

come on now...

[Run4yourlives]

MS Project dosen't plan projects, PM's do.

Garbage In, Garbage Out.

canada

[alexq]

has anyone clicked on the article? it seems to just be about canada (read the first paragraph)

Canadian information technology groups can't seem to get IT right.

A new report conducted by market research firm Info-Tech Research Group says 95 per cent of information technology groups "are not delivering some number of projects on time or to the full satisfaction of the business executive."

and why is the heading in slashdot "95% of IT projects" while the actual statistic is "95% of IT groups have SOME late projects"?

This seems pretty misleading to me!

Re:In my experience

[cbciv]

1) requirements are agreed on, seem reasonable enough, but then detailed specifications are drawn up and client keeps pushing to add more things to specs until you have a 120 page document that will take 2 years to deliver. If, however, you tell the client it will now take 2 years vs. the 5 months you said when you were looking at a 2 page requirements document,

This is the first mistake. Estimates and deadlines should never be based on a requirements document. That document only tells you what problem you're going to solve, not how you're going to solve it. Any estimate at this point in the process is pulled out of one's ass and worth what you would expect. It should never be given to the client.

they will cancel the project, and if they weren't paying for the requirements phase, forget about collecting any money for them (why you should always get paid for all phases of project planning).

Requirements (and design) documents should always be considered a separate deliverable. That way when some percentage of your clients decide to cancel the project upon really seeing the scope for the first time, you won't have to eat the cost. This happened to me just last year. I got paid for the requirements doc, so it wasn't a complete loss.

Since you can't do this, the client will eventually get upset, even though it's their own fault.

Can't do what, tell them the truth? That's compounding the first mistake. Don't lie to your clients in order to milk them for money when you know the project is doomed. That's unethical and your reputation will suffer accordingly.

2) Project is delivered very early in prototype form, only to have the client say they want 50 more features that they forgot to describe in the requirements process, but they refuse to pay more, and refuse to acknowledge that the time frame must be pushed out to accomodate their new requests.

I'd try to go over the head of the project manager first. If I couldn't do that, I'd look at my contract and consider my options, including termination of the contract. My contracts always have termination clauses that allow for this. I'd rather terminate the relationship and find something else than screw a client and myself by continuing the project under false pretenses.