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?"
When I suggest bringing in some "home grown" to my university, I usually end up "helping the police with their inquiries."
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
Some places place value in owning IP. If you develop it inhouse you own the IP and can log it in the books as assets.
If you buy a third party solution, they still own the IP.
Back in the dot com era it was a common way to cook the books. Development costs were essentially free because any money paid to the developers could be directly written off as an increase in value of the IP they developed.
I also work in small college IT department and have seen the exact same problem.
The reason is, if your home built system barfs, it's your fault, and also your boss's fault.
If it was contracted out, or a commerical produt. Blame lies with the vendor, not with the decsision to go with that product.
So far the best solution I've found is to find a Open Project, or system where you get the source (such as PerlDesk, www.perldesk.com) call them the vendor for upper management, and then make the "tweaks/custom code" that tailors it to your system.
The general rule when it comes to corporations and software is this:
1. If it can be purchased, purchase it. We'll be able to sue someone if we screw up.
2. If it can be written in-house, encourage the people who could write it to become familiar with the product we're getting ready to purchase. This way, they won't be able to hold anything over your head or try to claim rights to anything. No source ownership issues.
3. If it's free, it's no good. Why would they be giving it away if it was any good?
I don't agree with any of it, just for the record. That's just how the conversations usually end up when I have them.
Firstly, since I work for a large multinational company my experience may only be typical of that category but I think the lessons may hold value elsewhere too. Your question hit home since I'm on a project that was initially supposed to be done "in house" - now we have atleast 5 different 3rd party vendors and our job is more like being an "integrator" for all of them. We tried very hard to show that our solution was viable and that we could do it but in the end we lost. The lessons learnt are as follows:
My personal experience has shown that management doesn't place much faith in the technical staff. There is no rational, no logical reason for this behavior but they are only convinced by people they have known for a long time or come to them via some higher authority (e.g., super-star consultants who a technically astute person may recognize as no more than paper-tigers). This is more likely to happen if the upper management folks are new, don't know the technical staff and are easily taken in by hype or are plain narcissitic.
I don't discount that there may be management folks who are not like that, there are good companies who may listen to their technical staff but they're far and increasingly fewer today.
Another problem is that many management folk are like sheep/copy-cats - "hey! database XYZ worked great for that company, I gotta get me some of that...". The current mantra seems to be of reducing costs by outsourcing and reducing the true artistic/design level work to a minimum while "cheaply" getting results.
No matter how straight forward the design is, project manglement always gets the last say - I have $X and need this done - I can get it for $X/2 from this third party (never mind that it perhaps only gets you to 50% of the requirements).
Sad conclusion is that this is not bound to end here. The only recourse is that one joins the rank of one of the companies that actually do the work...until they grow and can outsource. Sometimes I code just because I want to build something for myself. The job...is just a job. The age of doing creative things at work is fast fading into memory. On the bright side, I have also encountered that short term expidency with this out-sourcing fever always loses in the long run. The solution to surviving in with irrational management? That I'm still working on :)