We consultants live and die on methodologies. Just as double-blind therapeutic trials are what make modern doctors are more reliable than shamans for preventing and curing diseases, the methodologies we consultants use are what make our analyses and recommendations more reliable than an executive’s gut feel.

Take, for example, the methodology I use for application, application portfolio, and application integration rationalization (AR/APR/AIR).

It starts with collecting data about more than twenty indicators of application health, redundancy, and integration for each application in the portfolio. It’s by analyzing this health data that my colleagues and I are in a position to reliably and provably recommend programs and strategies for improving the enterprise technical architecture’s application layer, along with the information and platform layers the applications rely on.

For large application portfolios the process is intimidating, not to mention invasive and expensive. Fortunately for you and unfortunately for me when I’m trying to persuade clients to engage our services, there is a more frugal alternative. In most situations it’s amply reliable for guiding AR/APR/AIR priorities as our sophisticated methodology, while costing quite a lot less.

Call it the TYE methodology, TYE standing for “Trust Your Experts.”

But first, before we get to TYE, take the time to clean up your integration architecture.

Maybe the techniques you use to keep redundant data synchronized and present it for business use through systematic APIs are clean and elegant. If so, you can skip this step on the grounds that you’ve already taken it. Also, congratulate everyone involved. As near as I can tell you’re in the minority, and good for you.

Otherwise, you need to do this first for two big reasons: (1) it’s probably the single biggest architecture-related opportunity you have for immediate business and IT benefit; and (2) it creates a “transition architecture” that will let you bring new application replacements in without hugely disrupting the business areas that currently rely on the old ones.

And now … here’s how TYE works: Ask your experts which applications are the biggest messes. Who are your experts? Everyone — your IT staff who maintain and enhance the applications used by the rest of the business, and the business users who know what using the applications is like.

And a bit often missed, no matter the methodology: Make sure to include the applications used by IT to support the work it does. IT is just as much a business department as any other part of the enterprise. Its supporting applications deserve just as much attention.

What do you ask your experts? Ask them two questions. #1: List the five worst applications you use personally or know about, in descending order of awfulness. #2: What’s the worst characteristic of each application on your list?

Question #1 is for tabulation. Whichever applications rank worst get the earliest attention.

Question #2 is for qualification. Not all question #1 votes are created equal, and you’re allowed to toss out ballots cast by those who can produce no good reason for their opinions.

Once you’ve tabulated the results, pick the three worst applications and figure out what you want to do about them — the term of art is to determine their “dispositions.”

Charter projects to implement their dispositions and you’re off and running. Once you’ve disposed of one of the bottom three, determine the disposition of what had been the fourth worst application; repeat for the fifth.

After five it will probably be a good idea to re-survey your experts, as enough of the world will have changed that the old survey’s results might no longer apply.

You can use the basic TYE framework for much more than improving the company’s technical architecture. In fact, you can use it just about any time you need to figure out where the organization is less effective than it ought to be, and what to do about it.

It’s been the foundation of most of my consulting work, not to mention being a key ingredient in Undercover Boss.

TYE does rely on an assumption that’s of overwhelming importance: That you’ve hired people worth listening to. If you have, they’re closer to the action than anyone else, and know what needs fixing better than anyone else.

And if the assumption is false … if you haven’t hired people worth listening to, what on earth were you thinking?

It was a busy week and busier weekend, so it’s re-run time again. This is one of my all-time favorites: The Desk o’ Death and why it’s a manager’s dream assignment. It first appeared, in InfoWorld, 12/11/2000.

– Bob

# # #

As every programmer knows, God was able to make the world in only six days because he didn’t have an installed base. Programmers rarely have that luxury.

New managers have a different kind of installed base to worry about. While the difficulties they face are not as technically daunting as creating a backward-compatible operating system upgrade, the social engineering issues faced by a manager taking over an existing organization present their own set of significant challenges.

When you take over a department, whether it’s through a promotion or a job change, you don’t get the luxury of designing your operation from scratch. You’re inheriting an installed base — an existing team, well-worn processes and ways of doing things, and an entrenched culture. But where programmers usually have a test environment in which they can safely find and fix mistakes, managers have to do their testing in the production environment of an ongoing operation. Missteps are very public, and hard to unmake.

The social engineering starts before you take the job. If at all possible, find out whether you’re walking into a problem area or not. If it isn’t a problem area, try to get a mandate for change from the reporting manager to create a problem where none existed before. Failing that, let some other victim take this no-win job.

Coming into a smoothly running organization is much harder than taking over a disaster area. How are you to succeed? Your chances of further improving the situation and having the team look to you for leadership are low. If your charter is to maintain the status quo, your predecessor will get the credit if you succeed; you’ll get the blame for any deterioration.

Compare this to the desk o’ death. The department is in shambles. The team is demoralized, productivity is low, waste is high, service levels aren’t. Whenever possible, choose the desk of death, especially if you’re the third or fourth manager to get the job — expectations will be so low that your success is virtually guaranteed.

So long as you follow a few simple rules.

The first is to keep your yap shut. Beyond the usual pleasantries of how delighted you are to have the opportunity, say as little as you can. Listen to everyone, in group settings and one-on-one. Neither agree nor disagree with anything beyond broad philosophical concepts, and above all, don’t choose sides or make any commitments. Offer no ideas of your own. Listen and make note of who says what.

In a desk o’ death, everyone has a private agenda and is trying to recruit you. Assume everything you’re told is biased. You have to piece together an accurate assessment jigsaw puzzle fashion out of bits and pieces. The moment you accept any individual as a preferred or unquestioned source of information, you lose your ability to lead — your preferred source will have established his perspective as your own.

So the first rule is to take time to size up the situation. Then you can decide what needs to be changed — processes, technology, reporting relationships, team members (chances are, if it’s the desk o’ death not everyone is a great employee), attitudes, or what have you. And, you can choose your priorities.

That’s the first rule. The second will have to wait until next week.

Until then, trust nobody.

# # #

Since this is a re-run it’s only fair to provide the link to the follow-up column. Here it is.