Dos & don'ts for technical assistance volunteers /
volunteers donating expertise

To keep a technical assistance volunteer experience beneficial rather than frustrating for the person or program you are trying to help, keep the following in mind:.
 

• If the organization that will host you as a volunteer does not train you about volunteering or give you some kind of orientation, ask for it! Learn the program's mission, get an overview of all of the organization's programs and current events, and have a list of the staff and the board, in case you encounter these people in the course of your service.
   
  
• Listen to what the program needs. And be ready to change the ideas you walked in with.
   
  
• What is the concrete goal or outcome that is wished for as a result of your volunteer activities? What does success look like for the program, from their point of view? Making sure you understand the expectations of the program will help prevent misunderstandings and disappointment about the service you are providing.
   
  
• Mutual agreement on a plan of action between you and those you are helping is the most crucial step of successful technical assistance. Outline the expected outcomes, approaches and resources and estimate the time you think it will take to complete the project.
   
  
• A not-for-profit or public sector agency can ask a lot of a volunteer, so make it your job to be clear about what you can and cannot do. Define the project using milestones that match your available time and skills and meet their needs. Do not over-commit yourself.
   
  
• Remember that you were a beginner too, once upon a time. Welcome questions and remind those you are working with that there are no stupid questions.
   
  
• Think about the language you are using to explain something; using terms that only a fellow expert would understand will frustrate the person you are trying to help. Use common language whenever possible, and fully explain technical terms you need to use a lot. Learn what you can about THEIR work and put things in a context they can understand.
   
  
• Those that you are helping are experts in many areas as well. Respect their knowledge, as you would expect them to respect your own. Don't forget that you are talking to professionals; it is ignorance about a particular area, not stupidity, that has put the staff in need of your services.
   
  
• Respect the time of the staff and other volunteers. They have many responsibilities outside of what you see as a volunteer. They may not be able to devote as much time to an issue as you think they should; help them to do the most they can with the time they have available.
   
  
• Not-for-profit and public sector agencies operate in a world of very limited resources and ever-shrinking budgets. Don't be surprised if they don't have a staff member devoted solely to human resources, legal issues, computer systems, etc. Also don't be surprised if they don't have a budget to buy and maintain a large computer system. Respect those limitations by helping them to do as much as they can with their available resources.
   
  
• If you encounter resistance to a suggestion, particular in an area where you consider yourself an expert, try to diagnose the cause: differing priorities? lack of information about you? lack of information about them? bad timing? preconceived assumptions? Once you have identified the reason for the resistance, it will be much easier for you to deal with it constructively.
   
  
• Exude quality in your service to the agency. For instant, if you are inputting information into a database and misspell a name or input the wrong phone number, the work you've done is not just useless, it can be damaging!
   
  
• Build sustainability. Don't just do it for this program and staff - involve the staff in the process. Explain each step, give background, recruit someone to write down procedures or troubleshooting steps if applicable. The most important part of your "mentoring" is that what you leave behind works and can be sustained by the organization.
   
  
• Provide technical documentation (e.g., how parts of a database relate to each other) and user documentation (e.g., how to do the data entry and how to solve the most common problems faced by the user) for the first piece before moving on to the next piece. This way, if you must discontinue work on the project, the staff has the documentation needed to easily integrate a new volunteer into the project.
   
  
• Make sure whatever system you recommend for the agency to use, whether this is a type of software or an organizational model, meets the unique needs of the agency you are helping. Is this a widely-used system? Is there sufficient documentation available on how the system works? Can the staff effectively use or even alter this system without always relying on your expertise? What kind of support is available for this system?
   
  
• If you are designing a Web site, a database program, or other computer-related product, what you may view as a "feature" may be viewed as unnecessary or distracting by the staff member or other volunteer who has to use it. If a flashy interface doesn't provide the user with an easy-to-use tool, it's of no real use to the user.
  

• A computer is a means to an end. The person you're helping probably cares mostly about the end. This is reasonable.
   
  
• Their knowledge of the computer is grounded in what they can do and see -- "when I do this, it does that". They need to develop a deeper understanding, of course, but this can only happen slowly, and not through abstract theory but through the real, concrete situations they encounter in their work.
   
  
• By the time they ask you for help, they've probably tried several different things. As a result, their computer might be in a strange state. That's not their fault.
   
  
• The best way to learn is through apprenticeship -- that is, by doing some real task together with someone who has skills that you don't have.
   
  
• Your primary goal is not to solve their problem. Your primary goal is to help them become one notch more capable of solving their problem on their own. So it's okay if they take notes.
   
  
• Knowledge lives in communities, not individuals. A computer user who's not part of a community of computer users is going to have a harder time of it than one who is.
   
  
• If something is true, show them how they can see it's true.

Examples:

Advice for online technical assistance from volunteers

Here is a long list of what virtual volunteering looks like. And The Last Virtual Volunteering Guidebook, written by myself (Jayne Cravens) and volunteerism expert Susan Ellis and the result of MANY years of research and experience, can help you, as a volunteer, help a nonprofit, NGO, charity, school or community-focused government program to develop a more widespread virtual volunteering engagement scheme, one that isn't limited to technical assistance volunteers (such as an online mentoring programs where online volunteers help a nonprofit's clients). The book details what virtual volunteering is, all of the many, many different forms in which it is practiced, various ways to support and grow virtual volunteering, and how to address various challenges that might arise in creating roles and activities for online volunteers and supporting volunteers in those roles.

The book can help you, or even your entire company, work with nonprofits, NGOs, schools, etc. to help them develop virtual volunteering opportunities for your employees, for the local community, for a nearby university, or anyone, anywhere, who might want to help. Many traditional nonprofits are still struggling with the concept of virtual volunteering, despite it being a well-established, credible practice; corporate support in the form of training and funding could help greatly in getting volunteer centers to embrace virtual volunteering. The book can also help individuals who just want to provide the highest quality service possible as a volunteer, in technical assistance roles or otherwise.