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. This article describes these three modes of engagements based on my experience as a business analysis and process improvement consultant.
Mode #1: 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 in to deliver some training, perform a process assessment, review a project’s requirements, or advise how to improve their BA processes.
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 clients with knowledge and resources that can help, and I can propose a roadmap for change. But the organization’s managers and practitioners must implement those actions — and associated cultural changes — effectively.
When I perform a process assessment, I rarely tell clients things they don’t already know. My clients usually are aware of their pain points. However, they might not be able to get senior management to take the matter seriously or to allocate resources to address the issues.
Some managers have said to me, “Please tell these other people what I’ve been trying unsuccessfully to tell them for six months. They’ll listen to you.” It seems to be more acceptable to have an outside expert make the same observations and proposals that fellow employees already have made. The consultant is independent of the local organizational politics and isn’t caught up in the history of “how we’ve always done things around here.” The outside expert has worked with numerous other organizations and noted patterns of both effective and ineffective practices. As an experienced BA, you bring everything you’ve learned from each previous experience to your next client.
Much of my consulting has involved reviewing documents such as requirements documents, procedures, and other project deliverables. I’m functioning as an outside expert in this sort of engagement too. After having reviewed many sets of requirements, I have an idea of what constitutes a good one and common problems to look for. I can’t confirm that the document contains the correct requirements because I wasn’t involved with defining the needs or eliciting the requirements. But I can spot other kinds of problems that someone with less requirements experience might overlook.
The Idea Man
As an expert consultant, I view my key responsibility as providing ideas to 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 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 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.
What I’m proposing must be both pragmatic and appropriate for the client’s culture and situation. I do a reality check on any advice I propose. 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. Each suggestion must pass both of these checks before I deliver it to the client.
And Then What Happened?
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 they did before I came along, they’ll get an ROI of zero.
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 practice I strongly advocate. This approach was really helping their projects be more successful. Such reports validate that I’m presenting practical suggestions that can yield better results.
Mode #2: Many Hands Make Light Work
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 client contact assessing the deliverables to ensure they are satisfactory.
Some companies hire an experienced BA on a contract basis for a specific 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 is a pair-of-hands consulting mode.
I have done a lot of work for one client over more than 15 years. Jack leads the software center of excellence in a large product-development company. Much of my work for Jack has been off-site (in my own home) consulting work in the pair-of-hands mode, developing process descriptions, templates, and other work aids. Jack reviews each deliverable I create and we iterate until he deems the final product acceptable. Jack relies on my domain knowledge to feel confident that he’ll get a product that makes him happy.
My consulting agreements with Jack include a general description of the type of services I will be performing and a list of deliverables. We generally have a good mind meld and don’t need much planning or scoping documentation. Sometimes, though, Jack invites 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 (described in Chapter 5 of my book with Joy Beatty, Software Requirements, 3rd Edition):
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 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 statement that keeps us 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.
Mode #3: Teamwork
In the third type of consulting engagement, the consultant joins forces with members of the client organization to work on the project or solve the problem together. The collaborative mode involves frequent interactions between consultant and client to identify solutions, set priorities, make decisions, and create deliverables jointly.
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 wrote a script for each slide with a more detailed narrative. I 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 (remotely in this instance) to generate effective work products that were better than either participant could have created alone.
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 when I became an independent consultant was the opportunity to kick ideas around with other people, get their feedback on work I’ve done, and put our heads together to come up with better solutions. The collaborative engagements help fill that gap in my professional interactions. They’re 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.
Karl Wiegers is Principal Consultant at Process Impact, a software development consulting and training company. This article is adapted from his book Successful Business Analysis Consulting. Karl’s latest book is The Thoughtless Design of Everyday Things.