That IT professionals can't "speak" to business professionals and vice versa is a universally recognized truism.  (To paraphrase Mae West, "Men and women have nothing in common; all men think about is women, but all women think about is men.")  If anything, the language/culture gap is even greater between IT professionals and lawyers. 

If I had a magic bullet to solve this problem, you'd be reading a blog about IT and business alignment instead of about the economics of law firms, but the chronic difficulty in coming up with a common language—where words like "cost," "process," "function," and "risk" actually mean the same thing to people on opposite sides of the table—can and often does have a serious detrimental impact on a firm's finances both through wasteful and failed projects and through less-than-optimally-productive "solutions."

Neither side, let me hastily say for the record, is right or wrong.  Both, understandably, proceed from their own comfort zone.  IT professionals may think that their focus on a coherent overall IT "architecture" for the firm and delivering specified functionality to the "desktop" is enlightened and strategically correct.   But lawyers may think that short or nonexistent learning curves, always-on availability, and seamless integration of digital and hard-copy documents is the name of the game.

I have a suggestion.  Or rather, both McKinsey and CIO magazine have a suggestion:  Create a joint IT/lawyer advisory council or steering committee to ensure alignment of IT initiatives with lawyers' actual needs.  The goal is to move conversations past crisis management and budgeting, and on to the plane of securing managing committee buy-in for IT's work.

The CIO piece discusses this straightforwardly and with great competence. 

The McKinsey piece, characteristically, adds a back-flip and a spin, but one of tremendous value:  It points out that a chronic "failure mode" of IT spending is the perpetual motion spent on trying to scotch-tape and baling-wire together an endless array of disparate systems (client information, conflicts, financial reporting, time-keeping, practice group metrics, e.g.) and that a newer and more enlightened approach is to substitute small stand-alone software "modules" (think LEGO blocks) for today's "spaghetti."  These discrete, stable modules can then be assembled into full-dress systems.  An example clarifies the concept:  How many ways does your firm have for users to log in and authenticate themselves?  If the answer is > 1, you can start there.