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.
[...] Here is the link to the post. Link [...]
Steve, I agree with you about customizations being critical to making a system usable and useful. I am also an advocate of keeping things simple. I think balance between the two is key.
I wonder if Keith Heller’s perspective on customizations is influenced by the old software model — the one where you had to worry about your customizations when the software was upgraded. We both know this is not something to worry about when customizing Salesforce.com, for example.
Reading between the lines, I think that might be what Keith is getting at–”Big C” customization. We shoot for the smallest customizations possible on top of tools that are really good at some core things. Agreed, balance is the key.
Like everything, the devil is in the details. And in your definition of customization vs. configuration.
I agree that everyone needs configuration. This is the “adjustments” natively supported by an application within an application-provided interface. These are usually learn-able and discoverable by an administrative user.
Configuration is still a very dangerous subject for most average buyers. By this I mean code and extensions that are usually done by specialists and NOT learnable or discoverable by admin users.
Salesforce and NetSuite and most modern cloud providers don’t break customizations on upgrade, however the actual mileage varies depending on how much of an edge case the customization is and the quality of the customizer.
So, in general, configuration is a yellow flag and customization is a red flag. But neither is intrinsically bad. Keith’s conclusion is right on: “Talk to people who have traveled the customization path and see if it paid off for them and was viable for the long term.”
One other point about customization: make sure there are at least 2 internal people who can make those (“small c”) customizations, rather than relying solely on outside consultants or the vendor who provided the software in the first place. If you don’t have that duplicate internal ownership, you’re going to be unhappy when the 1 person with the knowledge inevitably leaves the organization, or that vendor moves on to their next client.
I think the main problem we see with customization in Salesforce is that nonprofits tend to have very badly defined processes. A CRM system is only as good as the process it supports. An out of the box product on the other hand forces you to fit into it’s mold — which hopefully had some thought put into defining good business processes.
Once we see nonprofits switching CRMs over time — having already well defined processes — I think customization will become crucial for our sector. At present I think shared structure is a good way to introduce organizations to some semblance of good design, which is why the Starter Pack concept is so critical.
I mostly disagree. Energy spent on customization can usually be better spent on more important tasks.
I agree with everyone preferring customization. The results of customization is very effective, PWB. I insisted that even when I did project on CRM.