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.
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:
- Project based on CEO’s dream, but no one is clear about its business value.
- Sponsor is too busy to listen and too weak to support.
- Management wants to start working and worry about planning later.
- Duration estimates are done by management.
- Management directs Project Manager to ignore vague contract terms.
- Management warns Project manager about raising issues with clients during planning.
- Functional managers are providing the wrong resources.
- Clients representative accept work formally but refuse to put it in writing.
- Client’s expectations are too high and mismanaged by Project Manager.
- 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.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
10 to avoid and 3 to embrace
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
RE: IT failure and collaboration: Ten big symptoms
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
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
<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
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
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.