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?"
I don't know how feasible it is for your particular case, but when we needed an app to help us at work, we wrote a nice, clean working demo and showed it to management. *bang* Just like that, there was much praise and awe. Of course, YMMV.
What, me Tweet?
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.
What arguments have been used to sway the boss to use the super-cool home grown solution?
Well, for starters you had better stop thinking of your in-house solution as "super-cool" and start thinking in management terms. If you can replace "super-cool" with "cost-effective" or "easily-extendable" or "readily-supportable" without lying then you may be on to something. But from the brief description of the problem that you've given us, you didn't really make a strong case for why using the in-house solution makes good business sense. So I'm guessing you probably haven't made a real compelling sell to managment either. Maybe you feel that because you're talking to a bunch of "fellow nerds" that you can "talk frankly" with us. But if you really, truly, in your heart-of-hearts see the in-house solution as primarily "super-cool" then I would question whether the in-house solution is really the best choice here.
GMD
watch this
When I'm in this situation, I just do it. My dignity is at stake, so I'll even put in extra time to do it on off hours and weekends. If the solution already exists, then the boss will be very reluctant to pay for a second implementation.
On the other hand, if it would be too much work to get done on your own time, then your boss is probably correct in getting it outsourced.
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.
You may not be fighting a losing battle due to pointy-haired-boss problems. If you haven't developed much other software in-house and the boss thinks this app. is critical to not have done "half assed" then s/he has a legitimate fear that you have no track record, and s/he doesn't want to get saddled with crappy software.
That said, the fact that this is important enough to you to keep trying is some evidence that you might have the perseverance to create a polished, completed product.
A approaches come to mind:
1) As others had hinted, code a demo quick before s/he signs on the dotted line for the contractors. There is not better evidence that you can do something than doing it. If they boss sees you did 30% of the work in X weeks s/he might reasonably assume in 4X weeks you could have a pretty good version.
2) Create an implementation plan. Tracking systems can be imagined and built more grandios and powerful than can be found of the shelf. If you make a convincing development plan with milestones and features far in excess of the spec. going to the contractors s/he can see the big-picture value of the in-house development more clearly.
3) If a contracted services are a must (and they might be). Get a quote from people who will host onsite and maintain your systems remotely. Also get a quote that includes an Open Source solution. Letting someone who has coded a dozen of these systems start you off with a great code base is NOT a bad thing. This gives you the "proving ground" option with the boss as well. The boss can ask you to add a feature, and if s/he doesn't like the results he can still hire the contractors to add features until such time as your team can convince/replace him/her.
We Open Source contractors are not hard to find, and many are glad to share source, tips, good stories and stories of mistakes that you don't want to repeat.
Best of luck.
...accepting 3rd-party solutions isn't just a preference, it's a POLICY. With all the money we spend on licensing fees, we could afford to hire another programmer, not to mention the fact that we could sell the software to other organisations for quite a large profit.
And that's not all - open source stuff has been banned (the result of one of Microsoft's visits to the boss) and we once calculated OSS would slash our licensing prices by nearly 75%. We have plenty of OSS-savvy IT staff, so it's not like we couldn't maintain it.
Basically, my (somewhat cynical) advice is to implement the solution with or without permission from management, and chances are they'll be so impressed that they'll agree to keep it. You REALLY need a nice gui (even if you're never going to use it in practice), if possible even prettier than any of the 3rd party solutions. Perhaps even get a demonstration copy of the 3rd party solution and show it not doing what you need it too, or better yet, crash it.
This is the way I got Apache installed instead of IIS.
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.
99 times out of 100, if there is a solution that provides a substantial portion of the desired functionality, you will be better off using the outside solution, than making one yourself.
If you are that 1 in 100, perform a cost benefit analysis using twice your most conservative estimates for BOTH time and money. If your Return On Investment over the first 5 years is less than 50%/year, don't do it. Otherwise, present your analysis to your boss.
REMEMBER, your time is NOT free. In a university environment you cost about twice your salary. This is true even if you would otherwise be twidling your thumbs or if you offer to do the work during your "free time".
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 :)