Bad leadership causes failed IT

Bad leadership causes failed IT

Summary: IT failures continue to plague organizations across virtually every industry. Poor business leaders who don't possess the skills needed to manage change effectively have created this mess.


Bad leadership causes failed IT

This post was written by guest blogger, Mike Kavis, a senior enterprise architect. Mike describes how the roots of failed IT projects lie in management and leadership rather than in technology.

IT failures continue to plague organizations across virtually every industry. Poor business leaders who don't possess the skills needed to manage change effectively have created this mess.

There are countless articles about failed IT projects, ranging from outsourcing failures, SOA failures, technical architecture failures, and customer service failures. I outlined 10 reasons why large IT initiatives fail in a previous post:

  1. Poor Communication
  2. Underestimating or ignoring impact of change
  3. Lack of Leadership
  4. Lack of strong executive sponsorship
  5. Poor project management
  6. Poor Planning
  7. Trying to do it cheap
  8. Lack of technical knowledge
  9. Lack of sound business case
  10. Poor vendor management

This list boils down to three categories: technology, business, and people. You can probably count on one hand the number of folks that you've come across who excel in all three areas.

Most large business transformation projects fail because IT leaders don’t acknowledge, or at least underestimate, the impact of change on the workforce. These managers focus entirely on technical issues while failing to address the human side of change.

Driving change successfully requires creating a sense of urgency, communicating a clear vision, and addressing WIIFM (what’s in it for me) at all levels. Leaders must identify change agents throughout the company to battle resistance, while remembering success is about the people and not the technology.

Leaders often make a lethal mistake by not aligning technology projects with key business drivers, which is precisely why so many Service-Oriented Architecture and Enterprise Architecture initiatives fail. Both SOA and EA are long term strategic initiatives requiring many resources and a great deal of funding, which only worsens alignment issues.

When IT is not aligned with business drivers, IT makes poor architectural decisions that nobody on the business side will want or understand. Consequently, the business won't invest in these initiatives because they see no apparent benefit. This is where IT leaders must learn to speak in financial terms that the business will understand and appreciate.

Most IT failures are due to a team's inability to embrace changes needed to implement new technology. Nonetheless, leadership frequently points the harsh finger of failure to technology, which is simply the wrong place to look for solutions. No wonder IT failure rates remain so high!

The next time you see a major project fall apart, remember it's not the technology that failed but leadership that didn't measure up.

Topics: Software Development, Browser, CXO, Enterprise Software, Software

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
  • From the Obvious to the execution

    Much of what you say is true, and as you point out much has been written on this subject, and very little changes.

    Having delivered some very successful projects myself, the biggest success factor is a clear delineation between, business, technical and project management. It is the interference between them that causes the problems, especially project managers thinking they are architects.

    From my perspective, the business provides the focus and the technical leader provides the drive and manages the scope to the schedule, and the Project Manager ensures that our project measures are in place, e.g. burn rates, resourcing and does not get involved in tasking of the team, that is a technical function.
    • more on execution


      Great points. It all starts with strong executive sponsorship, a clear vision and goals, a guiding coalition made up of IT and business, and a firm commitment to the cause. Too often projects rely on the heroic efforts of one "leader". True leadership engages many and empowers others.

      Note: I am a practitioner not a philosopher. So this is coming from years of lessons learned.
      • Before alignment or execution ...

        ... the critical thing for IT project success is that the technology is the answer to a question. A technology implementation should be designed only when without the technology the business' strategy cannot be executed.

        "We will successfully implement SAP in 2008," is not a business strategy. Too often the goal of the technology implementation is to implement technology, not to lay the groundwork for the benefits the technology will provide.

        Too often, the thinking goes, "All the big companies in our space use [technology x], therefore we must use [technology x] to become a big company." And in a situation like this, no amount of planning, communication, leadership, sponsorship, spending or know-how is going to put the horse back in front of the cart.
    • Here's what SAP's CTO said

      When I interviewed Vishal Sikka, SAP's CTO, he said:
      Lines of business know the what and IT knows the how (

      This is a great statement of the relative roles for each group.
      • But you have to filter

        Too often, the users communicate problems in terms of
        solutions. I've seen projects fail because the IT staff were
        either too naive to recognize this, or the Management staff
        were unable to differentiate between the what and the

        For example, a project that I was brought into after it had
        been going on for a while, included a hard requirement for
        "intelligent product numbers". What the users really need
        is a mechanism to query by attributes. The current design
        will have many collisions in the derived numbers because
        of the mechanics of it. This, plus some other requirements
        that are beyond the scope of this reply, will cause them
        pain later on.

        The project spent a lot of time and money on the wrong
        thing. Now I am facing two challenges: education of the
        stakeholders and re-working design and code.

        The use-cases were correct as stated, but the underlying
        requirement and application of the use-cases is flawed.

        Many projects fail because everyone involved fails to
        understand that they don't always know what they don't
        know. And they don't know how to express what they do

        As in all things, the problems can be fixed - but with a
        cost (time, money, resources)
        • Good example

          If I were to teach a class on systems analysis I think I would use part numbering schemes as a case study.
          Erik Engbrecht
    • At the End of the Day, One Person Must Manage the Whole

      Granted you need team leaders in each domain: technology, business focus, project tracking. But you need one person to unify the sub-teams and identify and understand the issues on the ground, and the tradeoffs to consider and their ramifications.

      Yes, the challenge is finding the one person who can speak or perhaps translate amongst the various domains, who is also a diplomat and a good horse trader, who understands at the big picture level where everything is, AND can oversee and execute.

      And oh yes, has good judgment and isn?t afraid to make decisions.
  • It is IT that fails...

    to address the human side of change. Most users are technically challenged and IT fails to take this into consideration. Trying to lay the blame elsewhere is a cop out.

    The second reason is due to a lack of skills in the IT department. Most IT workers are young and lack people skills as well as real world technical experience. All you have to do is deal with IT personel once or twice to see a gross lacking and the real reason for failure.

    As long as we try to lay the blame on anything but its creator, we are going to fail.
    • Lots of overgeneralization here ...

      ... and I disagree with most of what you say, especially regarding skills, age, and professionalism in IT.

      Ideally users begin the cycle by defining a business need. Often, however, they don't define a business need -- they define a technology solution. They say, "We need x [software, platform, system, whatever]. [Buy, build, install] that for us." Or to every IT person's horror, "We just bought x. It'll get here tomorrow. How quick can you put it in?"

      IT fails when it doesn't say, "Why do you need x? What are you trying to accomplish that you can't do now?" This should start a dialog that results in a business problem defined by the users and a technology solution designed by IT.

      IT has its responsibilities, but I've seen way too many people on the "business" side of the house who were too young (or acted it), had NO people skills at all. Frankly THESE are the types who are always looking for someone to blame, instead of looking to step up as a team member and as a respectful colleague and work through a problem together.

      So, I have to reject your post completely.
  • Project Manager

    Is the project manager "business" or "IT?"

    I would say the project manager (or maybe I should say program manager) should always be business-side, but in practice this is seldom the case because business-side people have "real" work to do and consequently don't have the time.
    Erik Engbrecht
    • Wow, you've managed to insult every project manager ...

      ... with a few quotation marks.

      The project manager is often the go-between, managing both business needs and technical concerns. They should shepherd over the budget and the timeline, wrangle the stokeholders together, and make sure that the job is not only "done" but "done right", on time and on budget, to the satisfaction of the customer (i.e., the business stakeholder).
      • "real" work...

        I think you misinterpretted my quotation marks. Perhaps it's an inside joke and I have spent too much time with my coworkers and other in my industry...


        A project manager is supposed to manage people. There are people both on the business-side and IT side that are critical to project success. IT project managers usually have no authority and very little influence over people on the business side. Heck, sometimes they have little influence over either, because they live in some mythical project management group that is divorced from the rest of the management chain.

        A project manager on the business side will generally have substantially more influence over business-side staff, and at least as much influence over IT staff as an IT project manager.
        Erik Engbrecht
        • It can be difficult ...

          ... to convey the correct tone in a blog comment. My reply wasn't supposed to be serious either. I'm trying to make it through life without ending every sentence I type on the web with an emoticon ...

          I think what you're saying is generally true, but in my experience that has more to do with personality types, approach to the problem, and communication than it does with reporting structure. Business-side staff tends to respond well to PMs focused on solving the business problem better than they do to those focused on the technology implementation -- regardless of what part of town the PM grew up in.
        • It also depends on what your organization considers a Project Manager to be

          In some companies, the project manager just tracks costs and keeps the MS project schedule up to date.

          I other companies, the project manager runs the project--- hires (fires), sets up the teams, arbitrates and coordinates amongst the various parties, manages the project budget, and owns the schedule (whose ever tool you use).

          Depending on where you worked, the scope of authority of the PM is different.
          • project managers...

            People who just track cost and schedule (and maybe action items) aren't project managers. Yeah, people who do that are often called (or call themselves) project managers, but they're just clerks or secretaries with inflated titles and paychecks.

            Hire/fire decisions are a little different. Large organizations tend to acquire matrix-like qualities (meaning being like a matrix organization, not the movie). I would argue that you have "project managers" and "resource managers" or "functional managers," and it is fairly common for the same person to play both roles, usually managing small projects that are focused within their own organization.
            Erik Engbrecht
  • RE: Bad leadership causes failed IT [guest blogger]

    Just for clarification, my post is geared towards transformational projects. Projects like BPM, SOA, implementing outsourcing for the first time, implementing a new SDLC, or bringing Enterprise 2.0 into the company requires people to change. The project manager is not the one to lead these transformations. It must be a high ranking leader within the company that creates the urgency, builds a coalition, creates the vision, and makes the change happen. The project manager is likely a key player on the transformation team, but rarely does the project manager have that kind of clout and authority to transform a company. Change starts at the top!
  • RE: Bad leadership causes failed IT [guest blogger]

    This appears to be sweeping generalization based on a personal perspective, not a well-researched article. I think Mike needs to find a new job (Assuming he gets to make that decision after his employer reads this). While these problems may exist on some projects, PMI and other indsutry research suggests a number of different causes for project failure based on quantitative and qualitative research, not personal opinion.
    • Personal opinion


      Thanks for your kind words ;} I am familiar with all of the reasons that the PMI research has reported for project failures. It still takes leadership to implement them. It takes leadership to implement the PMI's best practices in an organization as well. My "opinion" is based on a combination of personal experiences, researching SOA and other culture changing projects of peers and the IT industry, and through my graduate studies which included four semesters of studying the PMI PMBOK and a graduate certificate in project management. Most of the failures that I was referring to were SOA and ERP failures that I have researched and not those of my company (we succeeded with SOA and don't do ERP). It is one thing to put a plan on paper, it is another thing to execute on it.