|
[Printer Friendly Version]
The Side-Effect Principle: How Stakeholders Share Information as a Result of Other Goals
By Michael C. Gilbert, November 13, 2009
I'll be teaching a workshop on stakeholder-generated content next week, entitled "The Voice of Your Community". One of the key elements of that workshop is a clear vision of why people share information about themselves. This is a summary of that vision.
Why do people share information about themselves?
For those in the business of community building, organizing, research, or fundraising, this is an important question. The better the relevant information we have about our stakeholders, the better we do our job. But why would anyone want to help us do that?
If we have a deep alignment of interests with our stakeholders then there's no problem - they will give us the information for the same reasons we're collecting it. But that's rarely the case. They will share information if we have some sort of authority over them and we require it of them, though compliance due to fear is often a costly thing. On the other hand, maybe there can be a positive spin on it. If you have something they want, compliance may still be due to external rewards, but it's a happier affair all around. People will share information to compete with others and for trivial rewards and for all sorts of other reasons, but none of these are the inducements I want to explore today.
The single most important way in which people share information online is as a side effect of another activity.
Anyone reading this article does this many times a day, every day. You left a web server log entry when you came to this website. If you received an email from us, we have a record of that too. More personal information is shared every time you log in to any of a thousand web sites and web applications. The biggest example is all the information you give Google, just by using their tools. Take a look at their new Dashboard, if you want to get a sense of what they know about you (and if you want to delete any of it).
It's not like any of this information gathering is underhanded. (Not to say that there isn't underhanded information gathering online. It's just not what I'm exploring here.) In almost every case, sharing the information is simply an intrinsic part of what you do to get things done. If you want to look something up on Google, you have to type in search terms, thus leaving a record of your interests. If we want to send you an email newsletter, we have to keep a record of whether it bounced. In each case, maintaining or enhancing those records could improve the search service (by taking into account previous searches) or the email (by tracking whether you click through to read items and articles), but it's still a direct result of a task that is distinct from information sharing for its own sake.
This principle has been applied successfully in application design, particularly in the last decade as the Internet made network and communication centric applications both easier and more important. For example, many social services have costly reporting and record keeping requirements imposed on them by funders and regulators. Most social workers can tell you stories of burdensome paperwork, most of which involves re-entering or compiling information that was already recorded elsewhere in the conduct of their work. Software that's usable enough to empower the work itself (not a simple matter, of course) means that there is no need for the subsequent data entry. More generically, relationship management systems that require you to make an entry as to when you last emailed or called someone are a bit absurd. Email and phone calls are among the many examples of information that ought to be, in essence, self-documenting.
So, how do we go about generalizing this? How do we use this Side Effect Principle to improve our information gathering practices?
The first step is realization: admit the truth of the principle. Examine your own data-sharing behaviors. Chances are good that 90% of the data that you share online is a side effect. Chances are good that you are not excited about data entry for someone else's project, even if you are generally supportive of the project. Chances are good that, even if you've overcome that resistance once, in support of some project, you haven't kept the data current. Maybe 10% of the time there is an annoying data sharing hurdle you will accept on the way to some other goal, or you have an obligation of some kind to fulfill, but that hardly changes the overwhelming role of the Side-Effect Principle.
The second step is determination: commit yourself to managing your projects based on this principle. Can you do that? I've seen a number of clients admit that they themselves don't generally go out of their way to share data except as a result of some other personal objective, but then proceed to act as though all their stakeholders are an exception to the rule.
The third step is implementation: take steps toward understanding your stakeholders well enough to position yourself in an empowering way in their workflow. Maybe this will mean tapping into an existing flow by leveraging open data standards. Maybe it means building a tool to make something they are already doing easier or more effective. It probably means leveraging their existing interests, relationships, and communication. But even if you introduce your own inducements, the data sharing must always be intrinsic to the immediate objectives of the person doing the entering.
A lot more can be said about implementation. How do you go about learning enough about your stakeholders' existing interests, relationships, and workflows to do this? When do you decide that you're not well-positioned to use the Side-Effect Principle and must resort to less effective and less prominent means of encouraging data sharing? How do you go about calculating the value of the data you're gathering? And how do you develop your return on investment calculations for strategies that implement the Side-Effect Principle and those that don't?
But you're probably not yet at a place to ask those questions. You probably just need to ask yourself if your current data gathering strategies are swimming with the current, or against it. It might just be time to turn around.
|
RSS