Most Linux installs in business and other organizations come as replacements or add-ons for existing systems. In most such cases, however, management replaces the operating system, the application software, and the hardware but not the people.
Where those systems run PC services like file and print or simple websites Linux usually replaces Windows. In that situation the people involved will be good at what they know how to do, and Linux won't force them to change - meaning that they'll just continue doing what they know how to do: run Windows, even though they're now doing it on Linux.
Where the new install is intended to replace machines running more complex applications services Linux usually replaces either Solaris or one of the dead and dying like AIX and HP-UX. Where it replaces Solaris you have to ask what would motivate such a change given that Sun makes the fastest and cheapest x86 boxes and gives away Solaris for nothing -and in the latter case you have to wonder why they hung on this long. Either way, you'll find yourself, more often than not, pondering the existential meaning of the fact that almost all IT projects fail to meet budgets, time-lines, or expectations but a similar preponderance of IT resumes show nothing but increasing personal contributions to the outstanding success of every project the person ever heard of. In other words, it's a pretty good bet that a majority of such installs will benefit from the same expertise that brought them about -not a pretty picture, but a realistic one.
What you usually see in smaller organizations whose people treat Linux as a simple Windows replacement is that Linux gets used to implement PC workarounds for limitations Linux doesn't have - things like the one application per server rack mount approach to SMP. The obvious result is a Linux installation that looks like a success because it works - but there are three non obvious results that are significantly more negative than that:
In other words, the potential gains from using Linux, both to the organization using it and to the Linux community, may be largely wiped out by superficially effective, but fundamentally ill-informed, implementations.
In big organizations where traditional data processing groups are still in control there's a tendency to do something even more counter-productive: create a compartmentalised Linux Development and Testing Center. This expands the director's span of control and budget, often garners positive press and certainly makes data processing seem forward looking, neutralises the threat of change to daily operations, and effectively ensures that any implementation eventually approved by an annual budget committee will require a second pass through data Processing's suitability filters before deployment and even then usually affect only systems staff judged low enough on the totem pole not to matter.
The underlying problem in both kinds of cases is that the bosses, the non technical types who make or ratify the decisions involved, haven't a clue and therefore rely on sources like their data processing director, the consultants he approves, or Sunday supplements and the similarly clueless nit-wit on the next barstool.
Fundamentally this is an information asymmetry problem - with most of the knowledge on one side and the money on the other: i.e. a real world example of the perfect theoretical recipe for ineffective decision making.
So here's my recommendation: take every possible opportunity to educate other people's bosses about Unix - and tell them that bringing Linux in is a great idea, but will generally also require them to take control away from their present staff and give it to people hired for the job.