Technical Volunteering with Non-Profits

Engaging with a non-profit as though you’re working on a consulting contract can help manage some of the risks in this type of volunteer project. Here are some of the things I’ve learned working on pro bono projects, with many thanks to Steve Andersen for lending his consulting expertise so my team could get it right on the first project!

Preparation

Projects are often easier to handle with a small team. You can pull in people with different skill sets who offer value in different areas. Try to find people who are as passionate about the mission of the non-profit you’re going to be working with as you are: people are more likely to make the effort and prioritize their volunteering if they care about the cause. Identify one person who will act as the project manager and keep the team on track — it’s easy for volunteer tasks to become deprioritized in the face of work you get paid to do.

Ask the non-profit to identify a few key people for their team as well — preferably the people who are most involved in their business flows. For example, if managing volunteers is a problem area in their organization, then the volunteer coordinator is a good person to be on the team. If it’s a website project, you’ll want to work with the person who will be updating the content.

Kickoff

Hold a kickoff meeting to introduce the teams. Do it in person, if possible. Identify who on each side will be the point person for questions, information gathering, etc.

Ask the non-profit what they need help with. What are their pain points? What are their most important problems? Are there things they don’t have now that they would like to have? When the project is finished, how will they know that it was successful?

This is also the time to set expectations. How many hours or weeks do you plan to dedicate to the project? What kinds of deliverables will you provide? Will you be available for additional technical support after the project’s completion? Are there requests that are clearly out of scope for the project due to complexity or time constraints, or that maybe just aren’t a good idea?

Information Gathering (Non-Profit Team)

The non-profit team team documents any current workflows and business processes. What’s the process when a donation comes in? How do they track who is using their services? Is there information they are required to disclose for their annual report or grant applications?

The non-profit team also gathers any artifacts from their business processes. These may include paper or online forms, spreadsheets, statements, emails, reports and any other deliverables related to the problems they want to solve — anything they require to get their jobs done. They may not want to disclose confidential information, and this is fine — just knowing what the columns are in a spreadsheet, or what demographics they are required to track, is enough.

Analysis (Consulting Team)

The consulting team analyses the non-profit’s processes and artifacts and documents the requirements. They may create diagrams of the workflows and processes. They begin to identify technology solutions, like any changes to the data model and how processes can be automated.

The team then scopes the project, breaking solutions into chunks that either stand alone or are building blocks for future phases. It’s quite likely that not everything will be in the scope of the project due to time or other resources that aren’t available, so having a list of options that can stand on their own will help.

Present Findings and Recommendations

Bring the teams back together. The consulting team summarizes their understanding of the problems, the analysis and their recommendations. Make it clear what is and is not in scope. Ask if the solutions will solve the non-profit’s issues.

The non-profit team asks questions, provides feedback and prioritizes which work needs to be done. If there’s a long list, ask everyone to choose their top three priorities and choose the items with the most votes.

Create a tentative schedule with the prioritized work. Leave some time at the end of the project for documentation, training and any migration or integration required.

Implementation

The consulting team gets to work. Check in regularly with the non-profit team, when possible — get them to try stuff out and determine if the solutions meet their needs. Iterate as needed.

The project manager checks in regularly with team members during this stage to make sure they’re on top of the project. It may be useful to schedule regular “working sessions” where everyone gathers to work on the project together.

Document all changes in a technical spec. The spec is given to the non-profit at the end of the project so they have a record of changes made to their system.

Present each phase on completion and get sign-off from the non-profit before moving onto the next piece of work.

Hand Off

Create documentation and training materials needed for the non-profit users to help them use the system. I can’t emphasize enough the importance of documentation! Provide this and the tech spec to the non-profit users. Train the trainers within the non-profit. Help with any data migration or other integration needed to move them onto the new system.

Be prepared to answer questions, fix bugs and tweak solutions for an agreed upon number of hours and period of time following the hand-off. And make the effort to check in with the non-profit and ask if there are any issues — they may not come to you for fear they’ll be bothering you.

November 26, 2013 · Tags: ,


2 Comments »

  • Spot on! I love the practice of putting a framework around a probono engagement. It sets clear expectations on what the involvement is, what the needs of the organization are, and which of them the project will (and won’t address). Also, having documentation and a strong knowledge transfer at deploy will hopefully show the organization some of the fabulous benefits that come from a sound methodology!

  • Shannon Hale says:

    Thanks Jen!

    To me, the documentation is as important as the actual customizations. Turnover can be high in non-profit organizations, so having that history is key to the continued success of the project.

    Which is why I often spend what feels like twice as much time writing documentation and training materials as doing the technical work :)

RSS feed for comments on this post. TrackBack URL

Leave a Reply