Decision Checklist: Building & Buying Nonprofit Tech

When to build custom software and how to have those conversations?

• Costs to consider and whether you want it to be open source
• More process than product
• How to keep it simple when you do need to develop software
• If we are not going to use tools because of privacy and security concerns (ie. no Google Apps), what do we use?
• How do we choose a vendor and a platform that will work for us?
• How do we trust we will get what we need and how do we communicate what we need?
• When someone tells me there's nothing out there that does what they need, I don't know if they've done sufficient research. Trying to figure out what they're needs are.

How do you know when you really do need to develop software?

• Good analogy = visiting a doctor
• Sometimes people have technology angst, ie. that they need to fix something that's not actually broken.

Important parts of the whole process

• Relationship with developer: How do I know they have my best interest in mind? Trust.
• Language: Developers speak a different language. Whe someone writes down what they want; what language are they using? You have to come to where they are.
• If you still don't have a good sense of their internal business process (including decision making processes), give them some homework. See if they follow through.
• If you can't understand how they cut up the universe, you probably can't build good software for them.
• If you're the one at an organization hiring someone to build you software, you still have to go through an internal process of figuring out where you're colleagues are at and what capacity they have to participate in the development process, learn something new, etc.
• It can be so helpful to see things before they get built. You can communicate more universally in images rather than words. Images can facilitate the conversation.
• You can't just have people fill out a form because that forces them to use your language.
• It's such a Eurocentric approach: requiring people to write down what they need, so I can deliver on it. Often not how things get done in community organizing.
• Written specifications: If it's on here, you'll get it and if it's not, you won't get it. Listing what you will not be doing can sometimes be as helpful as listing what you will be building for managing client expecations.
• People inevitably think of more things they want mid-way through the project.
• Fluid relationship: You want to be able to adjust. Think about working with clients as a long term relationship. We have a shared vision for what the end product will look like and along they way, I want to keep asking, have I lost you? Are you still with me?
• People don't know what they want. How do you respect that?

Exercise

• Tell someone a need and the other one is going to take as good notes as possible to get the solution. Don't have to solve the problem, but get the information you think is needed to get a solution.
• There will be a period when one person is talking and the other is listening and asking questions. Then both will reflect back what they understood to be the other persons' needs.

Post-Exercise: How well did you feel heard and why?

As the "Client"

• Felt safe to share.
• Felt perspectives on the problems were confirmed and validated.
• Empathy
• Vulnerability
• Felt like making a confession.
• Seek out help because we're struggling with something.
• You need that therapist because sometimes it's not safe to talk about these things interally.
• Looking for an ally.
• Felt heard when my partner used the words I was using.
• Felt respected when told the purpose of my partner's questions. What do you use that for? Different tiers of assumptions. Transparency in the process: why are you asking this?
• Felt good to talk to someone outloud.

What is the developer's role? To translate these needs into a product.

As the "Developer"

• Did the person know what their needs were?
• Do you feel you understood what the person's needs were?
• Iterated reflection: both people starting to use the same word correctly.
• Unpack an overly solved problem. Like when a client says I need a Drupal website. What are the elements that came to that conclusion?
• Isolate the issues. At some point you have to start looking at one thing.
• Prioritize and find the key to the problems.
• Letting someone pause to collect their thoughts.
• Know when to step into your expertise. "You probably have a lot of the information already, I'm just here to listen."

How do you know when communication about needs didn't work?

• Anxiety of getting something done for them and jump ahead. Slow down when you feel that sense of excitement.
• Approval process along the way.
• When you get busy with things, stop to ask yourself what are we not doing?
• Requires a huge of humility and transparency to talk about the things you're not doing. Focus on the targets you are aiming for. I haven't gotten to these things, are they still important to you?
• We like to be quiet about things we're unsure of. Not sure if they're working on it, so I'll just keep quiet about it.