We’ve been busy on the transition and we’re finally at a place where we can give you an update on what we’re doing and how things will proceed going forward. As we got past the initial stages of the project we ran into concerns in these areas:

• Technology Transfer
• Support hours from PASS HQ
• PASS Liability
• Event Leader Liability
• Handling & Managing Event Funds
• Privacy

Before I got into those, remember that our goal was to keep SQLSaturday as close to the original formula if possible and where changes were necessary, to do nothing that would remove the ability of each event leader to take ownership and execute as they saw fit. I  reached out to a few past event leaders to get their input on the items below and overall the consensus was that none of these changes would have a negative impact on their ability to manage a SQLSaturday. At the end of this post I hope you’ll agree with that assessment.

Now let’s talk about each of the concerns. The technology transfer should wind up being the easiest part of the move, consisting of 2 databases, a bunch of reports, 4 web sites, and assorted support stuff. We’ve done a test move on most of them and have most of the problems ironed out – for example, we didn’t have an instance of Reporting Services deployed. We haven’t set a final date, but expecting to do the hand off in the next 30 days, giving me time to make a few key changes needed for admin purposes.

The number of support hours is a huge point – we want to grow the number of events per year and we need something that will scale, in particular since PASS derives zero dollars from managing SQLSaturday (yes, it does get marketing value) which makes it a cost-center. The Board took on the project understanding that, but we also have an obligation to keep that cost to something reasonable. Based on my own experience I believe we can average less than 10 hours per event, but it makes sense to be conservative for now. We’re going to do five events under PASS guidance and then revisit our hours used to make sure we’re on track.

Next was the issue of PASS liability. As we put this through the legal review one of the key points was that PASS could not own SQLSaturday without addressing the liability in some way. Here’s a ‘for instance’; an event leader signs a venue contract on behalf of PASS and then there is an incident, PASS could well be held liable for damages. One way to solve this would be for PASS HQ to review and approve every contract/agreement. It would be safe, but would remove power from the local leader. Instead, we’re drafting a one page agreement (which I call the franchise agreement but is more like a memo of understanding) that establishes the ground rules with events. More on that further down in the post.

Of equal concern was the potential liability for event leaders. PASS isn’t going to mandate an approach, but will advise leaders that there are various ways to mitigate the risk and they should choose the one that best fits (attendees waive liability, they buy a one day policy, they use an existing policy).

Moving on to funds, we had hoped to find a way to simplify things so that event leaders would not face any tax consequences. Because PASS is a not for profit we have struggled to find a way to do this that didn’t hurt the event leaders ability to get things done. Instead, we’ll continue much as before, where PASS will hold funds in trust (for US based events only for now) and distribute them back in up to three checks. PASS will not issue a 1099 for those funds. Each event leader will be responsible for deciding how to address the tax issue (PASS cannot issue tax advice, but basically they can just treat as taxable income and pay using a portion of the sponsorship dollars, file a more complicated return so that they can write off the related expenses, or channel the dollars through a local business that can itemize the expenses). Note that we’ll also allow events to manage their own funds directly if they choose. We’re going to use this method for the next six months and then have our auditor review our books with regards to SQLSaturday, and at that time we’ll return to trying to find a better solution. No promises that we can actually do it, but we will try again later in the year.

The last hurdle was privacy. Right now we don’t have a published policy and that was definitely an oversight on my part. We’re going to put that together shortly, and one off shoot of that is that in order to comply with anti-spam laws we’ll be adding an explicit opt-in selection to the registration form that allows each attendee to decide if they would be willing to receive mail from event sponsors. For most events this won’t be a major issue, but it will greatly decrease the size of the list that can be shared with sponsors. We’ll coach on ways to offset this; raffles, email blasts, other contests.

At the end of this, we’re going to wrap all of these change into a one page document that each event leader will sign that will look something like this:

• PASS licenses a single person/company to use SQLSaturday#xx on DATE
• Admittance must be free
• A lunch fee of up to $10 is allowed, but attendees must have the option to provide their own lunch
• Must publish a sponsor plan and must accept sponsors willing to pay at the rates published in the plan
• Must comply with the SQLSaturday privacy policy (to be written)
• PASS will hold funds for US events in trust and issue up to three checks to the signer of the agreement. PASS will not issue a 1099, but will point leaders to tax resources for details. Alternatively, each event can totally manage their own funds
• Understands that they are responsibe for addressing liability concerns
• Understands that they cannot sign contracts or represent themselves as officials of PASS (though they can obviously be PASS chapter leaders/volunteers)
• Require them to let sponsors know they working directly with the event leader and not with PASS (and we’ll put similar language on the invoice).

That’s it. We’ve had to add bit of administrative stuff that shouldn’t take anyone more than a few minutes when they go to set up an event. Everything else remains the same – events raise funds, find speakers, set their own schedule, spend the money as they see appropriate.

Now on to related items.

At HQ Blythe Morrow will be the public face of SQLSaturday, in charge of coaching new events, following up on events that seem to be struggling, updating our documentation as we learn new lessons, and talking to the community via the SQLSaturday blog. Sanj will be assisting Blythe by monitoring the webmaster email alias and helping with documentation, and David will own support of the SQLSaturday web site and related tools.

There is still a lot to do. Things that I used to do with a query or two need to be converted to reports and web pages to keep the cost of ownership down. We’re going to make our entire documentation on how to manage a SQLSaturday visible to our members at http://wiki.sqlsaturday.com (and let event leaders update it). Doesn’t sound like much, but it’s definitely a good chunk of work to do.

When I reviewed all of this with the Board at the March 2010 meeting I explained what I thought our job was:

• Provide the best tools we can to reduce the time required of an event leader
• Provide great documentation and continuously update it as we learn new lessons
• Provide sponsorship dollars to events to the extent we can
• Be responsive to questions
• Stay out of the way of the event leader

To wrap this up I think these are changes I can live with easily enough when we do the next SQLSaturday in Orlando, and I think they preserve the grass roots feel of the event format. We need a few months to get past the transition phase and then….we can see about dreaming a bit bigger, 80+ events per year!

I’ll be glad to answer questions here or on the PASS blog, or in person as you run into me at the events.