Why CIOs fail - A short primer on success

Why CIOs fail - A short primer on success

Summary: Alignment with lines of business, rather than technology alone, is the key to CIO success.


Enterprise software vendors pitch their solutions at multiple levels in the organization, including C-level executives, line of business users, wizard-like technical experts, and a host of other stakeholders and interested parties. Each of these audiences has a different set of goals, measures success in unique ways, and defines its own view of business value.

This reality of stakeholder differences explains why many IT projects have trouble -- creating a unified set of requirements from these divergent, and often conflicting, constituencies is difficult at best. It also explains why enterprise software marketing and procurement are so convoluted.

Complex relationships among different parts of an organization are not a technology issue, but form the backdrop against which all business is conducted. However, this creates a problem for CIOs who are comfortable with the technical aspects of enterprise deployment but do not fully understand the dynamics of how stakeholders work together.

While tempting to focus on technology as the cause of most IT failures, experience tells us otherwise. For example, ComputerWeekly quotes James Martin, former IT COO in Europe at Lehman Brothers:

In my experience the key reasons for IT project failure have been consistent across firms and around the world. My top 5 pitfalls are: Lack of robust business requirements at the outset, leading to unrealistic IT project budgets and timescales; business sponsorship and participation start off strong and then tail off, leaving the IT project drifting; red herring stakeholders' frustrating a project by raising numerous side issues and minor concerns; the world outside moving on, forces a project to be re-defined during its course so it never really ends, it just runs out of steam; and the administrative burden imposed on the IT team eats more resource than technical development work.

Cultivating communication, collaboration, and knowledge sharing among stakeholders is a fundamental challenge on most large IT projects. For that reason, I invited collaboration expert, Dr. Graham Hill, to write a series of guest posts.

Also read: CIO view: Ten principles for effective collaboration Seven steps to successful organizational collaboration

Graham offers this advice for CIOs who want to achieve success by improving business communication and alignment across their diverse constituency:

1. Identify everyone who has a direct hand in influencing the project’s success, including key people from lines of business, functional experts, and change managers. The project cannot succeed without their active involvement.

2. Involve the right people at the right time to avoid creating the chaos that results from involving everyone all the time. Pull in only those people with the right knowledge, skills and experience needed to move the project forward at any given time. Although this will require some to be involved continuously, for many it will only require a single meeting.

3. Be sure stakeholders and project participants have all the information they need. Give everyone involved the information they need, guidelines for what you expect, and the opportunity to ask questions. Collaboration technology can help but is not always necessary.

CIO guidance. Although the best CIOs recognize their role as business leader, the image of CIO as chief technician unfortunately still prevails. To achieve success, CIOs must forge ties and links across the business and engage stakeholders meaningfully.

I cannot overstate the importance of this message and will write more about it in the future.

Image from iStockphoto

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
  • RE: Why CIOs fail - A short primer on success

    This is all nice and great. The article oversimplifies and outright skips a number of items such as:<br><br>- a belief by many business organizations that they know as much about technology as IT does, because they have an iPhone<br>- don't really want to hear more from IT than "I will take care of it" like an order taker because "we (business operations) pay the IT bill so you do what we tell you to, how to do it, when to do it and how often to do it"<br>- view that financial benefits IT provides such resulting in higher revenue or lower operating costs are not the same as the business operation benefits or cost efficiencies as if IT used some money from Mars but the rest of the company dealt in EUR or USD or GBP.
    • Company Culture or Lack there of

      @mikies, Your issues speak to a company's culture where organizations within a company don't respect each other or where some organizations are seen as more special than others. This lack of respect sows the seeds of poor morale, where workers in those organizations feel devalued. <br><br>This kind of organizational dynamic prevents collegial relationships from existing, and hinders cooperative or collaborative work from happening. It doesn't negate the validity of Dr. Hill's advice. It might make it difficult for companies to make that advice work.
  • RE: Why CIOs fail - A short primer on success

    I think the previous comment is an example of the attitude that gets IT the bad rap that it is trying to get away from. It is just not constructive.

    I think one of the biggest issues that get projects off track are that the initial project requirements are too rigid. Invariably, there are things that the users or the business in general did not think of initially. How many "oh, by the ways" have we dealt with in large projects. I think an agile approach deals with some of it, but I also think absorbent project schedules and resource allocation need to happen as well.

    But Michael is right - forging those relationships and keeping the communication flowing is key to overcoming all of it.
  • strikingly absent from your analysis ...

    Strikingly absent from your analysis is any mention of design, or rather the absence of it. You would think we were talking about hosting a successful party. The Japanese didn't eviscerate the American auto industry by "keeping the communication flowing". They did it by designing way better cars.

    Suppose I were to propose to you that we build a custom house in the same manner that most software projects today build custom apps. We'll hire a project manager with an MBA but zero construction experience. The manager will hire a bunch of contractors and hand them a list of requirements and maybe an artist's conception of the house. But there will be no designer and consequently no blueprint. How would this project fare? Most reasonable people, I think, would give the project a zero percent chance of success.

    I've been in this business thirty five years and every project that I've seen fail was due to a failed design (which includes the ever-popular "no design"). More recently I find projects staffed with people who simply have no conception that software even HAS an underlying design (whether you design it or not), and that most "designs" are actually intractable. Show me a project that's going down the tubes, and I'll show you a design that could never be implemented, no matter how many contractors, managers, or methodologies you throw at it.
    Dave Ziffer
  • rather than just complain: a constructive alternative to the vagueness

    By the way, I feel the subject of app development success & failure is so important that I'm in the process of writing a series of articles about it. The one that's most relevant here I think is my fifth one, which is here: http://www.projectpro.com/CIO/EssenceOfSuccess.aspx

    Any real solution to our decades-long productivity failure in app development is going to require some very specific new technical direction. Most of the commentary I find on the web regarding this subject seems to consist mostly of platitudes and advice so vague that nobody could act upon it. My hope is to offer some sort of constructive alternative. Thanks for reading.
    Dave Ziffer