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."
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?
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
Out-House solutions are full of crap
Go with the In-House solution.
134340: I am not a number. I am a free planet!
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.
Follow these simple steps
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.
The GeekNights podcast is going strong. Listen!
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
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.
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.
"Provided by the management for your protection."
and he's too lazy to solve a problem. If that doesn't get you fired it should greenlight your idea
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.
As a general rule, the constant debauchery and
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.
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
The key is to start small. You have to prove on smaller projects that you can make robust, reliable, and maintainable software. Then move up to larger systems. The more mission critical a piece of software, the harder it is convince management that you can provide the solution yourself.
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. Thus reducing your managements team of techs. Also, it looks poor for management because they:
1) hired someone that couldn't perform their job requirments
2) approved you to work on a project that could have been outsourced
Its a tricky situation that I fight with almost daily. Luckily, once you get passed the initial proof that your software works it becomes easier.
Altp.
Almost missed this one. I like to call it, the
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.
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
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".
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's job to be skeptical. (Would that he were more skeptical of the sales people who promise to do better than you.)
"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)
Sometimes I wish for the poster's problem.
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.
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 :)
Perhaps your boss wants to go with the commercial solution because he wants you to spend your time doing your job, not writing tools to assist you in doing your job when there are viable solutions already available?
;-)
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 solution that's already available when you have other things to work on? If its more reasonable to keep it in-house, then you should have no problem presenting a favourable argument to your boss. If you're having trouble rationalizing your desire, maybe your desire is irrational.
-Nick
If you were working for an organization that cared about finances then they would go with whatever did the job best for the least amount of money. Since you are working for a University it is likely that money is of secondary importance as it is not their money they are using.
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 reasoning the decision maker is using. Some folks might be concerned about cost and thus your in house solution would be attractive. If the decision maker raises objections to your solution try to determine what objections they feel are most important. If the objections change as you counter them then the decision maker has a reason that they are not voicing and if you can not determine what that is you will have no way of getting the solution you think is best.
Sadly the best solution in a technical and financial sense is very seldom the best solution in a political or organizational sense.
Good luck
dzimmerm
Jumping to correct solutions slowly is better than jumping to incorrect solutions quickly.
i've fought this battle myself (and eventually won it), but you have to understand that the management has a very good reason for frowning on in-house solutions. the number one factor is the 18-24 month average lifespan of technical employees. once the company has invested the time into your solution, and you then go off to greener pastures, they are left supporting an app that nobody knows a damn thing about and will then have to go and buy the 3rd party app anyway. basically the company (university in this case, but whatever) is choosing a supported application because they get signed contracts that the product will be backed up by the provider, even when people leave for another job.
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...
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
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 am becoming more and more of the opinion that becoming a good programmer/developer, you must have a good sense of what problems other departments in your organisation has. Once you grasp the issues that exist which hamper productivity, a programmer can try to implement something simple and elegant (or, sometimes, not so simple or elegant :) which can really do the job.
:)
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 to try to predict what it is that your organisation needs, and what bottlenecks and problems exist. Else you will just end up writing code for managers that had problems understanding the problem in the first place, and you implement something that takes 3 times longer because nobody can properly write a specification that explains the problem.
I work at a moderately-sized ISP, developing applications that try to reduce the load on the support staff. I'm thinking at the moment of actually doing some support work, just to get the feeling of what is needed, and what will reduce the support-staff's workload significantly.
Maybe I'm just being naive. I'll make slashdot my rant-outlet then.
ciao
So what if this Developer who makes this in-house app for you leaves and changes/upgrades to the code need to be made?
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
________________
Save the World! Use a Quote!
We recently had a situation similiar to this happen at the company I work for (a midwestern car manufacturer). About three years ago management decided to outsource a web-based project that would allow our parts suppliers to get real time information (inventories, orders, etc.) from our materials department. This company did all the development and also housed most of the data on their servers. About six months ago this outsourcing company declared bankruptcy and the prospects of them surviving don't look good. Now and only now has management decided that we had better develop an in-house solution.
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
You say that like it's a bad thing.
Clearly, you must be working with SAP.
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.
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 enough to trigger "you get what you pay for" syndrome.
Will I retire or break 10K?
At the risk of disappointing you, here's what I think:
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
It's an open-source Ticketing system that can run on MySql/Postgresql/etc. It has a nice web-based interface, and supports all the functions that you usually need with tickets (linked tickets, watchers, email support, attachments, etc.)
Lots of people have also written plugins for RT - you can pick your favorites, and also write your own. Hooking in the KMS sounds like a good example.
One key advantage with RT is that it stores its tickets in a database that can be easily reported on via any standard reporting tool. We always want some specialized reports from our ticketing tool (how long each operator took to answer tickets, how many tickets come from each account, what are the longest tickets to resolve, what's the mean time between open and resolve, etc.) Anyone who knows a little SQL can write all of these.
3) Get your requirements straight. Make sure you know what features you want out of a ticketing system - and then be sure to illustrate which ones Parature will not support. RT will almost certainly support anything you really need - and you can always add features if you really need them.
-Peter
Don't bother with going above his head or breaking whatever you've got going now. Rather:
It's like bowling for dollars! Set 'em up--then Knock 'em down!
I mean, if this manager had any skills, she'd get both you in-house and the consultant working on the solution "to see a demo", and saw what worked best, without making any concrete decisions or promises until it was absolutely necessary to make a decision. In the interests of (cynical spin on the positive approach here) "brainstorming" she'd flatter both of your sets of ideas in meeting after meeting, getting you to give away your best ideas in the course of "requirements capture" while the conslutant takes them, incorporates them into its own products, lands the fat contract, and gives her a fat kickback and/or perquisites (read: boozy lunches at the very least).
I mean, we should all be so lucky as to have a manager as honest and forthright and decisive as yours.