There are many reasons why managers today fall into the trap of building software solutions in-house.
* Management often views its employees as free. They think to themselves, "Well, I have these people on my staff and I'm paying them anyway so I'll just make them build it." Not only that, but budgets for people and budgets for software or Software-as-a-Service (SaaS) solutions are separated and unmalleable in many companies. People budgets are always much higher so the idea of employees being the better option is reinforced from a budgetary perspective.
* The ongoing support and maintenance cost of automated systems is often underestimated by managers. Software breaks all the time, even when you haven't changed anything: for example, Windows may ship a patch that breaks you or a slight change in usage patterns reveals a bug that was always there. If the employee who wrote your in-house system has already moved on by then, you are in big trouble.
In terms of cost, many managers also underestimate requirements gathering, testing, documentation, and to a lesser degree, the design and creation of the software in the first place.
* If a company had a bad experience with a software vendor in the past, managers may be hesitant to follow the purchasing route again. Unfortunately, some vendors raise maintenance cost too rapidly or sell a solution that is too impractical to be used, which amounts to shelfware. In order to avoid this, companies must use forethought in the contracts they initially sign with the vendor - forethought that many people don't get around to spending time on.
* Opportunity cost is generally ignored because the lack of a time tracking system leads to the lack of understanding of per-person per-project profitability. In other words, there is one most profitable thing that a particular employee can be doing right now for the company. Building an in-house time tracking, CRM or issue management system is almost certainly not it. If managers have not been measuring costs (i.e. tracking time), then they cannot possibly know where the company is profitable and where it is not.
Curt authored a project management book in 2007