I spoke recently for the Association Forum of Chicagoland on Business Intelligence. Afterwords I sat for a short interview on the topic of Business Intelligence.

As I watch the world financial crisis unfold, one contributing factor that has arisen is that there is a “lack of trust” among and between banks. In other words, because Bank A can’t trust what Bank B says about its solvency, Bank A won’t loan Bank B money. As a result, banks have stopped lending money to each other. And thus we have a credit crisis.

It struck me that this is a very good analogue to trust in your organization’s database. Many, many times, when I meet with clients or potential clients, one of the core challenges being faced is that of trust. Or more to the point, lack of trust in the database and the data it contains.

Recently I met with a mid-sized association (~30 staff) that is having some major challenges with their database. In the course of our discussions, it became clear that no one on staff really trusts any of the data in the database. Finance does not believe the numbers coming from membership. The events department has moved to a separate event registration system. The foundation went off and purchased its own database, even though the primary database could probably do everything they needed.

All because of a lack of trust.

And as a result, the organization is completely ineffective with their data management. Staff is frustrated, the executive director if frustrated, and nothing is improving.

I’ve written all over my blog and in articles about the need for business rules, documentation, and good training. All of these tools are a foundation for building trust in the database. Once you’ve lost that trust, it’s extremely difficult to get it back.

When discussing data management issues with clients I often hear “We want to be more efficient.”

Of course, we all want to be more efficient, but efficiency as a goal implies that you’re doing the right thing, just not in the right way. I would suggest that, quite often, we’re actually not doing the right things. Thus, doing the wrong things more efficiently won’t help us become more effective, just faster at doing the wrong things. Or as a friend of mine put it so indelicately, being more efficient with the wrong processes just means you’ll “suck faster.”

What we really want to focus on is effectiveness, not just efficiency.  So whever you hear someone say “We want to be more efficient,” your first response should be “Do you really want to be more efficient, or do you want to be more effective?”

I’ve posted a new article on my website, entitled “What’s Plaguing Associations 2008.”

Of course, if you’re already on my announcements list, you would have received notice of this new article right in your email box.

Not signed up yet? Sign up here.

At a recent ASAE Technical Section Council meeting, there was a lot of talk about benchmarking. One participant said his executive director is always asking for benchmarks from other organizations, to see (for example) if they’re spending the right amount of money in the right places.

In other forums, I’ll see people asking about membership retention rates or benchmarks for direct mail effectiveness. I’m here to tell you: stop asking that question. Benchmarking against other organizations doesn’t serve any purpose, because their goals may be different from yours.

Having said that, I do think you should have some form of benchmark (I prefer the term metrics) to measure where you are against where you want to be. Unfortunately, most of us don’t know where we want to be and thus don’t know what metrics we need to measure our progress.

For example, my clients will often ask what percentage of their budget they should spend on a new data management system. My response is always the same: that depends on what you want to accomplish. In this case, the metric is not some arbitrary percentage of the budget, but rather what your business objectives are for a new data management system. Once you know what you want to accomplish and price out a new system, you can then make a decision if the return justifies the investment.

When I work with clients on system selection (or when I’m presenting on this topic), I point out that one of the objectives of the process is to minimize the number of software demos we actually have to sit through.

Software demos are one of the most expensive steps in the system selection process, because they take a lot of time to prepare for, and require a lot of time from a lot of staff. When you calculate all the staff hours put into organizing and attending a software demonstration, the price runs up pretty quickly.

The second problem with too many software demos is that after seeing two or three, all of the products and demos start to run together. As one of my clients put it, “It’s like trying too many perfumes at the cosmetic counter.” And while I’m not prone to trying any perfume at the cosmetic counter, she’s exactly right. After about the third perfume, the smells all blend together, and you really have no idea which one you liked or didn’t. And so it is for software demos.

So if you’re working through the system selection process, be sure to minimize, as much as possible, the number of different software products you actually look at. You’ll come out smelling much better.

At the recent ASAE Technology Section Council meeting, Heidi Byerly of the Society for Human Resource Management (SHRM) made the following comment (and I paraphrase):

“The future of the CIO (chief information officer) is to become the chief process officer (CPO).”

I think that’s brilliant.

It is time for the chief information position to move away from technology (or information) toward process. Technology should be an enabler for helping us to better do our jobs. It’s a means to an end, not the end itself. And the key to success with most technology is process.  In my experience, how we are doing things (be it processing a membership order or renewal, or managing event registration) has as much impact (or more) as the technology we’re using to do it.

So let’s hope Heidi is right, and that more “technology” people start focusing on process.

It may be a cliche, but one of the most critical elements to the long-term success of your database is a high level of trust between you and your software vendor. You have to view your vendor as a partner in your success (and you a partner to their success). You can’t view the relationship as a zero-sum game where if you gain, they lose, and vice versa.

When a potential client calls me and tells me they’re interested in looking for a new association management system, one of the questions I ask them is which system they are currently working with and what kind of relationship they have with the vendor. Very frequently, I find that the level of trust between the association and the vendor has degraded to the point that the association doesn’t believe anything the vendor tells them. This is not the type of relationship you’re looking for.

So what is the key to a trusting relationship? Communication. My most successful clients are continually communicating with their vendor, letting them know what’s working, what’s not working, what new initiatives are taking place, and so on. And like all relationships, it isn’t all wine and rose. Sometimes there are very difficult discussions that have to occur, but most importantly, conversations are occurring. Both parties are talking. And they’re both focused on success.

Here’s a little more I had written about seven years ago.

There was a discussion on a users group listserver a few days ago about the pros and cons of centralized vs. decentralized data entry. The question was, should all staff be able to enter and correct data in the database, or should that function be restricted to just a few? Several people weighed in, and the majority seemed to be in favor of concentrating that work to a few people.

Centralizing data entry is the easy choice, which is why most favor it. While I see the attractiveness of concentrating the data entry management into the hands of just a few, I think it’s the wrong choice.
It’s easy because ultimately, data management is about personnel (or staff) management. That is, your data management is only as good as the people who are doing it. So if you have fewer people doing it, that’s fewer people you have to train, keep up-to-date, and check on. Simply, it’s fewer people to manage.

But I think the downside is worse. Here are just a few:

1. Data is processed more slowly. By definition, a concentration of the data entry processing is a bottleneck. For example, if I learn of an email address change today and have to forward it to the fortunate few who can make data changes, how long will it take for the change to take place? I know it’ll be a lot longer than if I had just made the change myself.
2. Non-data entry staff stop caring about the data. Ownership of the data, by definition, now belongs to the chosen few, which means those who are not responsible for data entry will eventually stop caring about the data. Or worse yet, when there are problems with the data (there always will be), guess who will get blamed?
3. Too many eggs in one basket. If you have only one or two people handling all the data entry, what do you do when those people are out sick, or worse yet, leave the company? There is little “bench strength” when data entry is centralized.

As I said, centralizing data entry is “easier” than decentralized, because in order for decentralized data entry to be effective, you have to have good documentation of business processes, good and continuous trainin, and diligent remediation with staff that aren’t “getting it.” You also have to have very clear rules about who can change what data.

I won’t kid you: It’s a lot of work. But the long-term benefits (e.g., cleaner data updated more quickly and more accurately, because fewer hands have touched it) make it worth it.

One of the most significant changes to occur over the past couple of years in database management is the idea that the database must be more customer-friendly. Prior to Al Gore inventing the internet, when associations considered which database they might use, the only audience to consider was staff. That is, how would staff interact with the database.

Of course, all of that has changed. As a result, when considering a new association management system, associations must now consider not only how the staff interacts with the database, but how members and customers will interact with it, as well.

What this means is there is a dynamic tension between making something flexible enough for staff, while making it easy enough for online customers to use the system without needing training. In my experience, some AMS vendors do this better than others, but all of them struggle with maintaining that balance.

So when evaluating new systems, you have to be aware of this tension and be sure to evaluate the system from both a staffer’s perspective as well as the perspective of your members and customers.