Persuading Management on Green-Lighting In-House Software? 56
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?"
Hmmmm (Score:5, Funny)
When I suggest bringing in some "home grown" to my university, I usually end up "helping the police with their inquiries."
Build a working demo.. (Score:5, Insightful)
Invented here IS a losing battle (Score:5, Interesting)
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.
Re:Invented here IS a losing battle (Score:4, Funny)
Luckily, I'm a consultant. If anyone here wants me to write a "proposal" to their bosses explaining that something would be cheaper in-house, just shoot me a note.
Re:Invented here IS a losing battle (Score:3, Insightful)
He is fighting a losing battle, because his boss believes (whether it's true or not) that outsourcing will be "easy" which translates into "cheap". The counterargument is that doing it in-house will be "super cool". From the manager's point of view, this is a no brainer: the programmer can't come up with a fact-based economic argument (or at least, cannot articulate one) and so probably doesn't have one other than wanting to work on a "cool" project. To the manager, it loo
IH vs OH (Score:3, Funny)
Out-House solutions are full of crap
Go with the In-House solution.
Call it IP (Score:5, Insightful)
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.
Re:Call it IP (Score:2)
There is some difference with generic components. If they are paying us AU$110 an hour they expect we don't use the stuff we do in that time for the competition.
Steps (Score:5, Funny)
1) Make the GUI really flashy and super cool. Or at least show the boss a super cool and flashy GUI, even if that isn't the one for your program. It doesn't even matter if your program is supposed to have a GUI. If the boss isn't smart enough to realize the superiority of the in house solution then he is stupid enough to be fooled by good looks.
2) Official written proposal. Official written things are good because it makes physical evidence. Make it good enough to convince any arbitrary 3rd party. That way, even if the boss says no, you can make him look like an idiot by showing the paper to someone else and saying "he said no to this".
3) Use big fancy buzzwords. It seems to work for a lot of other people.
4) Break the current solution. If it aint broke, don't fix it, is a common management philosophy. So if you want to improve on something just break it on purpose. It will give you an opportunity to present your better solution. As long as you don't get caught!
5) After you do all of the above, tell the bosses boss. Also, get fellow employees to help you. If 10 people go to the office to tell him to give the ok, he's more likely than if one goes. And nobody is a bigger influence on the boss, than his boss.
If that doesn't work, either your whole place is stupid and you should find a new job (however hard it may be). Or, your solution sucks.
FURTHER Steps (Score:2)
Don't bother with going above his head or breaking whatever you've got going now. Rather:
Cost vs Benefit (Score:4, Interesting)
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
Re:Cost vs Benefit (Score:5, Informative)
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.
Super-cool? (Score:5, Insightful)
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
Re:Super-cool? (Score:3, Insightful)
Outside companies will at least have a track record to show how long it will take. Unless the in-house people have a credible record for delivering things, of this type, on time and under budget, it is a long-shot.
I'm always proposing "super cool" projects. They would be much better than many solutions we have
Re:Super-cool? (Score:1)
Greener grass (Score:3, Insightful)
Any time we need new software the senior partner asks if we can build it.
I love writing code but my first question is usually "has somebody else already built software to solve this problem?" If the wheel has already been built it will often be cheaper than building a new wheel.
Just do it (Score:5, Insightful)
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.
Because it's his ass on the line... (Score:5, Insightful)
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.
Re:Because it's his ass on the line... (Score:2)
a) utterly mission critical.
b) far too complex to recreate in less than the six months spent by the original IT staff.
c) completely non-fault tolerant.
d) pretty stable as long as you provide lots of RAM and reboot the server every eight and a half hours.
e) written in a compiled language, the source of which has gone mysteriously missin
Research Pro/Con (Score:2)
Well, you'll have to start thinking less like a programmer that wants to do something fun and more like a manager that wants to do the best thing for the lowest cost.
That's not to say your case is hopeless. There are real pros and cons associated with going down either road. See, for example, this. [smallbusin...puting.com]
your boss is at a UNIVERSITY (Score:1)
and he's too lazy to solve a problem. If that doesn't get you fired it should greenlight your idea
Other ways to win. (Score:5, Insightful)
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.
Where I work... (Score:4, Insightful)
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.
Generally, yes. (Score:5, Insightful)
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.
Sue? (Score:1)
1. If it can be purchased, purchase it. We'll be able to sue someone if we screw up.
What about the Limitation of Liability clauses included with all proprietary software and free software licenses?
If it's free, it's no good. Why would they be giving it away if it was any good?
I was in Best Buy yesterday and saw Red Hat Linux Professional at $160 for a box vs. Windows at $300 for a box. Even counting volume licenses, it's cheaper enough per seat to make a potential dent in TCO, but it isn't cheap e
Never overlook the power of bribery or lies (Score:4, Funny)
screwing over of your fellow man you need to perform
in order to rise through the constantly churning
ranks of corporate american management acts as a
sort of "assholes with loose morals" filter. You'll
find that your typical manager type responds very
well to gifts of alcohol, cocaine, and the
occasional high priced callgirl. If you are of a
lower income bracket, lies are sometimes a good way
to proceed. If you can paint a picture in which
the manager will look like some sort of hero, and
hint that you won't mind if they take complete
credit for your hard work (like they won't anyway)
, you'll have a much better chance of getting your
idea past them. Feel free to mix and match
combinations of these techniques.
advanced technique (Score:5, Funny)
blackmail bribe. For a sum of roughly 750 dollars,
you can hire a private investigator to dig up dirt
on the management target you wish to gain influence
with. If you are of a lower income bracket, you can
do some simple investigative work yourself. The
smallest piece of potentially harmful information
can work out in your favor.
Real Life Example:
I found out, quite by accident, that my bosses
boss was a "super secret smoker". This is a major
no-no for a corporate VP. So I'd occasionally have
a gift carton of his favorite smokes delivered to
his residence with some sort of small message, and
a plug for an idea I was having problems getting
past his subordinate (my boss). It's amazing how
something like this can grease the skids for your
agenda.
I know this problem well. (Score:2, Insightful)
The reason? accountability. If a company says they can deliver a product and it fails, you can hold that company accountable. If you say you can deliver a product and it fails, you will likely be in big trouble or get fired.
Don't do it! (Score:5, Insightful)
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".
Strongest Argument (Score:2)
If you haven't built anything this big, what makes you so sure you can? The world is littered with failed projects by people too big for their britches. It's saddled with just as many projects that should have been cancelled before they were deployed to wreck the working lives of those forced to use them.
It is part of your boss'
Re:Not a good way to meet chicks.. (Score:1)
This has always worked for me (Score:3, Interesting)
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.
Re:This has always worked for me (Score:1)
While that might work, it's also an excellent way to make enemies of people in your chain of command who can make your life hell and/or make you go away.
Live to fight another day... (Score:5, Insightful)
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 :)
Beef for beef's sake (Score:1)
I'm not knocking your desire to write, host and manage your own software and services (I share your preference, believe me), but honestly, if it makes more sense to outsource, then outsource. You don't keep a project in-house for the sake of keeping it in-house. Why waste time re-implementing a
Re:Beef for beef's sake (Score:2)
Yep. For the boss, going with in-house software involves a decision about whether they want to be in the software development business. Committing to an in-house solution may imply significant ongoing staffing for development, maintenance, documentation, training (in the sense that the boss' staff must train users), etc. It may be impossible for the boss to make the committment to always
Financial logic (Score:1)
Sometimes the budgets for Universities are determined by how much they spent in the last quarter or last year. If they spend less money then they get less money the next quarter or year.
If I were you I would try and find out what rea
on-going support (Score:3, Insightful)
how did i get my home grown app accepted by management then?
it's been said here before, but i gave it a really splashy looking interface. it's a web based server performance montiroing tool (using rrd if you're familiar). a little bit of creative flash and some damn nifty looking graphs makes upper management cream. what they don't know however (and i've been told by my boss not to ever mention this) is that the software was written in house. as near as they know it is just an off-the-shelf open source software package that was slightly customized for our environment. it'd make me look good to management if they knew i had written it, but it would make my manager look like he wasn't doing his job, so mum's the word i guess.
personally, it's just satisfying for me to see it in use in a production environment so i guess that's thanks enough...
Start-up companies often face the reverse (Score:5, Informative)
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.
My experience... (Score:1, Interesting)
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
Offtopic rant (Score:1)
This requires alot of intellect, understanding, and patience on the part of the coder, but in the end I believe it will pay off. You have
Devil's Advocate Reply (Score:2)
Will new deveopers be able to understand the code?
Will the original devloper have good coding skills?
What happens when the developer goes on vacation and the app breaks?
These are the types of questions your managers will fire at you as reasons not to do this.
Dolemite
________________
What if company goes belly-up? (Score:1)
Don't "develop" or "customize" (Score:2, Informative)
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
Okay Guys - here's the DL on the options (Score:2, Informative)
The new solution is a PHP/mySQL app that, structurally is 70% there already. It is customized for our tracking needs, is tied to
Re: try RequestTracker (Score:2)
1) Try for a compromise solution - pick an open-source ticketing system which you can modify. Thus, your boss saves money because he's not buying a commerical product, and you can eventually customize the product.
This will work really well as long as you pick a good system - see item 2 for my favorite open source ticketing system.
2) Try RequestTracker - RequestTracker [bestpractices.com]
It's an open-source Ticketing system that can run on MySql/Postgresql/etc. It h
What's wrong with easy? (Score:2)
You say that like it's a bad thing.
Maybe they're right (Score:2, Interesting)
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 m
Re:Maybe they're right (Score:2)
What if there is a free software project that already does 80%? It would be criminal to be dependent on a single company without access to the source code if you could just improve something already out there, and then have the option of outsourcing it to any number of bidders.
Not necessarily so. I w