Outside Looking In
As an expert, you’re working with a client who has a problem and wants you to fix it. I’m working in the expert role when a client brings me into do some training, perform a process assessment, or review some project deliverables or process materials. More than one client has told me, “You’re here because the pain has become too great.” The organization typically is suffering from problems resulting from ineffective practices and processes in some domain, and they hired me to help them rectify those problems. I cannot actually fix the problems in their organization. I can assess the current reality, identify areas ripe for improvement, help identify root causes that lead to the pain, provide the clients with knowledge that can help, and propose a roadmap for implementing that knowledge. But it’s up to the managers and practitioners in the organization itself to implement those actions.
I’ve found that when I perform a process assessment, whether formal and structured with a written report or simply by providing feedback based on informal discussions, I rarely tell clients things they don’t already know. For the most part, my clients are aware of their pain points. However, they might not be able to get senior management to take the matter seriously or to provide the necessary resources to address the issues. It’s not unusual for a manager who brings me in to say, “Please tell these other guys what I’ve been trying unsuccessfully to tell them for six months. They’ll listen to you.” For reasons I’ve never understood, it seems to be more acceptable to have an outside expert come in and make the same observations and proposals that some in-house people already have made. It helps that a consultant is independent of the local organizational politics and isn’t caught up in the history of “the way we’ve always done things before.” The outside expert has the perspective of having worked with numerous other organizations and observing patterns of both ineffective and effective practices in the industry.
Some of the most fun I’ve had in the expert consulting mode involved sitting in a room at a client site for a day while a procession of people came in to talk about various random problems they were facing. I never knew what kind of question was going to come up next. It might be about getting customers engaged in requirements discussions, dealing with configuration management issues, or generating better estimates for project planning. I found these all-too-infrequent types of engagements stimulating and challenging. I really had to think on my feet to quickly understand the situation and try to come up with suggestions that were likely to be effective.
I've done a great deal of consulting that involved reviewing process or project deliverables (most commonly requirements documents) for clients to point out errors and provide recommendations for improvement. I'm functioning as an outside expert in this sort of engagement. After having reviewed dozens of requirements specifications over the years, I have a good idea of what constitutes a good one and what sort of problems to look for. This body of experience allows me to efficiently examine a client’s requirements spec and spot many improvement opportunities. Of course, I can't confirm that the document contains the correct requirements for the project because I wasn't involved with defining the need, interviewing customers, or otherwise eliciting requirements. But I'm very good at spotting other kinds of problems that someone with less experience in writing requirements might not detect.
One more way in which you might work in the expert consulting mode is as an expert witness in a lawsuit. I had this experience just once. The project involved a vendor of a package software solution and a customer organization that had purchased the package and hired the vendor to perform some customizations and data migrations. One of the parties in the lawsuit hired me to try to determine the factors that contributed to the project failing abysmally. After studying numerous project documents, I concluded that the party whose attorney had hired me was responsible for a lot of the problems. The attorney read my report, said thank you, paid me, and that was the end of that. I heard later that the parties had reached a settlement, so I never had to testify. This consulting engagement led to an article titled “See You In Court,” in which I shared some advice about making such outsourcing projects more successful. I know numerous consultants who make a very good living working as expert witnesses. The expertise these consultants gained from years of industry observation and participation serves them well.
The Idea Man
I view my responsibility as an expert consultant as providing ideas, ideas that will help a client solve a problem or build software faster and better. Some solution ideas are better than others, so I try to generate a lot of them. For every ten ideas I come up with, I figure that about two will be ridiculous, two might not be very effective or won’t suit the culture, three will be obvious, two will be clever and novel to the client, and one will be brilliant. So I need to produce enough ideas to get a nice handful of solid hits in those last two categories.
I use a mental test to provide a reality check on any advice I propose in consulting discussions or when I write a formal process recommendation report. First, I consider whether the actions I'm suggesting have a high probability of actually solving the client’s problem. That is, my proposal must be effective. And second, I ask myself if the client could actually implement my suggestions if he chooses to do so. That is, what I'm proposing must be both pragmatic and appropriate for the client's culture and situation. Each practice that I have in mind must pass both of these reality checks before I pass it along to the client. The last thing I want to do is give my clients advice that wouldn’t help them, isn’t realistically feasible, or might do more harm than good.
Perhaps the biggest source of resistance to input from an outside expert are NIH and NAH syndromes. NIH means “not invented here.” The solution proposed by an outside expert can be rejected because the affected practitioners didn’t create the solution themselves, so they don’t necessarily buy into it or trust it. NAH means “not applicable here.” I’ve often heard the claim “we’re different” from clients who weren’t interested in trying my recommendations. They thought that whatever I was suggesting might work in other places but certainly not in their environment. While organizations and cultures do come in a variety of flavors, there are also a lot of similarities between them. For example, I think nearly all software-developing organizations can follow basically the same change control process. Citing NIH or NAH as a reason not to accept the consultant’s recommendations is often just a sign of resistance against change in general.
And Then What Happened?
One of the frustrating things about working with a client as an outside expert consultant or trainer is that I rarely learn what happens after I leave. Unless the client has engaged me for some ongoing consulting, it’s totally up to the organization to decide how best to apply the training or recommendations I presented. Of course, I hope they will maximize their return on investment in the engagement, but if they just keep on doing whatever it was they did before I did my bit they’ll get an ROI of zero. There’s no way to find out what happened unless the client is willing to share that information with me.
Occasionally, I have received some feedback about the outcome after I taught a class. One time I had a student in a public seminar who had taken a requirements class from me about a year earlier. He said that now they have product champions serving as key user representatives for all of their projects, something I strongly recommend. This approach was really helping their projects be more successful. Such anecdotes help validate that I am presenting ideas and practices that in fact are pragmatic and can lead to better results in the hands of organizations that implement them and learn how to make them work.
Have you ever worked in the expert mode as a consultant? What sort of activities did you perform in this mode? How did you like it, compared to other types of consulting interactions you have had? Please share your experiences by commenting on this blog post. In the next article, I will take a look at the two other modes of consulting: pair-of-hands and collaborator.
(If you found this article helpful, please consider making a donation to the Norm Kerth Benefit Fund to help a consultant who has been disabled since 1999 with a traumatic brain injury from a car accident. You can read Norm's story or donate here. Thanks!)