5 ways to prevent IT failure

5 ways to prevent IT failure

Summary: Rather than acknowledge their own management shortcomings, project participants often blame technology for failed IT projects. This denial commonly arises when an organization's culture uses blame, and the corresponding implicit threat of job loss, as a political weapon. Denial aside, most failures arise from poor management rather than bad technology. Here are five management tips to prevent IT failure.

SHARE:
TOPICS: CXO
23

5 avoidable reasons IT projects fail

Rather than acknowledge their own management shortcomings, project participants often blame technology for failed IT projects. This denial commonly arises when an organization's culture uses blame, and the corresponding implicit threat of job loss, as a political weapon. Denial aside, most failures arise from poor management rather than bad technology. Here are five management tips to prevent IT failure.

From an interview with this blogger in Baseline magazine:

Sure, falling in love with technology can cause big project headaches, but rarely does technology alone cause an IT project to fail.

“Yes, IT sometimes falls in love with its technology, but most failures come about, not as a result of the technology, but as a result of the management of technology,” says Michael Krigsman of Asuret, a project management consultancy based in Brookline, Mass. “The consequences of failure can be dramatic, from a technical standpoint and especially from a business standpoint. And the sad part is that most of these failures could be avoided.”

Here's Baseline's list of five ways to avoid failure:

  1. Lack of preparation. One of the most obvious reasons a project fails is poor planning at the outset. Managers who fail to properly scope a project, apply risk management principles and plan in time for quality assurance and security assurance are courting ruin.
  2. Business misfit. Even when an IT project is implemented beautifully, it can be a failure. If a technology or a process doesn’t fit with the business needs or sync with the way the organization operates the project has the potential to be a waste of money.
  3. Unilateral decision making. When IT fails to involve business leaders while planning new initiatives that affect business operations, the technology department risks a business misfit.
  4. Inflexibility. Unfortunately, some IT projects can be so rigid that they fail to allow the business to change processes or adjust to new situations quickly enough to profit from them. This inflexibility is a project killer.
  5. Scope creep. Lack of preparation typically begets the kitchen-sink syndrome, where project leaders add in every kind of feature and the kitchen sink to boot.

Perhaps you think these points are intuitively obvious and suggest nothing new? If so, take a close at your own organization's track record on IT execution. Obvious problems, such as those described above, often fuel IT failures, which is why such lists are important.

If your organization has had IT failure issues, then study the list as a starting point to cut through denial and become more successful.

Topic: CXO

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

Talkback

23 comments
Log in or register to join the discussion
  • new litmus test...

    I have a new test to see whether a project is going to fail..

    If you consider "governance" to be one of your major
    challenges, your project is too big for you to handle. It is
    going to fail spectacularly to deliver value to the business.
    Erik Engbrecht
    • Not sure I agree

      Erik, There are organizations running many projects and governance helps establish consistency across the portfolio. So, while I see your point about manageable project size, I don't think governance in and of itself is an indicator of problems to come.

      Thanks for commenting.
      mkrigsman@...
      • It's not governance itself...

        It's when governance (err...a "governance model") is a
        major piece or somehow viewed as a significant
        deliverable.

        I'll also point out that consistency across the portfolio is
        not necessarily a good thing. Many corporations consist of
        a large number of diverse businesses. Pushes for
        consistency can destroy value and halt innovation. Outside
        of that there's the classic "don't put your eggs all in one
        basket."

        My observation is that governance becomes a major issue
        when the stakeholders are diverse and largely independent
        budgets. Often times someone gets the idea that even
        though the stakeholders are diverse their needs in a
        particular area are the same, but as the project gets into
        the details it becomes increasingly obvious that they are
        not the same. Governance then emerges as a means to
        drain the energy of the dissenters, which often means all
        of the business stakeholders.

        Again, it's not the existence of governance that is the
        problem but rather the focus on it. It your project is
        reasonably scaled for the organizations it is serving, then
        governance shouldn't be a big deal.
        Erik Engbrecht
        • Depends...

          IT depends on what you mean by "governance", which often has varied definitions. One is a guidance for what gets funded or gets killed. Another is ensuring compliance for internal or external rules (i.e., SOX). Or at a more detailed level, it could mean SLA control as defined by business.

          I agree that cross-project governance requirements that are too detailed could add unnecessary ankle weights. Maybe there's a certain level of governance with a common denominator that helps reduce risk for all diverse projects and stakeholders without stifling implementation. Kind of like our moms saying tie your shoes before you go out and look both ways before crossing the road, regardless of which friend's house your off to and which short cut you take.
          Paul Dandurand
        • If I may interject...

          What I got from the first post was something like this:
          <br><br>
          You are at some point into a project, and it suddenly becomes clear that there are governance issues (of whatever sort). This may indicate problems for the project as it progresses, and a lack of planning in certain areas from the start.
          <br><br>
          Perhaps this is what the OP was saying? If not, please ignore. ;) <br>
          seanferd
          • Good insight...

            But it wasn't what I was thinking...

            The core way IT delivers value is in delivering working
            technology. Governance is a way to help ensure it's the right
            technology, it's secure, compliant, etc..but governance does
            not in-and-of-itself deliver value.
            Erik Engbrecht
  • Poor management vs. poor IT...

    skills in general. There is a lack of truly skilled IT workers which includes management. I would have to say the average age of IT personnel is probably less than the average in any other field. For some reason it is assumed that an IT person needs to be young when every other field it is age and experience that counts. In IT, experience is definitely key to quality. As with every other profession, book knowledge very seldom equals real world.

    Anyway, it is not just management. It is a lack of real IT skills in general.
    bjbrock
  • There is a lot of crap systems to work with!

    We've been at this for over 25 years, in that time the biggest technical failure and time waster offender has been MS for providing faulty / poor quality systems.

    This mainly happened because the product was selling and market dominance led not quality engineering led, thus the crap ware. This was deliberate MS policy.

    90% of systems have to work with this crap somewhere along the line, sometimes most of the time.

    It is the smaller quality engineering outfits that suffer as a consequence, regardless of how good they are.
    wwwsupport
    • Re: There is a lot of crap systems to work with!

      Accusing Microsoft doesn't explain why a major producer like Oracle can "get away" with providing second-hand unintuitive products like the Client of their Identity Manager (sorry, Thortech; I'm sure you had meant well!) and service engineers are burdened with project implementation blame.
      FateJHedgehog@...
  • RE: 5 ways to prevent IT failure

    Of course it is bloody obvious - the real reason projects fail is that badly-appointed project managers allow their egos to run wild, and never listen to such "radical" advice as that above.
    leeegeee
  • RE: 5 ways to prevent IT failure

    I love this article, I experienced this myself first hand. I was working under a CTO for a tech company, who's experience was strictly in Microsoft based systems. We were running on Linux using php/mysql - out sourcing all of the work of course (terrible management move). He even had enough ego to tell me open source sucked.

    I left the company when he expressed we must make our Linux server run like server 2003.
    This company had been attempting to make a product for just under two years. I was part of the 2nd iteration. ( the first one failed trying to build a social network with community server - lol)

    Two months later my former CTO is fired because a partner company ratted him out for not knowing anything about the system (not knowing anything at all really) - I am called by the CEO that day, we meet up for lunch on a Thursday , The following Monday my team of 3 - just out of high school kids, has a completed and working product. 100 times more user friendly and next to free for us to produce.

    I got the CTO job the next Friday, has been history since.

    I will be 21 in Sept, my former CTO - in his 40's and munching on a major serving of Ego.

    Really with the way the IT field is, there are so many things to specialize in, and there are so many things that don't come from a book - because the second a first edition would be produced, the concept would be ready for a 5th edition book.

    As far as server side scripting - php-mysql etc.. it is a young mans game. I have met very few older people (late 20's 30's) that know a thing about it. Or know it up to date.

    I'm hiring the youngest ones I can find. They work constantly, and are the most knowledgeable. I had two older developers come in, and last less than a month. They just couldn't hang on.
    Jbirdsin
    • Talk about ego!

      As far as I am concerned, disregarding experience as a non-essential component in a team is just plain stupid. In most cases, it's a shortcut to "cheap today, expensive tomorrow".

      AND, seeing as you're such a brilliant CTO, how about negociating some training for your staff, you might find these 'old' chaps (oh, and girls perhaps too?) in their late 20's and 30's actually have a brain they can use.

      Nice try though...
      elinorH
    • You policy as CTO

      Allow me to congratulate you on your promotion and ask where you plan to work in 5 years when one of the "youngest ones" replaces you? Since your own policy is that only young people should work in IT, then I will expect to see you in another filed of work that does not involve networking..

      Good luck on your next career choice.
      OldSchoolIT
    • Ahhhh-- to be young and ignorant again

      They say ignorance is bliss, and you my friend are the poster child.

      First, congrats on your new "upgrade" in job-- on a team that small, being CTO really only amounts to being a development manager, and that your CEO recognizes the person getting it done is a good thing. However, I'd like to point out a couple of things based on your statements:

      [i]out sourcing all of the work of course (terrible management move)[/i]

      To issue a blanket statement is ignorant-- there are plenty of companies turning a beautiful profit by outsourcing, whether onshore or off...and my customers are among them. :)

      [i]I left the company when he expressed we must make our Linux server run like server 2003.[/i]

      Yup-- this definitely sounds like your former boss was misdirected.

      [i]The following Monday my team of 3 - just out of high school kids, has a completed and working product. 100 times more user friendly and next to free for us to produce.[/i]

      Working product-- in 3 days? Sounds like you reused components or produced something which can't be maintained by anyone but you, or worse: you're just not telling the whole truth. And nothing is free-- you paid for computers to run that software on, and countless open source developers (dopes?) have contributed their precious time for you to turn your profit. ;)

      [i]I will be 21 in Sept, my former CTO - in his 40's and munching on a major serving of Ego.[/i]

      Better than posting it on a board for all to see!

      [i]As far as server side scripting - php-mysql etc.. it is a young mans game. I have met very few older people (late 20's 30's) that know a thing about it. Or know it up to date.[/i]

      This is because you are young and ignorant to what is out there. Ignorant being used in the literal sense-- not the insulting one. You just don't have enough experience to know who's out there.

      Which brings me to my next point: it is most arrogant of you to make such a statement in light of how little you know.

      [i]I'm hiring the youngest ones I can find.[/i]

      Bad move-- you'll find out why when it comes time to maintain that product-- or scale it. If you product starts to experience use-- and make money, I GUARANTEE (sp?) you will find that a lack of engineering and proper design will show itself down the road-- guarantee it.

      [i]They work constantly, and are the most knowledgeable. I had two older developers come in, and last less than a month.[/i]

      Yes, this is because they have no life. And let me say this: any kid that is "working constantly" instead of out there partying their arse off will come to regret it when they find themselves at 30, with few or no quality friends, no wife, no family-- and laid off because they didn't put in 110 hours a week.

      [i]They just couldn't hang on.[/i]
      Or maybe they just knew better.

      ------------------------------
      Ignorance is a terrible thing because no matter how you argue your points-- not knowing just blinds your ego until you finally learn what you didn't know. But someday you will-- and when you do, it'll sting.

      And one more thing-- you shouldn't knock age so hard, unless you die, you will get there faster than you think.

      Just my $.02.
      kckn4fun
      • Well Said

        My initial reaction was to respond to KID CTO with many of the same statements you made. But you made them far more succinctly than I could. Thanks!

        Attitude and not age is the issue. Whether 21 or 40 something, if you have EGO you have EGO. EGO is part of the "gutsy", "ballsy", side of life. Without EGO as part of Linus's attitude we would not have had Linux, and Rasmus Lerdorf, who I'm sure is over 21, would not have created PHP (and still working on the new version) for KID CTO and his neverland bunch to use.

        Roads are paved by the experience of those before us - good, bad or indifferent - all worth studying/learning. KID CTO would well remember that if there were no attitude from those that came before him, he would definitely not be in the position today to show his newly minted talent.
        Meesha
  • RE: 5 ways to prevent IT failure

    From my point of view, many IT projects fail because they are ill conceived, poorly managed, inadequately resourced and have too many managers and not enough leaders.

    IT is the enabler, it is not the only element of a "system". A system consists of people, technology and processes, and whilst yes, I have had experience of project managers with huge egos, we suffer more from management and users who expect that the minute the server is turned on all the issues in the HR/Finance/EDRM System will magically disappear!
    Welsh Kiwi
  • security / in-security

    Your list is good as far as it goes. Having been there, There is just another level to look at.

    I once meet an upper level manager who told me, rather proudly, that he had held the most secure job for for 25 years (state employ). As I shook his hand I calmly stated that I had successfully held the most in-secure job in the work for longer than that (CS/Engineering upper level Manager). We became good friends.

    And the point is? The moment a manger (any level) becomes concerned about protecting his job, the project (if it's complex) is mostly doomed.

    Now why is that? Besides "not invented here syndrome" and cainotophobia "fear of new ideas" the list "five ways to avoid failure" is not all that bad. Most Managers have a really bad habit. They tend to NOT fire staff that scares them. Staff capable of replacing them! Thusly they have staff of limited ability.

    Can you say doom and gloom? And the "it's someone else's fault" syndrome comes to play. Now why is that? Simple, their upper level management selected them because they did not want anyone working for them to be able to replace them.

    Reality has nothing to do with how you look at.
    Anyone care to share an experience or two?
    dragon@...
  • RE: 5 ways to prevent IT failure

    Sir
    Your column and Yahoo are same.
    The modern letter writing is to start a letter with the subject and underline this. The days of RE: that was to state that I am talking of this .. is gone ..We are following the methods to the way modern writers write in more professional way getting rid of the RE: and Attached herein etc or I thank you in anticipation etc are long gone with the RE: These days there is no anticipation in th email or the UPS or FED or the DHL, you will get these.
    This is not the PC it is we with the loop on the program to loop all the time we write and say RE:
    SO STOP THE LOOP ....

    I thank you
    Firozali A. Mulla MBA PhD
    P.O.Box 6044
    Dar-Es-Salaam
    Tanzania
    East Africa
    famulla
  • RE: 5 ways to prevent IT failure

    Although i agree with the list of items here that causes project failure and have also sampled them once or twice in my career.

    But in my experience the lack of team work and coordination between the business and technology results in most of the project failures. Here the role of the project manager becomes very critical to organize tasks and execute plans with the concurrence of all the stake holder rather than have its own internal agenda which is undisclosed and which later becomes the real cause of failure.

    And in a large scale and complex project such as core banking implementation the team work and coordination becomes very critical for a successful execution.

    regards,

    NY
    deo_y@...
    • Cross functional teamwork +2 more

      I couldn't agree more about cross functional teamwork and involvement of all stakeholder groups. I have 2 more traditional shortcomings in most failed projects that are also closely related:
      - Testing
      - Training

      It doesn't matter how good a job has been done conceptually. If the system has not been adequately tested and user training is not part of that testing, the project is likely to fail.
      mstephens@...