Decision-Making Under the Influence: SME, HiPPO, and BOGSAT

The most significant driver of cost and schedule variance in the execution of any project is indecision. While most projects can absorb a few bad decisions or even course-correct without a hitch, delaying a decision almost invariably creates damage. Agile practitioners will typically defer decisions until required to move forward so that the Decider has as much information as possible, but a lack of information isn’t always—or even usually—the problem. Sometimes the Decider just doesn’t feel empowered, and sometimes they are having trouble reconciling input from different Influencers. And there are several common types of Influencers.

SME: The Subject Matter Expert

The SME understands the business process, constraints, data records, information security concerns, and so on. In a lot of cases, the SME is the person who owns—or will own—the results of the decision, but doesn’t have the authority to make the decision. So the Decider—rightly—looks to the SME for input, trusting that the expert opinion will not be influenced by the impact of the decision. Usually, it isn’t. Usually.

The wise Decider will usually align with the SME, unless something else comes up. Usually, this takes the form of another Influencer.

HiPPO: Highest Paid Person’s Opinion

Inviting a very senior person to weigh in on a decision they aren’t being asked to make is like prospecting for uncertainty and doubt. Numerous studies have verified the existence of the HiPPO effect—junior team members defer to the expressed opinions of the Highest Paid Person, because they assume that they are paid so much due to their greater knowledge. And the Highest Paid Person may actually have greater knowledge in some area—but that doesn’t mean their Kung Fu is the best for this particular decision.

An even worse situation can occur when the Highest Paid Person asks a clarifying question, which nearly always raises doubt in the minds of the Decider and SME. I once saw a SVP of Human Resources stop a presentation cold by asking whether a bullet point referred to something that was done, or that needed to be done. I had to help the stunned Decider find her car.

“It’s the Heisenberg Principle…me asking the question changes the answer.” – Barack Obama

BOGSAT: Bunch of Guys Sitting Around a Table

It’s good to network, but parents worry about peer pressure for a reason. I once worked for a guy who used the term “strap-hangers” for those he perceived were just along for the ride. As he put it: if they didn’t have any skin in the game, their opinions shouldn’t matter. I used to think that was a bit extreme, but as I’ve come to understand the dynamics of making choices under conditions of uncertainty, it’s become plain that not all points of view are valuable. I had a client defer a decision until she could reach out to confirm whether the passing comment from a friend in another company was relevant. It wasn’t.

Uncertainty, Assumptions, Influence, and Decisiveness

Uncertainty is a given—we are rarely asked to make decisions with all the facts. Usually, at least some things are unknown or even unknowable. So we have to make assumptions in order to close the gaps. Those assumptions represent risks, which have to be managed. We seek out the opinions and counsel of those we trust and respect in an effort to assess the risks and proceed with a decision, and in many cases that additional input makes the issue and choices more clear. But reconciling different opinions and different points of view should not take precedence over making a timely decision.

Managing Transitions Between Outsourcing Vendors

With apologies to Sir Walter Scott: Oh, what a tangled contract we write, when first we practice to outsource. Having managed outsourcing projects on behalf of both the customer and the third-party administrator, and managed transitions from one outsourcing firm to another on behalf of several clients, I have a lot of anecdotal evidence that outsourcing generally works best on a spreadsheet—in practice, results tend to be rather variable. But because most business decisions are driven by spreadsheets, businesses keep outsourcing.

That’s not to say that migrating to a better outsourcing relationship isn’t a net positive—only that changing who does what across organizational boundaries is stressful for all concerned, and that increased stress level and instability tends to last longer than most decision-makers expect. And when transitioning from one third party to another, you get something like a long, drawn-out divorce where the spurned spouse is required to help tailor her wardrobe to the mistress, who arrives with an extensive list of demands.

Transition Projects and VUCA

VUCA is an acronym originally coined by the US Army War College to describe a state of increased volatility, uncertainty, complexity, and ambiguity. Transition projects have it in spades:

  • Volatility: Disrupting the current state produces lots of process change points, and most are not under the control of the client.
  • Uncertainty: There are a lot of opportunities for all parties to be surprised, from the customer decision-makers to the employees of the departing administrator. Do not underestimate the emotional impact of being asked to help a stranger take over your job—some folks resign the same day they get the news.
  • Complexity: Since the only contracts are between the customer and each of the two rival firms, the customer must act as intermediary in all things. Issue management quickly becomes a significant challenge, since each party wants to avoid blame. Cause and effect can become blurred, and even disconnected.
  • Ambiguity: There is so much potential for miscommunication and differences in terminology that even simple discussions require extreme care. Insist on a common set of terms and acronyms and what they mean, or you’ll be discovering gaps nearly every day.

Over the years, I’ve adopted a few techniques for facilitating projects built on a team of rivals, and I’ll share a few of them here.

The Central Clearing House

While every firm has a preferred collaboration and file sharing tool, it is vital for the common client to provide the tools for secure file sharing and provide equal access to both incumbent and replacement. The client must manage the content and organization, no matter how eloquently the replacement firm pitches their approach. All fingers should point to the client, or the potential for blamestorming becomes unmanageable.

The Cheshire Cat

Since the rivals have no contractual relationship, the client (or their representative) must chair every joint meeting. Over time, the individuals on each side develop relationships with their counterparts, and collaboration becomes natural. As this happens, the potential for emotional conflict gradually diminishes, and the client can gradually be less visible, although still present and ready to step in.

The Captain’s Table

Dave GordonOnce the transition is under way, the project leaders for all three organizations need to collaborate on resolving issues, following up on requests, and otherwise executing on their joint plan. This joint meeting should be scheduled as often as necessary, whether weekly or daily, and chaired by the client’s project manager. Avoid having more than one person from each organization, so internal politics don’t bleed over into the project.

An experienced project manager is used to leveraging influence in the absence of direct authority. What most of us are not used to is influencing people who are about to lose their jobs, when we want them to work with their replacements. It isn’t just about the need for emotional intelligence, but the need to preserve the dignity of the employees of the departing incumbent. I’ve seen some folks take the opportunity to move on to much better circumstances, and I’ve seen some fall into deep depression. You might not get the chance to influence that outcome, but be sensitive to the fact that these people are not just numbers on a spreadsheet.

The RAID Log: Right Topics, Wrong Sequence

If you were to poll project managers on which software tool (aside from email) they use most often, for the largest number of tasks, I imagine that Excel would predominate. From complex calculator to data analyzer to zero-effort database and factoid organizer, I doubt there is a more ubiquitous multi-tool. And yet, we sometimes use it in ways that inhibit our understanding of the problems we’re trying to solve. One example that comes to mind is a spreadsheet template we used in a former life, called a “RAID log.”

The spreadsheet had four tabs: Risks, Assumptions, Issues, and Decisions. Each tab had columns defined that would drive identification and management of their namesakes. In and of itself, it was an excellent starting point. But the sequencing that made the template name pronounceable hid the complex relationships among the four objects. And that probably caused more than a few problems along the way.

Assumptions

Most projects begin with a limited number of facts, or “knowns,” and a by-product of the project is to expand that knowledge base. But at the beginning, a lot of assumptions are needed to fill in the gaps. These assumptions help us better visualize the current state, the desired future state, and the space between. With assumptions, we can make plans and estimates, communicate and collaborate, and otherwise act on those things we know to be facts. Consequently, all projects begin with a set of assumptions.

That said: every assumption carries some amount of uncertainty. Because we depend on assumptions to proceed with our work, and that uncertainty is present, each assumption represents a source of risk. Of course, not all assumptions are foundational, and few will be purely wild-assed guesses, but one of our process goals in every project should be to verify every assumption. To do this, every assumption should be documented and referenced when used in estimates, plans, schedules, budgets, and any other project activity.

Issues

Whether the goal is to correct a problem, develop a new capability, or comply with some external requirement, projects are approved to address issues. If the status quo were acceptable, no one would spend money to change it. On many projects, the project is an umbrella for the resolution of all sorts of issues. As you explore the project scope for details, more issues will emerge, and some of your assumptions will be challenged. This is a good thing: solving the wrong problem won’t get you any points. You might discover some issues can be resolved along the way, while others depend on the outcome of the project. Persistent issues frequently have roots in an earlier solution, and it’s common for them to be well-documented. So capture that content in your project issue log.

Once you transition to the execution of your project, more issues will manifest, especially as you make changes or consume scarce resources (like the time and attention of your stakeholders). On some projects, tracking and resolving issues becomes the key to making progress. The old adage about being up to your ass in alligators speaks volumes about the potential for creating new problems while trying to solve old ones.

Risks

A risk is an uncertainty that matters. As noted, every assumption has an element of uncertainty, and every issue matters. Consequently, a review of assumptions and issues logs should give you a starting point in identifying risks. If an assumption is incorrect, what are the consequences? What is the likelihood of resolving one issue, only to create a new one? In reviewing the plan, identifying risks isn’t just about understanding the proposed solution, but the current state.

As Tim Lister so famously said, “Risk management is how adults manage projects.” Tracking risks, from identification to analysis to action to retirement, is one of the keys to a successful project. Once you understand both the risks and the issues, you can select better risk responses. Being able to link risks to assumptions, and to both the issues that made them worth taking and the issues that they might become, will help you keep preventive and corrective actions from falling through the cracks.

Decisions

The most expensive part of any project is indecision. Many decisions are the leverage needed to resolve issues; others drive risk responses. Still others change or confirm assumptions. Many schedule delays can be attributed to the failure to make a timely decision, or the failure to communicate a decision once made. Once the need for a decision is identified, whether to resolve an issue, manage a risk, or just eliminate alternatives, it should be logged. Allowing a pending decision to drag on too long is an impediment to the project, and to the business of the organization. A review of the decision log for pending items should be part of every steering committee meeting.

The relationships among assumptions, issues, risks, and decisions are complex, and somewhat recursive. Tracking them is not a chore to be done once and then checked off the to-do list. Taken together, they are the background (and sometimes foreground) of every project. Understanding how they interact can be critical to keeping your project on track. So if you use a spreadsheet like our old RAID log, be sure to use it wisely.