Managing Nonprofit Software Developers

Facilitated by Allen Gunn, Aspiration

Session Description

One of the most vexing challenges in developing nonprofit software is managing the lovable, irascible labor demographic known as "developers". This session will cover best practices for clear communication, project management, compensation negotiation, change order management and project acceptance criteria. Participants are invited to share their their success (and horror :^) stories and bring questions and learnings to the session.

Session Notes

Group interests

• Sustaining momentum
• Managing contracts with volunteers
• Why do projects fail?

Background and general philosophy “Recovering developer” Learning by failing – learning by what you don’t do for software development Healing to apply many lessons learned to nonprofit sector

Huge mistake for nonprofits to write new piece of software. Fundamentally 99% indefensible to undertake new piece of code. The norm is for nonprofits to treat software development like ordering pizza - can I get a large with pepperoni, mushrooms, etc?

Too much ego and power with funders and executive management. Lots of funders and leaders who believe they should be able to just say when something should exist and their staff or supporters should make it so.

Nonprofits have no idea what the "right" software/applications means. Have a hard time defining this.

Aspiration supports a negotiation model for bids. "Give me a good reason this can’t exist on Wordpress." Start there and build up when you hit certain ceilings. Grow with reason. Don’t reinvent.

Are there exceptions? Yes, there are occasionally situations where you have to write your own code for example if the software really isn’t out there and the nonprofit really can prove value. Otherwise, convince people to go join other projects even though it can be difficult and require group therapy and removing vanity/arrogance/visionary aspect from executive directors.

Answer isn't always yes or no, try to scale to leverage what's out there already. For example, if a CMS doesn’t work out, then it’s which framework are you using.

Best practices

Creating successful new technology is really hard.

Divine to develop new modules/plugins for Drupal/Wordpress/etc. Modular systems are great.

Feature-oriented software development is code-language for “we’ve never done this before” and red flag. Features do not add up to solutions. Workflows make solutions.

Get people to think about what they do about executing a series of steps that are technology enabled to get to an outcome (not featured-based). What is information model? Is it fresh? Ex: try using delicious for 6 months to test it out.

Are workflows not supported by existing information category and is the information model independent?

Really believe in user-driven software development. Use the same process for basic Drupal site. Get 20 people to use software and participate in testing. If you can’t get people on advisory committee, that should be a reflection of market reality. Tough love. Prove that there is demand by forming advisory groups, get support from user audiences. Define the Mimimum Viable Product (MVP) – how do you get to the mvp as fast as possible?

Mantra is technology last. Value first engagement protocol. What value are you bringing to your users? Ex: noprofit websites often structured to reflect organizational structure (about 70%). Universal question to ask is what are you putting on your website that will cause people to come back more than once?

What’s the value proposition? Who is the technology/software for? Answers like “we want to build the site for everyone” are a big red flag.

Figure out exactly who you are building it for, do audience research first. Good criteria is can you find 5/10/20 of them who would engage with you and help evaluate the vision?

Working on 2 white papers:

• RFP
• Workflow inventory initiative – collection of online workflows (ex: prepping email blasts, etc).

Build workflows that are independent of specific technology and tools. All good programming is extraction. Specific technology implementations should be treated like hardware – low level. Should be able to be swapped out as it become obsolete/outdated.

Work with developers who share values. The leading edge is 99% never appropriate for nonprofits. Means you are paying a higher rate because you’re paying for debugging. Believe you don’t get developers involved until late in the process (though this is debated by some). Need extremely concrete document that is mechanism for doing due diligence first. Developers can’t run away with things if they’re not in the room.

Mantra 1: All nonprofit technology undertakings are organizational development opportunities in disguise.

Lots of decisions made on emotional rationale. Where is nonprofit with true internal transparency? Lots of nonprofits don't even have transparency between teams like Fundraising and Communications. Don’t work together, fight over sending out messages/bandwidth. Say upfront that we won’t work with you if power can’t be distributed. Organizations have to be ready to change internally. Have to soften them up at first though they won’t likely end up changing radically in reality. If you do your job, can get technology in there for higher transparency.

Apply constructive passive aggression. "That’s an interesting discussion to have later after this piece/value proposition is in place." Avoids the “no, you’re wrong.”

Mantra 2: We insist that every step in the technology project, the rule is that for entire scope (cradle to grave), all documents happens exclusively in end-user language.

Always have discussions that are accessible. Invite developers to take convos offline and summarize in human language (ex: talk in terms of speed and security – explain what the decisions mean). Specifications/core requirements and all meetings is a zen exercise discipline to keep the discussion in end-user language. No jargon. In our role, we are advocate of user, person who will be using technology. Technologists are used to getting their way because they can speak above the users.

If you can’t talk to the user in end-user language, if you can’t ekep it in the user story space, you don’t belong here. Good way to put developers back on their heels. Ex: Radical Designs. Ex: I can give you that feature, but here are 3 ways that’s going to make you look bad to your org.

It’s about the smallest possibly vocabulary to keep everything in end-user language. Talk tech in an intentional way, report back to larger group.

People who are trying to build these tools “need it now.” Hard to make case for slowing things down and building in intentional way. As implementer, work with partners to get there – beat the functionality out of you. Aspiration is a cost-checking service because they have free proposal review process for nonprofits. Look at both hourly rates and aggregates.

Example: What should this website cost? Session at annual Managing nonprofit technology projects conference.

Nonprofits get fixed budgets, never do fixed budgets for startups because you don’t know what you need, how long the project will go, not a short-term project. Nonprofits don’t usually have this luxury. Issue with fixed budgets is they don’t support he project structure that developers often want. Having a cap doesn’t support an ongoing relationship/long-term relationship model.

Best practice fix: For a fixed amount of time, you can’t make changes, but we will revisit this later at X date. Need to get to stable point before you can get estimates/bids/etc. Beware of pathological feature creep. Many consumers think that small cosmetic changes shouldn’t be as expensive as they sometimes are. Need project manager to defend trade-offs to find balance. Best practice to get into give and take, but then you get into methodology of give and take. Trading doesn’t guarantee final output. Put it on wishlist and triage when you reach fixed point. Discipline is to go back to core deliverable to see if anything can be sacrificed (answer is likely no). Put in on list to revisit at the end. Triage all requests at the time.

Important difference exists between implementing and designing. Get a spec document that has airtight user stories. Figure out the MVP. Who are you building this for, what does it do, beaten to a pulp. Can layer in other things later once a stable starting point is reached.

People want to hire developers directly to reduce middle man, but helpful to have a developers often aren’t good at playing this role/managing the users.

Develop user stories, then prioritize list, and go through line by line.

Never tell an implementing shop what your budget is first. Tell them what you need. Get proposals back first, then treat budget in fraction. Give yourself some room for costs over.

Good development shops need “ass-kicking” change process. Free work can lead to mediocrity. Aspiration works free or will charge nominal amount to consult with nonprofits. Recommendation for provider is to give cost estimate ranges, explain risk factors, contingencies, places the budget might go over thoroughly. Awareness of what could push project off time/budget. Good implementer is someone who understands pattern language.

Curse of being implementer is that platforms change (ex: Salesforce/CiviCRM). Technology changes, dealing with moving targets.

Tell a client the minute there’s a problem. Super high frequency, transparent communications.

User stories

User stories document is magna carta – organizational development touchstone. Speak now of forever hold your piece. There’s an art as an implementer of pointing out and getting clarity on explanation of what it will/won’t do.

How many user stories in some examples/how long are they Big fan of less is more. Trying to estimate a general cost per user story amount because there seems to be an average. A good criteria is to not let a user story be more than a half a days work.

User stories are one sentence: "As a user, I need to be able to do X because Y."

Fantasy scenario

Have the vision discussion proactively with setting expectations on the floor. Figure out the MSVP – minimum shitty viable platform/product. Can it be simulated by using something easier? Bad process to code something before you know what you want.

Do some facilitation with advisory committee first. Tell the story of how you’re going to get to done first. Shop the story around, does it resonate with your people/audience? Then audience analysis. Define audience, then ask advisory group if they are representative of that group. Develop pilot protocol.

Advisory committee, then build user stories, have team walk through user stories together amongst stakeholders and prioritize (would you use them? Etc). Then review user stories with fine-toothed comb. Need good rubric for “what is a shitty user story” besides using sixth sense. Have org fill it out and then passes to vendor from approved list (of about 15 shops). Farm the RFP out and then Aspiration gets out. Answer questions on proposals to help clarify. Simply advise to go with the group you like the most. Now have about half dozen groups who’ve gone through this process.

Can always call Aspiration b/c their mission is to save nonprofits money.

First client in group of nonprofits that Aspiration has helped from the very beginning of their project process just finished their site (first "fruit of the process"): http://www.climatehealthconnect.org. Got funding to track public health implications on climate change. Drupal site with a few modules. Used mostly existing code.

In-house vs outsourcing

Want an in-house person that owns the relationship. Have person on payroll tracking and that they can understand in simple human language what is going on. Fine-grained, contain domain knowledge inside organization. Report back to staff to keep knowledge circulating. A good suggestion from the group is to have a Friday demo with a project team to walk through everything that was due that week.

Resources:

• http://www.aspirationtech.org/training/eadvocacy/resources: Collection of templates, zip file of email newsletter html template that works with all email complaints (next step will be to put under version control)

• http://www.aspirationtech.org/training/workflow/templates: Workflow template to inventory user stories

Would be good to have YouTube videos about this process for nonprofits to show what is needed from nonprofits, what keeps projects from going down in flames, what are reasonable/normal expectations, who should be involved, etc.