gokubi.com

I just read Keith Heller’s article about choosing a donor management package over on Idealware. I generally agree with the article–I think his comments on the big picture are applicable. I do have one point of contention, however.

Heller says,

If you consistently hear that the software you want is going to need customization to do what you want it to do, stop and consider what you need—and the limits of the software. Customization is always more time-consuming and expensive than it looks. Ideally, you want something that will work out-of-the-box for your organization. Talk to people who have traveled the customization path and see if it paid off for them and was viable for the long term.

I disagree. In my experience, everyone needs customization.

CRM systems, like donor management, need to support the work you’re getting done in order for them to be helpful. If they don’t support the work, they get in the way of the work. This leads to dissatisfaction, lack of use, and inability to trust the data in the system.

I think that the difference between a usable system, and one that is considered “in the way” can actually be very small. Little usability problems can loom large to users. When the system doesn’t go that last mile, people get frustrated and forget that the system brought them the first 99 miles. All that is forgotten, because some annoying work-around is necessary.

But if the system is customized to fill in that last mile, then it will no longer be seen as a barrier. Often this customization is very small compared to the size of the system as a whole. These are the kinds of customizations people need, and should demand.

While I agree with Heller’s point that all nonprofits are very similar, especially around the way they fundraise, I also know that each nonprofit is, indeed, unique. Each one I’ve worked with has had some business process that was different enough, and important enough to them that we needed to customize the software system to support it. Could they have ditched their practice and adopted some well-defined fundraising strategy supported by a donor management system? Sure. Then they’ve changed their most fundamental revenue-generating business practice at the same time they’re making a software buying decision. I’ve found the groups I work with are reluctant to make that kind of change, and don’t want to tie it to a software purchase.

Customizations can be critical in making a system usable and useful to the organization. I don’t steer organizations away from customizations. I try to help them find the most valuable customizations, and make them as useful as possible.

Here’s a short movie explaining how we’re doing multi-payment Opportunities and dealing with complex nonprofit accounting.

Watch it here.

Charlie Wood tells of what must have been a very frustrating experience: making the final cut for two awesome high-tech jobs only to learn that the requirements had changed and to get the job he’d have to move to the Bay Area. He turned down both jobs and runs his software business out of Austin with a 100% remote team.

In a post today, he muses on remote teams vs. local teams, and has a really interesting passage about hybrid teams–some local staff and some remote staff:

Finally, I had a great conversation with Clay Spinuzzi, an associate professor at UT who’s writing a book on modern working arrangements. In that conversation, we talked about the awkward dynamic of a team comprised mostly of people working in the same physical space but with one or two members working remotely. We agreed that such an arrangement is problematic, and that the remote workers would no doubt become marginalized. But then it struck me: maybe the fact that a team can’t support remote members effectively is an indication of a problem with the design of the team.

In the same way that on-premise systems that use proprietary protocols and can’t connect to cloud-based systems are problematic for IT managers, a team that relies on “proprietary” communications among its members—that is, informal, social interactions that can’t be replicated online—limits its own potential.

The good news here is that new technologies like Twitter make it possible to translate much of the casual, interpersonal communication that has traditionally happened in an office to online, asynchronous, geographically-distributed teams. In other words, Twitter is the new water cooler—which comes as no surprise to anyone who uses it.

When two machines sit next to each other in a server room it doesn’t really matter what networking technology they use to communicate: AppleTalk, NetBIOS, and Banyan VINES will all get the job done. But TCP/IP will too, and with the added benefit that if you move one of the machines across the world it will “just work”. I suggest that the same is true for intra-team communications.

Teams built to rely on electronic, and more specifically Internet-based, communication channels can include remote members transparently, and can therefore be comprised of not only the best people in town but the best people period.

My team is mostly local, but with one remote person. The same is true of a couple other teams at ONE/Northwest. We hear constantly that the remote team members don’t feel connected to the group. Charlie’s identification of the problem rings very true.

The concept of ditching non-Internet communication in support of the team-dynamic is a very interesting one. It maps very well to the local protocol vs. IP decision–I think that’s an astute and thought provoking comparison. I remember how much I came to loathe NETBIOS when I was in IT. It was great for local communication, but when we added multiple offices connected by the Internet it was clear NETBIOS didn’t scale.

Is it worth ditching voice conversations because they aren’t accessible to remote team members? I’m not sold yet that it’s worth it. Remote teams can do amazing things, that is true. But aren’t local teams better? Communication just seems easier and has so much more density in person. The Internet has made impossible things possible, but I don’t think in my situation it’s worth the trade-off yet.

Thanks, Charlie, for such a great frame in which to think about the problem!

Sonny Cloward spotted this in the S-Control editing interface:

S-controls have been superseded by Visualforce pages. Salesforce will, sometime after January 2010, remove the ability to create and distribute new s-controls. Existing s-controls will be unaffected.

At Dreamforce it was made clear that this technology is on the way out. S-Controls are being replaced by VisualForce. I have gushed about VisualForce in the past. I think that it is a design marvel–the balance of simplicity and power continues to blow me away. The more I use it, the more impressed I am.

But with all it’s power and simplicity, VisualForce currently can’t do everything that S-Controls can do.

S-Controls run in your browser and use the API when communicating with Salesforce. How many interactions they can do with Salesforce are limited by the number of API calls your organization can make and by the amount you can ge done before your browser connection times out. You can actually get a lot of data processing done this way.

VisualForce is light-years ahead of S-Controls in how it works. It hands all the Salesforce heavy lifting to Apex, which runs on the server. This is a great idea–why send all that data across the wire to you only to send it back to Salesforce? Theoretically, you could process a whole lot more on the server and get very fast response. But, because the server is a shared resource, there are operational limits to the amount of processing you can do. These limits are hard and fast, and haven’t budged since Apex was announced two years ago.

There are a number of use cases where I can’t get VisualForce to do what S-Conrols can do for me. One such use case is when you are trying to compare two lists of data and look for similarities. Like comparing the Campaign Memberships of two Campaigns, or looking at all Campaign Members on a Campaign and flagging all the Accounts that are represented more than once. I can’t figure out how to use VisualForce and Apex to handle these kinds of operations that may be comparing lists of 1000+ members.

I’m all for killing S-Controls–I haven’t written a new one in over a year, it seems. But I have some that I haven’t re-written as VisualForce, because I can’t replicate the functionality. I hope that before S-Controls are killed, VisualForce can do the kinds of processing that S-Controls can do, and more. I hope Salesforce.com figures out how to take the operational shackles off VisualForce and Apex in a way that good coders can use to do much more intensive processing than is currently possible.

[Update]: Via twitter, Simon Fell reminded me that VisualForce pages can interact directly with the API. I’d rather be able to use Apex to touch 5000 records, but nice to have this option. Thanks Simon!

Tanner Shamrock (best blogger name ever) wrote up how to put Salesforce’s Advanced Search on the sidebar last October. He just posted the simple instructions of how to set it up for yourself. It’s a really easy install and if you use Advanced Search, I think you’ll love it.

I’m building a system for sending out daily emails to Contacts that uses Time-Based Workflow. We’ve done some work in this area before, but now it’s really starting to come together.

In this example, Contacts are added to a Campaign that is configured with a number of planned email sends. Once the Email Series is kicked off, the Contacts will receive emails on the determined schedule. This example uses hard dates for the individual sends–we’ve also got working code that sends out emails on interval from the individual Contact’s campaign join date. That allows for open-enrollment to an Email Series.

Check out the example, I’m very happy with it. Check out the background noise–we sound like a CRM sweatshop!

Loved this transcript from Bruce Sterling. Wide-ranging synthesis with a great look backward and some good ideas for moving forward. Worth the read.