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, Insightful)
Managers just seem to cut it out of plans because clients don't like paying for it.
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
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)
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.
And in related news... (Score:5, Funny)
In other news (Score:5, Insightful)
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)
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)