> Posted by: "Robert Citek" [email protected] rwcitek > Date: Sun Feb 15, 2009 7:31 am ((PST)) > [...] > Of course the number of hours in the example are arbitrary and for > illustrative purposes only. We'll have to assess where the comfort, > stress, and burn-out levels are. Also, the above examples assume that > volunteers can do each others tasks. A more unfortunate case would be > if the 20 hour volunteer knew how to do things that no one else does. > > How do we avoid this? > > Some solutions (not an exhaustive list): > > 1) keep tabs on the number of hours volunteers are working. We need > to know in advance of when volunteers are being stretched too thin.
OK, I'm going to make a snarky comment ... to keep tabs on volunteer hours, we need the volunteers to utilize our login sheet. Some volunteers (including Robert Citek) do not log their time. So this is always going to be an imperfect art. > 2) prioritize projects. We can't do everything, nor should we. Agreed. However, if we're teaching classes and advertising EAC computers to be given out at graduation, then we need to build EAC computers. If we are supposed to generate a certain monthly amount of revenue from PC sales, then we need PCs to sell. Also, your suggestions assume some things which I don't think are reflected in the reality of our shop, such as: 1) all volunteers put in the same number of hours. We have a small dedicated core that shows up weekly. We have people that show up one or two times per year. And we have some in between. 2) all volunteers are willing to do all tasks. If that were true, then Karen's and my name would not be the only two ones on the log sheet of who cleans the bathroom (Thank you, Karen!!!). 3) all volunteers are able and available to do all tasks. We've got folks that want to teach but not build computers, or folks that want to work in the shop but not deal with the public, or folks that do Windows but not Linux, or folks that can come in on Wednesday evenings but not on Saturdays. > 3) make recruiting and training new volunteers a top priority. The > easiest way to do this is to pair up. And I don't mean pair up as one > person does part A and another person does part B. Instead both > people work on parts A and B. If you can't find a partner to do a > project, time to recruit or put the project on hold. When we get new volunteers in the shop, we always try to train them on everything we're doing. I don't think "put it on hold" is acceptable, not if we want to keep the operation going. Do we say cancel classes 3 weeks into the course? NO. Bill puts in extra hours to get the graduate image built (Thank you, Bill!!!). I bring home hard drives to clone during the week. And somehow, some way, we manage to get the grad boxes built before week 6. Recruiting new volunteers? You betcha booties! Nate was working on a new sign to put in the shop window, and I think he's talking about getting some fliers out, too. Jen may know more about it, too, she's the volunteer coordinator. Things would be a whole lot better if our "core" consisted of 20 rather than 6. I uploaded the hours for 2008 (.xls) to the bworks_staff files section, if anyone is interested. The "core" volunteers are all within a handful of hours of one another, over 200 hours per year. The next level works about 25% as much as the core. After that, there are a whole bunch of people who work from 3 to 30 hours per year. I agree, we need to avoid burn-out. We also no longer have a ByteWorks Director, who worked 4 times as many hours as the "core" group does. So, either we recruit a new director, or we distribute a much heftier workload, or both. Thanks for your input, though -- good to hear what people are thinking, and good to hear some suggestions. Theresa
