Prelude Interactive

Growth!

As threatened, we are growing.  A few weeks ago I settled on the right person to become Prelude’s first real hire.  We’ve been doing great work with contractors for a while, but now that we’re up to around 500 hours of effort a month, it’s clear that I’m the bottleneck.

HelpAttack!

As you may have noticed we’re involved in HelpAttack!  Our mission is to build a platform that will help people pledge and give based on their passive online activity.  What does that mean?  Think about pledging $0.25 per Tweet for the month of July to the United Way.  Or maybe $0.50 per Facebook update to Mobile Loaves & Fishes, or $1.00 for each Flickr upload to a nonprofit photography center.

The HelpAttack! “Alpha” is launching to a small pool of people and nonprofits mid June, and all of them have promised to not be too mean about the bugs that they find.  We aim to release a beta version in early August and will start building up a user base from there.  You can sign up for the beta on http://helpattack.com.

Interns!

We also have three industrious interns this summer.  Jason Gladu is back, and is currently researching the science of volunteerism, volunteer psychology, and other topics.  In addition we have an English major at UT soon to enter her senior year, as well as a Masters graduate student who will be helping with marketing, SEO, and analytics for both Prelude and HelpAttack.  Hopefully they’ll be up for making an appearance on this blog to augment or interrupt my ceaseless droning.

Vis-a-vis a conversation with Hilary Mason and Chris Wiggins, Jake Hofman pointed me towards Catchafire.org.  Ever since getting involved in the nonprofit technology sector, I’ve been curious about skilled volunteering, and somewhat fascinated by the lack of attention paid to it.  Catchafire wants to make it easier for people to participate as effective skills-based volunteers.

Unfortunately, I see a similarities with Smart Volunteer, an older organization that never quite…caught the fire, as it were.  The founding stories of these two organizations are almost identical.  Replace Rachel with Dan (and others), “investment banker” with “management consultant,” and hauling lumber with painting (schools in both cases!) and you have it.

Both organizations are/were trying to create their own communities of nonprofits and volunteers, rather than piggyback on the far larger communities which already exist. I think this is a critical mistake on Catchafire’s part, because so much energy, luck, and extra effort is needed to build and sustain such a community of users.  I was very impressed that they had already build a LinkedIn connector, but I think their service could fly farther, faster as a LinkedIn, Twitter, or Facebook app.

Even aside from massive general purpose social networks, there are many sites that already have an existing large community of users and nonprofits:  VolunteerMatch, Idealist.org, Everywun, Causes, All For Good, Social Actions, OpenAction.org, etc.  Also, don’t forget the 20-30 software suites that nonprofits already use for volunteer management.

I think that strategically, rather than trying to directly serve the public, Catchafire and similar startups should build tools that could be licensed or sold to these other companies.  This way they could concentrate on solving the tough, general problems that all these sites face – but don’t have the bandwidth or focus to solve for themselves.  One of the VolunteerMatch conferencegoers I know said he had yet to hear of such a pitch – someone designing tools & technology with VolunteerMatch as a customer rather than competitor.

I also don’t think either organization has made much progress into the difficult human resources issues of skilled volunteering.  Extracting, tracking, annotating, searching, and matching skills is an incredibly difficult problem.  Just ask the swollen HR departments at large companies and nonprofits – finding the right person for a job is time intensive, highly domain specific, and frequently prone to costly, inefficient error.

I also think that the projects already populating Catchafire may miss the mark with the general public.  They seemed to general and abstract to me at first, and I think the listed projects are too heavily oriented towards capacity building – press releases, donation engine and website support.  Perhaps people who want to start volunteering want to serve the mission, rather than serving the organization?  I don’t have any articles to cite here, but I’m starting to look for them.

The Catchafire.org site is pretty, but would do well to borrow Kiva’s emphasis on images and tangible, unique stories from the end beneficiaries – third world entrepreneurs in Kiva’s case.  Photos and stories pull harder on the heart strings than and motivate people to take action.  Again, I lack proven references, but it’s definitely worth an A/B test to see if Catchafire’s conversion rate increases.

Remember, this post is based on a cursory examination of the site and I have not used it heavily as either a volunteer or a nonprofit/NGO.  Am I missing the point and trying to shove Catchafire into the wrong pidgeonhole?

Update:  I actually spoke with Rachel Chong of Catch A Fire and she explained a little more about their concept and what sets them apart.  Their model does commit significant resources to both the task specification and personalized matching aspects of skilled volunteering, and she stressed that charging for the service requires that nonprofits have some ‘skin in the game’ – another choice that sets them apart.  I think the more people who are using their skills and resources to enable more skilled volunteers, the better, but I remain unconvinced that this is a scalable model.  Nobody has come up with an algorithm for skilled volunteering yet, and it’s just plain hard to scale a services business.  So, in other words….we’ll see what happens!  Lucky for Rachel, I’m wrong most of the time.

I wanted to write a short post simply to highlight a piece of volunteerism related software that I think does a lot of things right.  In the spirit of MailChimp, BasecampHQ, Freshbooks, Threadless, and other darling websites, it does one thing well:  Helps people self-organize their volunteer activities and volunteers.  Where this really hits a sweet spot is with the kind of volunteering that I almost never think about.  Volunteering that’s so pervasive, real world, and widespread that nobody makes a big deal out of it:  PTAs, Girl and Boy Scout troops, school bake sales, church groups.  You know, just the fabric of our communities.

VolunteerSpot does a great job with “Web 1.9″ users that would rather print out their schedule and post it to the fridge than try to sync it with their iPhones.   Plus, it’s free, which is – for better or worse – the right price point for volunteer management tools. Right now they are advertising-supported in some ways, which can be distracting.

Check out some of the things they’ve been able to do:

• Red Cross DAT Teams save 2 days a month scheduling volunteers for local disaster response (house fires, etc.)
• Some homeless shelters in Oregon were able to expand from 2 days a week to 5 because VolunteerSpot makes it easy to coordinate volunteers.
• Volunteers from Fork it Over in Washington pick up leftover food from school cafeterias and deliver it to community kitchens.  They expanded from picking up food at 2 schools to 9  because the software makes it much easier.

They aren’t a client of ours or anything – just something you should know about, use, and support.  VolunteerSpot’s fearless founder, Karen Bantuveris, has been kind enough to sit in on HelpAttack’s advisory board and has already contributed a terrific amount of wisdom.

Internships. The only way to get a job out of college. Résumé builders.

Sometime in December, I was attentively sitting in PR 305 anxiously waiting for class to begin when in walks a guest speaker—score! No class today. Perfect time to stream the soccer game to my laptop—who claimed he worked for the American Cancer Society. I instantly connected with him as a son whose mother was affected by cancer, but nonetheless, I had to look him up on the social media networks in order to verify his existence and credibility. As my bandwidth was fading, I am only allocated so much bandwidth per week, I decided I might as well pay attention to our speaker, just this once though, since guest speakers don’t happen all that often, that is unless your teacher decides to take a two week hiatus. After going through the motions of a lecture to a bunch of undergrads in an intro class, I approached him after class and struck up a conversation.

Let’s explore my expectations prior to jumping on board: Initially, I had no expectations or anything what-so-ever, I was excited to try my hand in the workforce and learn new information; but after learning that Prelude focused on technology, I was more excited than before as I have a passion for technology. After meeting with Ehren Fross on multiple occasions, it became clear that our partnership would work and could be prosperous. I had never tried my hand at anything more than rudimentary HTML and a nervous shockwave hit when more complicated languages were being explored during our conversations. The shockwave reverberated through me as the conversations delved deeper into Salesforce and other applications I had barely even heard of.  Not to confuse you, but while these discussions were frightening, it wasn’t anything I couldn’t handle or Ehren couldn’t teach/guide me.

Fast forward and here I am: Three months into my internship and I couldn’t be happier with my decision to move forward with the internship opportunity. Flexible hours, good pay, and priceless experience.

My first project included writing documentation on the Salesforce application Survey Builder. Writing documentation requires more time than I expected, not for the actual writing part, but to become familiar with the tool one is writing about. This project allowed me to try my hand at technical writing, which did not come as easily as I expected. My tendencies (writing to the audience, not getting to the point quick enough, et cetera) in writing proved detrimental to technical writing. However, after many revisions and meetings, the final copy worked. Not only did this writing bit help me become a better and more versatile writer, it opened my eyes to an entirely new field: technical writing.

Researching volunteer management systems became the next big task. In hopes of publishing the data and finding commonalities amongst the different systems, I compiled all of the research I could find into a spreadsheet. This process took longer than I expected largely because many companies would not post information on their websites, a frustration nonetheless. With the spreadsheet completed, I was tasked to create a website to access the database. While I had dabbled a bit in HTML and Dreamweaver, I had virtually no experience with PHP.  I immediately felt a steep learning curve as it became difficult to grasp the PHP concepts (I should note that I had some experience with Java, but nothing major). This website is still in it’s infant stage, but should be completed soon.

No classroom could have taught me the things I have learned with my tenure at Prelude: teamwork, real world technical writing, deadlines (while I must admit I was the Editor in Chief of a yearbook and am familiar with deadlines, the deadlines I deal with at Prelude are in the real world—the yearbook was as close as a school can prepare you for the real world), meetings, learning new things, expectations, and complications.  If I had to recommend an internship, it would be this one right here: flexible hours, great pay, great business, great guy, great work, and great industry.

Over the past two years we’ve had occasional involvement with a very interesting research project in Malawi. Malawi is in Africa, near Zambia, Tanzania, and Mozambique; I’ll save you the search.  The project has to do with microloans.  If you want to know more, or get involved, check out OptInNow, Kiva, BRAC, and perhaps the Grameen Foundation and the Acumen Fund.

I know I don’t have enough pretty pictures in my post but Shutterfly, where some of the project photos are posted, is really not helping today.  Ok?  Ok.

More specifically, the researchers wanted to find out if they could increase repayment rates (and thereby strengthen the effectiveness and permanence of microcredit) in Malawi by showing people that they could be uniquely identified.  Malawi, like many areas in the world, has no pervasive Social Security Administration, Department of Motor Vehicles, or other widely accepted way of uniquely identifying its citizens.  So, intentionally or by accident, people were able to receive multiple loans in different villages – thanks to misspellings, miscommunication, moves, or other natural bureaucratic phenomena.  Perhaps some people really wanted to pay their loans back but were unable to find a reliable way to do that.

Don’t quote me on these figures, but I think Malawi had a repayment rate in the 70% range while other areas such as Bangladesh are able to report repayment rates closer to 98% or 99%.  A good problem to fix!

The research team located a vendor of small, rugged fingerprint scanners, and contacted me to see if I could help build some software they could use in the field.  I was very interested in the project, because it meant a short escape from the day-in,  day-out web applications.  Unfortunately, the project did not go perfectly. The remainder of this post attempts to describe, and learn from, the various things that went wrong.

The application we built had several main tasks:  Collect fingerprints, identify people using their fingerprints, and merge fingerprint databases.  Believe or not, small villages in the Malawian outback are not internet enabled, so collected data had to be manually merged into a central database after each collection run.

• The fingerprint scanner vendor supplied a suite of software developmest kits (SDK), but the only one I could reasonably hope to work with (Java) wasn’t my main area of expertise (PHP). These SDKs were also quite finicky and it was sometimes impossible to tell why it was working or not working.
• The fingerprint scanner vendor released a new version of their software which probably worked better on Windows XP-64 bit and Windows 7, but for reasons probably having to do with the very fine print of grant applications, it was never purchased or deployed as an upgrade.
• Timelines for delivering various components of the project were too short.  Timelines are always too short, in all kinds of projects, all over the world.  In this case, it affected our ability do develop slowly and carefully, and meant that not many “test runs” were possible in the field before they started collecting real, experimental data.
• Some unknown issue, perhaps tied to the above bullet points, or some mistake we made, led to the corruption of some of the collected data.  This means the researchers couldn’t do the entirety of what they needed to do with the data.

So, how to do it better next time?

• Refer the project to someone else.  Even though the timelines were too tight for anyone to do a search for a Java-specializing firm, I should have put my foot down and insisted the project was not right for us.  It’s funny, once delivering something by next month is known to be impossible, the deadline can magically be extended or reshuffled.  It may have led to a delay in the first phase of the project, but would probably have led to a better end result.
• Insist on good tools.  Developing on the older version of the SDK took probably twice as much time as it would have with the newer, more compatible one.
• Test, then test more.  Testing and QA are hard.  Very hard.  It is important for everyone, developers and clients, to perform thorough tests.  It is important to test at the beginning, and then to test again while you think everything is going fine.