Taking a Systems Stance Toward the Problems of Human Service Information

There’s more and more talk about using systems thinking to solve problems. But many people find it hard to put a finger on exactly what that might mean.

One reason: systems thinking can feel very alien. It’s inherently abstract. It tells observers to set aside their usual ways of looking at a situation. It introduces an unfamiliar set of concepts. It invokes principles that apply to systems in general. But what kinds of principles? And what is a system anyway? Most people aren’t used to thinking in those terms.

Another reason: systems thinking is a very broad tradition. A few dozen well-known thinkers developed systems approaches over the last century. They share some common ground, but they also go in very different directions. On its own, the phrase systems thinking merely points to the broad tradition, it doesn’t specify which problems could be addressed with which tools.

These are real stumbling blocks to talking with people about the value of systems thinking. But just for fun, let’s ratchet up the difficulty a bit more.

What about the role of systems thinking in managing human service information? Uh oh. People already talk about human service systems in a non-technological sense. And people also refer to software as information systems.

All that existing language makes it hard to pose a question like: How can systems thinking lead toward building more successful information systems for human service systems? Beneath the hypnotic repetition of the word system, with all its vague associations, the listener’s mind soon feels like it’s turning into oatmeal.

It’s still an important question, though.

Resources for an Elevator Pitch

What to do? For starters, it would help if there were a quick and easy way to make systems thinking accessible to people who aren’t already fascinated with it. An elevator pitch.

(Then, after systems thinking has been distinguished from information systems, perhaps the conversation can turn to the relationship between them.)

One way to start, with only fifteen seconds: A system is just a bunch of parts that make up a whole. Systems thinking looks at how the parts work together, what they might be trying to do, how they can change over time, and how they relate to other stuff outside, which might be changing too. (That’s my attempt to boil down one of the classic articles in the tradition, written by Russell Ackoff.)

If the elevator is moving slowly in a tall building—or gets stuck—then there may be time to go a bit deeper. Here’s another resource: a very readable and entertaining article by Mike Metcalfe. He proposes that systems thinking is really a critical stance. Systems thinking means choosing to pay attention to transformation (inputs and outputs), connectivity among elements, purpose (what a system is intended to do), synthesis (disparate elements working together) and the boundary between what is included in the system and what is not.

Rethinking the Boundaries of Human Service Systems

That last item—concern with boundaries—is the area where systems thinking has so far made its biggest impact on the human service sector. It’s taken various forms. Social workers have long used the ecosystems perspective to holistically understand the situation of their clients. At the institutional level, there’s a growing desire to coordinate service delivery among multiple agencies: a decade ago people began developing resources for planning service integration and today the idea has morphed into a whole business model designed around horizontal integration that U.S. states are being encouraged to adopt.

And of course, integrating services depends on integrating information. That too has taken different forms. There’s now a technology toolkit, the National Information Exchange Model, that helps agencies exchange data between separate information systems. Some jurisdictions are developing common client indexes that link all their information systems so that all agencies can share a unified view of each human service client. Companies are marketing enterprise-wide human service software platforms to government. And designers have moved toward building databases that more accurately reflect the human service ecosystem.

But rethinking boundaries is only the beginning of what systems thinking could do for the human service sector. Other possibilities haven’t been explored as much yet. Here’s one:

Designing Data That Can Serve Multiple Feedback Loops

The common business jargon of asking someone for feedback and closing the loop originally comes from the systems thinking tradition. It’s based on the fact that organizations collect data from the environment and feed it back into their own operations. (Living organisms and some machines—such as thermostats—do that too.)

Human service organizations use a lot of different kinds of feedback loops. They’re usually treated, though, as if they were entirely different activities.

A caseworker records data about the services she’s provided and the progress that the client has made, and then looks back at those records when she needs to revise the client’s service plan. (That’s a feedback loop—a very small one.) Before meeting with caseworkers, their supervisor runs a report to see how many of each worker’s clients received the recommended set of services that month. (Another feedback loop, slightly larger.) An executive creates a new  strategic plan designed to increase the proportion of clients who graduate from the program and achieve good outcomes a year later. (A much bigger feedback loop.) Evaluators analyze the data from a whole cohort of funded programs and make judgements about whether the model is effective for its cost. (A really big feedback loop!)

(Note for systems thinking mavens only: this may remind you of the Viable System Model by which Stafford Beer described different levels of cybernetic processing in organizations. There’s a good study of a homeless shelter by Dale Fitch using that framework. But this post is headed in a different direction: toward software development methodology.)

These activities get labeled as casework and supervision and performance measurement and evaluation. And of course, they are all those different things. What they have in common, though, is that they’re all feedback loops.

[Skeptical Questioner: Well, so what? How does calling them all feedback loops help anything?]

I’m glad you asked.

Calling them all feedback loops is useful because the human service sector has a big problem with data. Organizations typically spend enormous resources collecting data and building software to support particular feedback loops—only to discover that the data, for one reason or another, don’t support other feedback loops that are equally important. (Think of software systems that support caseworkers well but performance measurement poorly. Or vice versa.)

In this blog’s first post I outlined what I think are the sector’s four biggest information management problems: isolated agency silos, unsuccessful information system projects, barriers to producing performance measures, and uncoordinated demands on service providers. The last two of those could be summarized as: data that can’t support multiple feedback loops. And that problem, in turn, often contributes to the failure of information system projects.

But if these are problems of feedback loops, then the systems thinking tradition—which has devoted a lot of effort to studying such matters—can offer resources that will help. (They may challenge some of the conventional wisdom of the software development profession too.) Much more on that in a future post.

—Derek Coursen

If you found this post useful, please pass it on! (And subscribe to the blog, if you haven’t already.)

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License

4 Comments on “Taking a Systems Stance Toward the Problems of Human Service Information”

  1. Bill Harris says:

    You speak about elevator pitches. You might be interested in http://www.stewardshipmodeling.com/documents/SDinElev.doc, a similar attempt done some years ago by a group of system dynamicists. I like Barry Richmond’s statement perhaps best of the lot.

    • Thanks very much for recalling this. I think I saw it a long time ago and forgot about it… no doubt it subliminally influenced my post! I like Eric Wolstenholme’s phrase about system dynamics “externalizing mental models”.

      My sense is that in order to address the human service sector’s current predicament of poor information management, the necessary starting point is a couple of steps back before system dynamics, with the most basic systems concepts.

  2. Dick Schoech says:

    Boundaries and feedback loops are two very important system concepts for the human services and especially for their use of technology which can cost-effectively automate the feedback loop across agency, departmental, land level-of-staff boundaries. We had a child welfare grant to develop an information system to connect workers/supervisors with information related to how their casework contributed to the agency achieving Federal child welfare performance indicators. Dale Fitch was part of that project. We used OLAP technology that allowed anyone in the agency to drill down and slice and dice through agency data to determine how workers achieved these agency performance objectives. The system, called DEMOS, was well received by workers and supervisors, but it also pointed out the how problematic child welfare data actually was. Our training on the system found it was easy for workers/supervisors to use, but most of the training time was spent trying to correct the data that was in the agency database. A report on this DEMOS project is in the J of Technology & Human Services, 2004, Vol 22/4 abstract.

    BTW, I also have a course handout on systems theory and human services. It expounds on what Derek is saying in this useful post.

    • Thanks for mentioning that OLAP article, Dick. It’s a good resource for helping people imagine all the feedback loops that other stakeholders in other roles may need.

      And the problematic source data that you describe is a critically important point. I think that if software designers and system stakeholders begin to think of human service software as needing to be interrogable models of their work rather than just toolkits, that will go a long way toward improving upstream data.

Your Thoughts?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s