Everyone needs customization

Last Updated on Wednesday, 25 March 2009 07:31 Written by Steve Wednesday, 25 March 2009 07:31

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.

Multi-payment Opportunities

Last Updated on Thursday, 19 March 2009 11:35 Written by Steve Thursday, 19 March 2009 11:35

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

Watch it here.

Charlie Wood on remoteness

Last Updated on Monday, 9 March 2009 08:10 Written by Steve Monday, 9 March 2009 08:09

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!