I'm late and most of what I'll write has in one or another form already been said in some of the comments. Nontheless I can't resist to provide an answer. I might add that I'm working for a german based engineering service provider (SmartCAE) and we are using Mathematica as one of our main tools for almost 15 years, so we do have some experience in the field.
Here are the answers to your specific questions from my point of view:
- From a pure technical point of view, Mathematica would definitely be suitable, and much more so than Excel.
- Learning Mathematica can very well be seen as a lifetime's task. On the other hand I think it's possible to get ready to solve typical engineering tasks within a day, depending a lot on prior knowledge about mathematics and other tools or programming languages. But Mathematica is quite different than many other systems/languages, so at some point many people start to struggle. It needs a "positive attitude" to get past that point, and only after that one will reach the full productivity that it can provide. I would expect only a fraction of the engineers in a large departement to reach that point, everyone else will learn enough to get their jobs done but probably not enough to recognize/appreciate the added power that Mathematica could provide.
- Considering engineering applications, I think there are alternatives, but I think they either do suffer from roughly the same weaknesses as Mathematica or are very (too) limited to what they were made for, which might or might not be a problem for your departement. Some of them might be more well known among engineers and thus have a lower acceptance threshold. From the pure technical point of view I'd consider Mathematica to be a good choice when compared to the alternatives.
For engineering applications both Mathematica and Excel do only provide a relatively low level platform, so you will probably need some additional tools to make your engineers productive. This could be a (or some) DSL as Leonid suggests, but maybe also just some other tools which will help the engineers to do their job without necessarily become software engineers and Mathematica experts. We have developed such tools for our internal usage, and without them would have a hard time to provide our services within the given cost limits. Actually I'd consider it necessary to provide such additional tools for Excel as well, but there some knowledge is implicitly expected from everyone working with a computer and people will happily (?) use and accept it as it is. That might be unfair but is a fact that simply can't be overseen.
That said, I think whether Mathematica can successfully be introduced in a larger departement which uses Excel at the moment is not so much a question of technical suitability. I'd rather see it as a "social task": Such a transition will force everyone to learn new things and will make experienced personell feel like beginners. Only if you can convince the key users ("tool providers") and a majority of the engineers that such a transition makes sense you can expect them to take that hurdle. If only some users with influence will not be convinced, I would expect such a transition to fail. As every software tool Mathematica has weak spots and oddities: these are usually easy to overcome and none of them does actually make Mathematica useless or very hard to use, but it's easy enough to make it look like that would be the case. Unfortunately it doesn't help that you can find such cases for the exisiting tools like Excel just as well, you can't expect people to make fair comparisons in such situations. So I think you'd really need to make sure that you have the support of users and the management. To gain that, you'll probably need to:
- Ensure that everyone agrees that there is a problem with using Excel, maybe listing
everything that can't be done with it or has gone wrong in the past.
- Persuade that Mathematica will solve those problems without introducing new ones.
- Comparison with alternatives
- Have ready a plan how the transition could be done
- Have ready an estimation on what this will cost and what it might save/add in the future.
Especially the latter will need to be realistic, you'll most probably be cited on that. Costs will of course include training, licenses, expenses for rewriting existing tools, additional IT administration, etc.
A set of real world examples will help a lot, unfortunately many of the examples you'll find on WRI's pages are rather showing the principles, but don't really qualify as "real world" (IMHO). In many cases that's just because they avoid the "simple" things like importing and exporting data, providing numbers with units etc., in other cases they just don't provide all the parameters as inputs that you'd need to run real world examples. So you'd probably need to provide some examples yourself.
All in all that might be a big project. On the other hand, and that has also been mentioned in the comments, you could just as well try to introduce Mathematica as a tool in a less official way by just starting to provide useful stuff written with it. If you manage these tools to run in the CDF-Player, you could even give them away to your colleagues without causing additional costs. I think many "modern" tools have been introduced in such an "informal" way in large companies (I know some examples from german automotive companies, but unfortunately that hasn't happened to Mathematica in a larger scale (yet?)).
Of course that's only possible if your employer allows it.