Slashdot Log In
95% of IT Projects Not Delivered On Time
Posted by
Zonk
on Thu Mar 31, 2005 10:56 AM
from the quiet-desperation dept.
from the quiet-desperation dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Nah (Score:5, Insightful)
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)
Re:Nah (Score:5, Funny)
You may learn from this experience.
Parent
Re:Nah (Score:5, Funny)
Clearly a specification error on the customer's behalf. You should have requested 8 (or so) fluid ounces of liquid caffeine-bearing (I assume!) sustenance produced by passing hot water through the ground, blended beans of particular coffee tree species, while supported in a paper (or copper, or gold. Again, assumptions!) filter.
Parent
Re:Nah (Score:5, Insightful)
Parent
Re: Here's a relevant old joke (Score:5, Funny)
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."
Parent
Re: Here's a relevant old joke (Score:5, Funny)
"My smallest cow, you say? Well, why not, give me your estimate," replied the cowboy.
"Sir, you have exactly 400 head of cattle," the man said after some contemplation.
"Wow, that's exactly correct," said the cowboy surprised. So, the man walked over, picked up his prize and put it in his trunk. The cowboy, concerned for the animal, asked, "Now, if I can tell you your profession, would you let me win back the animal?"
The man, somewhat taken aback, agreed with a chuckle, "Sure."
"Sir, you are a consultant," said the cowboy without hesitation.
"Wow. That's pretty impressive. How did you know?"
"Well, you came out of nowhere telling me that you could give me an answer to a question I didn't ask for a price that was over the top," said the cowboy with a stern look. "Now give me back my dog."
--Wish I knew who to attribute this to
Parent
Re:Nah (Score:5, Funny)
Upon delivering the completed project, the end user simply states:
"Now hold on, this is exactly what I asked for.. But not what I wanted!"
Parent
Re:Nah (Score:5, Insightful)
Managers just seem to cut it out of plans because clients don't like paying for it.
Parent
Re:Nah (Score:4, Insightful)
Parent
Re:Nah (Score:5, Insightful)
Non IT people just don't understand why code isn't written correctly the first time.
Parent
Re:Nah (Score:5, Interesting)
When an engineer designs and builds a new bridge it is entirely possible that no bridge like it has ever been designed or built before. Sure, there are some base cases that just get churned out, but there are also big, new, creative designs that occur for bridges. How is that bridge engineers usually manage to not have their bridges falling down all the time? Well, for starters the designer doesn't run with a "build and test" mentality. There are formal methods for bridge design, and if you assume the properties of various basic components, there are methods to prove the stability and properties of the bridge. Did you know that there are formal methods for software design, and if you assume the properties of basic components (like hardware, OS , etc.) there are methods to prove the stability and properties of the software?
Yes, formal software methods are hard and time consuming compared to just building and testing. Formal bridge design is hard and time consuming compared to just building and testing.
For some reason we accept that software should be just thrown together rather than properly designed and proved. Yes, there are plenty of projects for which the level of formality I'm talking about simply isn't required - that's fine. My point is that there are plenty of projects for which the level of formality I'm talking about would be a damn good idea - yet it is never even contemplated let alone used. At worst you should be considering some level of formality for just those components of your system that are most critical.
Jedidiah.
Parent
Bridge not comparable to most business software (Score:5, Insightful)
Consider the construction of a house, or an addition to an existing domicile. Price is a significant factor, and the customer has many arbitrary constraints (call them "aesthetics"). In many cases the customer isn't sure what they want until they see what they don't want, which requires rework. There is no official certification process for most construction trades - only specialties like electrical wiring. So it is difficult to know how good a crew is until you work with them. Many (if not most) construction projects like this run over budget or over schedule.
I think writing business software is more like building a house. The constraints are unique and vague. The workers vary in their abilities. And the customers are cheap bastards. Projects in this environment have very little chance of coming in under budget and on time.
Parent
Re:Nah (Score:5, Funny)
Parent
Not on time again (Score:5, Funny)
Understanding your art (Score:5, Insightful)
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.
VERY true (Score:5, Interesting)
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.
Parent
Re:Understanding your art (Score:5, Insightful)
- you hit the nail right on the head!
I'm working on a project right now (software is installing as I type this) where I'm supposed to migrate an existing web server to a new datacenter accross the country.
The PM's take on the whole thing was "All you have to do is:"
- Load the software on the new server.
- transfer the data
- ship the server to the new location
- have the server racked and powered up
I could tell he though I was just being difficult when I told him:
- While we're at it we should upgrade the app that's running on it since it's no longer supported.
- If we upgrade the server will be running a different web server and therefore will need a new ssl cert.
- Get the network guys engaged so they can punch what ever holes are needed in the firewall.
- We'll need to do some level of testing.
- Notify the end users that the look-n-feel will change/new applets will be downloaded, etc.
And now, as far as upper management is concerned, I'm the one that is behind schedule...
Parent
Re:Understanding your art (Score:5, Insightful)
The utility program mentioned supported one of our products and was for inhouse use only. It had been whipped up quickly in the devs spare time, had no documentation, no time spent on QA, was not an official product of the company, and had a completely unfriendly UI because the dev had developed it piecemeal for his own use. Needless to say once it had been *sold* to a customer as a feature that attracted their interest enough to purchase our product, it became an official product and was quickly rewritten to be more presentable, but that developer told me he would *never* mention anything to a sales guy again because they couldn't be trusted.
I have seen sales people sell a product based on a feature that they assured the customer the product offered, then once the phone call was done and the sale completed, checked with Tech Support to see if it actually did offer the feature they sold it based on.
Parent
This just in. (Score:5, Insightful)
Phew!!! (Score:5, Interesting)
Thanks /. a copy of this story now sits on my boss' desk.
misleading headline (Score:5, Informative)
Re:misleading headline (Score:5, Insightful)
Parent
Merge it. (Score:5, Insightful)
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 [agilemanifesto.org] method.
Re:Merge it. (Score:5, Insightful)
Please...
I know it's Slashdot I'm reading, but I didn't know readers had that high thoughts about themselves.
Parent
Re:Merge it. (Score:5, Insightful)
I call this the myth (or culture) of managerial superiority. It tends to go "I'm your boss, therefore I must be smarter than you are." It's one of the reasons that some managers come to resent technical people, whose jobs require that they be smart, and who are not usually reluctant to show those smarts. Maintaining a culture of managerial superiority is difficult when your subordinates often demonstrate that they know more than you do. Too often, the result is either denigration of the subordinates knowledge (You were hired for your expertise in X, but your manager keeps on overriding you on matters relating to X, leading you to wonder "Why did they hire me if they won't pay attention to the knowledge I was hired for?"), or denigration of the importance of subordinates knowledge.
The fact is, management requires a different set of abilities, not necessarily a superior set of abilities. Acknowledge that, and you've at least opened the door for each side to recognize the others talents and use them together.
Parent
And in related news... (Score:5, Funny)
Where's the Obvious Tag (Score:4, Funny)
Oh, its late...
In other news (Score:5, Insightful)
Re:In other news (Score:5, Funny)
Actually, it won't be until 11:30
We're running late
Parent
Slashdot Already Proves This (Score:5, Funny)
95%... (Score:5, Funny)
... and the other 5% never ship at all. (ie Duke Nukem Forever)
Circular (Score:5, Interesting)
This is why (Score:5, Insightful)
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
I remember on my first web dev (Score:5, Funny)
Re:I remember on my first web dev (Score:5, Insightful)
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.
Parent
Not projects (Score:5, Informative)
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.
If an IT department never, ever is late... (Score:5, Insightful)
Adding requirements (Score:5, Insightful)
Sometimes some of the new requirements or wants involve going back and rewriting a good chunk of code, or changing the DB design, etc, no matter how carefully you wrote your code and flexible the code may be.
Correction: 95% of Schedules are Wrong (Score:5, Interesting)
Have there been any advances in scheduling technology? Like profiling developers over the types of software they write, etc.. ?
Canadian I.T. projects? (Score:5, Funny)
In my experience (Score:5, Interesting)
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.
Methodologies and the lack of it (Score:5, Insightful)
Second of all, rather than delving in to the varied array of processes and methodologies prevalent in the software development arena and reviewing advantages and disadvantages of each, the report goes in lenght talking about Vendor issues. I dont have a clue why.
Right from the Waterfall approach, or having no approach as well, we have RUP, XP and a mix of each playing itself out for the last few years. In my past projects, I have implemented each or a customized version of each and has varying levels of success. The biggest issue that I have so far seen is the lack of adequate knowledge in each methodology that someone who starts implementing any approach, either loses interest and resorts to a quick fix at which point the process starts to wither and die. More over, to some of the developers I have worked with, its not process, its documentation. CRC Cards is not a design tool, its documentation, its impediment to writing code. Much of it has to do with no academic background in best design or coding practices. They have heard of design patterns, and probably has used MVC to death, but when it comes to designing a system, its back to "lets start writing code rightaway and maybe the design will flesh out over time". The system gets built, but it suffers from Simplicity, it has very low quality.
I have seen a lot of firms talk about having a process, they love throwing RUP in the air, but nary a project which has successfully or much less adequately implemented any sort of process. They talk about Use Cases/ User Stories, but when the project gets kickstarted, they resort to SRS documents or less. And then they forget to adequately keep them up to date. Many even have Requirements management tools like Requisite Pro which hasnt seen daylight yet. Fuck the tools, atleast have a damn process. Many dont even define success at the outset of a project, no acceptance criteria either. They end up in a deathly downward spiral towards absolute failure dragging their clients with it.
I love XP, I love it for several reasons. Having a Client involved during all phases of the project, much less have a day to day interaction with the team is a phenomenal idea. I have had great success with this, but it becomes a bit of a problem, when the project is outsourced. No amount of communication (documents/mail/phone) can stand up to having a person next to you to tell you whats important and whats not. I love pair programming even though I could never fully implement it, when the client doesnt believe in it. I have tried pair design and have had great success. I have a few developers reviewing Test First Design and this has limited success as well. Limited, since the developers rebel, having low discipline and patience to write tests as they code. They are tutored and trained in the ways of "lets code first, maybe manually test it later and let the QA worry about it".
I would like to hear about other's experiences as well.
or (Score:5, Insightful)
Optimism (Score:5, Interesting)
Even with the benefit of fixing our estimates as we liked, the entire class did very poorly. The morals of the story were
a) people are over optimistic in the accuracy of thier predictions
b) even, in our case, when we could have given zero-to-infinity ranges, we tied ourselves to restrictively narrow frames.
I thought it was fascinating, it's one of the few classes I remember vividly.
story (Score:5, Funny)
The Three Failures of Engineering (Score:5, Insightful)
- 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.But what about non-IT projects? (Score:5, Insightful)
Let's see... Boston's Big Dig. Nope. Designing a new aircraft carrier... nope. Red Sox winning the World Series... badly delayed
I wonder if in general it's creative projects or maybe highly complex projects that suffer lousy under-estimates for completion dates. Many software projects (i.e., MS Longhorn) are both.
On an unrelated note: I wonder how project planning estimate accuracy correlates with the experience level of the person making the estimate. Because if the IT industry tends to burn out the young people os that there are't many older IT people, that could contribute as well.
Algorithm: why projects are not delivered on time. (Score:5, Funny)
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?
Yep. (Score:5, Interesting)
In my experience, a much higher percentage of European projects are delivered on time than US ones. The simple reason is that in Europe, engineers are more respected and are usually tightly involved with the requirements gathering/planning phase.
Unfortunately in the US it usual practice to keep engineers away from clients and only involve them when everything is already agreed on paper. This means that the engineer gets a garbled requirement to work from, and the technical decisions have already been made/commited to by someone without any technical skills (i.e. sales or management).
The net result is that the engineer is expected to implement someone elses bad design that usually misses important aspects or doesn't address the actual problem, in a hopelessly optimistic timeline. Furthermore god help the engineer if the customer isn't kept happy.
You have to lie to get the project (Score:5, Funny)
There are two type of managers. Let's call them "Honest Joe" and "Sleazy Bob". Both want to lead the project and must meet with the executive who can approve the project. This is how it goes.
Executive: "Hi Joe. Tell me you much this project will cost and how long it will take."
Honest Joe: "It's going to cost five million dollars and will take about eighteen months".
Executive: "Thanks, Joe. You're fired. Before you clean out your office, could you stop by Bob's office and tell him I want to talk to him?"
Bob walks in...
Sleazy Bob: "Wow, I really like your tie. You know, I saw that tee shot you made on number four yesterday. Absolutely amazing. Did you ever consider going pro?"
Executive: "Thanks, Bob. Now about this project. How much will it cost and how long will it take?"
Sleazy Bob: "Six months and a half a mil."
Executive: "Sounds great. Get on it".
Eighteen months and five million dollars later the project is complete and Bob gets promoted.
If I had a nickel for every time I've seen this scenario play out, I wouldn't need a job anymore.