Why IT Projects Fail
BA Forum Moderator
======================
Opinion by Jian Zhen
FEBRUARY 07, 2005 (COMPUTERWORLD) - It's estimated that over 50% --
some say 80% -- of all large IT projects fail. The reasons for that
startling failure rate aren't mysterious. Too many companies make the
same mistakes too many times. I've identified five of the most common
causes for failure. I've also come up with some questions your
organization should answer before it starts a project, to boost the
chance of success.
1. The project's real value isn't understood.
When calculating ROI, be sure to have a clear understanding of the
total cost of ownership. Without a concrete TCO, the ROI figures are
meaningless.
Understanding the various ROI metrics, acknowledging that these are
fuzzy metrics and clearly defining what the organization expects from a
successful implementation will produce a clear view of the project's
value.
2. You don't know your users.
Who are the main users of the technology you're implementing? Are they
business users or technical users, power users or casual users?
Business users are usually from marketing, finance and other
nontechnical groups in the organization. They want to see summaries,
dashboards, charts, graphs and other reports that enable them to spot
trends.
Technical users are usually from IT, security and other operations
groups. These are the ones who want all the nitty-gritty details. They
want to drill down and diagnose problems. They perform the root-cause
analysis when things go wrong.
Power users want sophisticated interfaces and flexibility. They
generally use the system three or four times a week or even every day,
and they can be anywhere in the organization, including marketing and
finance.
Casual users are on the system once a week or less. They may not even
log on at all and prefer to receive reports via e-mail.
3. Requirements aren't clearly understood.
The only way to identify real requirements is to talk to potential
users and get the answers to these questions: Are your requirements
based on regulations, operational problems, performance, capacity
optimization or trend analysis?
Do you have platform requirements -- Windows? Linux? Java? .Net? How
about requirements to integrate with corporate infrastructure?
What's your requirement on performance? Scalability? Extensibility?
Manageability? Usability? Security?
Before evaluating any technology, answer those questions in detail.
Don't choose a product or create unreasonable requirements because of
brand loyalty or FOE (friends of executives).
4. You've limited your options.
Too often, companies decide that only a commercial product will meet
their requirements, before all the options have been evaluated.
Before you jump to a commercial solution, you should evaluate your
resources and skills within your own organization and see if you can or
should go open-source. There are many factors to consider when choosing
among the commercial, open-source or homegrown options.
Do you have the resources (head count) to support whatever option you
choose? Commercial products may save you some development time and head
count, but you may get faster feature updates if you have dedicated
developers for a homegrown system.
Do your engineers have the necessary skills to maintain an open-source
product or develop a homegrown solution? This really goes back to your
requirements.
Even if you have the resources and skills within your organization, can
you spare the time from other projects? What's your budget? It will
vary based on the executive sponsor, the project's scale, its urgency
and other factors.
Knowing your requirements will allow you to find the right option to
meet them.
5. You don't have a clear understanding of the products available.
Many of the IT products out there are strong in some areas and weak in
others. Many vendors will tell you that they are strong in all areas.
If they tell you that, run away as fast as you can.
Tell the vendors about your requirements. Ask them to rate how well
each of their products meets your requirements. Ask for an evaluation.
Ask them how their software/hardware compares with that of their
competitors. Ask them to share their product road map. Ask about the
support structure.
Never buy a product without actually using it. There's no way to tell
whether it meets your requirements by looking at PowerPoint slides.
Try to be open-minded. There are no 100% solutions. Prioritizing your
requirements will help you determine which system best fits your
company.
Spending some time upfront will help you avoid these common problems
and allow you to meet your real requirements.
==================
Jian Zhen, CISM, CISSP, has been in the information security industry
for nine years. He can be reached at j...@trustpath.com.