Modes of Consulting: What’s Your Preference?

In his classic book Flawless Consulting, Peter Block described three types of roles that consultants might take on: expert, pair-of-hands, and collaborator. Each of these represents a different kind of interaction when working with clients and a different source of satisfaction for the consultant. Business analysts can engage with clients in the same three modes. This article describes some of my experiences with these three modes of consulting engagements.

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 in to deliver some training, perform a process assessment, review a project’s requirements, or advise how to improve their business analysis process.

More than one client has told me, “You’re here because the pain has become too great.” The organization was suffering from problems resulting from ineffective practices and processes in some domain, and they hired me to help them rectify those problems.

Unfortunately, I cannot actually fix the problems in their organization. I can evaluate the current reality, identify areas ripe for improvement, and suggest root causes that lead to the pain. I can provide the clients with knowledge and resources that can help, and I can propose a roadmap for applying that knowledge on their projects. But it’s up to the managers and the practitioners in the client organization itself to implement those actions effectively. Many improvement actions also require culture changes. Those take time and must be driven from within.

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 to have a manager who brings me in say, “Please tell these other people 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 make the same observations and proposals that some in-house employees already have made. It helps that the consultant is independent of the local organizational politics and isn’t caught up in the history of “the way we’ve always done things around here.” The outside expert has the perspective of having worked with numerous other organizations and noted patterns of both effective and ineffective practices in the industry. As an experienced BA, you bring everything you’ve learned from each previous experience to the next client who hires you.

I’ve done a great deal of consulting that involved reviewing process or project deliverables—most commonly requirements documents—to point out errors and provide improvement recommendations. I’m functioning as an outside expert in this sort of engagement too. After having reviewed many sets of requirements over the years, I have an idea of what constitutes a good one and common problems to look for. This body of experience allows me to examine a client’s requirements spec efficiently 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 needs, interviewing customers, or otherwise eliciting requirements. But I’m very good at finding other kinds of problems that someone with less experience in writing requirements might overlook.

When I’m working as an expert consultant I view my key responsibility 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 more might not be very effective or won’t suit the culture, three others will be obvious, two of the remainder will be clever and novel to the client, and the final one will be brilliant. I need to produce enough ideas to get a nice handful of solid hits in those last two categories.

I use a mental test as a reality check on any advice I propose in consulting discussions or when I write a formal 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 actually could 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 checks before I deliver it to the client. The last thing I want to do is give clients advice that wouldn’t help them, isn’t realistically feasible in their world, or might do them more harm than good.

A frustrating aspect of working as an expert consultant or a trainer is that I rarely learn what happens after I leave the client site. Unless the client has engaged me for some ongoing work, it’s totally up to the organization to decide how to apply the training or recommendations I presented. Of course, I hope they will maximize their return on the investment they made in the engagement. But if they just keep on doing whatever it was they did before I came along, they’ll get an ROI of zero. There’s no way to find out what happened afterward unless the client opts to share that information with me.

Once I had a student in a public seminar who had taken a requirements class from me about a year earlier. He said that his company now had product champions serving as key user representatives for all of their projects, a requirements development practice I strongly advocate. He said this approach was really helping their projects be more successful. Such anecdotes validate that I am presenting ideas and practices that are practical and can lead to better results in organizations that learn how to make them work. It’s always great to hear that someone has found my advice valuable.

When working in the pair-of-hands mode, the consultant is providing a service that the client might be able to perform himself but for which the client lacks sufficient staff or time. The client defines the need and sets the project boundaries and expectations. The consultant then goes off and performs the work largely on his own, with the contact at the client site assessing the deliverables to ensure they are satisfactory.

Some companies, for instance, hire an experienced BA on a contract basis for a specific software development project. The consultant comes into the organization and performs the traditional BA tasks of identifying users, eliciting requirements, writing specifications, and so forth. Such short-term staff augmentation for a specific project is a pair-of-hands mode.

I have done a great deal of work for one client I’ll call Jack over more than fifteen years. Jack leads the software center of excellence in a large product-development company. Much of my work for Jack has been off-site (that is, in my own home) consulting work in either the pair-of-hands or collaborative mode. Most of the pair-of-hands work has involved developing process descriptions, templates, and other work aids. Jack knows how to do this kind of work himself, but he doesn’t have the time or the skilled internal staff available to do it quickly.

Jack carefully reviews each deliverable I create and we iterate, working back and forth, until he finds the final product acceptable. For the most part, though, Jack simply delegates the work to me. He relies on my domain knowledge and our previous agreement on the form and structure for such documents to feel confident that he’ll get a product that makes him happy.

My consulting agreements with Jack always include a general description of the type of services I will be performing and a list of deliverables. Such an agreement is called a statement of work, or SOW. Most of the time this works fine. We generally have a good mind meld and need very little planning or scoping documentation. I understand what Jack is asking for, and I can accomplish the objective independently without demanding a lot of his time.

Sometimes, though, Jack asks me to do something novel. Neither of us has a clear idea at the outset of exactly what the desired outcome is. In those cases, I ask him to write a short vision statement using the following keyword template, which is described in Chapter 5 of my book with Joy Beatty, Software Requirements, 3rd Edition (Microsoft Press, 2013):

For [target customer]

Who [statement of the need or opportunity]

The [deliverable name]

Is a [type of deliverable]

That [major capabilities or key benefits]

Unlike [current reality or process]

This Deliverable [primary differentiation and advantages of new deliverable]

Jack usually grumbles a bit about having to write this vision statement because I’m asking him to think carefully about just what he wants out of the project. That’s hard! But then he works through the keyword template and always comes up with a clear, one-paragraph, structured statement that keeps us wonderfully focused on our mutual objective. I highly recommend asking your client to write such a vision statement anytime the nature or goals of the engagement are too fuzzy at the outset.

In the third type of consulting engagement, the collaborative mode, the outside consultant joins forces with members of the client organization to work on the project or solve the problem together. In contrast to the more independent work that characterizes the pair-of-hands mode, the collaborative mode involves frequent interactions between consultant and client to identify solutions, set priorities, make decisions, and create deliverables jointly. As an analogy, you could think of co-authoring a book as being a collaborative engagement, whereas hiring a ghostwriter to craft your memoirs would be a pair-of-hands type of engagement.

A client recently hired me for an extended off-site collaborative engagement. This financial services company wished to implement peer reviews as part of its architectural governance process. A manager at the company was familiar with my book Peer Reviews in Software, so he engaged me to help. The clients relied on my extensive experience to advise them on how to make peer reviews effective in their environment for a specific set of work products and review objectives.

One member of the client’s staff worked closely with me on this project to define the review process. We then developed several hours of e-learning presentations to train their staff in the new approach. The client drafted the slides and key talking points for the presentations. Next, I fleshed out a script for each slide with a more detailed narrative. I have considerable experience giving presentations and developing e-learning training, so I could improve his initial slides for a more effective presentation. I also recorded the audio from the scripts and generated the e-learning presentations, since I was already set up to do all that.

This was a fine example of collaboration, with a consultant and a client employee working side-by-side (albeit remotely in this instance) to generate effective work products that were better than either participant could have created alone. It was also educational and enjoyable for both of us.

I enjoy the collaborative type of activities the most. It’s fun to work with smart, creative, and energetic people. One thing I felt lacking in my career as soon as I became an independent consultant was the opportunity to kick ideas around with other people, scribble on a whiteboard together, get their feedback on work I’ve done, and put our heads together to come up with better solutions. That’s probably why I enjoy the collaborative engagements; they help fill that gap in my professional interactions.

The collaborative engagements are good learning opportunities as well. They always leave me better prepared for the next project, with a broader base of knowledge and experience to rely on when I confront the next thorny challenge.

I recommend that you keep these different consulting modes in mind when future client engagement opportunities arise. Understanding your own preferences will help you select those gigs that are likely to be most enjoyable and fulfilling. It’s also a good idea to match the mode with the needs of a specific project. Your client might ask to hire you to perform some work in a pair-of-hands mode, but you might conclude that a collaborative engagement would be more effective. Shaping the engagement’s parameters to yield the best outcome is part of your responsibility as a consultant or business analyst.

Author: Karl Wiegers, PhD, Principal Consultant, Process Impact

Karl Wiegers, PhD, is Principal Consultant at Process Impact, a software development consulting and training company based in Portland, Oregon. He is the author of nine books on software development, management, consulting, and self-help, as well as a forensic mystery novel, The Reconstruction. This article is adapted from his book Going It Alone: Essential Tips for the Independent Consultant. You can reach Karl at processimpact.com or karlwiegers.com.