Consultants! Good God! What are they good for? Absolutely —!
Through Rose Colored Glasses #
If you bring it up, I’ll be the first one to admit that consultants are leeches. Our least endearing quality is the habit of pointing out the almost painfully obvious, and then getting rewarded for it. Then, there’s also the fact that thanks to Clinton and to Mr. Inconvenient Truth, the government can’t run without us.
But we must also do some good, otherwise, we would have been driven off the cliff in a bus with all those lawyers. I actually enjoy consulting work. I enjoy experiencing different environments, applying my management and tech expertise so others can focus on what they do better, teaching people what I know, and leaving behind a solution I poured my sweat and time into and am feeling pretty good about.
Normally, on a new project, the people at the organization I’m parachuting into have a pretty good idea of what they think they want, they have ridiculously high expectations because everyone who was asked gave their two-pence about what the solution needs to do, and they are ready to live through your process…which usually turns into you living their process.
People are the most difficult part of any project. But even so, for the most part, well-meaning or not, people are pretty sanguine, and they know stuff.
Now I’m Speechless #
In the recent past, two incidents shook me to my consulting core. (Do I have a “consulting core”? Hopefully, I’m just like…people…)
Incident #1: Within a few minutes of being pulled into a meeting to solve some deep technical problem or other, I uttered the utterly bland words, “Yeah, I think we need to understand the user requirements, and the users themselves. What are the user types?”*
“We did that at the beginning when we first built the system.” That would have been years ago. “The users don’t matter. What matters is what the future system will be.”
Exactly what you’re thinking right now is what I thought too. This is where in my youth I would have blanched, my eyes would have bulged, and I would have taken off my glasses and rubbed the bridge of my nose. Luckily, I’m too old for obvious physical reactions–too little energy, see.
“Okay, but to understand how to build the future system, we need to understand the different types of users.”
“The main system has the users. It lets them log in, so we don’t need to worry about the users, that system handles it. When they log in, then they can choose our module, and that’s what we have to worry about. How to modernize it and get results fast.”
“But…!” This was my first meeting and I was barely an hour into my first day on the project. So I was picking my words carefully. “You have to know the different types of users, how they use your module, and the use cases. All the users of the larger system can also use this module. There are lots of different users and uses for the larger system. What does fast mean, and to whom does it mean that? You need to understand the users for that. You can’t walk into this meeting tomorrow, propose how this system will be redesigned for ‘the future’, and not even talk about why it will do the things it does. The why comes from the users.”
“Yes, but the larger system will have roles for the people who log in. When they get to our module, they just need to use it.”
“Who needs to use it?”
“All the users.”
“And what different types of users are there?”
“Managers, field people, etc.”
“So there are different types of users then? And they have different needs? And in the module, there are different results created for those different needs?”
“Yes, but once they log in to that system, then they’ll use our module for what it does. So we don’t need to worry about the users. We just need to make it perform faster and to return information the instant it’s created.”
I’ll just say that after I got home, I did eventually stop shaking my head.
And You Don’t Know Whose Side You’re On #
Incident #2: I found myself in a discussion about serving reports to users. The reports needed to serve casual users in the field who just needed specific information, and super users in HQ who could do business intelligence. Reports for the super users had been built using an Enterprise reporting tool, that also allowed them to create ad hoc queries for new reports.
I was saying: “For the casual users, we can build reports that provide them with the simple views they need. We don’t need to drop them into the enterprise tool at all.”
T’other person was saying: “We’ll use the enterprise tool, that way they can use ad hoc to create whatever reports they need.”
Quoth the consultant: “But from what I understand, the casual users at these hundreds of sites hate the enterprise tool. It’s just sitting on their desks, unused. They think it’s too complicated and they haven’t bothered to learn it. Instead, they’ve turned to simpler reports from the systems they use daily, which have all now been moved into this team’s responsibility. So for them, you can create the simpler static reports that will help them do their jobs.”
“Yes, but if we create one report for them, they’ll just ask for more reports sliced differently. They can just use the ad hoc capability to create the reports they need. We don’t need to create reports for them.”
A pause here to make sure I heard what I just heard, which was: we don’t need to serve our customers in the best way possible to complete their jobs, they just have to adjust to the tool.
“I’ve done this many times in the past. Casual users aren’t super users, they don’t care about ad hoc, they aren’t going to learn the tool. And this is a complicated enterprise-level tool, and on top of that, they’d need to understand how the whole business works and how it’s represented in the metadata in order to pick fields for their reports. But all they need is to verify their data is in and—”
“Yes, but we’ll have data dictionaries. And we’ll have tooltips. So they can learn to use ad hoc to create reports. This is the tool the organization has chosen. They have to use it!”
Another pause as I searched my data banks wildly.
“Yes, but we can make it easier for them to do their jobs. The reports aren’t tied to the tool. Think of them as just objects, and we can serve the objects any way and anywhere we want.
“Let me give you an example. In a past project for a certain fed agency, we had this same enterprise tool, and we served a report on a plain web page. We made that web page available to all US citizens to check for specific information where they live. We didn’t force all of the US to learn the enterprise tool, we just presented the static report on the web page, with some very simple dashboard filters, and that was it: anyone in the country could easily use it. Same thing with your casual users: simple static reports geared to their job functions, and that’s all they get. Then, if they want slicing and dicing, they can request special access, and you’ll give them the ad hoc abilities. So either way, your team doesn’t have to do extra work for them once the reports are in Production.”
I took the silence and skeptical look as progress and returned to my cube. Also, I shook my head all the way home.
When I Lost My Motivation #
Now, I don’t mean to make fun of the people in these incidents. In fact, I’m well aware of how they got there: years of heavy bureaucracy over their heads, insistently drilling into them the need to just get this done and make sure it does this.
But still: you gotta defend at least somewhat your ultimate customers. After all, like you, they’re just trying to do their jobs. So help them do it.
“So help them do it” is the consultant’s credo.
Well…it should be.
(Hirschfeld number: schooloffish4)
*All quotes are paraphrased, some of them from continuing conversations, and the actual topics have been obfuscated.