IT failure and collaboration: Ten big symptoms

IT failure and collaboration: Ten big symptoms

Summary: IT failures often arise from dysfunctional communication, collaboration, and planning across information silos and boundaries. Success requires more.

TOPICS: CXO, IT Employment

IT failures often arise from dysfunctional communication, collaboration, and planning across information silos and boundaries. More simply, many projects fail because participants and stakeholders are not on the same page regarding shared goals and expectations.

Although there can be many reasons for these disconnects, three reasons stand out:

  • Circumstances force stakeholders to make decisions based on incomplete or inaccurate information
  • Participant groups may each have their own unique, and sometimes incompatible, definition of success
  • Goals, metrics, and expectations among different groups may be defined with mutually exclusive, or even irreconcilable, differences

All this creates corporate initiatives that fulfill process and protocol, but nonetheless result in bad outcomes and dissatisfied stakeholders.

Signs of failure. The Companies Management blog offers a list of ten symptoms that reflect these problems. Here's a quote from that blog:

  1. Project based on CEO’s dream, but no one is clear about its business value.
  2. Sponsor is too busy to listen and too weak to support.
  3. Management wants to start working and worry about planning later.
  4. Duration estimates are done by management.
  5. Management directs Project Manager to ignore vague contract terms.
  6. Management warns Project manager about raising issues with clients during planning.
  7. Functional managers are providing the wrong resources.
  8. Clients representative accept work formally but refuse to put it in writing.
  9. Client’s expectations are too high and mismanaged by Project Manager.
  10. Project Manager is too worried about losing job or making people angry.

Note that these symptoms are related to organizational, collaboration, and communication issues, with no reference back to technology.

Perhaps it's an obvious point, but many companies become enamored by software and forget that people and process are the ultimate drivers of success. Although technology is an enabler, success on cross-boundary initiatives requires the context of a broader enterprise strategy that synchronizes expectations and goals across stakeholders.

My take. Project success demands highly coordinated activity and information sharing across stakeholder groups; methodologies and process can help, but are not sufficient to actually achieve success. Although most companies use guesswork and ad hoc approaches to decision-making, the best organizations possess consistent techniques to highlight and deal with mismatched expectations on collaborative projects.

Has your company developed impartial, systematic, or quantitative methods to measure mismatched expectations? Let us know in the talkbacks.

Topics: CXO, IT Employment

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
  • 10 to avoid and 3 to embrace

    Thanks for this really nice write up on what to avoid in enterprise collaboration. Here is a piece ( see ) on what to embrace in enterprise collaboration.

    I believe that deployment is the most compelling concern right now in industry adoption of social media. Like with most project success drivers, execution is king and the devil is in the details.
  • RE: IT failure and collaboration: Ten big symptoms

    I work for a very large shipping company. The company's IT department has god-like authority and it has worked tirelessly over the years since it came into existence to accumulate territory and reduce computing facilities to the lowest common denominator. Since OUR department opened in 1988 we have worked very quietly and mostly out of sight with no contact from IT. For over twenty years we have had a "working" computer control room for our equipment. This room is where we do our work and write and maintain our software that runs our particular 100 million dollar operation. This past winter, a group of muckety-mucks came through on a tour and one of the group was a company IT manager from somewhere on high. A month later, without ever having asked us how we operate, we receive a series of lists of "recommendations" from the IT gods. They tell us that our work tables (that we lay out our schematic drawings on) are too large, our printers must go, our trash cans must go, our cables must run in the ceiling not in the false floor, all work terminals must be moved into the equipment bays despite that our insurance company says we can't put them there, etc. In short, that one little visit to our facilities has resulted in months of headache and expenditure and hasn't resulted in even one improvement in the way we work. Our protests up the chain are met with the same refrain, "It (whatever it is) is not up to the IT department's SPEC." All I can say is that every little bit HURTS and once again we have a situation where a department with unchecked authority is interfering in the proven processes of another simply to exert influence and acquire more turf. Management at the very top needs to start asking IT some questions and they need to pay attention when they hear that tiny voice talking to them. IT is not a god. IT needs to be spanked once in a while. They should remain a department that provides a service to other departments and they should not be permitted to become an opportunistic, self-serving, blob that feeds off company assets.
  • RE: IT failure and collaboration: Ten big symptoms

    You mentioned some symptoms come from non technical only.
    Just to add your symptoms,
    1. Lack of Quality Assurance
    2. Inadequate testing.

    And many more, can anyone else add ?
  • RE: IT failure and collaboration: Ten big symptoms

    I have always heard and used the three terms in this order to ensure success of any project: people, processes and technology.

    The emphasis here is that people do come first and those within the group must be selected based on a wide range of talent and areas in order to create a diverse team capable of finding solutions. Foremost, there must be rules and expectations clearly laid out as well as how to deal with biases, conflicts and so forth to keep the group on track. Without this, projects will not be as successful, on time and on budget.

    Then, processes come second. Processes usually equate to bureaucracy so they must still provide enough flexibility to guide people without restricting them to the point that critical thinking is removed and replaced with dogmatic nonsense. Intelligence Analysts use critical thinking and structured analysis when faced with hard questions and writing quality intel documents. Critical thinking is a group mindset for looking at the problem from all angles. However, it lacks process so structured analysis provides the approach for the group to use to apply critical thinking without restricting people in the group.

    Lastly, technology is a tool that enables people to use processes to solve a problem. Remove that technology from the group as an experiment and the group should still be able to succeed albeit at a slower pace and output. When technology supercedes people or processes in importance the project will suffer if not fail. Again, falling back to Intel Analysis, new Intel students are taught the manual "old school" methods using paper before being allowed to use the software-based tools. While the the manual methods take much longer than the computer methods the people are still using the same processes to do the job and the problem still gets solved (again, slower but done nonetheless).
  • RE: IT failure and collaboration: Ten big symptoms

    I disagree with this a little bit:

    <blockquote>Circumstances force stakeholders to make decisions based on incomplete or inaccurate information.</blockquote>

    I think the problem is when decisions are made <em>permanently</em> based on incomplete or inaccurate information. It's the nature of IT (particularly software development) for information to be incomplete until very late in the project. You have to make tentative decisions as you go along and keep checking against your team's progress and the reality of what's getting done.

    At least that's how I've experienced it. Make final decisions as late in the process as you can... without unduly compromising other goals.
  • RE: IT failure and collaboration: Ten big symptoms

    Collaboration IMHO has always been a touchy-feely nightmare... ignorance, arrogance, competition, petulance, hidden agendas, fear and loathing, oh and 'I really hate your coffee" (inane excuse boneheads)- the whole primary school nine yards.

    There have only been three projects I've been involved in where the the specific aims were nailed on the first day: the goals agreed, and everyone was on the same page. Egos and personal agendas were specifically highlighted as instantly sackable offences, so issues were on the table in the first two hours. The result was frenetic activity, resulting in on time and under budget results. The carrot of finally being involved in an IT project where everyone was switched on 24*7 and good to go far outweighed any fear of being fired. Change control was frequent and tightly controlled. They were all multi-million $ projects, involving up to 3 outsourcers, ranging from 6 months to 1.5 years.

    All the other projects were only-just-there status to abysmal failure for some/all of the 10 reasons in the article.
  • RE: IT failure and collaboration: Ten big symptoms

    Muzza has it right. All failures can trace root causes back to a risk that was known or ignored in the business case. When everything is included in the business case fact based decision-making can replace office politics for which projects are funded.

    The issues that Bill mentioned can be called out in the Capital Acquisition Request. The business case can call out certain policies as risks for failure. The staff boys usually get soft when they are labeled with a risk for capital failure.

    The business case for a large capital project should be complete and resemble a mini-business plan.