My biggest consulting mistake and the systematic development of informed consent : Conferences That Work

At edACCESS 2008 I gave a 90-minute presentation entitled “Learning from the biggest consulting mistake I’ve made — and that you probably have too”.

OK, the formal title was “The Systematic Development of Informed Consent“, which sounds much fancier but requires explanation.

16 years have passed, yet I think the blunders I made while working with a client during one of my past careers—IT consulting—are still relevant and instructive. So, I’m going to ‘fess up to the world. And as a bonus, I’ll introduce you to the people who taught me the biggest reason worthy projects don’t get implemented, and what you can do about it.

The story begins

The story begins in November 2007, when I was invited to a two-day training given by Hans and Annemarie Bleiker. There were about forty of us. Here is a photo of our merry group.

While teaching at MIT in the 1960s, Hans and Annemarie noticed the dismaying reality that many public projects never get implemented or even started. They decided to research to find out why, and if there was anything people could do to improve their chances of success. She’s an anthropologist, he’s an engineer. Since then, they have presented their findings and unique methods for improving matters to more than forty thousand professionals around the U.S. Here are some of their clients…

[Click on the image for the current list.]

…and their mission.

Mid-morning on the first day of the workshop I had a major aha! moment. I understood a core mistake I’d made eighteen years earlier. That mistake led to my failure to successfully implement an organization-wide IT system for a major client.

During the workshop, I discovered that the mistake is so common that the Bleikers have spent decades teaching people how to avoid it.

So, I want to share what I learned with you because you have probably already made the same mistake.

My Harrowing Story

The following story is mostly true, though I’ve changed all names to confuse the innocent.

In July 1989, I was hired by a client I’ll call Seagull School. The school had two campuses, North and South, that were three miles apart and housed slightly different academic programs. The key personnel I worked with were Mr. Head, Mr. South (head of the main campus), Mr. North, and the Tech Director.

From 1989 – 1998, I wrote custom software or adapted commercial software for Seagull’s administrative needs. It was all hosted at South. South’s computer labs included both PCs and Macs; North decided to only use Macs. At the time, I didn’t think much about it.

In 1999, I was asked to develop an integrated administrative system that would eventually be used at both campuses. It took about a year to develop. During the development, North was asked repeatedly to define what system functionality they would like, but they didn’t want to talk about specific data elements. Over the next couple of years, it slowly became clear that they wanted something that could be changed on a whim. North wouldn’t consider the ramifications for the whole school. For example, North wanted the school registrar, based at South, to create transcripts, but wouldn’t specify what might be on them for North’s programs.

Finally!

In 2001, Mr. Head decreed at a meeting with all the administrators that the system I’d developed should be used at both campuses. Yay!

But…no.

A few days later, Mr. Head called me into his office. He had just met with Mr. North who had presented him with a large packet of documents expressing his view of the current state of affairs. Mr. North claimed that the integrated system solution had been developed without talking to people at North. So, he had just purchased another system from a neighboring school (without talking to anyone at South). He told Mr. Head that he thought Seagull School should use North’s system for both campuses and have the existing integrated system be an archive of past data.

Everyone at South whom I talked to thought this was ridiculous.

However, for some reason that I was never made privy to, Mr. Head left that meeting feeling it would be impossible to make my integrated system a viable solution for Seagull School right now. So, Mr. Head told me to keep the folks at South campus happy and leave North to its own devices for the present.

Well, what about…this?

A year went by and I had a bright idea. Why not develop a web-based system that would be platform-independent? I gave the Tech Director a quote, but the school decided it was too expensive.

North decided to hire its own consultant to develop a custom system. As I expected, the consultant didn’t do much because he was incapable of pinning North down to say what they wanted.

By 2003, Seagull administrative staff at South were complaining that they couldn’t do the work that North wanted them to do because North’s data was still in a separate system.

So, Mr. Head hired two more consultants to advise on what Seagull School should do. Eventually, the second consultant concluded that the “strongly recommended” scenario was to use my system, with North accessing it via remote control software. The next best option was to develop the web-based system I’d recommended. The third option “difficult to justify”: was to keep using two systems.

For another year, Mr. North ignored the report, and Mr. Head did nothing.

Finally, in July 2004, Seagull asked me to create a web-based system.

I told them, “No, I’m retiring from IT consulting in a couple of years, and I don’t want to start a new project for you now.” <Muttering under my breath: “You should have said ‘yes’ two years ago when I suggested it – I would have done it then.”>

More dramatic twists and turns ensued, which I will spare you because they aren’t germane to the topic of this post. I’ll just add that Seagull School kept using my system for another five years.

So, what went right?

As a fan of Appreciative Inquiry, I think it’s important to spend a moment summarizing what I did well for Seagull School.

I successfully devised, created, updated, and supported easy-to-use custom software that handled the core administrative needs of Seagull School for almost twenty years.
The core Seagull School staff, based at South, appreciated my work and were strongly supportive during this time.
The investigations of several other independent consultants upheld my recommendations.

So, what went wrong?

I was unable to get Seagull School to adopt a single integrated administrative system for both North and South.

You might ask: “Why did I fail?” But “Why” questions are not especially useful in cases like this.

A better question is: “What could I have done differently?”

I’ll answer this question after telling a fairy tale…

The Fairy Tale

Once upon a time, there was a baby princess, born into wealth and privilege. Everyone who’s anyone was invited to her christening.

Unfortunately, the invitation email sent to a wicked fairy with an AOL account bounced back to the palace mail server, and the bounce never made it through the palace spam filter.

You know what happened next. Although guarded carefully, the princess, grown to a young woman was one day accidentally tased by a palace security guard.

Nothing would wake her.

She had to sleep for a hundred years with her crown on until tech support finally showed up and rebooted her.

The Wisdom of The Bleikers

So now we arrive at The Wisdom of The Bleikers. Here’s their answer to the question “What could I have done differently?” It was the following explanation that provided my aha! moment halfway through the first day of the Bleiker workshop.

Setting the stage

You’re trying to implement a Good Thing for a constituency. It could be a new water treatment plant for a town, a program to reduce the number of unhoused, or—dare I say—the adoption of a single organization-wide administrative information system.

When we do this, invariably some folks are against our Good Thing. Our constituency is divided.

[An important caveat: The Wisdom of the Bleikers is not a panacea for developing consent for a poorly thought-out plan or proposal.]

The Bleikers’ research found that just about everyone thinks of a divided constituency they’re working with like this:

The Bleikers reframe this common view in the context of a scale of agreement, like this:

The key Bleiker addition that the above diagram omits.

Almost every major constituency faced with a significant change includes NIMBYs (“Not In My Backyard” aka “Over My Dead Body”) who, even if they are a small minority, have a great deal of power to torpedo implementation of the Good Thing.

Mr. North was my NIMBY. And, as I’ve related, he succeeded in preventing the implementation of a single administrative IT system during my entire consulting gig at Seagull School.

The Bleikers have found that the single most effective way to improve the chance of implementing the Good Thing is to focus on the NIMBYs.
And the heart of the Bleiker strategy is to move NIMBYs to 0+%.

The Bleikers have found that this strategy works. Though it’s not 100% guaranteed, they have successfully helped hundreds of organizations to implement complex projects despite the existence of considerable NIMBY opposition.

Why don’t people follow the Bleiker strategy?

Why didn’t I talk to Mr. North as soon as I started to realize that not all was well?

Fear.

Remember that everyone at South who worked with me was very happy with my work. It was easy for me to hang out with the folks at South and join them in complaining about how unreasonable the folks at North were. It would have been scary to go and listen to Mr. North. I felt scared to hear what they might have to say. So, I played it safe. For years.

It’s really easy to hang out with the folks that agree with you. It’s hard to go into the lions’ den and talk with people who are highly opposed to what you, and perhaps a majority of a constituency, think should happen.

My mistake was to focus on developing support at South for a single administrative system at both campuses, rather than developing what the Bleikers call Informed Consent at North. I never really thought about who might be affected by my work. If I had, I might have realized that I needed to spend a lot more time listening to Mr. North. If I had successfully implemented what the Bleikers eventually taught me, Seagull School might have had a single administrative system by 1999, instead of nine years of countless meetings, expensive outside consultants, and school-wide frustration.

This was my biggest consulting mistake. (That I’m aware of.)

Informed Consent, and an introduction to what you need to do to move NIMBYs to 0+%

The Bleikers identify three kinds of consent:

Informed
Uninformed; and
Misinformed

And they define Informed Consent as the grudging willingness of opponents to go along with a course of action they are opposed to…”

So, if you can develop Informed Consent, you can get your proposal implemented!

You can become what the Bleikers call an “Implementation Genius”!

Implementation Geniuses:

Don’t concentrate on developing support for their proposals
Focus their efforts primarily on the bottom of the Agreement scale
Aim to develop their fiercest opponents Informed Consent

The Bleikers spend most of their workshops teaching how to develop the Informed Consent of NIMBYs. I’m not going to try here to reiterate or summarize what they teach. I recommend you go to their workshops for that! But I want to end with five Bleiker “pearls” that give you a taste of what to expect.

Pearl 1. Why versus What

Telling your constituency:

- WHY you exist…
- WHY you do what you do…

…is ten times more important than just telling them WHAT you do.

Pearl 2. The mission is not the mission statement

Your mission is a bunch of responsibilities. It resides in people’s guts.

Your mission statement is a bunch of words, a verbal sketch of the mission, but just a sketch.

You need many different mission statements, some long, some short, some technical, some non-technical – but many, many…

Pearl 3. The Bleiker “Life-Preserver”

Repeat often!

“There really is a problem.”
“We are the right entity to be addressing this problem; in fact, given our responsibility, it would be irresponsible for us not to address it.”
“Our approach is reasonable, sensible, and responsible.”
“We do listen, we do care.”

Don’t say “we want to” or “we would like to”.

Say “we need to do this!” or “we owe it to you”.

Pearl 4. The Null-Alternative

The Null-Alternative is the sequence of events that, most likely, will come to pass if you don’t implement a workable solution.
It is the consequence of your failure to implement a workable solution.
Write it as a story.

Pearl 5. Use stories

You have to get anecdotal to communicate.
“Anecdotes make policy.” (Here’s a post I wrote about an anecdote that Hans Bleiker shared at our workshop.)

Conclusion

I titled this post “Learning from my biggest consulting mistake”. There aren’t really any dumb mistakes. Mistakes are integral to learning. They only become dumb if you don’t learn from them and consequently repeat them over and over again.

Have you ever avoided people who have the potential to torpedo important work because you feel scared of what might happen if you do?

I have, and I believe such behavior is understandable and, unfortunately, common.

I hope that by sharing my story and the Bleiker approach to developing Informed Consent with you, you learn how our natural unwillingness to listen to those who vehemently oppose something we think is a Good Thing can be overcome.

To your and your constituency’s benefit.

Has something like this happened to you? Please share your stories, experiences, and thoughts about anything in this post in the comments below!