Please add examples of Consultant Wisdom here.
Real Consultant Wisdom:
- Come up with some excuse to pull people off and talk with them. (We used an automated tool to do "paper flow analysis" of companies.)
- Ask every employee you meet "what should be done to fix things around here?"
- Write down their answers and present them to upper management.
Upper management will consider you brilliant, as they've never heard these ideas before. (...something about not listening to the people actually doing the jobs... ;-)
Sounds like the SnafuPrinciple
at work to me...
(Don't blame this on my current employer. This happened with a previous employer; a large multi-national corporation who's name everyone would recognize. ;-)
As far as I can see, there's nothing morally wrong with that; after all, everybody profits. Of course, the customer could have listened to his employees in the first place; but that's not your fault, is it? -- FalkBruegmann, in a provocative mood
Nothing wrong except it's claiming/accepting credit for ideas other than your own, and making the employees with the ideas feel even more outraged as the ideas they have been promoting are accepted only when echoed by an outsider.
[They should feel outraged that ideas are only accepted if they come from outside, but the blame doesn't necessarily lay with the consultant; for that matter, a lot of the time sharp people will see the same right solution, but the hard part is getting people to actually do it. I've been on both sides of this.
I do a fair bit of contracting for large corporations where I end up playing more of a consultant role than a "warm body filling a seat". The majority of the value I bring to the situation actually comes from my techwriter (and before that, journalistic) background. I talk to everybody in sight, ask the stupid (and not so stupid) questions, figure out what's going on, who's doing what, what needs to be done, what everybody thinks is the best way to do it, and put it together in a coherent written form.
It's astounding, sometimes, how little people in these organizations know about what's going on around them (sometimes as much as one row of cubicles over :-). It's also astounding how powerful the simple act of writing something down on paper can be in persuading people. Of course, I also stick around to implement it, but the point I'm getting at is that in fact this is a critical need that is ignored until I show up and do it (even though it's not particularly my job); I just wish people (on both sides of the fence) would recognize the need and do it. Hell, I'd love to get jobs where that's my specific job.
The difficulty and importance of communication, like graphic design and writing, is generally undervalued. Or maybe it's that all three are valued (at least lip service is given to the value) but everybody assumes that they can do them well (we all communicate, we all look at things, and most of us write to some degree or another; we just don't do them well
-- Steven J. Owens ]
Folks, this gets repeated ad nauseam. Too many times I have gathered up the complaints, observations, and suggestions of the "worker bees" and presented them to the client as solutions to his current problem. After marveling at the wisdom of my findings they ask, "How did you arrive at these conclusions?" Slack jawed, I respond, "by asking your own people."
When you're brought in to debug some impossible bug that no-one has been able to find. Ask "where are you absolutely certain the problem cannot be?" That usually gives you a clear indication of the bug's location. If people have checked all the obvious places and can't find the problem then it's your job to check all the non-obvious places.
I'm not sure this belongs on this page, but the comment above is what brought it to mind. A friend of mine at work had two Windows NT computers in her office. I walked by one day and tech support was in there trying to figure out what was wrong with one of them. I looked over their shoulders and the error message said that a device or file on the system was malfunctioning, and named a particular .dll file. They were looking at the devices and not finding a problem. I walked by several times in the next few hours and they were still looking at all the devices and not finding anything.
Finally they gave up and went away.
I went in, got my friend to reproduce the error message and read it again. "device or file".... Tech support had been looking at the devices for hours, so the problem probably wasn't there or they would have found it. What's this .dll file in the error message? Did the .dll file exist? Yup, it was there. Hmmm. Ok, so did it exist on the other computer in the office? Yes. So which version was on each computer? The non-malfunctioning computer had a newer version of the file. Backup the old version on the "broken" computer, copy over the newer version of the .dll file. Try to reproduce the error message again, everything works fine. Five minutes, problem fixed.
Tech support was convinced I had caused the problem because I fixed it so quickly. I hadn't, of course -- they had kindly eliminated one of the possibilities for me, and the other possibility just happened to be relatively easy to fix.