10 reasons for IT failure

10 reasons for IT failure

Summary: Readers of this blog know IT initiatives generally fail for business, organizational, or cultural reasons. Sure, technology screw-ups occur all the time, but that's one of the realities to be managed. Success or failure ultimately depends on how project leadership manages the full range of technical- and non-technical issues.


10 reasons for IT failure

Readers of this blog know IT initiatives generally fail for business, organizational, or cultural reasons. Sure, technology screw-ups occur all the time, but that's one of the realities to be managed. Success or failure ultimately depends on how project leadership manages the full range of technical- and non-technical issues.

Blogger and enterprise architect, Mike Kavis, who's obviously been through some battles, has created ten guidelines describing critical areas of weakness in many projects:

  1. Poor Communication. Enterprise projects usually impact a large amount of people. This requires constant communications to all levels of people throughout the organization. A strong communication strategy can help with this.
  2. Underestimating or ignoring impact of change. This is another way of saying poor change management. People need to know WIIFM (what's in it for me). Resistance to change can kill any project. Your initiative must have a champion who carries a lot of clout.
  3. Lack of Leadership. IT Leadership requires excellence in three key areas: Technology, Business, and People. If the leadership is missing any of the three components you are doomed.
  4. Lack of strong executive sponsorship. For these projects to succeed you must have somebody high up in the organization with a lot of clout.
  5. Poor project management. Often, large enterprise initiatives have a ton of logistics that need to be identified and managed accordingly.
  6. Poor Planning. This could also fall into a category of unrealistic expectations. Initiatives like SOA require a well thought out strategy. Many IT shops do not have the patience for this and rush into their project head first without a clue of how to actually accomplish their goals.
  7. Trying to do it cheap. Organizations want it all, but they don't want to invest the time and money. I have seen many projects get completed using this strategy, but they almost always run over budget, are late, are missing many features, and have many various quality or process issues due to the quick-n-dirty approach.
  8. Lack of technical knowledge. You wouldn't ask me to remove your appendix so why would you have somebody with little or no knowledge of the technology at hand lead your enterprise initiative.
  9. Lack of sound business case. You can get all of the other issues right but if your solution has no business context then you are wasting your time.
  10. Poor vendor management. Somebody hires a high priced group of consultants and let's them run wild. You should make sure that what they build meets your requirements, your standards, your needs, and your timelines.

Whenever I blog this kind of list, some commenters invariably say the whole thing is obvious common sense and therefore not worth consideration. If so, then why do so many projects fail precisely due to items on this list? Complex projects are hard to get right, which is why IT failure remains a serious issue.

Successful leaders create project success on the foundation of skillfully managing people, process, and technology. While this perspective may appear obvious, the experience and wisdom needed to make IT projects successful is not common at all.

Topic: CXO

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • The number one reason...

    I still say the number one reason for failure is the mind set that in some magical way IT project management is different than other diciplines. (Engineering projects as an example.)

    One of the short comings I see in most curriculum for computer science majors is there is nothing about project management. It seems the assumtion is that given the technical skills people will some how just figure it out on their own. They are wrong, good project management is a skill set of its own.
    • Most professional project managers are CS majors

      I completely agree with your point. The skills set of CS and engineering are completely different from those needed by professional project managers.

      Engineering is about details of science and technology; project management is about details of relationships, time, and money. They are definitely not the same.
      • The sad thing is

        IT people get thrown into project management without the begin of a clue how to go about it. Even sadder is they lack enough experiance to say no.
        • Bingo

          This is a real cancer where I work. You've got good ones, of course, but so many bad ones that result in failed projects (or ultimately "success" but late and way over budget) as well as staff leaving because they can't take it anymore.
        • Set up for failure

          I can't tell you how many times I've seen people take on projects that are destined to fail. It would almost be funny if it weren't so sad and common.
  • RE: 10 reasons for IT failure

    It managements failure because they don't stop people who as we say do the "I want a pony" factor. when I say that it weak management who let the morons run the show.

    As for purchasing items someone comes in and picks a national chain and they get ripped off in prices and its like tossing dollars out the window. Thats because these people don't see anything but a expensive way to order parts.

    Another faulure is you have network printing and then eveyone want a deskjet printer and your management gives it to them. Or managers ina another deprtment just go out and buy printers and expect the IT dept to set them up and the IT managers cave in. its called the lack of backbone management.

    Also you have your managememnt that rules with emotions instead of their brains. For example they worry more about the people working instead of worring about the sever with all their data thats about die. in this cast the manager should be fired from his job so the server can be fixed or replaced.

    My favorite is users who think they know more about the network than you. I worked ina IT dept that walked out after a few users said they knew more than us. We all took a week off and did not worry about what was happening and when someone called our cell phones we told them to talk to the employees who said they knew more than us. Upper-management was not amused at what we did but we told them our points and in turn they told the so called employees who thought they knew computer networks to shut up or be fired. I bet allot of IT people can relate to many of my listings on here. love to here from them.
    • Everyone has a cousen who knows networks.

      In Washington state Senate bill 6776 addresses this and passed into law. The bill was an outgrowth of a boss bully bill that comes up every year but 6776 basically addresses the notion that information techicians are like scientists. They are allowed to speak up about techical issues that are not in agreement with management portrayals and if disciplied for that the IT employee can apply laws involving retaliation.

      When the project goes bad and folks are suing other folks it is the IT professional who is the credible witness and not a lay person. This is why legals hire folks like us after the fact. A little attention to this up front would do a lot for project management. You might hire an electrical subcontrator and then have him install components that are not standard but that subcontractor is going to speak up about it. Same is true for any profesional in the building industry and it has become true in Washington state via this 6776 thing. However - I am not a lawyer - this is just the law man's take on it. In anycase thank God for IS 29500. Every standard our industry comes up with makes our job and the vendors jobs easier. We will be seeing more successful IT projects because of it.

      Frank L. Mighetto CCP
      • Ethics and projects

        PMI, Project Management Institute, has as part of its certification a section on ethics. i.e. it's your obligation to do what's right and report if it's not.

        Many of the posts here are correct about project leadership. Most PMs are 'accidental.' They're either engineers or developers asked to manage all the elements of the project on top of doing the technical work. Kinda like your wife expecting you to keep track of the kids while you're under the car fixing something. When companies take PM seriously, changes will appear.

        F Polack PMP
  • Cheap is as cheap does.

    And having explain to the upper echelons why the multi-thousand dollar application they bought into, despite being years old and on the face of it "stable", has dozens of aggravating quirks.

    No wonder tech people lack communication skills. If not for other reasons, they certainly don't want to cover up for the brainless marketers who say "Use Mail Client 7; it's got all these features!"
  • Poor vendor management should be higher

    You wouldn't decide to be your own general contractor for your new house building project and then treat the subcontractors poorly but that is exactly what happens on to many IT projects. The subcontractors get the word out very quickly in the home building industry and that has become true for IT projects as well.

    Eventally the project manager (you in this house building project example) has to be replaced because he/she no longer can get bids let alone cooperation from vendors and is spending to much time fighting Vendor related battles. It is more likely the he/she (you in this case) will just abandon the project.

    In 2000 Roberto Sanchz of the Seattle Times had a thought provoking article considering the 1997 falure of the Licenase Application Mitigation Project (LAMP) here in Washington State, a 1993 California Department of Motor Vehicles uprade effort and other projects. June 12,2000.

    The conclusion he advocated was from a Barbara Reed who was at IBM at the time. She stated that successful projects balance three factors; a detailed plan with room for changes; qualified committed people for the job; and a realistic schedule.

    I would add to that that innially project staff in IT are usually committed at the start of a project and the challenge later on is to keep that committment when the team starts competing against eachother for the plum career enhancing assignments.

    You could lump that into communication about roles and responsibilities but using the house building example, your dry wall subcontractor usually doesn't lobby for the painting subcontractor work. Hence tools like Eclipes that focus on defined roles and responsibilties are so important in our work.

    Frank L. Mighetto CCP
  • The champion and the leader

    The champion of the project must be high up in the organization and have a lot of clout.


    Your initiative must have a champion who carries a lot of clout.

    For these projects to succeed you must have somebody high up in the organization with a lot of clout.

    [End quotes.]

    But the leader of the project must know the technology at hand. In many cases, that won't be the champion of the project.


    You wouldn???t ask me to remove your appendix so why would you have somebody with little or no knowledge of the technology at hand lead your enterprise initiative.

    [End quote.]

    Another point of failure is between the leader and the champion. If the champion has priorities, will the leader have to comply? If the leader has priorities, will the champion have to comply?

    When the situation changes, if the leader and the champion do not agree on the response, how will any disagreements be resolved?

    The words "cats in a sack" may be resonant.
    Anton Philidor
    • The Project Manager

      A good Project Manager does NOT have to be the technical expert. He manages the delivery of the work produced by the technical experts. Yes, it helps to know about what's being built, but a project team is facilitated by the PM do identify the deliverables, roles and dependencies and they develop a schedule, cost, etc that the PM will manage. By involving the 'worker bees' there is buy-in and the project is more successful.

      F Polack PMP
  • Things are 'a changing

    Businesses will no longer have to worry about employing Project Managers, or large IT departments for that matter.

    My company, Nasstar plc, provide Hosted Desktop - a service that removes all focus and reliance on IT. IT departments do not earn a company money, IT staff are not chargeable to your clients so therefore are an overhead.

    Whenever one of our clients has to open up a new office, or department, the whole project takes 24 hours. Not weeks, months and also without any failures.

    • out of house Software

      another reason for project failure is the manager's adoption of out-of-house software. Yes it is cheaper, available immediately off the shelf, and requires no brains from the manager. However, it will be the local IT staff who will have to fix and/or find some way to work-around its problems. One can't take the Verrazano narrows bridge, for instance, and plop it down in San Francisco Bay to replace the Bay Bridge! It won't work.
    • Depends on the company

      Where I work, IT is always billable to someone. For example, if sales decides to push additional development, then they must either figure out how to get the client to pay for it, or eat the lose themselves. In addition, saying that "IT departments do not earn a company money" is a ridiculous statement. They may not do so directly, but they facilitate the process that leads to the earning of income.
    • Depends on What Kind of IT Services

      It really depends on what type of enterprise applications and infrastructure we?re talking about.

      If we?re talking about Saas or PaaS that is coordinating various and disparate business functions/operations, hosting services, or virtual IT, then the provider is taking on that responsibility and needs to have adequate PM capability. In addition, as long as these enterprise apps and infrastructure need to be customized to reflect the way a company?s feels best serves them, then project management is still needed on both the provider?s and customer?s side.

      If we?re talking about the equivalent of simple desktop applications being accessed through Internet delivery, than perhaps it?s true that PM is not needed. Use of wordprocessing-, spreadsheet- type applications falls into the category of customer support dealing with technical support, and license management.
  • RE: 10 reasons for IT failure

    After 50 years dealing with technicians and engineers of all kinds, I now agree with my cousin, a former ETS Director and Rutgers English prof. He once told me, "The biggest problem in industry is communication." I hate to call my cellular communications company with a minor problem - their techs have an awful time getting the information they need, just to TALK to me! Minor, I know, but it typifies having to address far more complex matters.

    Sometimes I think, "I'll bet the person I'm talking to has never sat down in a comfortable chair with a good book. I've done some pretty interestings things... and, well, wish I didn't have to be as patient as I have had to be at times.
  • RE: 10 reasons for IT failure

    Managers regard anybody in IT as a middle ages serf, to be paid as little as possible, to clean the bathroom if necessary, and to meet deadlines the managers sat on for 3 months - in a week. Instead of looking at their staff as an investment to be maximized to produce the highest dividend; they look at the staff as cannon-fodder to be replaced as necessary when used-up, stressed, or routed.
  • LOL!! IT is like any other job? L!

    Take the bullet points, replace IT with appropriate job titles and you have just about everywhere. Just because you work with computers does not make you that much different, dare I say that any particular task isn't the hardest part of a job. The hardest thing is putting up with the peripheral BS and lack of support.

    Bottom question, Is any places management sane?
  • RE: 10 reasons for IT failure

    It is a nice article.