Ask Slashdot: Event Sign-Up Software Options For a Non-Profit?
New submitter don_e_b writes I have been asked by a non-profit to help them gather a team of volunteer developers, who they wish to have write an online volunteer sign-up site. This organization has a one large event per year with roughly 1400 volunteers total.I have advised them to investigate existing online volunteer offerings, and they can afford to pay for most that I've found so far. In the past two years, they have used a site written by a volunteer that has worked fine for them, but that volunteer is unavailable to maintain or enhance his site this year. They believe the existing online volunteer sign-up sites are not quite right — they feel they have very specific sign-up needs, and can not picture using anything other than their own custom software solution. I am convinced it's a mistake for this non-profit to create a software development team from a rotating pool of volunteers to write software upon which it is critically dependent. How would you convince them to abandon their plan to dive into project management and use an existing solution?
Look at CiviCRM (in combination with drupal). Extremely flexible, build for non-profits, completely Open Source.
Yes, it is, for a whole host of reasons that I'm sure will be expanded upon here shortly. I've spent 20 years dealing with troubled and failed IT projects, and one of the biggest mistakes I see time and again is an organization trying to create a mission-critical project, often in a compressed time frame, using developers who are not an experienced, functioning team. You can usually throw into that first-time adoption of some silver-bullet technology and/or methodology. So, what you get it, "OK, let's get 10 random programmers who have never delivered a working system together as a team, and they're going to develop this mission-critical system from scratch in 4 months using Swift and Agile, even though none of the programmers have ever used either. And we can add more programmers if we start to fall behind."
Having the programmers be volunteers is even worse, since they are now self-selecting based on their own interest, instead of being chosen for, you know, actual skills, talent, experience, and so on.
Sigh. ..bruce..
Bruce F. Webster (brucefwebster.com)
How would you convince them to abandon their plan to dive into project management and use an existing solution?
I wouldn't. This seems like a trivial project, something you could whip up with Perl/CGI in a few hours. Is there something wrong with the "site written by a volunteer"? Why is the original developer the only one that can "maintain" and "enhance" the site? What exactly needs "maintaining"? Why do you expect that there is an "existing solution" that not only meets their needs but that also costs nothing to "maintain" and "enhance"?
I've noticed a sort of reverse-Not-Invented-Here syndrome recently, where problems that would be trivial to build one-off solutions for are instead solved with huge, unwieldy, general-purpose, off-the-shelf products. It seems the pendulum swings both ways.
Chuuch. Preach. Tabernacle.
How would you convince them to abandon their plan to dive into project management and use an existing solution?
Easy, give them a quote. Then let them know that doesn't include support.
I think any developers on slashdot could likewise quote them...
I'm going to say, if I like the charity and am willing to do them a favor: $100k up front, and another $50k on completion if it's relatively simple. Then another $50k per year for support. I can pass background checks and all that stuff.
Oh... so they want, for free, something that would cost at least $200k? And they think their free versions going to be even remotely be equivalent? It's like saying "Well, we could take the buss, but ferrari's are more comfortable. We can't afford a real ferrari so go get us some volunteers and have them custom build a Ferrari from the ground up so we can save money."
It's silly on its face... and if they can't figure that out, I think it's a clear sign how they'll handle the rest of the money they get. Run, don't walk away from that place. This is an important lesson for you not them.
Here's a list of 62 volunteer-management packages. Some are web based. Some are free. Somewhere in there should be something that solves your problem.
They're being lazy, and you're being lazy. Let me give you some real get-shit-done dealing-with-dullards project management 101.
When an organization feels they must use custom developers it's often because of those "unknown unknowns" in the non-existent specification that they want to make up as they go along because they cannot sit down and concentrate long enough to commit it to paper. You should not accept this. If you do, you shouldn't be in this business. Your job is to MAKE them decide on the specifications. If you think it's someone else's job, but nobody is doing the job, then guess what - it's your job, because your job is to do the fucking project correctly.
Mock it up SCREEN BY SCREEN ON PAPER, button by button, every edge case handled. Nail down every field, every possible error condition. Hold meetings with simulations waving bits of paper around to simulate swiping, button clicking, and result pages. Do not stop until you have a "working" piece of software that exists entirely in paper mockup that everyone agrees will solve all their problems. Tell them it is crazy to start coding until you get to this point because it's like starting work on a custom engine before you know if it's going into a car or truck. There is no reason not to do this, and nobody does this, because people are stupid and don't understand how software development works, and they think they can write the spec as they go along and the developers will just adapt and figure it out. It's our fault for being so adaptable on 90% of late-stage feature requests that come through, and it makes us feel like the 10% that kill us are actually our own inadequacies.
Then you write it up formally (as briefly as possible, preferably with shiny pictures or a pop-up book if you can) and you tell them this is the specification. You get signatures. You create an Appendix A that says that any feature request is a change to the scope, and that changes require a new Appendix, and also make them sign something that acknowledges that any appendices may necessitate starting ALL CODING FROM SCRATCH AGAIN, and that if the appendix is added because of something they "forgot" or "didn't think of until they had a chance to actually use the UI" then they take full responsibility for not thinking about the mockups hard enough.
Once that nightmare is over (which should be 3/4 of the cost of the project if you're getting paid), then you try to match their needs to a piece of existing software. Only if they truly have requirements that do not exist do you accept a custom development project.
The rotating pool of volunteers is of far less importance. A shitty implementation and customization of a third-party system can be just as confusing as a custom code project for new volunteers coming in, though arguably slightly less so, so it is certainly preferred.
A couple of years ago, I was asked to be the registration chair for a national event, which we successfully held this spring. All previous events had been run strictly on paper-and-pencil mail-in forms, but that involves a lot of manual work, including a lot of last minute work at the event door. I looked long and hard at various open source and commercial event management offerings, and I spoke to other people who ran similar events. Based on recommendations from other event organizers, I landed on regonline as a good blend of features and customizability, even though it was a bit expensive (though they offer a discount for a 501(c)(3) organization.) What it came down to for me was effort. I wouldn't have time to set up all the hosting needed, to install and configure the software, or to integrate with a payment gateway, and I got a lot of really valuable features from their system. I didn't want us to make our attendees suffer through hour-long lines at a registration booth. And I was able to provide instant reports to the conference chair, who used them to help run the event smoothly.
Something it sounds like you need to do here is figure out "who is the Registration Chair"? If it's you, your only question to the Event Chair should be "what is my budget?" Base your solution on the bottom line. If your budget is $5/registrant, and it includes lanyards and ID cards, your options are wide open. If your budget is $0.50/registrant, and you have to use a box of old "Hello my name is..." stickers, your options are a bit more limited. The important thing is: the Registration Chair is in charge of registration. He or she decides how to best solve the problem, not "here are some random developers, you must write us a site."
One thing that still isn't clear is why you would have to "write" a new site. It sounds like you created one a few years ago, and then another, and then another. I realize your group is a precious snowflake, completely unique in the world, but events really are just events. They all have web sites, registrants, admins, venues, agenda items, merchandise, travel, lodging, taxes, payments, receipts, badges, volunteers, and reports. And there is nothing in that list you can't get from the marketplace. Ultimately, if you absolutely can't use a packaged solution because of [illogical rationale], you should only need to have someone reconfigure the existing site. That's a lot less effort, perhaps not much more than c/2014/2015/g
Finally, if you're taking payments on line, you're going to run into extra effort and risk to interface with them. No matter what, you really, really don't want to be responsible for someone else's credit cards. Not these days. The risk is more than you can imagine. If that's something you can foist off on a third party, you'll keep a ton of liability out of your organization.
John