Slashdot Mirror
Persuading Management on Green-Lighting In-House Software?
Raisin Bread asks: "Maybe I'm fighting a losing battle - but has anyone out there encountered an administrative resistance when it comes to giving approval to make in-house solutions for problems? I'm at a university, and we want to build a tracking system that will accommodate our needs perfectly (and can do it), but the boss wants the easy way out by contracting out to a remotely-hosted and managed solution. Sure, they are commercially supported, but the fix is only mediocre. What arguments have been used to sway the boss to use the super-cool home grown solution?"
Absolutely. It's not different than, say, getting your managers to let the developers switch over to using Linux for their dev workstations, or MySQL or PostgreSQL instead of Access or MS SQL Server -- it's a cost/benefit comparison, which you have to *figure out* the correct answer to. Developing software in-house is almost always at least as expensive as buying it; however, if the off-the-shelf solution doesn't have features or options you really do need, then you're going to have to get the vendor ($$), a consultant ($$$), or someone in-house ($-$$, plus a lot of waiting) to do the customization. Plus, once you've customized an outside solution, it may or may not still be eligible for normal support and upgrades from the original vendor.
I've found that having a short (1-3 page) analysis, which lists the functional requirements for the system first, and then breaks down where the front-running commercial packages do and don't meet those needs, along with an estimate of the cost and time needed to adapt them to work (if it's even possible, of course; sometimes, you don't get access to source code, or even an extension API). Along with that information, you need at least a ballpark estimate of the development time and costs associated with doing it in-house, which should actually be fairly accurate. If possible, get a non-programmer who has been involved in development projects before to look over the estimates for your solution, and call BS on you where they can.
It's definitely a battle you can win, but first you need to have more than your hacker's disdain for other people's code to prove that the in-house way is best.
I've often had the experience working for start-ups where in-house software was preferred over anything else, despite dumping well over $500k in development cost into a program that's only half as good as a commercially-supported $200k program.
As has been stated elsewhere, there is the problem of people only staying so many months, but there also is the problem of inertia in a business. If you buy something, then switching to another bought solution is easy. Getting rid of the sacred cow of internal development is difficult.
I fought and lost an uphill battle to chuck internal software development on certain apps. Now that company has all but tanked.
The power of accurate observation is commonly called cynicism by those who have not got it. - G.B. Shaw
Instead, find an existing OSS project that is close to what you need (or not very close, in which case, make sure it's obscure) and tell your boss all it needs is to be configured for your needs. Even if this means you are "configuring" PHP, Perl, or Apache.
I was amazed to find out how much can be justified in terms of development if you call it configuration instead of customization or development. You might suppose these words overlap in meaning, but not to a business person who has already made up their mind to only use "off the shelf solutions".
Try it!
The home-grown solution is an upgrade from the legacy FileMaker Pro system that helps us track trouble tickets (for the campus CMS called 'Blackboard') and small multimedia projects. It works, but we are going to support the entire student body in the fall. We need a better system. (The FMP dies everyonce and a while, and its just not made for what we are doing with it even now.)
The new solution is a PHP/mySQL app that, structurally is 70% there already. It is customized for our tracking needs, is tied to a Knowledge Management System (that is also tied to completed tickets). The KMS will have an expert system (sorta like a troubleshooting wizard), a keyword search and a pseudo-natural language search. It has its own project management system that is tailored to our needs.
The commercial product (called 'Parature') the boss is looking at is a ASP based (I think) solution that has basically generic trouble ticketing functionality. The GUI looks great to me. It is terribly slow right now (10 secs to load the main admin screen), but that is supposed to change. No projects management that I'm aware of. It has a KMS, but its a simple keyword searchable categorized organization that only goes two levels deep.
I like my own solution because it gives us ultimate flexibility. We can tweak whenever we want (which happens on a semi-weekly basis already). I hate outsourced out-hosted solutions because they go down and you can't do anything about it. Also - I'm not writing it in some obscure language.
We have maintained our current solution for two years - so its not like this is a first for me.
Also - I plan to make this Open Source if we do it . . . so help me out here, gentlemen!!
--John