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?"
The boss will always have the idea "These guys CAN'T be any good. They work HERE!" also for the consultants "These guys are GOOD. They cost a FORTUNE."
On such concepts are huge outside consulting practices built. If you want to do the job, go work for a big consulting company; come back to your boss and be amazed on how you're suddenly a genius and he likes your ideas.
Scott Adams had a Dilbert where Wally got canned and came back the following week as a consultant on the same project and recommended exactly the same solution. As a consultant he was listened to.
Ever dream you could fly? Get up from the Flight Sim. I Fly
Do a Cost/Benefit analysis and figure out if you can compete with the vendor. Remeber, you're not only competing on features and stabillity. You're also competing on budget issues.
90% of the problems that I've faced in this area can be resolved simply by coming up with a realistic apples to apples comparison. A lot of the time I've done the comparison and thought to myself... gawd! My manager WAS right!!
This isn't always the case, but managers aren't as stupid/stubborn/ignorant as we would first think.
Step into their budget constrained shoes for a while and see if you still dissagree with them.
foooo
"Don't make me strap the bulk eraser to your head and stick you to the computer-room floor AGAIN!"
That can lead to some interesting conversations later on, though. Your best bet would be to build a (somewhat) working prototype and present it to all layers of management simultaneously - that way, no one person can kill the project. (Although when that happens, it's easier to know whose UTP cable should accidentally be connected to the variac and given a healthy dose of mains.) Be sure to make it beautiful as well as functional; don't let them think that the in-house software will be drab and boring or a pain to use. Try to go for a simple and elegant interface first.
Every cloud has a silver lining (except for the mushroom shaped ones, which have a lining of Iridium & Strontium 90)
In my experience, I started at a company which was making a home-grown application (crm app, mainly). Over the past few years it has been expanded, and updated. It has had its bad moments, but we manage to get fixes out quickly (we have an "automagic" update system in place). Overall, it does the job, most people like it despite some of its quirks - except for upper management, who only recently started disliking it.
Basically, they dislike it because they see it as a "money-sink" - not something that makes them a profit - even though it saves them a lot of money. It has a ton of features tailored to our business - no commercial app exists that could do what it does without requiring - doh! - customisation. At a hefty cost - very hefty.
We basically keep any new development low-key, and keep the current stuff in maintenance. What really irks me most is that the people that dislike the software have never used it. Seems hypocritical to me. The only thing that bouys my spirits is that we have had both clients and vendors see the code in action, and they want to buy it - maybe someday we will sell it...
I work for a company that creates shrink-wrap software, insofar as that description means anything anymore. It's not cheap.
At least once a quarter, a largish potential customer is persuaded by internal IT that they can write the application more cheaply than buying it from us. The IT department is always wrong. I don't mean mostly wrong. I mean wrong 100% of the time. In the vast majority of cases the company ends up coming back to buy a solution and dumps the in house solution. In some cases the company makes do with something they hate.
Think about it. If there is a company out there that provides something close to what you want, and it has more than a few developers / real tech support / real QA etc., how possibly could an in house solution work better?
1) The company could be charging a completely outrageous amount for the software. Good idea, but that simply doesn't happen. That company is out of business immediately, especially in this economy.
2) The company is selling a product that doesn't exist. Vaporware is a real possibility, but if you can actually pilot the stuff, and it's close to what you want, buy it.
3) The software actually doesn't do what you want. You have unique requirements. This is the only actual legitimate reason to build.
If the software addresses a requirement of your company, and no other, the build it. But if the problem is one faced by some reasonable number of similarly situated companies, then just buy something. Robustness, maintenance, updates, new features, support etc. will be way better. It's the advantage of specialization.