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.

Have a question you’d like answered? Let me know.

Let’s say you go to your dentist because you’re experiencing some tooth pain.

You’ve done your (Google) research to determine what the cause of the pain might be, and have decided that it’s a cavity. You contact your insurance company to see how much it’ll cost to fix the cavity.

You get to your dentist’s office and tell them you need a cavity filling based on what you’ve discovered in your research. Without any questions, the dentist fills the cavity.

A month later, you’re back at the dentist’s office with more tooth pain. That pain ended up being way more than a cavity, and it’s about to cost more to find out what the real cause it. You’re frustrated because you told the dentist that you’re still experiencing tooth pain and the cavity filling didn’t solve the problem.

But can you really be upset with the dentist? After all, they only gave you a solution based on what you thought the real problem was.

This is how it feels to go through the Request for Proposals (RFP) process. If you’re not familiar with what an RFP is, it’s a document developed by an entity looking for a particular service. In my case, it would be consulting services.

The RFP process can be frustrating, and it’s a process I only participate in if the project sounds interesting (or if I’m interested in the prospect of working with a prospective client). The majority of my clients have not come by way of an RFP process, which pretty much gives you the answer to this month’s Ask Nicole question.

But do I really feel that all consultants should abandon the RPF process? Not really, but I do feel that we need to take nonprofits, foundations, and social service agencies to task on how ridiculous this process is in the hopes that they develop a better process that’s beneficial to everyone. There’s a lot left to be desired about the RFP process, but here are five things that bug me about it:

1) It’s an extremely vague process, focusing more on deliverables rather than being open to identifying what’s needed to get to those deliverables (and also figuring out if the process to get to the deliverables is even feasible within the budget and timeframe identified by the client. Which leads to the point #3).

2) The RFP is designed around what the organization thinks they need. As with the dentist example, if you tell your dentist what you think the solution is, it prevents them from doing a further examination to discover what the underlying needs really are and give you an appropriate diagnosis and treatment. I can’t develop an appropriate proposal for a prospective client just based off of what’s in the RFP without knowing some background information on the organization or program that’s more than likely not listed in the RFP.

3) Clients are weirdly vague about how much all of this is going to cost. If we’re being honest, an organization knows how much they’re willing to budget, but none are upfront about it. They’re either afraid to list it because of the belief that the most talented individual or group will believe the budget is too small, or they think they’ll have the upper hand at negotiations.

( I do not know of anyone willing to apply to a job posting that doesn’t have the annual salary listed. It’s tacky and unethical to deny someone the right to determine whether working for an organization will result in pay equity and livable wages. Plus, we all know an organization will eventually go with the consultant or group that costs the least.)