[Off-topic]
Bonnie,
From what you've told us about real estate prices out there, programmer rates (actually rates for most occupations) are likely well above national norms. I knew companies like CSCO do a fair amount of merging, but would have guessed that mostly there are startups (IPOs) going on out there, and hence the insatiable need for technical talent.
Usually when company A buys company B, company A calls the shots in terms of information infrastructure, unless company A concludes their systems are far inferior to company B's, in which case they will want to move their stuff to company B's system. I've seen it done both ways.
Merging the systems' data, though time consuming and requiring a great deal of attention to detail, is something of a no-brainer. Usually, the two databases can be made compatible in the abstract and the appropriate conversion programs are written, tested, and executed. I've done several. The two systems are kept running in parallel only if absolutely necessary, and usually for political reasons, as you've indicated, or severe technical problems. Of course, once the databases are merged, the retired system's employees must be trained on the continuing system's processes. And even in the most successful of system merges, there will need to be additional functionality created over the continuing system so that the retired system's employees don't lose any functionality that they deem critical. Usually, this last step is performed in the name of political appeasement, since the previous system did everything necessary to conduct the business. Still, if new areas of business activity come on board as a result of the merger, then this missing functionality becomes absolutely critical, and must be replicated as soon as possible.
Not merging the systems is ultimately a mistake, as the data resource cannot achieve its full potential due to disparities and inaccessibilities. Furthermore, high- and some mid-level managers have great difficulty getting the big picture because it has to be laboriously constructed from incompatible data sources. Ad hoc questions become completely out of the question. The relatively recent introduction of data-warehousing was supposed to correct for this but, as usual, theory works a bit better than practice.
There is nothing particularly special about a merger that would require high-priced technical consultants, although I can imagine a few scenarios where it might be appropriate:
1) The I/T groups from both companies don't the possess the skills to conduct a large-scale merge. Though unlikely, this could happen.
2) A great deal of functionality needs to be developed over the merged system because the merger involved multiple new lines of business. This would require swarms of temporary workers to crank out and test new code. Code from the retired system, though possible as a reference, cannot generally not be used, as it is now incompatible with the continuing system's database.
3) It may be decided that both systems are a hopeless mess, or, more likely, that now is a good time to upgrade to a newer technology (wrong!), and a new package that will satisfy the merged entity is selected. This is where a product like SAP or BAAN is selected, or a complete rewrite(!) is performed. In this case, most (a much as 95%) of the existing I/T groups are deemed redundant and let go, or more likely, the I/T function is out-sourced to someone like EDS and the total existing I/T staff is laid-off and then rehired by the out-sourcing company, maybe. A completely new, high-priced I/T group is brought in with the required technical expertise. Some of these merger projects last many quarters. As you can imagine, this proposition is very risky (the new system may be a complete failure), very political (everyone hates the new system), and very expensive.
4) The politics of the merger are such that those in a less than secure position wish all (or certain) aspects of the merger to fail. Therefore, outside consultants are brought in as paid patsies. You don't want to use your own people when playing these games, if possible. The project fails due to lack of management support (though this is not entirely apparent to the casual observer), the consultants are discredited, the appropriate entities get to say "I told you so", and then firmly seize the reins and call the shots. Don't laugh, this does happen. In this case, the cheaper the outside consultants, the better. You don't want to overpay for failure!
As for programmers with MBAs? These are what are I would term "glorified technical managers". I've seen some of this, but usually (and again, this is a generalization), the twain shall never meet. You end up with about what you would expect. The mind-set of a programmer is not that of an MBA. The programmers that I've seen go this route are usually, not always, pretty poor programmers. Most programmers hate politics and people issues -- that's why they're programmers and very happy in that role. Furthermore, anyone professing to be both would very likely not be particularly effective at either, especially straight out of school. This would explain why the combination programmer/MBA would be a hot commodity, if it even truly exists. |
