IT Project Failure Reasons ERP , SAP , CRM , Siebel , B/OSS , Oracle,

1. IT PROJECT FAILURE – Hidden Reasons
Ijaz Haider Malik Prince2 ® Project Manager ERP,,CRM & B/OSS,
weboriez@hotmail.com +92 3335690567
Abstract
Enterprise IT project failures ratio is much higher than small projects due to multiple
hidden reasons. Despite the fact that every possible reason has been mentioned in the
white paper published on the internet. Reasons of failure are hidden at almost every stage
of the project. But majority is looking at the failure reasons popped up during the
implementation rather that at pre or post implementation. Project failure reasons which
were not highlighted before are mentioned in this document.
Introduction
IT projects are highly dependent on the pre-implementation activities but not given much
attention due to several reasons. It is like constructing a building with a weak base and
faulty structure. Then putting up strong material in the later stages. Building shall prone
to fall or collapse even though upper structure built with the top quality steel by top notch
builders. And later building could not be made strong no matter how genius people and
ideas put on the drawing board. The only solution shall be to re construct it from the
scratch or keep it standing weak and fragile. Similarly, if mistakes made during pre-
implementation, project is more prone to failure. As most of the reasons during and post
implementation are the by products of pre-implementation mistakes, therefore
highlighting its importance is more important than anything else.
Pre - Implementation
Scope of Work
The biggest reason which drags the project towards failure is the scope of work which
often is unrealistic and developed in the over excitement of starting a new project. Scope
of work should be based on purely business requirements with maximum flexibility in the
solution to cater the current changes and future requirements. Maximum considerations
should be on flexibility in the solution rather performing exhaustive exercise to predict
the future requirements. Scope of work should be properly evaluated by all the stake
holders along with business justification before its finalization. Once the detailed scope
of work is developed, Project technical team must evaluate it before moving to next step
as business stake holders only cover the business side. If process re-engineering is
required, it must be done before start of the project to avoid any risk during the project
implementation.
Pre Project Planning
After scope of work defined and mutually agreed by the stake holders, next step comes
towards the proper planning for RFP, technical and financial evaluation and selection of
apt implementer/ Vendor / Partner and Product/Solution. Often big names or less prices
proved as devil in disguise. Therefore going into details is must have.

2. Vendor / Implementer / Partner
Pre project planning part is often being ignored and hence vendor / implementer or
partner takes the advantage and customer ended up in the wrong selection of vendors /
implementers and solutions. No matter how excellent is your procurement department,
when it comes to IT projects, due to technical limitations on the procurement side it gives
an extra advantage to the vendor / implementer or partner. To handle such short comings,
it is recommended to involve project technical team since day one in the procurement
process.
If vendor / implementer or partner does not have subject matter experts and experience in the
similar project, it would be a risk for the project. For IT projects first and the foremost is the
correct definition of the work. If subject matter experts are not there from the partner side, even
world’s best configurators / developers could not deliver the right solution. Wrong perception
produces wrong conception and eventually turns into wrong solution. Successful projects are the
outcome of perfect marriage between solution and business knowledge.
For IT projects, it is always recommended that core team should remain with the project till its
successful implementation. Often frequent changes in core team also results in disaster. To reduce
the risk, core teams should be dedicated for the project from both sides: vendor and client.
In case, internal development team is implementing the solution rather than partner, it is
important to include key SMEs as part of project implementation team.
Product / Solution
Selection of wrong product / solution is another critical mistake which may push the
project towards the failure. If product / solution is off the shelf (e.g., SAP , Siebel CRM ,
etc), Gartner Magic Quadrant, Forrester Wave or business case study would help. But,
still one has to be careful as some times similar industries may have different standards
and processes. So, product / solution which may be successful for one organization with
similar business nature may not be successful for another. Initial gap analysis may help to
mitigate the risk of selecting wrong product/solution.
Also to consider the roadmap of the product / solution. Acquisitions of product / solution
by other companies raise big question marks. Different companies are acquiring
competitor’s products and then gradually give them a slow death. So, proper evaluation
of road map for a product / solution may reduce the risk.
Open interface for integration with third party applications without using adaptors or
specific tools can be considered as add-on (Web Services / SOAP).
In case of bespoke or Tier-4 applications, only existing customers of the solution can
provide reference. For enterprises, Tier 1 and 2 are recommended rather than bespoke. In
bespoke solution provider develops what is known to them or by customer. However, in
Tier-1 and Tier-2 applications, international standards already implemented which give

3. an extra edge to the customer. Bespoke only help where budget is low and requirement is
unique. With bespoke, transfer of technology shall mitigate future risk.
Unrealistic Timelines
Rushing the implementation for quick implementations with strict timelines and large
scope, often multiplies the implementation timelines. It is far better to sustain the
pressure of the management on unrealistic timelines rather than squeezing the actual
requirements and paying it off with failure or continuous sleeping of timelines. To
balance the managements’ wish for quick implementation and realistic timelines, quick
wins can be planned for easy and small sub scope. For an example, in CRM
implementation, product sale can be implementation which is straight forward and does
not have any complex process linked.
Wrong Infrastructure sizing
To reduce the cost, usually infrastructure corners have been cut. Despite right
implementation on application side, infrastructure bottlenecks hit back the project with
performance and crashes. Users before using the solution / application, decides not to
continue as users’ expectations with new application are always higher than before and
giving them same or less means big criticism on the project.
Teams
It is important to select the right people for the right job. Often even on big projects,
shared resources have been placed and these resources’ priority is not the project. Also
key stake holders must be included in the project team. With the help of HR department,
ensure that people placed on the project, their KPIs must be adjusted accordingly so that
responsibility shall be established. Evaluate both side resources (internal and partner side)
before deputing on the project. It will mitigate the risk of failure.
During - Implementation
Planning
Project plan is the soul of a project. Project plan must be detailed, mutually agreed and
then followed in true spirit. Project plan activities must be updated on daily basis. Any
risk or issue popped up during activities must be mitigated and handled accordingly.
Requirement Gathering
In IT projects, major activity is gathering the exact requirements. In enterprise projects,
arranging requirement gathering workshops is the best technique compared to
conventional techniques of SDLC. It is faster and effective way to listen and record the
business requirements.

4. Documentation and Sign off
Once requirements put on paper, it is important for project technical team to review it
before business sign off. Often, technical teams do not review the document considering
that these are business requirements and later in design they found basic problems and
issues. Also it is important to review each single sentence and word as later it could be
difference point between implementation partner and customer.
Sign off on each small details from both side is important. It will mitigate the risk of
wrong design and delays in implementation.
Testing
Often testing has been ignored considering the high cost. But the impacts and cost of non-
testing are much higher than testing cost. All testing like unit, SIT, functional, stress and
load are important for the smooth execution of the project. Selecting few key stake
holders or users who have more influence and giving them sandbag testing environment
would help mitigate the risk. Compromise on testing could have catastrophic results.
Big bang vs stage wise
It is recommended to avoid big bang approach and adopt stage wise approach in rollouts.
First rolling out in selected departments or specific geographical area will help in smooth
roll outs. However, if big bang is unavoidable in that case, parallel run for few days may
also help for smooth rollout.
Training
Train as many people as you can during implementation. Plan the hands on training for as
many users as you can. In addition to on hands training, provide simulations, videos and
soft training material. Try to provide iHELP within the solution/application for easy
access of material. Smart scripts may also help especially for call center agents who
switch their jobs on regular basis.
Following points must be considered while planning the training:
a. Training schedule must be near to rollout so that when solution/application
implemented, end users must have fresh knowledge.
b. Train the right people. Do your homework for selecting the right people to be
training.
c. Also run train the trainer program. It will help reduce the training cost.
d. Training material mist be simple to read. Step by step with screen shots will
help end users to understand. Real business scenarios must be part of training.

5. e. Trainers must be evaluated before they train others. Training others is
specialized field and its importance must be considered.
Post - Implementation
Support
Post implementation is as important as pre and during implementation. All hard work can
go in vain if post implementation shall not be properly planned or handled. After
implementation the most vital is support. Put as many resources on support as you can for
at least few weeks after implementation.
No matter how excellent and easy to use new solution/application is, end users need
support in the start.
Change Management
End users either handling their day to day work manually or via legacy application, they
do not want to come out of their comfort zone. In order to bring change, it is important to
have continuous sessions with influence groups after implementation so that end users
keep using the application and give their feedback openly to further improve it.
Conclusions
For successful implementation of IT project, it is important to keep things simple and
realistic. But at the same time from pre to post implementation, keep a close eye on every
granular information related to the project. Put people on the project, who are experts and
experienced in the relevant fields: Project Manager, Technical team, stakeholders and
SMEs.
Quick Reference