Three Modes of Business Analysis Consulting

Featured
Jun 16, 2019
6484 Views
0 Comments
9 Likes

A business analysis consultant might perform three types of roles when working with clients: expert, pair-of-hands, and collaborator. Each of these represents a different kind of interaction and a different source of satisfaction for the consultant. This article, adapted from my book Successful Business Analysis Consulting: Strategies and Tips for Going It Alone, describes these three modes of consulting engagements, which apply both to independent consultants and to internal consultants who work in large organizations.

Outside Looking In: The Expert Mode

As an expert, you’re working with a client who has a problem and wants you to fix it. You’re working in the expert role when a client brings you in to deliver some training, perform a process assessment, or review some project deliverables or process documentation.

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. That is, they sought help from an outside expert.

Unfortunately, I cannot actually fix the problems in an organization. I can evaluate the current reality, suggest root causes that lead to the pain, and identify areas ripe for improvement. 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. However, it’s up to the managers and practitioners in the client organization to implement those actions effectively themselves. Sustained improvement actions also demand culture changes. Those take time and must be driven from within, not by outsiders.

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 discuss various random problems they were facing. I never knew what question was going to come up next. It might be about getting customers engaged in requirements discussions, dealing with configuration management problems, or generating better estimates for project planning. I found these engagements stimulating and challenging. I really had to think on my feet to understand the situation quickly 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—to point out errors and provide improvement recommendations. I’m functioning as an outside expert in this sort of engagement too. After having reviewed a lot of requirements for clients over the years, I have an idea of what constitutes a good set and some of the common problems to look for. I can’t confirm that the document contains the correct requirements for the project because I wasn’t involved with setting the business objectives, defining the needs, or interviewing customers. But I’m very good at finding other kinds of problems that someone who has less experience working with requirements might overlook.

The Idea Generator

As an expert consultant, my key responsibility is to supply 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 come up with a lot of them. For every 10 ideas, probably two will be ridiculous, two others might be ineffective or won’t suit the culture, three more will be obvious, two of the remainder will be clever and novel, 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. 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 practical and appropriate for the client’s culture and situation. I don’t want to give clients advice that wouldn’t help them, isn’t realistically feasible in their world, or might do more harm than good.

The Coach

Another way to function as an expert consultant is in a coaching role. You could work with individual BAs to assess their current ways of working and recommend better practices. On a larger scale, you might help an organization establish a business analysis center of excellence to establish, maintain, and monitor standards of practice. Your expertise could help them develop methodologies, training materials, templates for project deliverables, process and guidance documents, and other resources. You might help define career paths and professional development sequences for practitioners. Providing such leadership lets you leverage the effective techniques you’ve observed from previous clients to help new clients work in better ways.

Roadblocks

Perhaps the biggest sources 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 might 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 whatever I was suggesting might work in other places but certainly not in their environment.

Organizations and cultures do come in many flavors, but there are also many similarities between them. For instance, 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 often signals resistance against change in general. If you detect either NIH or NAH symptoms, your challenge shifts from proposing solutions to considering how best to have those solutions reach a receptive audience.

And Then What Happened?

Expert engagements like this often are short interventions, not ongoing projects. A frustrating aspect of working as an expert consultant or 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 my training or recommendations. 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 a return on investment of zero. There’s no way to find out what happened afterward unless the client opts to share that information with me.

Occasionally, I have received feedback about the outcome some time after I taught a class. I once had a student in a public seminar who had taken a requirements class from me about a year earlier. He told me 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 anecdotes validate that I am presenting ideas and practices that can yield better results in companies that learn how to make them work. It’s always great to hear that someone has found my advice to be valuable.

Many Hands Make Light Work: The Pair-of-Hands Mode

When working in the pair-of-hands mode, the consultant is providing a service that the client company might be able to perform themselves but for which they lack sufficient staff or time. The client defines the need and sets the project boundaries and expectations. The consultant then performs the work largely on his own, with the client contact 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 staff augmentation for a specific project is a pair-of-hands engagement mode, and could involve on-site work for the duration of the project.

I’ve done a lot of work for one client 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 involved off-site consulting (that is, in my home office) 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 perform this sort of work, but he doesn’t have the time or the internal staff available to do it in a timely fashion. Therefore, he outsources it to me.

Jack carefully reviews each deliverable I create and we iterate, working back and forth, until he finds the final product acceptable. 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. I’ve done a lot of process development, so we just write a simple statement of work that outlines the type of services I will be performing and lists the deliverables.

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, Third 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 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 he 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 consulting engagement are too fuzzy at the outset.

Working Side-by-Side: The Collaborator Mode

In the third type of consulting engagement—the collaborator 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 collaborator mode involves frequent interactions between consultant and client to identify solutions, set priorities, make decisions, and create deliverables.

A client hired me a few years ago 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 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 their 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, and then 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 on his draft slides for a richer presentation, record the scripts, and generate the e-learning courseware.

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 of us could have created alone. It was also informative and enjoyable for both of us. I like these collaborative engagements the best. It’s stimulating and fun to work with smart, creative, and energetic people. Such collaborations provide good learning opportunities for me as well.

Consulting Modes: What’s Your Preference?

I recommend you keep these three consulting modes in mind when future opportunities arise. Understanding the types of engagements you prefer will help you select those gigs that are likely to be most enjoyable and fulfilling. It’s also a good idea to match the consulting 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 your assessment of the project might indicate that a collaborative approach would be more effective. Shaping the engagement’s parameters to yield the best client outcome is part of your responsibility as a consultant.


Author: Karl Wiegers, Principal Consultant at Process Impact

Karl Wiegers is Principal Consultant at Process Impact, a software development consulting and training company in Portland, Oregon. He has a PhD in organic chemistry. Karl’s latest book is Successful Business Analysis Consulting: Strategies and Tips for Going It Alone, from which this article is adapted. You can reach him at ProcessImpact.com or KarlWiegers.com.





Latest Articles

Domain Expertise and the Business Analyst: How Vital Is It?
Sep 15, 2019
0 Comments
The question of how essential domain expertise is to a business analyst is a recurring debate in the BA community. One school of thought maintains tha...

Copyright 2006-2019 by Modern Analyst Media LLC