Slashdot Mirror
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?
Start with:
Is this software related to our industry?
Do we need some advantage over our competition or can we just use the same stuff they do?
What's our back up plan if we discover that our self created software ends up making the Obamacare website rollout look good?
How much money do you think we will save?
If it ends up costing more money, how much we will sink into this project before quitting?
excitingthingstodo.blogspot.com
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)
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