Ignoring complexity can make sense – Part 3 of a 10-part series on how complexity can produce better insight on what programs do, and why 

Common Introduction to all sections

This is part 3 of 10 blog posts I’m writing to convey the information that I present in various workshops and lectures that I deliver about complexity. I’m an evaluator so I think in terms of evaluation, but I’m convinced that what I’m saying is equally applicable for planning.

I wrote each post to stand on its own, but I designed the collection to provide a wide-ranging view of how research and theory in the domain of “complexity” can contribute to the ability of evaluators to show stakeholders what their programs are producing, and why. I’m going to try to produce a YouTube video on each section. When (if?) I do, I’ll edit the post to include the YT URL.

Part	Title	Approximate post date
1	Complex systems or complex behavior?	up
2	Complexity has awkward implications for program designers and evaluators	up
3	Ignoring complexity can make sense	up
4	Complex behavior can be evaluated using comfortable, familiar methodologies	up
5	A pitch for sparse models	up
6	Joint optimization of unrelated outcomes	up
7	Why should evaluators care about emergence?	up
8	Why might it be useful to think of programs and their outcomes in terms of attractors?	up
9	A few very successful programs, or many, connected, somewhat successful programs?	up
10	Evaluating for complexity when programs are not designed that way	up

Ignoring complexity can make sense

Complexity is in large measure about connectedness. It is about what happens when processes and entities combine or interact. I believe that understanding complex connectedness will make for better models, and hence for more useful methodologies and data interpretation. Of course I believe this. Why else would I be producing all these blog posts and videos?

Still, I would be remiss if I did not advance a contrary view, i.e. that avoiding the implications of complexity can be functional and rational. In fact, it is usually functional and rational. I don’t think evaluators can do a good job if they fail to appreciate why this is so. It’s all too easy to jump to the conclusion that program designers “should” build complex behavior into their designs. I can make a good argument that they should not.

The difference between Figure 1 and Figure 2 illustrates what I mean. Every evaluation I have been involved with comes out of the organizational structure depicted in Figure 1. A program has internal operations (blue). Those operations produce consequences (pink). There is a feedback loop between what the program does and what it accomplishes. Real world cases may have many more parts, but qualitatively they are all the same picture.Figure 2 illustrate s how programs really operate. The core of the program is still there, color coded in the same pink and blue. However, that program contains embedded detail (dark blue and dark red), and is connected to a great deal of activity and organizational structure outside of its immediate boundaries (green, gray, yellow, and white.)

The people working in the program certainly know about  these complications. They also know that those complications affect the program they are managing. So why not act on that knowledge? There are good reasons. Think about what would be involved in taking all those relationships into account.

• Different stakeholders will have different priorities.
• Different organizational cultures would have to work with each other.
• Goals among the programs may conflict and would have to be negotiated.
• Different programs are likely to have different schedules for decision making.
• The cost of coordination in terms of people, money, and time would increase.
• Different time horizons for the different activities would have to be reconciled.
• Interactions among the programs would have to be built into program theory and evaluation.
• Program designers would have to interact with people they don’t know personally, and don’t trust.
• Each program will have different contingencies, which instead of affecting a narrow program, would affect the entire suite of programs.

That’s the reality. I’d say its rational to work within narrow constraints, no matter how acutely aware people are of the limitations of doing so.