Slashdot Mirror
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."
I'd say its actually closer to 100%.
Actually, it really depends on who they would ask in a company. Whether it be
the business executive (probably a higher estimate)
the IT middle manager (lower estimate)
the IT worker (who would think that they are on time)
or the customer (who sometimes have unrealistic expectations)
I was going to be the first post, but I could not get it in on time.
San Francisco Photographers
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."
:-) I say that joking, but have seen discussions like this almost erupt into fist fights as the sales staff makes promises to customers that are either 1) blatantly false or 2) concepts under development and are nowhere near "production".
Could it be that marketing is always overselling the product? Seriously. I cannot count how many times I have heard (in the past now I am in science), "oh, yeah....well, you need to include feature X because we told customer Y we already had that feature". This is often followed up by the engineer muttering under his/her breath "Dumb jock.
So, this is another example of why pre-announcing products is a baaaaad idea. Treat your customers with honesty and announce the product when it is ready and not before. Again, this is why vaporware only serves to irritate your customers and build expectation of a product that is not always delivered.
I also believe the fundamental problem is that managers these days (in many cases) no longer come from the ranks and are not engineers. So, they do not always understand what is involved in 1) building the codebase 2) testing code base 3) proper interface design 4) end user testing 5) documentation 6) making sure it does not suck.
The last point is where most executives seem to get hung up. More often than not in most companies, executives really have no idea of what makes good code and all too often, what makes a good product. Come on now, a good portion of executives can barely use their personal computers to answer email or browse the Internet. When you have companies run by executives and managers that have come up through the ranks, you are much more likely to get quality which often is much more important than meeting an arbitrary deadline.
Visit Jonesblog and say hello.
95% of the time, the business changes their mind about the project and/or doesn't know what they want, anyway.
Thanks /. a copy of this story now sits on my boss' desk.
Introducing Microsoft Vacuum 1.0 The first Microsoft product that doesn't suck.
There's a huge difference between 95% of firms not delivering a project ontime, and 95% of all projects being late.
My sig is blank, I typed this by hand.
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 answer to this problem is change, and isn't change always the answer?
Consider if you will for a brief moment the vast difference between the average executive and the average programmer. Programmers are generally broad-picture thinkers who solve largely complicated problems that regular folks can't possibly wrap their heads around. The executive runs on a schedule and uses reports and correspondance to understand what is going on, because business folks have to judge their employees and projects.
These two groups are forced to work together, and we expect good results? We need someone to interpret between these two groups! The HR department can't regularly serve in the interpretive capacity, but perhaps they should.
Managers generally don't want to give the programmers the whole picture, because management often believes that they are superior in rank to programmers, placing the programmers on a need-to-know-basis, only. Huge mistake.
What programmers and managers need to do is realisticly approach their solutions together. They need to be honest with each other. They need to share each other's thoughts and feelings about the subject matter. It's not happening today.
The programmers need to come to the table and care about their customers a little more. The managers need to come to the table and care about their programmers a little more. The customers need to be more specific and realistic about how far their dollar can go. Then deadlines will be met and promises kept and successful solutions provided to customers.
I encourage a no-holds-barred approach to project management. The superior product is developed using the Agile method.
The dangers of knowledge trigger emotional distress in human beings.
95% of IT project specifications are what the user WANTS rather than what the user NEEDS. When they get what they want, and discover its not what they need, of course they wont be satisfied.
A study shows that 95% of clients don't know what they want.
... and the other 5% never ship at all. (ie Duke Nukem Forever)
Trolling is a art,
Isn't it ironic that Slashdot is linking to an article speculating on why IT projects are completed late, that will then be speculated upon by hundreds of Slashdot users, during typical business hours?
Us: We can do that for $x in 12 months.
Customer: But Joe Bloggs says his company can do it for $x/2 in 3 weeks!
Us: That's simply not possible.
Customer: Well, for that sort of savings we're going to give them a try.
11 months later and $x^2 later they're still waiting for Bloggs to finish but by then we're on the dole and Bloggs is laughing all the way to the bank.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Then they are either padding their project plans way too much, or are really not trying to do anything new.
"Could it be that marketing is always overselling the product?"
I work with OCR/ICR technologies. NO SALESPERSON should EVER be allowed to sell this without taking a month long training course about what it actually does.
I can't count the number of times customers were expecting 100% accuracy because thats what the salesman sold them.
This is almost always because the scope of a project changes between when it's initially described and when it's delivered. A majority of projects I've been involved with fall into one of two categories:
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, 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). Since you can't do this, the client will eventually get upset, even though it's their own fault.
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.
Yes, I've managed client relationships before and large (multimillion dollar) implementation and customization projects. I have reasonably good people skills, and still found these problems generally insurmountable when my client's company had a completely nontechnical person in the role of project sponsor and manager on their side.
The best predictor of success of a project in my experience are the lines of reporting and control in the client's company, and the existence of some technical knowledge in a position of responsibility and authority. If their CIO or President or whoever is the ultimate decision maker has a senior arhitect or tech VP that knows their shit AND functions as a trusted aid in the decision making process, these issues can usually be bypassed. If there is no senior source of technical knowledge, you can kiss the entire project's ass goodbye. Try to get as much money as possible from the client while it's going on, but forget about the project being "successful" in how its received by management.
This reminds me of my PM class I had. ..., then a project plan, then an end date is to be derived.
In a nutshell, the instructor said that the requirements, then the specs, then design,
The guy next to me who was a PM just shook his head and said, "No, the end date comes first and then we figure out how to get it done." I have had the same experience in my decade+ of experience.
The instructor said that's why most projects fail.
- Failure to Understand Business Need
- Trying to Solve Training/Documentation Issues via Engineering
- Scope/Requirements Creep
Join me next week as I discuss the problem with dumbing down your architecture so that you can hire morons for less money to maintain it when all your best talent gets fed up with their 2% raises and quits."I have never won a debate with an ignorant person." -Ali ibn Abi Talib
if(internal project){ // CONTRACTORS! HERE BE DRAGONS! // VENDORS! GOOD LORD, HIDE THE WOMEN, KIDS, AND FARM ANIMALS!
;)
if(doneByEmployees){
if(manager.clueless){
if(manager.schedule.isRidiculous()){
project.lateness.reason = "Employees came, they saw the schedule, they laughed, then they did the project in its natural timeframe";
} else {
project.lateness.reason = "Employees came, they saw the schedule, something went wrong, all hell broke loose, then they finished the project as fast as they could, considering";
}
} else if (manager.isEvil) {
project.lateness.reason = "Employees hate him anyway and ignored his sadistic schedule. General sentiment of 'fuck it, I'm on salary' prevails, manager crashes and burns, employees get reassigned, everybody sings 'ding dong, the witch is dead' and goes to Starbucks for coffee";
} else {
project.lateness.reason = "Unforseen problems arose, employees did their best to deal with them, stakeholders wouldn't budge on schedule, so the project was late.";
}
} else {
project.lateness.reason = "maximization of billable hours (duh)";
}
} else {
project.lateness.reason = "Incredible, absolutely amazing scope creep, maximization of billable hours, platform/system/vendor changes midstream, refusal to engage in technology transfer as extortion technique, total screw up of vendor, outsourcing to country without indoor plumbing (but assume they can handle high technology), etc, etc, etc";
}
Did I miss anything?
Farewell! It's been a fine buncha years!
A man is flying in a hot air balloon and realizes he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts, "Excuse me, can you tell me where I am?"
The man below says, "Yes, you're in a hot air balloon, hovering 30 feet above this field. " "You must be an engineer", says the balloonist. "I am", replies the man. "How did you know?" "Well", says the balloonist, "everything you have told me is technically correct, but it's of no use to anyone."
The man below says, "You must be in management." "I am", replies the balloonist, "but how did you know?" "Well", says the man, "you don't know where you are, or where you're going, but you expect me to be able to help. You're in the same position you were before we met, but now it's my fault."
There are 2 kinds of people in this world. Those that can keep their train of thought,