Simple Complexity

Why not? Right? It is 2020 after all.

I recently had the pleasure of working on a project with an organization building a rather sophisticated list for their Annual Campaign. It involved giving history, of course, varying participation levels in a wide variety of diverse programs, family relations, and some reference to a kitchen sink. It was great! I enjoyed it thoroughly, and we were able to more accurately hone in on the exact population of prospects with which they planned to communicate.

A considerable amount of time as a consultant is spent defining, interpreting, translating, refining and delivering the needs and wishes of the organization into an actionable work product. For example, a prospecting list, a report, an analysis, a database conversion.

The conversation very commonly begins with valuable examples of exceptional circumstances where internal efforts have failed to generate the desired work product.

“We almost have it. I think. But Mr. and Mrs. Smith keep showing up, and they shouldn’t.”

This usually evolves (or devolves) into a discussion drilling way down into the details of both applicable and irrelevant defining characteristics of the circumstance’s relationship to the situation. Huh? In the example above, we often learn not only about Mr. and Mrs. Smith’s unique giving history causing angst in the creation of the list or report, but their love for animals and beautiful vacation home in the Hamptons.

Now. I am not entirely sure I would like the Hamptons. It seems a little uppity for me, but I am willing to try.

That detail right now can serve more to derail progress than to advance it. We want to know where the pitfalls lye. Please do not misunderstand. Advance warning is always welcome. The fact is, however, the process of building complex analytics actually reveals as much about the way an organization thinks, as it does about the tools in place, their use, its capabilities and the team’s ability to harness it all.

Start with the simple. Build to the complex. Test against the exceptions. Address the core of the issue.

Start with the Simple

Let me first understand the goal. What are you trying accomplish? Translation of need starts with understanding of the purpose.

Is this a solicitation? Direct mail? Fall? Event-specific? Great.

Who do you want, generally? Donors, friends, alums, individuals?

Broadly tell me what defines a prospect? Giving history? Program participation?

It is very difficult to plant a tree, if you think you are building a house.

Build to the Complex

Add color to the canvas and begin to capture the nuance. In doing so, populations of seemingly disparate groups can actually be found to be the more inclusive definition of a very simple characteristic.

For example, clients will say, “I want everyone who gave to the Annual Campaign, but I do not want to include those who only gave a tribute gift.” That can be defined in one way. Everyone who gave a non-tribute gift to the Annual Campaign. Too often the complexity of the internal discussion clouds the understanding of the established goal. The perception of complexity shadows the simple.

As you build to the full rainbow of considerations, test. Do not create the entire breadth and depth of detail in one intensive, brain-crushing process. Build parts. Define aspects. See the people, in the case of a mailing list, moving in and out of the prospect pool. Understand why they are, or are not, being selected. Learn the data – both as it exists in the system and in the spirit of what it is intended to capture.

Years ago, we were pulled into an organization to help with mailing list segmentations. There were only six (6) distinct groups to capture, but the Database Administer was using 32 selections/queries through a process merging compounding selections. Often, the building blocks of the process did not result in a change in results. It was undue complexity. The simplicity had been lost.

Test against the Exception

This is where rubber truly meets the road. Who is included who shouldn’t be? Who is not included who should be? Why?

Ideally, the exceptions go away because the process was so informative and probing. The end product is laser-focused on the goal at hand.

So…that doesn’t always happen. Actually, the universe of exceptions against which you are testing will very likely shrink. Mr. and Mrs. Smith may very well be excluded with an improved selection.

What is left is the core of the issue.

• The built tool is flawed.
  Fix it.
• The system mechanically cannot accomplish what we want.
  Consider utilizing an external resource such as a custom report writer.  
• The vision itself is contradictory.
  Prioritize defining characteristics and address accordingly.  
• Past decisions have caused a data conundrum.
  Evaluate the value of continuing with the past decision and own the cost by working around the exception. Or, change the adopted rule causing the issue.

Address the Core of the Issue

In building the complex, it is important to keep an eye on internal contradictions of data capture, vision, management and system architecture. Do not ignore that which causes problems, as the exceptions can be very enlightening.

It is not uncommon where a decision made to temporarily navigate an episodic situation turns into a guide, then a rule, then an impediment. Make a change if the long-term environment warrants it, but do not change to get past a temporary challenge only to face a new problem down the road.

Sometimes an organization does not have the internal resources to see both the simple and facilitate the complex. Employing a systematic approach to “peeling the onion”, “separating the wheat from the chaff”, serves the process well. Third party facilitators can be invaluable in these efforts as well.

I loosely used a mailing list as the background against which this discussion is based, but the same process benefits other endeavors as well. What are we trying to accomplish? What is a broad road map to get there? Then – once we know that – tell me where the rest stops and constructions zones are.

Dan Barney, Principal

Red Barn Advisors

dan@redbarnadvisor.com

www.redbarnadvisor.com