The IT systems and applications are everywhere now, from simple to complex systems to run basic data entry to control autonomous cars and autonomous planes and more complicated systems.
Unfortunately, after a lot of research in software process models and project management frameworks, Software and IT projects still have a very high failure rate. According to a study has been made by Mckinsey in 2012
On average, large IT projects run 45% over budget and 7% over time while delivering 56% less value than predicted. That’s beside the common issues of deliverable quality of final software product according to specifications.
Another study from McKinsey in 2014 regarding how to achieve success in large, complex IT projects.
In this article, I’m not discussing why Software and IT projects implementation failed. I’m actually challenging the definition of success even after considering the software project implementation is successful but is it enough? Does it mean that we have operating application and can be involved in the day-to-day business activities?
Unfortunately, successful implementation of the software project does not mean the software application is actually successful. In this article, I will discuss the reasons behind the unsuccessful operation of Software and IT projects. The success of your customer to use the application you implemented is a factor to have a successful implementation not only by signing off the project closure and to not fall into the successful failure trap.
Another study from Mckinsey in 2009 mentioned that
A team of business and IT executives helped the company find more than 50 unused applications to decommission, 150 redundant applications to consolidate.
Can you imagine 50 Unused applications at only one company! And also 150 redundant ones, this means a waste of money, time and resources. Let us discuss the factors behind that.
Leadership, sponsorship, and influencers of the change in the organization to make it happen, if the entity or the company who acquired the software does not have a strong leadership to ensure the usage and utilization of the software application, it will be considered as wrong investment of money, time, and resources in an application will never be used.
Leadership can affect the software project negatively or positively, for example, consider that one of the executives has the initiative to implement a CRM project for company call center, during the implementation, this executive left the company. Now, the main leader and influencer who had the idea, he does not exist and the project may continue in the implementation without actually going into an operational application and actual usage.
This is a typical case in the most of the organizations these days if the initiative sponsor left, the initiative will be considered as canceled.
What if a Governor, Minister, CEO has been replaced, does it mean we should not continue the investments have been done! That’s why we do not need only Leaders and top executives involvement, their involvement is important but not enough.
Stakeholders are people who have key roles in, or concerns about, the system; for example, users, developers, etc. Stakeholders can be individuals, teams, organizations, etc. The main issue if the implementation team did not consider all stakeholders buy-in for the project and highlight what are the added business values for each one of them. They became a source of a threat because they did not find any additional value for them and they are happy with their current operational model and the current skills they have. It is their comfort zone, why they need to change without extra benefit.
If you delivered the value to stakeholders, it will guarantee a successful operation of the software even if the leaders are changing over time because each one of them will be considered as a change agent for the change and spread the value of the project and the transformation. Moreover, they will ensure that this software application is fulfilling their requirements to enable them to improve their performance and make things easier than their previous operation.
The fear of change from my opinion is the most critical reason for software operation failure and the implementation team should extensively work on this to eliminate this fear and turn the resistance into supportive actions and enthusiasm.
IBM has published a study discussing the reasons for IT projects failure, which indicates that the main barriers to success listed as people factors:
- Changing mindsets and attitudes 58%.
- Corporate culture 49%.
- Lack of senior management support 32%.
Consider that the other reasons do not exist, most of the organizations, especially in the governmental sector are neglecting the sustainability of the operation. When we talk about sustainability, it can be different from business to business and the criticality degree of the operation. While there are common factors need to be considered, for example, the software maintenance, data security, disaster planning, hardware failure scenarios, …etc. Thanks to Cloud Computing services has eliminated a lot of these risks, but the organizations have to consider how they should ensure continuous operation of their day-to-day systems.
Proper and effective communication of the project status, requirements, validation of the deliverables not only with the stuff and users who were responsible for the requirements for all stakeholders who will be affected by this project, even if they will not use the software but how they will benefit. The art of highlighting the business value and validating that the project is delivering this value with the software operating model.
Another study from Geneca at 2017, it mentioned that:
Business involvement is inconsistent or results in confusion: 78% feel the business is usually or always out of sync with project requirements and business stakeholders need to be more involved and engaged in the requirements process.
This is not only important for successful implementation but also for successful operation and usage.
The software became obsolete when it cannot fulfill the new business needs when the skills who implemented this software does not exist anymore when it cannot handle the increase in data amount.
It is important to always improve the software and continuously add new business value to the stakeholders. At some point, we have two paths:
- The software application cannot accommodate new business requirements and it hard to change and the cost of the change will be higher than implementing new software with new technologies. So, you have to think about how you will replace the application.
- The business needs of operation are fulfilled, while I doubt that because of every day in business operation and with dealing with business users, they have always new requirements. And on this path, you do not have to change the software, but you can implement new systems to complement the new business needs. For example, the operating software is doing well all operations, and processes automation, but there is a business need for having analytics and reporting solution which cannot be fulfilled by the same software, at this, we may think of implementing another software or tool for doing this business need without the need of software replacement.
Moreover, we need to separate between when the original project scope is done and what to be considered as the new improvements, ideas, and innovation.
The same study from Geneca stated that:
Lack of complete agreement when projects are done: Only 23% state they are always in agreement when a project is truly done.
Lack of Enterprise Architecture
This is one of the main reasons as well for not having successful usage of software applications inside the organizations. Despite the organization size, the alignment between business architecture and the acquired information systems and technology created these unused applications and redundant applications as well. These applications with time will contain data which cannot be utilized or used and at the same time consume organization resources and the organization cannot purge them.
The Enterprise Architecture practice has to be considered and to have the blueprint of the organization assets and applications and how they are used and mapped to organization capabilities.
There is another article from IT Business Edge at 2009 about the high cost of unused applications and the lack of governance which is discussing this point.
Most of the software projects include the training phase for users who will use the system, but this happens once mostly, but with software upgrades and improvement, rarely it happens again.
How to onboard new users to use the software easily without reading more than 100 pages user manual if it exists. How to observe the feature and function usage for users and based on this usage, we can know which features are obsolete and which are important but they are rarely used and we need to remind and educate the users about them to simplify their operations.
I think we need not only consider the successful implementation of the software project and that we built the right software, it is important to have a successful journey until the usage and operation of this software. This is not only good for the customer, It is good for the team who implemented it when they see how the piece of software they developed became an important component at business day-to-day operation and how it improved their customer business.
These are the most reasons I faced during my career until now, I would like to know your thoughts and if you agree or disagree with these factors and if you have additional factors to be considered.