Hi, I'm a Computer Engineering at CSU Chico. I'm conducting a research paper on "Why IT Projects Fail". If someone could give me an example of a failed projects, "failed" meaning that it didn't get finished on time, or the final project did not meet the requierments. Also if you could give a quick description of why the project failed it would be greatly appreciated. Feel free to e-mail me at dbrazeau1024@gmail.com. Thank you.

First of all, I absolutely agree with Bob’s points. I had a few additional thoughts:

+ A very basic reason for project failure is that it does not follow any formal project methodology, which, sadly, is true in too many organizations. Not folling project metholdogies will allow just about anyting to derail any project. It is harder to get a project derailed if a formal methodlogy is used.
+ A slightly different take on Bob’s 1st bullet is projects will get derailed if the requirements are not fully vetted and understood by all parties, and, most importantly, have senior management buy-in.
+ My last poiint is that many projects get derailed becuase there is no project change management in place, which allows scope creep.

That’s my two cents….Ken
=====================
I’m a little puzzled – I answered this the other day, and nothing ever showed up – which is why (I’m guessing) that you reposted. If you didn’t repost, then perhaps someone at TechTarget reposted for you. Puzzling either way.

Anyway – here’s a copy of my original reply.

———————————————-
Perhaps I should stand aside while the floodgates open…

Be prepared for many, many responses to this. Personally, I’m looking forward to collecting some more war stories from other folks. Meanwhile, I’ll offer some high-level generalizations, each of which cover much ground below. You’ll notice that there’s room for a lot of overlap – but I call them as I see them.

1) Projects in which the expectations and objectives were never clearly laid out.

2) Closely overlapping 1, 3, and 6 are those which caused “turf wars” within a given organization.

3) Projects which were meant to solve a particular problem, but in which the technical details were either forced on the project team by management (You will buy Brand X, Product Y), or in which vital interactive portions were never researched, but merely assumed to “work out”. I personally believe that the Denver Airport automated baggage handling system was one of these.

4) Projects which were someone’s pet, never wanted, needed or valued by anyone else.

5) Projects which got underway, but then suffered a large change in staff (technical and managerial) which devalued the need or relative priority. Major reorganizations tend to do this as a side effect.

6) Projects where it was politically dangerous (Think CLM=Career Limiting Move) to point out ANY shortcomings to ANYONE because upper management had a vested role or position. In many ways very similar to 3) above, but the key difference being someone’s ego being in the way. This is not the same as 4). Pet projects which are unneeded or unwanted simply languish because no one ever spends time on them except the owner.

7) Projects which threatened some other portion of an organization. Basically they were sabotaged. This is similar to # 2 above, but in the case of #2 participants killed it. In this case, an “outsider” killed it.

8) Projects which died due to simple incompetence on the part of technical and/or managerial staff. This one is last for a reason – I believe it’s the least common of all the others.

Now, let’s all sit back and watch the horror stories roll in.

Bob

************************************************************
IT Projects fail because of many reasons, few of them could be:
Wrong selection of product
Wrong people driving it
Wrong strategy
Wrong implementation partner
Wrong roadmap
Wrong milestones
Wrong goals
Wrong requirements
No or very low top management involvement
IT project taken as IT project and not management project

************************************************
I have found that when IT projects fail, the reasons are similar to when a theater performance fails. Both a theatre troupe and a programming group have a number of similarities:
1. Often have a widely different back ground from others in the group.
2. Are very creative
3. Tend to be better read, and more confident in their subject knowledge
4. Usually have a bit more ego than average.
5. Are usually very individualistic.
6. Are more devoted to their “art” than to any one project or show.
7. They tend to get personally involved with their “part” and criticism of ones work is taken personally.

The main failure (IMHO) comes when the entire cast fails to buy into the unified image as set forth by the director. There are often differences of how various parts of the final product should be achieved, and what they should look like when they are done. You will have visionaries who will severely underestimate how long a certain task will take, or how much it will cost. You will have those who are so bolted into one mind set that they will frustrate the creative efforts of others. I have only worked on a few software development projects, and even those mainly as hardware and network support. One place had a sign that hung on the wall in on of the development “cube farms” I liked it:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

Processing your response...

Discuss This Question: 31 &nbspReplies

There was an error processing your information. Please try again later.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

Ok - just like all the folks I love to blame - I failed to read your question as written! And people wonder why IT projects fail.... Seriously though, there was a very real project which I will call "X". It was a remote-desktop control tool which would allow the help desk to diagnose and fix problems for remote users - mostly sales folks.
There was a manager named Tony who insisted that the product named "X" was the solution to all of our problems. This particular example fits profile #4 as described above/previous answer....
He deeply believed that "X" would save the company. Problem was that nobody else believed it, and rather than do any real research to find out some facts, he just pressing for the implementation of "X".
"X" might have been a good thing. I don't know, and will never know. Since Tony was already regarded as an idiot (by me as well) by most folks who had the misfortune to work for him, he never got credit for anything, since most of the things he asked people to do were counter-productive, he managed to spend between 1/4 and 1/3 million dollars on a doomed project.
The key historical points being that while he insisted that "X" was a good product, and would solve our problems, he never actually bothered to get real-time data on whether or not "X" actually worked, on whether or not "X" was being used by the help desk, on whether or not "X" was useful to the helpdesk (or their victims - pardon me - clients)
After 2 or 3 years, he gave up on "X" (which might have actually been a useful product), and it died as "shelfware", meaning that it was bought and paid for - but nobody ever paid it any real attention. After all, it wasn't "our" 250-350 million dollars that was thrown down the drain.
Does that help?
Bob

Projects fail when the intended recipients of the new hardware/software are not kept in the loop or not made part of the process. In this case it was a software package that was completely different from that last 5 years software. The employees were told, get over it and use the new one. They revolted and when their manager did not respond, they went higher to the corporate office. The manager and everyone related to the project were reprimanded or fired, and the old software restored. If the employees would have been consulted and made part of the 'team', the project might have been successful. If managers are not part of the team, the failure rate increases, also.

Hello,
Having been around the ring with many different projects from brand new construction to refurbished buildings, I guess I should take a poke at this.
1. Having engineers that do not actually think about what they put on paper, for instance.: Setting up a run of fiber and copper, 4 innerducts 12 300 pair ARMM cables all in a 8"x8" raceway which works quite well then expecting all these cables to fit in a 6" dia. pipe. (do the math)
then when confronted with the simple problem, telling the contractor to "go ahead" so now you have the provebial sqare peg round holt thing going. Simply put not thinking about what you did. This pipe was put in the pedistal that supported a whole building, 12' thick. It took the head contractor a week to safely cut the pipe out from around the cables and insert the same 8"x8" raceway. total cost,
$500K in fines labor and other.
2. Using unexpierenced engineers/ managers to quote a job.
When doing a cabling job, not knowing the formula for running wire can cost you your job. Took a measuring wheel and ran up and down the walk ways measuring the footage, forgot about vertical and linear obstructions, did not even get on a ladder to look in the drop cieling. He was fired due to lack of materials needed, and the company had to suck up the loss. (he had a degree, but no common sense). The cieling had ductwork everywhere for the air conditioning system. He did not measure the vertical rise needed on both ends. Special note( rule of thumb after you measure everything, add 15% to total length, just to cover eventualities).
3. Relying on subordinates to think or cover everything.
Nobody is responsible but you, they will not be as thorough as you, always get out there and eyeball every job. New manager comes in, starts being Nazi about when people get to work, ordering people around and being a general $#^!head. The employees set him up to fail, he didn't know the ropes. Treat those under you with as much respect as those over, either can make or break you.
4. Subcontractors, they can be the worst offenders, some companies go out bid a job at there rates then subcontract out to another company whom do it down, dirty and as cheap as they can get away with it. Make sure your spec. sheets are specific about liabilities and the scope of the work.
So as you can see there are many weak links to be covered,
no one person knows it all, so make a good working team, this doesn't mean you have to put up with certain types, but you should always be certain that everything you do adds to the project instead of taking away from the project. Learn about the job from msomeone who has actually done it, and the books too. NEC (National Electrical Codes) EIA/ TIA standards must always be met, but research local codes as well. It always has to pass inspection.
Sorry to be long winded, but I've been around the block from ground up. Good luck in your studies.

First I would like to point you to a book called "The Mythical Man Month" by Fred Brooks. Mr. Brooks was the project leader for the team that developed the operating system for the IBM System 360 in the mid 1960s (and happens to be the computer system that I cut my teeth on). The project spun out of control early on, and Brook's analysis of what happened and why is illuminating for all of us.
I have two examples of failed projects, both of which I worked on as an indepentent contractor.
The first one was implementing a financial reporting system for a very small business (four employees). We did what we thought was a thorough investigation into the variations of input parameters needed to be considered and what the reports should contain (the reports went to four different agencies for perusal and settlement). As the project progressed we kept getting pieces of information of the "Oh, we forgot to tell you..." type. And then it turned out that the agencies had much different procedures than we had been led to believe. We abandoned the project when the company ran out of money. I don't think they could use any part of the system we provided for them. Sad. There was no deliberate hiding of facts on their part, just being so immersed in the day-to-day things they did that they neglected to tell us about procedure that were automatic to them.
The second project was for a large national research bureau supporting one of the public utility areas. We contracted to implement a program that would allow managers of power generating plant to mix and match fuel properly. Using some of the skills we had developed in the afore-mentioned project, plus the knowledge we had gained in probing more deeply for "what do you REALLY want this application to do," we spent several months interviewing the end-users, which included the managers who would be the end-users, as well as technical folks who had the knowledge of how the fuels really behaved.
We implemented a prototype which we demoed at one of the user conferences that happened quarterly. The prototype was a big success; everyone loved it (which they should have, since they "designed it." Then, when we got down to business implementing the final product, we got into a cycle of "we need to add this capability," and "we have to cut $10,000 (or $50,000) off the project." This happened 3 or 4 times as I recall. Needless to say, the finished product--the product that resulted when the money ran out--did not work. And we were blamed for the failure. This time there was deliberate misleading information (re funds available) as I found out later. But everybody lost on this one.
Are you sure you want to get into this business?
Good luck,
Phil

Two things now are the bane of all American projects: offshoring/nearshoring I.T. work to other countries who have no clue what we do here; and h1b visas, bringing in labor from other coutries, that are a little less clueless, but still not up to the bar that the American I.T. worker can achieve. Globalism is the wrong way to go with programming and we should all work in our own countries and not in someone elses. Period.

Your best source regarding project "failure" is in the government arena, not as much because government projects fail more often, but because a lot more of the information about those projects is public. The FBI recently ditched a project named VCF - virtual case file, and you can read various reports on what went wrong.
Be careful about the term "failure" because there is a big difference between projects that "fail forward" and just plain fail. My guess is that by your definition (late, didn't meet all requirements) the early versions of Microsoft Windows and of SAP R/3 were "failures." On the other hand, those early version "failures" also represented progress toward the funding company's realization of enormous business franchises. The third versions were worth many billions of dollars. Therefore, projects that fail but that also move the company ahead may be more valuable than projects that succeed but that address trivial goals. In contrast, "fail backward" projects take the organization in some direction contrary to "progress" and therefore are even deeper failures than the direct loss on the project would indicate.

I disagree that H1B and offshoring would cause a project to fail. I do agree that you may have to spend some more time and effort to ensure that what you think you say and what they understand you to say can be radically different. This unfortunately is not just limited to using workers from other countries.
Most projets fail due to objectives of the project not being clearly defined. Sometimes the customer does not know what is technically possible and sometimes the technical department does not know what is practially feasible. Throwing more resources at a project sometimes slows it down.. For instance, in a programming project with a small team there is less need for formal meetings and get-togethers to let everyone know what is going on.. Sometimes losing sight of the objective causes the project to fail i.e. when you are up to your a$$ in alligators it is hard to remember that your objective was to drain the swamp.
Each large project cam be broken down into smaller more manageable units and even the 'smallest unit' can also be broken down even more and more.. You also have to have the right resources available at the appropriate times.. Having the plumbers wait on a housing site while the foundations are being dug is a waste of resources.. then again once the interior wall are up is not the time to bring in the electricians, plumbers and HVAC personnell.. but having the drywallers sitting around also wastes resources.. Ergo, proper planning is a major item to be considered.
Then there is the cost/benefit ratio of the project itself.. if the project costs $1000 and it saves you $0.01 per 1000 units that you sell 100/week where is your break even point..

#1: Insufficient Planning.
#2: Inadequate Management.
Everything else is a function of these two, things like "we ran out of money" just mean it was not planned and scoped properly, and "nobody could have known that" means that risk management was poor.
IT Projects are no worse than any other type of project. Scope carefully, allow for risks and build in a margin and you can succeed.
The two biggest problems with IT are that non-IT managers think IT is a cure-all, and IT managers get seduced by flashing lights and sexy hardware...
NickB

There is one item that I haven't seen mentioned yet, and that is a change with a vendor that cannot be forseen. Case in point:
My company implemented a barcode system to track items between different units using a vendor's label printer recommended to us by our vendor for the barcode system. We began purchasing these printers and had deployed over 100 of these label printers. Then the printer vendor announced that they would no longer manufacture these printers, but that a new printer would replace this printer that they were phasing out. After discussing with our hardware supplier and purchasing the rest of their stock of the old style printers, we contacted our software vendor to see if they would offer support for the new printer. We were scheduled to deploy 50 more printers, but had to wait six months while the software vendor added support for the new printer. We were stuck with a project on hold for a long time (we are just now starting to move foward with this) until both vendors worked out their issues and we could adequately test the new printers on our system.
There are thousands of reasons that projects fail or are delayed, but if planned correct, most succeed albeit with a few problems along the way. If there weren't problems, we wouldn't have jobs!

I have been involved with a project where so many things went wrong that the project was doomed to fail from the start of year 2. This involved a project that initially spawned a very large initiative by a higher Government and was outrageously successful in year one. The Manager of the project left and took a couple of key people with him. Fortunately the system admin was not one of those taken as he was very bright and very effective. The Steering Committee hired a replacement for the Manager and then the trouble started. The new Manager was not an easy person to get along with by any means and caused all sorts of trouble for the Sys Admin. I found a short time later that his education was in the '70s and he had not in fact kept up to the world of computers. Thus, the system and project he was hired to manage suffered because he didn't understand the technology. There was also a strong political problem and several things took place on that score. The unfortunate problem here is that many of the peopl on the Steering Committee didn't understand things well enough and one of the founders of the Project was removed from the Committee at the Manager's insistance. Yes, the project failed miserably and we were left with only the knowledge that similar projects that were based on this model succeeded in other places around the country. We are still reeling from this one.
So, to sum up and add to what has already been said, I have seen projects fail due to lack of knowledge on the part of people directing projects, people managing projects, politics and ego. There are also the pie-in-the-sky projects that should never be attempted as they too are usually doomed due to reasons I have outlined and those of my colleagues above.
Best,
Paul

In other words, what did your $200M buy (or not?)?
1. Who is in charge here?
Contracting agency wanted to manage program. previous program to do same task had failed.
TIP: You contract because you can't do it - let contractor manage it. You are buying their expertise.
2. who is doing the work?
Contracting agency staff, contracting agency's site contractor and program contractor were thrown together to work program. Several reorganizations took place to integrate or separate, and change tasks took place. Civil servants wouldn't/couldn't answer to contractor supervisors, etc. Site contractor had its own agenda at times.
TIP: If you can't do it internally, contract for it. If contracting out, let contractor do it.
3. Requirements, scope creep (part 1)
Have requirements. Monitor for scope creep, changes. Keep requirements focused on goal.
4. Requirements (part 2)
Reject introduction of irrelevant "requirements".
5. Requirements (part 3)
Regulations aren't scope creep. You can't ignore them just because contracting party or contractor was ignorant about them when writing contract.
6. Requirements (part 4)
Address new regulations when applicable to program. Failure to comply means failure.
7. Who is contracting whom? (who is in charge here?)
This agency had a site contractor that maintained their systems. Program contractor was to perform upgrades. Program contractor was a professional services agency. Site contractor was primarily an industrial support company (lots of "type X personalities"). This was a major conflict in goals, attitudes and approach. Site contractor imposed superfluous and onerous requirements and procedures on Program contractor (program contractor was probably did not have prior knowlege of these).
8. Metrics? what metrics? ("1, 2, 3, ummm . . . 6?")
At one point, program declared that due to an impending release on schedule, a party would be held in celebration. This was about a month in advance. A couple weeks later, it was discovered that the program was a few months behind.
(Also, in one unrelated study, of just less than 100 projects that went "red", only 7 knew they were going "red" in advance. Apparently, only 7% had valid metrics and/or understanding of Value mgt).
TIP: Learn, love, breath, live (or die by) Value management. Value lives at the junction of cost, technical and schedule.
9. Top-to-bottom communication
Management had no communication with lower-end staff (see above). Problems at work were not flowed up adequately.
TIP: Email isn't a communication media. Talk. Watch.
10. Management speaks another language.
Managment doesn't understand. Not even the threat of infosec incident taking control of mission critical systems (impact to life and costs of up to several billion US$ possible) got through ("You can't install intrusion detection on a mission critical system - its critical") Translating from information assurance to mission assurance made some difference. Talk risk, not firewalls. Talk value.
. . . Or not. In November 2002, program was cancelled despite investments of over $200M US.

Looking at jobs requirements for project engineers (I'm looking), it looks like people are asking for PMI (pmi.org) certification, or at least know what that means. After you graduate, I would join them (or join now) and keep up with their body of knowledge.

PaulHinsberg mentioned there are 3 components required for projects to succeed: Time, Resources and Manpower. I would add two others: a plan and user buy-in.
There are four failed projects I can tell you about, each failing for different reasons.
One project I was involved in a number of years ago was installation of a system upgrade which involed installing new versions of the operating system, CICS and database. Fortunately this was during the summer months in the school system, so the impact was imperceptible to the users. We ended up being down for the better part of 12 days because of a couple of bugs in part of the database software. Record locks were not being freed which caused CICS to queue tasks waiting for DB resources. This caused the CICS task queue to fill which locks up the system. We finally go in touch with one of the guys at the development lab in Germany who knew what the problem was, so we followed his advice and dropped back to our old releases and waited for the subsequent release of the software. We had planned for everything except a bad release of software :-/
Another large failure was at the state level (no surprize there). This one was to provide a single system for the child support offices of the counties (except the state of Los Angeles). Every county would have the same software, but different sized systems. Lockheed got the software contract and Digital subcontracted for the hardware.
Initial releases were sent out to the counties so they could begin getting used to it and train their personnel on it prior to the implementation; also to shake out any bugs. The system actually went live in about 12 of the smallest counties for a short time. Then all Hades broke loose. Word got back to the other larger counties that the system was extremely cumbersome and took twice as long to do the same tasks on the old systems... including one small county which had not been automated in this department. The remaining counties slammed on the brakes telling the state they were NOT going to the new system because there were too many problems.
The result was that the project was terminated in 1997 after spending $344 million or more. There were any number of problems in this, but the major problem was that the designers of the software never went into the field to observe how the family support officers did their jobs so they could keep things as simple as possible, and in the end none of the users bought into the system.
Another more recent failure was part of a mainframe elimination project - I won't mention any names. The CIO decided they were going to become a Java and Oracle shop. Like a number of us these days this installation decided to eliminate their mainframe and move to another platform. The CIO decided (see a pattern yet?) that they would convert all their legacy COBOL code to Java and convert their database to Oracle. The product they bought to do the COBOL translation was little known. It converts COBOL to Java runtime but does not provide any source output. The CIO decided that once they got everything translated, tested and put into production, they would then begin rewriting the entire system so they'd have source for the future and could do away with having to make changes to COBOL code then translate them to Java. They figured they'd probably spend about $2-3 million. I did my own calculations based on conservative figures for personnel costs plus actual numbers they provided and figured this plan would end up costing them (if it succeeded) about $11 million... did anybody look at ROI?
A number of problems cropped up. The database interface program had to be modified many times and kept growing in size and complexity. Next, they found that any program that printed (whether batch or CICS) would not run properly. Then there was the batch environment itself. Not only did batch programs have problems, there was no job scheduling system to replace what they had on the mainframe. I recently heard that after two years (and still in test phase with the same old problems) they abandoned this approach, hooked up with a consultant and are looking at one of the more popular methods of migrating mainframe applications to Windows/Linux/UNIX platforms.
This project failed for a bunch of reasons, not the least of which was total lack of planning, in fact, they probably hit everything bobkberg listed in his post and then some -- including absolutely NO user department involvement.
The last project I'll cite was one within my department which was to provide automated statistical reporting to the state for our Courts. I don't know many details of the project because I wasn't assigned to it, but from what I've seen and heard, it exceeded both budget and deadline.
The problems I saw were poor project management (got it started and never really checked the status and/or failed to control the team working on it). Of course that had to include poor estimates for the project as well. The analysts working on the project were exceedingly anal and rather than doing things a simpler, quicker way, were totally determined to restructure the database and add tables to make the system create the files that would be reported. The customer got nothing for the nearly $800K spent.
I was assigned last year to a follow-on project to complete what the first team was unable to do. We began with an accurate project plan, got our now reluctant customer to buy in and we got started. We had weekly status meetings with the customer continually involved in the project. We tore out everything the original team hadn't put into the production database and used a much simpler method to get the data needed for reporting. In the end, we finished the project under budget and on time and the customer was extremely happy -- to the point that they are willing to give us more work. Needless to say, our group manager is not the same as the one who lead the failed project.
On every project we do now, we use a specialized spreadsheet to manage the project. Every task is tracked and the stats feed a chart that tells us exactly where we are at a glance. We can make any necessary adjustments quickly and keep the project on track.
If any of the above needs clarification, feel free to ask. I've had to put this together in pieces between interruptions... they actually expect me to work while I'm doing this ;-)

Maybe one reason that projects fail is that people tend to rush into things without asking some basic questions first. As an example, take a look at how many respondants to the question have described project failure before exploring further what you actually mean by project 'failure'. If we limit ourselves to over-runs (or under-runs!) of the three main project management measures (time, cost and quality/deliverables) then that can serve as a definition but doesn't consider things like whether any benefits were achieved from the project.
As a simple example to ponder - a project takes twice as long as its estimate, costs three times as much and delivers only a quarter of the specified functionality. Is that a failure ? Most people would say that it's a no brainer.....However, what if as a result of the project, the benefits achieved are a saving of ten times the cost of the project, increased profitability by 30% and a halving of ongoing costs ? Compare this to another project delivered on time, to budget and specification but for which no benefits have been achieved. Is this a success or failure ?
Gary
Gary

Hi dbrazeau1024,
You've already got many excellent posts with the reasons for the failure of IT projects, so I am just going to point you to some real examples of very high-profile Government IT projects that have gone pear-shape in Ireland recently.
From the Irish Independent newspaper (you need to register, but it's free):
?150m bill for sick computer
A staggering ?70m of taxpayer's money has been splashed out on consultancy fees for a computer system that may never be fully used. There are massive overruns.
http://www.unison.ie/irish_independent/stories.php3?ca=9&si=1481205&issue_id=13089
?27m blown on 'tamper-proof' passports fiasco
The Government is at the centre of a fresh controversy over the squandering of taxpayers' money on a new "secure and efficient" passport operation system.
http://www.unison.ie/irish_independent/stories.php3?ca=9&si=1484787&issue_id=13116
?3m spent on website that never existed
A showpiece ?3m health internet site set up by the Government never existed. No one can access it and - like the other recent major computer debacles - no one is 'responsible' for it either. It has the wrong specification, so it never did what it was intended to do.
http://www.unison.ie/irish_independent/stories.php3?ca=9&si=1485981&issue_id=13123
Good luck with your studies!
H

8 out of 10 IT projects fail as many IT project managers are not aware of PMI's body of knowledge, project lifecycle and software development lifecycle (Note: knowing "programming" is different from knowing software development lifecycle). If a knowledgable person with PMP certification with some or little knowledge of IT is appointed as a project manager , chances of dooming an IT project are greatly reduced. A PMP without IT background can successfully pull off an IT project if he/she possesses extraordinary set of inter-personnel skills and communication skills. Skilled IT persons without PMP background ends up executing 8 of those projects mentioned above.

Some of you guys asked to clear-up terminology re PMP and PMI in my message above. Here it is.
In recent years project management field has become rich enough to warrant its own professional association called 'Project Management Institute' (www.pmi.org). The association has emerged as a de facto international standard and publishes project management bible called 'A Guide to Project Management Body of Knowledge' (PMBOK). It also offers certification to project managers as 'Project Management Professional' (PMP), which is internationally recognized and boasts close to 100,000 PMP's world wide. Hope this helps to all those aspiring to make a career in project management field.

people who do not have good organizational skills.
priority?s in the construction process of what has to be done in what time frame. how to set and meet those goals
with in the frame work of what you are given the military rocks at this

In addition to all the cases described in previous responses there are two aspects which you might consider both of which relate to the delivery of tangible results .
Delivering something ,which can be further developed to the desired solution is often neglected in favour of political , planning and organisational considerations all of which valid but external to the target result .
There is no replacing the confidence and enthusiasm felt by a customer when they see tangible progress and this is often enough to restart a stalled project .
A recent project for a billing system replacement highlighted both .
- Lack of domain experience - whilst integrators may have experience in software delivery ,maintaining expert knowledge of the particular environment in which the delivery is to take place is not always easy . This means that an educational cycle is necessary which is called "requirements capture ". The case in point in which consultants were hired to rescue an ailing project proved that the lack of domain knowledge led to the consulting team extending the requirements cycle to over 8 months , essentially learning the business on the back of a supplier contract .At the end of this period no tangible deliverables were forthcoming and there was no flexibility or know how in maintaining parallel threads within the project ,with the result that the client was increasingly alienated . Domain knowledge is irreplaceable which leads me to the next point .
- The project methodology - although essential must be tailored to the circumstance at hand . No methodology is
adequate for all purposes or for all stages of a particular project . Whilst a waterfall method is ideal for well defined soultions this may not be suitable for
experiemental work where some element of prototyping is necessary in order to make a decision for the next stage .
In the case of this particular failed project there was a swing from complete lack of planning to a rigid waterfall method ,this pushed the delivery time scale even further out into space not taking into account that for every passing day the dynamics of the market place are changing
( in this case the application was mobile telephony )
Consoidation should not take longer than the project budget
will allow otherwise it has no value .
Again , this project would have benefited from a short sharp ,cycle with tangible result, under methodology , in which all parties would have gained the necessary confidence in a deliverable to go forward .

Would I be correct that you're questioning why IT projects fail more often than other more concrete projects? Here are some of my favourites:
1) The project is running over budget so someone high up in the organisation decides to bring it back to budget by reducing the scope. Trouble is, they don't know/haven't read? the reasons for the bit they draw a line through,
2) Government ministers love HUGE projects. The bigger the better - there's soo much prestige attached to spending billions of dollars on systems that will integrated everything and do anything that anyone wants. So lets call in a gazillion consultants (who on occasion seem to be worse than useless) and make this thing zing. Trouble is that the big bang simply doesn't happen because the huge system fails to take account of the everyday (small) needs of average users.
3) Scope creep. Sigh. If I had a dollar for every time somebody thought that this project would be an ideal opportunity for doing that (often unrelated) function...
The top and bottom of it is, I believe, more subtle though. When I build a wall, I drop the foundation in according to the design. If the design is right then the foundation is right...and if the foundation is right the wall will stand up and if the wall stands up...
With IT I have never (never, never, ever, ever) discovered an organisation that is willing to spend the time to design a piece of software thoroughly. If such an organisation did exist, then I believe it will be producing software that is years out-of-date. It's the very speed of IT development that means that IT professionals have to be fleet of foot and constantly implementing newer (and sometimes better) ideas. And it's the same speed of development that makes IT projects significantly higher risk than other more concrete implementations.

IT Projects failo because they're treated as though they were pure IT projects. Almost all IT projects require change. That requires people to understand, value and accept them. Just training on how to be a good "user" isn't enough.
"Ready, willing and able" starts with "wanting to". The history of most past IT projects doesn't help, so you start with an orgaization's hope "that this too shall pass" leaving you behind before you start.
No one trusts the "value statements" anymore based on past promises made and not kept. "What's in it for me?" becomes the predominant test question and it better be godd and more credible this time than last.
The single best strategy to succeed is to start with the informal leaders in the organization and getting them to help you plan how the new system could be implemented best, listneing to them and keeping them convinced throughout the project that this is really best for them and their constituents. Sound easy? it isn't! That's why IT continues to try to ignore the reality of what an IT project really is- People changing!

Surely one of the fundamental problems with IT projects is that one basic stage has probably been omitted (because top management is afraid of the possible consequences).
The initial stage of any big project should be to undertake a complete process analysis exercise, i.e. look at and document all of the current business processes (in all the affected departments), and then analyse them - in most cases it should be possible to rationalise those and dramatically reduce the complexity of the desired solution. It is only AFTER that stage has been performed that consideration should be given as to what form of IT application(s) will best suit the new revised business processes.
Of course the big implication of this approach is that there will be changes in the activities of various staff members. Ideally this needs early management involvement to 'sell' this new approach to the staff, i.e. the need to justify why such changes will actually be advantageous to the organisation and hence to the (majority of) staff.
But, hey, that could be awkward for managers to deal with, so let's skip that stage all together !!

An IT project fails because :-
The scope was wrong
or the budget was wrong
or the timescale was wrong
or the resources were inadequate
or the infrastructure was inadequate
or the solution was wrong
or the testing was wrong
or the implementation was wrong
or the training was wrong
or the users weren't involved
or the users manager wasn't involved
An IT project succeeds because :-
The scope was right
and the budget was right
and the timescale was right
and the resources were adequate
and the infrastructure was adequate
and the solution was perfect
and the testing was perfect
and the implementation was perfect
and the training was perfect
and the users were fully involved
and the users manager was fully involved
It's a wonder that any IT project succeeds!

Talking about software projects, I think that analysis is the most important phase of the lifecycle, and the resources (time and people) assigned to it are frequently insufficient, or in some cases this phase is omitted. Note that analysis does not only include the requirements and the process analysis, but the technical, economic and operational feasibility. A bad analysis may result in project "failure".
Estimation (time, costs, resources) and planning are basic steps as well, and the plan must be flexible and it must consider all the possible problems that can arise, and the concrete solutions for each one of them. Project management is vital for success.
This takes time, but reduces (not avoid) the failure risk.
Regards,

dbrazeau1024 asked for examples...
We developed a few years ago, a project for inventories control, in response to a requirement from the Administrative Manager.
He requested that it was not allowed to make certain transactions, if the user had not made certain procedures in the system; which sounded logical, but, to save time, a thorough study was not made of how this would affect other areas, one of which had such amount of operations, that it had been impossible for them to fulfill that requirement.
When the solution was presented, the affected area rejected it, with reason, and was necessary to make great modifications so that the system could work.
What was the main reason of the fault?
the request was good, and would allow a better control, but it was not operationally feasible. The feasibility study had not been made.
Thanks,

For me, the definitive answer regarding programming is in "The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition (Paperback) by Frederick P. Brooks " ISBN: 0201835959.
Whilst written some years ago, all of his comments (and all but one of his predictions) remain true today. (The only exception is that more powerful PC have allowed a working intellisense.)

Most IT projects fail - like most human communications fail - because of unset expectations. Not getting *all* the key players on the same page by properly communicating what's going to take place and who is to do what. It really can be distilled down to that.

There are several reasons for project failure. The most obvious and sometimes overlooked reason is that the project does not follow the first rule of engineering, the KISS rule or Keep It Simple Stupid, of course this is normally taken care of in the discovery aspect of the project, but you would be suprised in the number of projects that get started without the proper discovery in place. I have also seen projects fail because there is no one person who takes ownership of the project. With no Owner, MGR of the project there is no one accountable to see if things are getting done and if they are correct. I work in an IT dept. for a company with 16 remote locations across the United States with over 500 Active
Directory Users, our IT staff totals 10 and 5 of these are in house programmers. Our programmers are constantly putting out fires instead of working toward the future, the reason they are putting fires out all the time is the initial discovery and scope were not completed correctly. The best course I ever took was a class at our local community college and it was Systems Analyis and Design. It pretty much covers everything that has been said in this post.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

Processing your reply...

Ask a Question

Free Guide: Managing storage for virtual environments

Complete a brief survey to get a complimentary 70-page whitepaper featuring the best methods and solutions for your virtual environment, as well as hypervisor-specific management advice from TechTarget experts. Don’t miss out on this exclusive content!

Share this item with your network:

To follow this tag...

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy