Tammy, a licensed independent clinical social worker and consultant based in the Pacific Northwest, recently sent me a really thoughtful email. Tammy writes:

Hi Nicole, 

First, I just want to thank you for writing your blog, and let you know upfront that this is one of those, “Thank you! I needed to read your website.” kinda emails.

In consulting work, I feel like I’m going to struggle with communicating how design-based thinking and evidence-based decision making (and not necessarily Evidence-Based Programs (EBP)) could be really powerful tools for organizations. Where I live, the agencies that design their own programs are often bootstrapped for cash; and the ones with money will just purchase a curriculum and send their staff to a national training on how to implement that curriculum. To get funding for a lot of things out here, you need to use an EBP. I’m a big fan of evidence-based decision-making processes, but I think most pre-packaged evidence-based programs (at least that I’ve worked with) are like disempowering wet bandaids that never really stick! It seems like most organizations are more willing to pay someone else to train their staff to implement a very structured program that’s already been created than they are to work with someone to design a program that really suits their needs, strengths, and resources (even when they acknowledge they probably would do a better job than the pre-made curriculum!)

So, the question is: how do you help people realize the potential for design-based thinking and evidence-based decision making processes in a non-profit/agency world that has become relatively disempowered in the realm of program design? Have you run into that at all with your consulting work focused on program design? If so, how do you navigate that conversation? 

A few months ago, a prospective client organization came to me about a project opportunity. I had some initial conversations with the client, but I got the sense that what they wanted and what my process is weren’t in alignment.

It was confirmed when the client asked me to further explain one key aspect of my process. The aspect–something that the client initially agreed with and wanted to be included in my proposal–focuses on participatory processes between myself, the staff, and key stakeholders. The client seemed less interested in this aspect and wanted me to tailor my approach to just outcomes.

Over the past year, I’ve developed more of an interest in working with clients to develop, evaluate, and refine their process versus solely focuses on outcomes. So, I knew deep down this wasn’t the project (or the client) for me.

The bulk of my consulting as of late has centered around evaluation, with design thinking included depending on the work scope. I’ve found that clients who’ve hired me to evaluate a specific program have been more rigid in what takes place in our time working together compared to clients that hired me specifically for capacity building purposes that span all of their programs and services.

This comes down to whether the client is focused more on the process or the outcome. Based on my observation, when client organizations are focused solely on outcomes, they’re confined to certain parameters that may be heavily influenced by a funder, things being “evidence-based”, or a deadline. As a result, I have more flexibility with clients that have hired me for building organizational capacity and learning about their programming in a more exploratory manner.

Outcomes center around aspects of a program that led to data that can be reported on, including the number of participants and how they engaged with the program. A more process-centered approach assesses how the program was developed, how it got to where it currently is, and what factors along the way got it there (including staff capacity.)

Ideally, you’d develop a process that addresses both. However, the approach the client wants to take can ultimately decide if you’re going to have a great time partnering with this client or spend most of your time arguing back and forth.