I spent most of my early career as the one-stop technology department for small-to-midsize nonprofits. I have been the first technology employee on more than one occasion – this means that aside from walking into some chaotic technical situations, I’ve regularly faced a very common & problematic misunderstanding about whether problems are related to Process or Technology.
Small nonprofits with smart, hard-working, dedicated staff who have realized they need technology help (be it on staff or on contract) tend towards some other characteristics. Perhaps these sound familiar:
- Employees have broad areas of responsibility (by necessity)
- Lots of hard work is creating lots of (unmanaged) data
- There is often only one person who knows how to answer a specific question
- Different technology tools exist for each technology task, with no integration (mass email through a web service, donor tracking through a different web service, donation tracking in QuickBooks, client management & grant tracking in two different spreadsheets, etc)
- Spreadsheets are being used for tasks better suited to databases
- Any employee taking vacation for more than a week creates a great deal of stress in the office
The recognition of a need for more “nerd capacity” is admirable, but those hard-working staff want to hand off their perceived technical issues and get back to the rest of their accumulating work: that’s a good way to end up with great technology tools that don’t properly solve the organization’s problems.
Why does this happen? Because a growing organization needs more than Technology: it needs Process. For a lot of really smart people, the words Technology and Process similarly evoke a combination of feelings: fear, intimidation, anger, confusion, and lethargy. (Once, when I was trying to convince a data-rich organization to hire a Database Manager, a decision maker objected: “I don’t want people working for me to be unhappy, and that job sounds boring.”) As a result, these “boring” tasks get lumped together.
What ends up happening is that Process tasks are handed off to the technologist as Technology tasks: “Our donor data and our mass email records and our client services information need to be synced up. And the donation data, too, which means the finances need to be connected. Can you set something up?” The (understandable) perception here is that the proper Technology tool will take care of the details: so the Technologist should find and setup the tool, and these problems will be solved. The reality is that the only way to solve this problem is with a combination of Technology and Process, carefully and deliberately planned, integrated, and customized for each organization; and that the best solution will always be less than perfect.
Does this sound like a brewing disaster? It doesn’t have to be. The first thing that on organization has to do is slow down and understand itself. This means putting someone in charge of understanding the organization’s existing hodgepodge of processes for managing work & data, giving them the time & information they need, and being ready to trust the processes that person proposes. Here is my general outline for the “Process Process”:
Step 1: Talk to everyone
Talk to everyone in the organization to get detailed answers to the following questions. Take your time, delve, and listen carefully for hints of deeper answers. Have each conversation privately, and don’t let anyone put you off or insist they don’t have time for a detailed interview. Bad information now will result in bad Process and the wrong tools.
Skills required: persistence, patience, listening, data savvy.
- What do you do?
- What are the biggest obstacles you face internally?
- Do you track any information of organizational importance? (this means anything that anyone else in the organization might need access to.)
- Do you have any import spreadsheets you forgot to tell me about? (press this point)
- How do others access this data when they need it?
- What unique information comes to you from your daily work that the organization might want to track?
- What opportunities to gather valuable information do you think the organization is missing?
- In an ideal world, what internal tasks would you not have to deal with?
- What sort of numerical questions do you have about your own data? (think charts & graphs– this is a great way to find out what information people want to have but don’t have any established way to record)
Step 2: Describe what you have learned
Use whatever data visualization tool you prefer to describe the existing data “system”. Be painfully honest, but avoid implying blame. Include sources of data, even ones that currently go nowhere. Identify existing staff that serve as data “hubs”, either due to the nature of their work or their personalities. Show your description to each of the “hubs” and other key stakeholders and ask the following questions.
Skills required: data visualization, patience, communication, tact
- Do you understand what I’m showing you?
- Which parts of this description can you confirm are accurate or inaccurate?
- Which parts of this description are new information to you?
- Which parts make you concerned?
- Is anything, to your knowledge, missing?
- Based on this description, what are the top 1-3 things that need to be fixed or added on an organizational level? (note: this is not about the accuracy of the description, but about the goals going forward)
If question 2 reveals a lot of inaccuracies, you may have to revise your description and try again. This is not unusual, especially if Step 1 was rushed.
Step 3: Establish & prioritize goals
Invariably, there will be a set of “goals” implied or explicitly set out before you began this process, so this step might be “Revise & prioritize goals” in many cases. By now you should have a pretty clear understanding of what’s going on in the organization, and what needs to be improved. Sit down with your description & the feedback you received on it and write down some goals in direct language. Examples:
- Establish a single home for all supporter data
- Make all client data available to all outreach employees
- Track client data that is required for grant reports in a reportable format
- Establish a consistent process for tracking & thanking donations
- Automate membership renewal reminders
It’s ok to write down your goals with an eye towards the problems you perceive as realistically solvable, but be sure to include “problem goals” that are hard to meet as well: especially ones that are important to the organization. If you leave out important goals of the organization, you can lose the trust of the people who have spent valuable time to go through steps 1 & 2 with you.
Skills required: synthesis, interpretation, concision
Step 4: Present your goals
Meet with key stakeholders and present your goals. Work with them to re-prioritize. Be an advocate for those people who are not in the meeting– you may have a better understanding of everyone’s needs at this point than their supervisors. If you have “problem goals”, explain why they are problems and see if they can be de-prioritized, restructured, understood in a more solvable way, or if you will need to ask for more resources (time, money, or both) to solve them.
Skills required: communication: presenting & listening
Step 5: Describe a proposed solution
Using what you have learned, create a new version of the description in step 2 that addresses the priorities in step 4. Include data sources and make it obvious which steps are technically automated and which will require human interaction. Naming specific new technologies should be avoided for now: use generic terms. Take your description back to the key stakeholders, and make sure they understand where direct staff work is implied in your proposed solution. These staff-driven steps are the hardest part of establishing the Process your solution is going to rely on: you need full buy-in from your stakeholders on these Process pieces. Stop here until you are sure everyone understands the parts of your solution that are additional, process-related work, and that they are ready to do that work.
Skills required: system design, communication, persistence, persuasion
Step 6: Turn back into a nerd
Find & implement a solution using your deep understanding of the issues & priorities, the desired flow of data, and your ability & requirements to use staff as a part of Process.
Skills required: nerd stuff
Step 7: Train everyone individually
One of the beautiful things about working with a small organization is that this is actually possible. Walk every single person through the new Process using real tasks from their daily work. Take the task from start to finish with them, and imagine doing the task yourself. Get feedback on frustrating or inefficient parts of the process and use it to refine your systems. If you are deliberate and patient in steps 1-5, you should have a great framework, but it won’t be perfect. Some of the things people described to you might have been less precise than they thought. Programs evolve, staff understanding changes, and you need to be ready to refine your processes and systems to account for these shifts. Think of your solution as an Alpha version, and embrace the inevitable flood of feedback.
Skills required: teaching, patience, listening, humility, nerd stuff
There are two obvious keys to success here: organizational recognition of the need for a deliberate solution, and the solver’s ability to put together a clear picture of the organization’s work. The hidden key to success is organizational buy-in: but that’s a whole other article. For now, the important thing to understand is that taking your time and doing things in the right order will help avoid a lot of painful wasted effort. In nonprofit Technology, we often have to be Process nerds, too. The good news is that Process is a lot like Technology: both are way more fun than most people think.
Get In Touch
Questions? Comments? We want to know! Drop us a line and let’s start talking.