Top reasons why IT projects fail?
Why are there so many IT projects fail after spending million of dollars? Here are some of the most common reasons in real life projects.
1. Lack of an agile process:
Plan big fails big. Agile process
identifies critical issues much earlier and allows more time to resolve
them before running out of time or budget. Some staff may be skeptical
of the changes. Clear vision and determination from the executive is
critical. Bring in expertise to implement the first agile process.
2. Unrealistic deadlines & expectations made by executives:
Under presssure, engineers cave in to
the executive demands rather than buy in to the deadlines. Engineers
usually focus on feature completion and neglect performance, scalability
and non-functional issues. Those projects are often not production
ready and require far more time to undo the mistakes. All the chaoses
make staff retention, especially the good one, challenging.
3. Risk intolerance:
IT projects includes many turning
parts. A trouble free project is not only prohibitive expensive but
usually counter productive. The intolerance of mistakes in an IT
project creates a culture of finger pointing and issue hiding. Risk
intolerance usually do not reduce mistakes but rather hinder open and
honest communication.
4. Inexperience in realize and manage risk:
Project management requires
significant effort in identify and mitigate risk. Many projects fail
because problems are identified too late. Hire expertise that understand
cross domain issues including development, testing, deployment and
operation. Prototype components that use new technology. Integrate early
and deploy a working integrated system as early as possible before
features completion.
5. Politics between operation and engineering team:
Many projects stall when the
engineering team hands over a project to the operation team for
deployment. Relationship worsen when production problem occurs. During
the configuration, deployment and production time, have a full time
hands on liaison developer to work closely with the operation team.
Engineering team should provide expertise and documentation in
application configuration, trouble shooting and operation.
6. Managers need to be hands on and pay due diligence:
Do not expect information presented
to the executive is 100% accurate or even honest. Executives needs to
analysis and evaluate the information thoroughly. Be critical. Develop a
team of capable expertise that gives direct and high value
information. Make tough decision quickly. In-decisive often causes more
damage than making the wrong decision.
7. Improper scalability and performance testing:
Test early and very early. Execute
the testing at early development phase to prove the core framework can
scale and perform. Non-functional tests take time to develop and should
start at the early code development phase. Comprehensive performance
tests take time and expertise to develop.
8. Fail to control & manage changes:
Moving target is counter productive.
Introduce an agile process to balance the needs of making changes and
a sustainable productivity. Late changes should be reviewed and approved
probably before making the requests to the engineers. Do not
under-estimate the side effects of a late change since those changes
rarely go through a regression test.
9. Do not have the right team and resources:
Make bold personnel changes to a team
inherited from an old project. Bring in new expertise and leadership. A
hands-on architect or team lead makes a lot of difference. Invest time
to find a good one. Bring in expertise that can bridge between the
database and the middle tier business logic in particular during
performance trouble shooting. Have a architect that have significant
configuration, operation and monitoring experience.
10. Be proud of what is NOT done as well as what is done:
Deliver 100% of the "must have"
rather than a feature infested product. Focus the team on a smaller
must have features. Many IT projects have feel-good features that end
users rarely use.
11. Over design:
Don't over design. Don't handle all possible changes or scenario. 70% of those predictions never materialize.
12. Too much talk but not much action:
Adapt a development process that
focuses on deliverable. Planning & design phase should not be longer
than 20-25% of the overall project time.
By Jonathan Hui
Aucun commentaire:
Enregistrer un commentaire