skip to main content

4 Things You Should Consider before a Volunteer E-Learning Project

In: Showing my Work, Tips, 

For the past 3 months, I have been working on a volunteer e-learning project. I’ve written about my struggles with it previously on the blog. It started off pretty well, but eventually spiraled into a scope explosion that had to be reined in, degenerated into essentially text and next, and slowed to a crawl with only one module and a storyboard to show for all 3 months work. In other words, it has not been a great experience. Now, I do kickoff meetings all the time for projects and, at work, nothing is allowed to drag on this way. The major difference being of course, at work, clients who want a course have to pay for my time and so it’s in everyone’s best interest to set and meet deadlines. Volunteering, while an excellent way to build your skills, has this one major disadvantage: since people aren’t paying for your time, there’s a (mostly unconscious, I think) tendency to abuse your time. Given all of the things I try to do in my spare time, this has not been a great experience.

But it has been an experience from which I have learned a great deal. I think that it’s also given me a bit of a glimpse into the world of freelancing and forced me to think more about what I did wrong, what I did right, and what I could do better next time. With that in mind, here are 4 things that you should consider before you jump into a volunteer project.

Make Sure that You’re a Good Fit

One major thing I want to change about my process is making sure that I’m a good fit. Yes, you’re only volunteering, but honestly, it behooves us to treat this the same way we would a paying gig. I created a small mockup based on our original conversation so that the organization could get a feel for my style. But I should have done more than that. I should have asked more questions about whether their training philosophy fit with mine. I should have probed more for information. From the beginning, the project was amorphous and had no clear direction and I should have seen the red flags there. I didn’t really have anything else going at the time and I thought it was going to be a small project, so I thought I could go with the flow. While I still think I have to remain open to changes, I really should have done more research.

My Takeaways

  • Ask more questions about required time commitment
  • Ask about major milestones and an end date
  • Get firm details about approval process (for example, I should have never started working in Storyline until the storyboards were approved by all necessary people)
  • Don’t just go along with a project idea that is “still in development.” If they aren’t sure what they want, that means bad news for you.
  • Be sure that they have a clear view of the kind of instructional design they’re after. Ask the tough questions, “Why does this need to be a course?” “What are your goals?”

Create Hard Deadlines and a Schedule

As I said, I figured it would be a small project. The original deadline was the end of May. I knew that and so I think I got that right. What I didn’t do, however, was sit down and iron out a schedule of milestones, approvals, etc. That extra step was important. Furthermore, when my contact came back and said that he didn’t think it would be finished by the end of May and he was going to stay on until the end of June (see point number 3), I would have had a firm schedule that we had both agreed to as proof that I wasn’t being unreasonable. I stuck to my guns (see point number 4) but I would have benefited from a schedule of mutually agreed upon milestones and due dates.

My Takeaways

  • Create a schedule and have it signed off by everyone
  • Be realistic about your needs and ability to commit
  • Be sure to include milestones (such as storyboard 1 approved date, storyboard 2 approved date) along with the final due date

Create a Statement of Work and Stick to It

Scope creep. Or in this case, scope explosion. It must be avoided at all costs. This project started with the idea of one module with 5 sections. However, as my contact began asking around to all of the (far too many) people who wanted to have a say in the course, that small 5 section course exploded into a 5 module course, each with 4+ sections. I knew immediately that that was not what I had signed on for and could not commit to that. And I spoke up about it. But again, I think I would have been more effective (and saved myself a lot of headache) if, before work started, I had created a statement of work (SOW) document and everyone had agreed to it. Bottom line, my willingness to allow the project to completely evolve (as opposed to small revisions, which again, I think I have to be open to) was a problem here. A detailed SOW would have forced us to confront all of these things up front.

My Takeaways

  • Create a Statement of Work and make sure that everyone understands it
  • Be detailed about what exactly you are agreeing to provide (including the number and size of modules, whether you are developing the full modules or just the storyboards)
  • Be detailed about when the project is due and that all parties agree to meet the deadlines
  • Be open about what happens when the organization fails to meet a deadline
  • Be detailed about what they need to provide you so you can do your work (including text, images, voice over, music, etc.)

Contract Resources

If, like me, you are a complete newbie, here are some contract resources I found helpful. You’ll have to modify them, as they pertain more to web design, but they’re better than trying to start with a blank page.

Be Vocal When Things Aren’t Going Well

I think I got this one down! When the scope creep happened, I was very upfront about the fact that I was, in no way, shape, or form, prepared to commit to that scale of work. When the deadline continued to drag on, I clearly stated that I was going to have to stop work on the project and turn it over to the organization by mid June (though I should have stopped at the end of May). When more iterations came (just recently, in fact) on a finished module, I said that I would attempt them but couldn’t guarantee it. It’s good to be clear in situations like these. Unfortunately, I think that my clarity now, instead of setting a clear line previously with a statement of work or clear approvals, may seem like I’m getting frustrated and running away, instead of being a reasonable reaction based on the violation of agreements. While there’s a chance that a client could get upset even with all of those things in place, it’s still partly my fault. And I’ve learned my lesson. With agreements like a SOW and a schedule, even if it hadn’t stopped all of the problems from surfacing (and in this case, it probably would not have), it at least makes the parting of ways something that doesn’t seem out of the blue. I sincerely hope that I haven’t burned any bridges, but it’s past time for me to put this project to bed.

My Takeaways

  • Don’t be afraid to speak up when the client wants to tack on things you hadn’t agreed to
  • Having a SOW and a schedule makes it easier to speak up on things that violate those agreements

Final Thoughts

I declared, in my best Twitter southern accent, that I would never do another volunteer elearning project again. I think that’s probably true. Though, as I seek more experience in software engineering and web design, other volunteer projects may not be off limits. So, while this has been a bit of an ordeal, I would encourage other instructional designers seeking to widen their scope and update their portfolios to seek out volunteer projects, if that’s what appeals to you. But please, learn from me. Don’t just go along with with because you aren’t getting paid. In fact, exactly because you won’t be paid, it’s really important that you create an environment that honors your time commitment by taking the time up front to explore whether you’re a good fit for the project, setting deadlines and milestones together, creating a statement of work, and being prepared to speak up based on those agreements. In other words, treat this project the same way you would treat a freelancing job.