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