Author: Adrian DIMA
I was recently asked what I think about applications written and used internally by customers from the non-IT industries. From the start, I exclude from this category large non-IT companies, which have invested in dedicated IT centres, where software development is a well-developed process. I also excluded simple applications such as Excel, which rises only slightly issues dealt with below.
The truth is that I have met over time many companies (not only from industrial production) that had employees with some software development skills and they preferred to implement their own applications to cover internal needs – some of them were simple, others critical.
In the short term, internally written applications usually do the job for which they were written. It covers one-off needs with lower costs than if external resources were used. Because developers are already employed and know the specifics of the organization, the requirements are clear and easier to apply in a software implementation.
All is well so far…
But contrary to popular belief that the hard part is implementing a project, the reality is that this is only the first stage in the life cycle of an IT project, and real problems occur while in the medium and long term.
Of the most common problems encountered over the years, I have structured a list of eight reasons to use applications written internally can be an unfortunate idea.
1. Business processes in the company is constantly changing.
The change must be reflected in IT project and resources that originally developed must intervene. As they are not usually allocated 100% for the project, it is possible to intervene late and specially to solve a problem on time, not to make changes in a wider future context. If the resources are 100% available for the project, see also reason 4.
2. Internal resources are limited.
I rarely saw more than 1-2-3 resources available in a non-IT company who have the competency of configuration / software development. Over time, they advance to other positions, their time becomes more precious, and the priority is no longer the project.
3. People leave the company and no one knows the detailed history of the IT project.
There is no documentation, and potential IT providers will be reluctant to take over a project whose history they do not know. And if they take over, the costs will be higher than if they had worked from the beginning.
4. The quality of implementation may suffer when internal resources are used.
The effects can be seen during the life cycle of the IT project. In the case of implementation with internal resources, the employees know best the internal processes, but there is no guarantee that they will optimally manage the implementation in the business and technological context. Instead, a specialized external supplier has already seen several customers with the same specific. In addition, he knows the ins and outs of an IT product, certainly much better than someone who hasn’t made it a full-time job. In most cases, an external vendor can optimally combine business understanding and technology implemented.
5. Maintaining the technological stack used by the implemented solution (servers, operating systems, other related IT products) is a continuous process.
If we are talking about a solution in the cloud, someone must follow the parameters of operation, access and consumption. In all cases, we are talking about an effort for an organization that does not have IT in its core concerns.
6. The implemented IT product needs maintenance in turn.
If that does not happen, most likely that while product will generate operational problems. Sounds easy, but can be serious work and there is never time for that when the core business is another. Customers have no reason to pay dedicated employees, so maintenance of infrastructure will never be a priority. It usually occurs when something is no longer working properly, that is too late. IT organizations typically have dedicated resources for infrastructure maintenance. Their work is noticed in a few cases by customers, but the effort of these resources is real and critical.
7. The real cost of an IT project is not that of implementation, but that generated throughout its life.
Commercially, things seem good at first – the costs may be lower than those of an external supplier. A black scenario is one in which damage is generated due to the implementation of the project / solution. If the project was managed internally – in the worst case, your own employees can be fired, but usually this does not happen either. Instead, an external supplier may be held liable by contract and / or obliged to resolve the situation.
8. Re-implementation costs with an external supplier will be higher.
For various reasons at some point there will be the problem of replacing the internal solution with a product / solution on the market, an external provider. But the existing project generated historical data and habits that will have to be taken over, thus there will invariably be a longer and more expensive re-implementation project.
Finally, it must be said that there has always been and will be a temptation among non-IT customers to turn to internal resources. Someone in the management will think that rather than paying an external supplier, it is better to put employee X to work, as he seems to be able to do. And in some cases, things will work out but only in the short term.
In the rest of the cases, the project / solution will be outsourced to an external supplier (to the joy of the latter) with much higher costs.
How should things be treated correctly? We will write about this in the following articles.