techcafeteria

Techcafeteria Blog

Does Your Data have a Bad Reputation?

notepad.jpgPhoto by StarbuckGuy

As you probably know, the U.S. Congress has been having a big debate about what went on behind closed door briefings on the treatment of detainees in the war on terrorism. At issue is whether House Leader Nancy Pelosi was told about the use of harsh interrogation tactics, which many of us define as torture, in 2002 and 2003 briefings, when the tactics were actually in use. Rep. Pelosi maintains that they weren’t discussed; The CIA, responsible for the briefings, maintains that they were, but neither of them has yet provided documentation that might settle the matter. Meanwhile, Rep. Pelosi’s Democratic colleague, Rep. Bob Graham, who, as head of the Senate Intelligence Committee, was also to be briefed on such actions, reports that the CIA’s assertions are in error. Dates that they claim he was in briefings on the subject are wrong. His his meticulous notes, which he has traditionally been kidded about keeping, establish that only one of four CIA-alleged meetings actually occurred, and, in it, the harsh interrogation tactics weren’t discussed.

At this point, you might well be asking why I’m bringing this up on the Idealware blog. And the answer is, because it’s about data, or, more to the point, the integrity of data and data keeping systems, and that’s a topic close to our hearts here at Idealware. This example was inspired by some great reporting by the frivously-named, but thought-provoking blog BoingBoing, and a post of theirs on May 21st titled “Bob Graham’s much-scoffed-at little notebooks are more reliable than the CIA’s records“. They quote Gary Wolf’s post (which I highly recommend reading) about the intriguing fact that the CIA backed off of their record keeping claims rather quickly upon learning that they didn’t jibe with Graham’s personal notes. Consider this for a minute: Bob Graham’s personal note-taking has more authority than the record keeping of the Central Intelligence Agency. The killer line from Wolf’s post is:

“Personal data, kept by a dedicated and interested party, even using yesterday’s technology, will trump large scale collection systems managed by bureaucrats.”

You can find some really excellent advice here at Idealware on what to buy and how to implement the software that will manage the critical information that your organization lives and dies by. You can spend hundreds of thousands of dollars deploying it. But it, too, might be outclassed by the scribbling of a person who’s scribble-keeping habits are far less impeachable (to keep the political allegory going) than the data integrity securing processes that you build around your system.

When you deploy that software, one thing to consider is “who owns this data? Who has the most respect for it?”. Distribute the data entry duties in ways that insure that the people who first put that data into the system care about it, and are invested in seeing that it goes in correctly. Then, integrate your systems in ways that eliminate duplicate entry of that data. Set up triggers that push data from the authoritative systems of record (the ones that the people who care enter the data into) to the auxiliary systems, insuring that no donor or client’s name is misspelled one place, but correct in another; and that a $50 donation via the web site isn’t recorded as a $500 entry in your donor database.

Doing this will insure that your data-keeping systems have the upstanding reputations that your organization depends on.

Share/Save/Bookmark

The Road to Shared Outcomes

At the recent Nonprofit Technology Conference, I attended a somewhat misleadingly titled session called “Cloud Computing: More than just IT plumbing in the sky“. The cloud computing issues discussed were nothing like the things we blog about here (see Michelle’s and my recent “SaaS Smackdown” posts). Instead, this session was really a dive into the challenges and benefits of publishing aggregated nonprofit metrics. Steve Wright of the Salesforce Foundation led the panel, along with Lucy Bernholz and Lalitha Vaidyanathan. The session was video-recorded; you can watch it here.

Steve, Lucy and Lalithia painted a pretty visionary picture of what it would be like if all nonprofits standardized and aggregated their outcome reporting on the web. Lalithia had a case study that hit on the key levels of engagement: shared measurement systems; comparative performance measurement and a baked in learning process. Steve made it clear that this is an iterative process that changes as it goes—we learn from each iteration and measure more effectively, or more appropriately for the climate, each time.

I’m blogging about this because I’m with them—this is an important topic, and one that gets lost amidst all of the social media and web site metrics focus in our nptech community. We’re big on measuring donations, engagement, and the effectiveness of our outreach channels, and I think that’s largely because there are ample tools and extra-community engagement with these metrics—every retailer wants to measure the effectiveness of their advertising and their product campaigns as well. Google has a whole suite of analytics available, as do other manufacturers. But outcomes measurement is more particular to our sector, and the tools live primarily in the reporting functionality of our case and client management systems. They aren’t nearly as ubiquitous as the web/marketing analysis tools, and they aren’t, for the most part, very flexible or sophisticated.

Now, I wholly subscribe to the notion that you will never get anywhere if you can’t see where you’re going, so I appreciate how Steve and crew articulated that this vision of shared outcomes is more than just a way to report to our funders; it’s also a tool that will help us learn and improve our strategies. Instead of seeing how your organization has done, and striving to improve upon your prior year’s performance, shared metrics will offer a window into other’s tactics, allowing us all to learn from each others’ successes and mistakes.

But I have to admit to being a bit overwhelmed by the obstacles standing between us and these goals. They were touched upon in the talk, but not heavily addressed.

  • Outcome management is a nightmare for many nonprofits, particularly those who rely heavily on government and foundation funding. My brief forays into shared outcome reporting were always welcomed at first, then shot down completely, the minute it became clear that joint reporting would require standardization of systems and compromise on the definitions. Our case management software was robust enough to output whatever we needed, but many of our partners were in Excel or worse. Even if they’d had good systems, they didn’t have in-house staff that knew how to program them.

  • Outcomes are seen by many nonprofit executives as competitive data. If we place ours in direct comparison with the similar NPO down the street, mightn’t we just be telling our funders that they’re backing the wrong horse?

  • The technical challenges are huge—of the NPOs that actually have systems that tally this stuff, the data standards are all over the map, and the in-house skill, as well as time and availability to produce them, is generally thin. You can’t share metrics if you don’t have the means to produce them.

A particular concern is that all metrics are fairly subjective, as can happen when the metrics produced are determined more by the funding requirements than the NPO’s own standards. When I was at SF Goodwill, our funders were primarily concerned with job placements and wages as proof of our effectiveness. But our mission wasn’t one of getting people jobs; it was one of changing lives, so the metrics that we spent the most work on gathering were only partially reflective of our success – more outputs than outcomes. Putting those up against the metrics of an org with different funding, different objectives and different reporting tools and resources isn’t exactly apples to apples.

The benefits of shared metrics that Steve and crew held up is a worthwhile dream, but, to get there, we’re going to have to do more than hold up a beacon saying “This is the way”. We’re going to have to build and pave the road, working through all of the territorial disputes and diverse data standards in our path. Funders and CEOs are going to have to get together and agree that, in order to benefit from shared reporting, we’ll have to overcome the fact that these metrics are used as fodder in the battles for limited funding. Nonprofits and the ecosystem around them are going to have to build tools and support the art of data management required. These aren’t trivial challenges.

I walked into the session thinking that we’d be talking about cloud computing; the migration of our internal servers to the internet. Instead, I enjoyed an inspiring conversation that took place, as far as I’m concerned, in the clouds. We have a lot of work to do on the ground before we can get there.

Share/Save/Bookmark

Earthjustice Blogging

In addition to my weekly Idealware posts, which are reprinted here at Techcafeteria,, I also contribute to my organization’s blog at http://unearthed.earthjustice.org.  Here are links to my two recent items there:

How Technology Might Shape the Future of Our Cities is basically a tribute to Mitchell Joachim, a particularly visionary scientist/architect/artist who has brilliant ideas about how we might make our urban centers eco-friendly.

Flying in Place: Videoconferencing is basic advice about what to look for in videoconferencing software, a potentially green investment.

Share/Save/Bookmark

The Silo Situation


The technology trend that defines this decade is the movement towards open, pervasive computing. The Internet is at our jobs, in our homes, on our phones, TVs, gaming devices. We email and message everyone from our partners to our clients to our vendors to our kids. For technology managers, the real challenges are less in deploying the systems and software than they are in managing the overlap, be it the security issues all of this openness engenders, or the limitations of our legacy systems that don’t interact well enough. But the toughest integration is not one between software or hardware systems, but, instead, the intersection of strategic computing and organizational culture.

There are two types of silos that I want to discuss: organizational silos, and siloed organizations.

An organizational silo, to be clear, is a group within an organization that acts independently of the rest of the organization, making their own decisions with little or no input from those outside of the group. This is not necessarily a bad thing; there are (although I can’t think of any) cases where giving a group that level of autonomy might serve a useful purpose. But, when the silo acts in an environment where their decisions impact others, they can create long-lived problems and rifts in critical relationships.

We all know that external decisions can disrupt our planning, be it a funders decision to revoke a grant that we anticipated or a legislature dropping funding for a critical program. So it’s all the more frustrating to have the rug pulled out from under us by people who are supposed to be on the same team. If you have an initiative underway to deploy a new email system, and HR lays off the organizational trainer, you’ve been victimized by a silo-ed decision. On the flip side, a fundraiser might undertake a big campaign, unaware that it will collide with a web site redesign that disables the functionality that they need to broadcast their appeal.

Silos thrive in organizations where the leadership is not good at management. Without a strong CEO and leadership team, departmental managers don’t naturally concern themselves with the needs of their peers. The expediency and simplicity of just calling the shots themselves is too appealing, particularly in environments where resources are thin and making overtures to others can result in those resources being gladly taken and never returned. In nonprofits, leaders are often more valued for their relationships and fundraising skills than their business management skills, making our sector more susceptible to this type of problem.

The most damaging result of operating in this environment is that, if you can’t successfully manage the silos in your organization, then you won’t be anything but a silo in the world at large.

We’ve witnessed a number of industries, from entertainment and newspapers to telephones and automobiles, as they allowed their culture to dictate their obsolescence. Instead of adapting their models to the changing needs of their constituents, they’ve clung to older models that aren’t relevant in the digital age, or appropriate for a global economy on a planet threatened by climate change. Since my focus is technology, I pay particular attention to the impacts that technological advancement, and the accompanying change in extra-organizational culture (e.g., the country, our constituents, the world) have on the work my organization does. Just in the past few years, we’ve seen some significant cultural changes that should be impacting nonprofit assumptions about how we use technology:

  • Increased regulation on the handling of data. We’re wrestling with the HIPAA laws governing handling of medical data and PCI standards for financial data. If we have not prioritized firewalls, encryption, and the proper data handling procedures, we’re more and more likely to be out of step with new laws. Even the 990 form we fill out now asks if we have a document retention plan.

  • Our donors are now quite used to telephone auto attendants, email, and the web. How many are now questioning why we use the dollars they donate to us to staff reception, hand write thank you notes, and send out paper newsletters and annual reports?

  • Our funders are seeing more available data on the things that interest them everywhere, so they expect more data from us. The days of putting out the success stories without any numbers to quantify them are over.

Are we making changes in response to these continually evolving expectations? Or are we still struggling with our internal expectations, while the world keeps on turning outside of our walls? We, as a sector, need to learn what these industrial giants refused to, before we, too, are having massive layoffs and closing our doors due to an inability to adapt our strategies to a rapidly evolving cultural climate. And getting there means paying more attention to how we manage our people and operations; showing the leadership to head into this millennia by mastering our internal culture and rolling with the external changes. Look inward, look outward, lead and adapt.

Share/Save/Bookmark

SaaS and Security

My esteemed colleague Michelle Murrain lobbed the first volley in our debate over whether tis safer to host all of your data at home, or to trust a third party with it. The debate is focused on Software as a Service (SaaS) as a computing option for small to mid-sized nonprofits with little internal IT expertise. This would be a lot more fun if Michelle was dead-on against the SaaS concept, and if I was telling you to damn the torpedos and go full speed ahead with it. But we’re all about the rational analysis here at Idealware, so, while I’m a SaaS advocate and Michelle urges caution, there’s plenty of give and take on both sides.

Michelle makes a lot of sound points, focusing on the very apt one that a lack of organizational technology expertise will be just as risky a thing in an outsourced arrangement as it is in-house. But I only partially agree.

  • Security: Certainly, bad security procedures are bad security procedures, and that risk exists in both environments. But beyond the things that could be addressed by IT-informed policies, there are also the security precautions that require money to invest in and staff to support, like encryption and firewalls. I reject the argument that the data is safer on an unsecured, internal network than it is in a properly secured, PCI-Compliant, hosted environment. You’re not just paying the SaaS provider to manage the servers that you manage today; you’re paying them to do a more thorough and compliant job at it.

  • Backups: Many tiny nonprofits don’t have reliable backup in place; a suitable SaaS provider will have that covered. While you will also want them to provide local backups (either via scheduled download or regular shipment of DVDs), even without that, it’s conceivable that the hosted situation will provide you with better redundancy than your own efforts.

  • Data Access: Finally, data access is key, but I’ve seen many cases where vendor licensing restricts users from working with their own data on a locally installed server. Being able to access your data, report on it, back it up, and, if you choose, globally update it is the ground floor that you negotiate to for any data management system, be it hosted or not. To counter Michelle, resource-strapped orgs might be better off with a hosted system that comes with data management services than an internal one that requires advanced SQL training to work with.

Where we might really not see eye to eye on this is in our perception of how ‘at risk” these small nonprofits are, and I look at things like increasing governmental and industry regulation of internal security around credit cards and donor information as a time bomb for many small orgs, who might soon find themselves facing exorbitant fines or criminal charges for being your typical nonprofit, managing their infrastructure on a shoestring and, by necessity, skimping on some of the best practices. It’s simple – the more we invest in administration, the worse we look in our Guidestar ratings. In that scenario, outsourcing this expertise is a more affordable and reliable option than trying to staff to it, or, worse, hope we don’t get caught.

But one point of Michelle’s that I absolutely agree with is that IT-starved nonprofits lack the internal expertise to properly assess hosting environments. In any outsourcing arrangement, the vendors have to be thoroughly vetted, with complete assurances about your access to data, their ability to protect it, and their plans for your data if their business goes under. Just as you wouldn’t delegate your credit card processing needs to some kid in a basement, you can trust your critical systems to some startup with no assurance of next year’s funding. So this is where you make the right investments, avail yourself of the type of information that Idealware provides, and hire a consultant.

To me, there are two types of risk: The type you take, and the type you foster by assuming that your current practices will suffice in an ever-changing world (more on this next week). Make no mistake, SaaS is a risky enterprise. But managing your own technology without tech-savvy staff on hand is something worse than taking a risk – it’s setting yourself up for disaster. While there are numerous ways to mitigate that, none of them are dollar or risk free, and SaaS could prove to be a real bang for your buck alternative, in the right circumstances.

Share/Save/Bookmark

Technology and Risk: Are you Gathering Dust?

Last week I had the thrill of visiting a normally closed-to-the-public Science Building at UC Berkeley, and getting a tour of the lab where they examine interstellar space dust collected from the far side of Mars. NASA spent five or six years, using some of the best minds on the planet and $300,000,000, to develop the probe that went out past Mars to zip (at 400 miles a second) through comet tails and whatever else is out there, gathering dust. The most likely result of the project was that the probe would crash into an asteroid and drift out there until it wasted away. But it didn’t, and the scientists that I met on Saturday are now using these samples to learn things about our universe that are only speculative fiction today.

So, what does NASA know that we don’t about the benefits of taking risks?

In my world of technology management, it seems to be primarily about minimizing risk. We do multiple backups of critical data to different media; we lock down the internet traffic that can go in and out of our network; we build redundancy into all of our servers and systems, and we treat technology as something that will surely fail if we aren’t vigilant in our efforts to secure it. Most of our favorite adages are about avoiding risk: “It it ain’t broke, don’t fix it!” and “Nobody was ever fired for buying IB.. er, MicroSoft.”

On Monday, I’ll be presenting on my chapter of NTEN’s Book “Managing Technology to Meet Your Mission” at the Nonprofit Technology Conference in San Francisco. My session, and chapter, is about mission-focused technology planning and the art of providing business-class systems on a nonprofit budget. That’s certainly about finding sustainable and dependable options, but my case is that nonprofits, in particular, need to identify the areas where they can send out those probes and gamble a bit. For many nonprofits, technology planning is a matter of figuring out which systems desperately need upgrading and living with a lot of systems and applications that are old and semi-functional. My case is that there’s a different approach: we should spend like a regular business on the critical systems, but be creative and take risks where we can afford to fail a bit, on the chance that we’ll get far more for less money than we would playing it “safe” with inadequate technology. It’s a tough sell, yes, but I frame it in my belief that, when your business is changing the world, your business plan has to be bold and creative. As I mention often, the web is, right now, a platform rife with opportunity. We will miss out on great chances to significantly advance our missions if we just treat it like another threat to our stability.

We need stable systems, and we often struggle with inadequate funding and the technical resources simply to maintain our computer systems. I say that, as hard as that is, we need to invest in exploration. It’s about maximizing potential at the same time as you minimize risk. And its all about the type of dust that you want to gather.

Share/Save/Bookmark

NTC (Just) Past and Future

Photo by Andrew J. Cohen of Forum1Photo by Andrew J. Cohen of Forum1

Here it is Saturday, and I’m still reeling from the awesome event that was the Nonprofit Technology Conference, put on by org of awesomeness NTEN. First things first, if you attended, live or virtually, and, like me, you not only appreciate, but are pretty much astounded by the way Holly, Anna, Annaliese, Brett and crew get this amazing event together and remain 100% approachable and sociable while they’re keeping the thing running, then you should show your support here.

We had 1400 people at the sold-out event, and if that hadn’t been a capacity crowd, I’m pretty sure we had at least 200 more people that were turned away. What does that say about this conference in a year when almost all of us have slashed this type of budget in response to a dire economic situation? I think it says that NTEN is an organization that gets, totally, and phenomenally, what the web means to cash-strapped, mission-focused organizations, and, while we have all cut spending, sometimes with the painful sacrifice of treasured people and programs, we know that mastering the web is a sound strategic investment.

Accordingly, social media permeated the event, from the Clay Shirky plenary, to the giant screen of tweets on the wall, and the 80% penetration of social media as topic in the sessions. As usual, I lit a candle for the vast majority of nonprofit techies who are not on Twitter, don’t have an organizational Facebook page, and, instead, spend their days troubleshooting Windows glitches and installing routers. My Monday morning session, presented with guru Matt Eshleman of CITIDC, was on Server Virtualization. If you missed it, @jackaponte did such a complete, accurate transcription, and you can feel like you were there just by reading her notes (scroll down to 10:12) and following along with the slides.

My dream—which I will do my best to make reality—is that next year will include a Geek Track that focuses much harder on the traditional technology support that so many NPTechs need. I stand on record that I’m willing to put this track together and make it great!

I was also quite pleased to do a session on How to Decide, Planning and Prioritizing, based on my chapter of NTEN’s book, Managing Technology to Meet Your Mission.  It was really great to start the session with a question that I’ve always dreamed I’d be able to ask: “Have you read my book?”.  I’m in debt to NTEN for that opportunity!

The biggest omission at this event (um, besides reliable wifi, but what can you do?) was the addition of a twitter name space on our ID badges. Twitter provided a number of things to the—by my estimation—half of the attendees who hang out there.

  • Event anticipation buildup, resource sharing, session coordination and  planning, ride and room sharing and other activities were all rife on Twitter as the conference approached.

  • Session tweeting allowed people both in other sessions and at home to participate and share in some of the great knowledge shared.

  • For me, as a Twitter user who has been on the network for two years and is primarily connected to NTEN members, Twitter did something phenomenal. Catching up with many of my “tweeps”, we just skipped the formalities and dived into the conversations. So much ice is broken when you know who works where, what they focus on in their job, if they have partners and/or kids, what music tastes you share, that catching up in person means diving in deeper. The end result is clear—#09ntc is still an active tag on Twitter, and the conference continues there, and will continue until it quietly evolves into #10ntc.

One thing, however, worries me. This was the tenth NTC, my fifth, but it was the first NTC that the online world noticed. Tuesday, on Twitter, we were the second most popular trend (the competing pandemic outranked us). NTEN’s mission is to help nonprofits use technologies to further their missions. But, as said above, this conference was, in many ways, a social media event. I’m hoping that Holly and crew will review their registration process next year to insure that early spots in what is sure to be an even more popular event aren’t filled up by people who really aren’t as committed to changing the world as they are to keeping up with this trend.

But, concerns aside, we need to send that team to a week-long spa retreat, and be proud of them, and proud of ourselves for not only being a community that cares, but being one that shares. I urge even the most skeptical of you to jump on the Twitter bandwagon, we’re not on there discussing what we had for breakfast. We’re taking the annual event and making it a perpetual one, with the same expertise sharing,  querying, peer support and genuine camaraderie that makes the nptech community so unique – and great. Come join us!

Share/Save/Bookmark

How to Send an All Staff Technical Email

I had big plans for another insightful, deep, break-down-the-walls-of-the-corporate-culture-that-diminishes-use-of-technology post today, but I think I’m gonna save it for a rainy day and write something a bit more useful, instead.  I have a big nonprofit technology conference coming up this weekend, as you might, as well, and I think we should all be resting up for it.

The most important skill for any IT staff person to have is the ability to communicate.  All of the technical expertise in the world has little value without it, because, if you can’t tell people what you’re doing, what you’re doing won’t be well-received.  And there is an art, particularly with tech, to telling people what you’re doing, whether it’s taking the system down for maintenance of upgrading staff from Notepad to Office 2007.

Here are my five rules for crafting an technical email that even my most computer-phobic constituents will read:

  1. Let no acronym go unexplained.

    The simplest, worst mistake that techies regularly make is to tell people that

    “The internet will be down while we reconfigure the DHCP server” or

    “The database will be unavailable while we replace the SCSI backplane”.

    Best practice is to avoid the technical details in the announcement, if possible.  But if it’s relevant, speak english: “In order to accommodate the growth of our staff, we need to reconfigure the server that assigns network resources to each system to allow for more connections.”

  2. Be clear, concise and consistent in your subjects

    Technical messages should have easily recognizable subjects, so that staff can quickly determine relevance.  If your message is titled “Technical Information”, it might as well be titled “You are getting sleepy…”  But, if it’s titled “Network Availability” or “Database Maintenance Scheduled”, your staff will quickly figure out that these are warnings that are relevant to them. Don’t worry about the Orwellian aspect of announcing system downtime with a message about availability.  The point here is that using the consistent phrasing will grab staff’s attention far more effectively than bolding, underlining and adding red exclamation points to the email (see rule 4).

  3. Keep it short and simple

    It’s about what the staff needs to know, not what you’d like to tell them.  So, the network maintenance email should not read:

    “The systems will be down from 4:30 to 9:00 tonight while we replace drives in the domain controllers and run a full defrag on the main document server”

    It should read:

    “The network will be unavailable from 4:30 pm until 9:00 pm while we perform critical maintenance”.

    If it’s only a portion of the network, but something useful will be up – as when the file servers are being repaired, but email is still available, make a note of that: “While the main servers will not be available, you will still be able to send and receive email”.

  4. No ALL CAPS, no exclamation points and go sparingly on the bold

    System downtime might be urgent to you, but it’s never urgent to the staff.  It’s a fact of life.  A reply from the Director of Online Giving that the downtime will jettison a planned online campaign is urgent; not your routine announcement.

  5. Tell the whole story

    ...even if this sounds like it conflicts with rule 3.  Because there are two types of people on your staff:

    • The majority, who want simple, non-techie messages as described above
    • The rest, who want the gory details, either so they can rest easy that you aren’t making anything up, or because they’re actually interested in what you’re up to.

    My approach is to do the simple message and, below it type, “Technical Details (optional reading)”.  In this section I might explain that we’re replacing the server that processes their network logins (I won’t use “DHCP” or “Domain Controller” if I can help it) or that we’re upgrading to the new version of Outlook.


The key concepts here are consistency, simplicity, and a focus on what impacts them regarding what you’re doing.  Stick to it and, miraculously, people might start reading your all staff emails.

Share/Save/Bookmark

The ROI on Flexibility

Non Profit social media maven Beth Kanter blogged recently about starting up a residency at a large foundation, and finding herself in a stark transition from a consultant’s home office to a corporate network. This sounds like a great opportunity for corporate culture shock. When your job is to download many of the latest tools and try new things on the web that might inform your strategy or make a good topic for your blog, encountering locked-down desktops and web filtering can be, well, annoying is probably way to soft a word. Beth reports that the IT Team was ready for her, guessing that they’d be installing at least 72 things for her during her nine month stay. My question to Beth was, “That’s great – but are they just as accommodating to their full-time staff, or is flexibility reserved for visiting nptech dignitaries?”

The typical corporate desktop computer is restricted by group policies and filtering software. Management, along with the techs, justify these restrictions in all sorts of ways:

  • Standardized systems are easier, more cost-effective to manage.

  • Restricted systems are more secure.

  • Web filtering maximizes available bandwidth.

This is all correct. In fact, without standardization, automation, group policies that control what can and can’t be done on a PC, and some protection from malicious web sites, any company with 15 to 20 desktops or more is really unmanageable. The question is, why do so many companies take this ability to manage by controlling functionality to extremes?

Because, in many/most cases, the restrictions put in place are far broader than is necessary to keep things manageable. Web filtering not only blocks pornography and spyware, but continues on to sports, entertainment, politics, and social networking. Group policies restrict users from changing their desktop colors or setting the system time. And the end result of using the standardization tools to intensively control computer usage results, most often, in IT working just as hard or harder to manage the exceptions to the rules (like Beth’s 72, above) than they would dealing with the tasks that the automation simplifies in the first place.

Restricting computer/internet use is driven by a management and/or IT assumption that the diverse, dynamic nature of computing is either a distraction or a problem. The opportunity to try something new is an opportunity to waste time or resources. By locking down the web; eliminating a user’s ability to install applications or even access settings, PC’s can be engineered back down to the limited functionality of the office equipment that they replaced, such as typewriters, calculators and mimeograph machines.

In this environment, technology is much more of a controlled, predictable tool. But what’s the cost of this predictability?

  • Technology is not fully appreciated, and computer literacy is limited in an environment where users can’t experiment.

  • Strategic opportunities that arise on the web are not noticed and factored into planning.

  • IT is placed in the role of organizational nanny, responsible for curtailing computer use, as opposed to enabling it./

Cash and resource-strapped, mission-focused organizations only need look around to see the strategic opportunities inherent in the web. There are an astounding number of free, innovative tools for activism and research. Opportunities to monitor discussion of your organization and issues, and meaningfully engage your constituents are huge. And all of this is fairly useless if your staff are locked out of the web and discouraged from exploring it. Pioneers like Beth Kanter understand this. They seek out the new things and ask, how can this tool, this web site, this online community serve our sector’s goals to ease suffering and promote justice? More specifically, can you end hunger in a community with a widget? Or bring water to a parched village via Twitter? If our computing environment is geared to stifle innovation at the cost of security, are we truly supporting technology?

As the lead technologist at my organization, I want to be an enabler. I want to see our attorneys use the power of the web to balance the scales when we go to court against far better resourced corporate and government counsel. In this era of internet Davids taking down Goliaths from the RIAA the the mainstream media, I don’t want my co-workers to miss out on any opportunities to be effective. So I need the flexibility and perspective to understand that security is not something that you maintain with a really big mallet, lest you stamp out innovation and strategy along with the latest malware. And, frankly, cleaning a case of the conflickr worm off of the desktop of an attorney that just took down a set of high-paid corporate attorneys with data grabbed from some innovative mapping application that our web-filtering software would have mistakenly identified as a gaming site is well worth the effort.

Flexibility has it’s own Return on Investment (ROI), particularly at nonprofits, where we generally have a lot more innovative thinking and opportunistic attitude than available budget. IT has to be an enabler, and every nonprofit CIO or IT Director has to understand that security comes at a cost, and that cost could be the mission-effectiveness of our organizations.

Share/Save/Bookmark

More RSS Tools: Managing Content with Pipes

I’m continuing with follow-up topics from my RSS article, Using RSS Tools to Feed your Information Needs. Last week, I discussed integrating content with websites, and this week I’m going to dive into one of the more advanced ways to work with RSS content. This gets a little geeky, but it really shows off some of the sophistication of this technology.

The article provides numerous examples of RSS sources, but all in the form of web sites, blogs and web services that offer you one or more streams of information. If you want to narrow your view beyond the feeds available on a site, say, because you are only interested in Idealware posts about CRM tools or the ones written by Steve Backman, then you need a tool that will refine your search. Alternatively, you might want to put a section containing news stories relevant to a particular issue on your site, but want some control over the sources, as well as the subject matter. For this amount of control over the content you retrieve, you want to use something like Yahoo! Pipes.

Pipes is an RSS mashup editor. It’s a tool that looks a bit like Microsoft’s Visio, where you drag boxes onto a grid and draw relationships between them. But it’s not a layout or flowcharting tool; instead, it’s a visual mapping and filtering tool that lets you identify sources and then apply rules to those sources before merging them into an aggregated feed. To break that down, let’s say that your goal is to either monitor talk about a bill, or, maybe, to publish a section on your web site titled “What they’re saying about bill 221b” (I made that bill up). You have identified eight blogs that have good posts on the subject, and these are blogs that you trust to properly represent the issues and not, in any way, malign or confuse your efforts.

In Pipes, you can select all eight as sources, and then set up a filter to block any posts that don’t reference “221b”. The resulting RSS feed—which you can then subscribe to our republish— will isolate the posts that are relevant to the bill from your selected sources.

For example, here’s that pipe that will allow you to skip Michelle, Heather, Paul, Laura, Eric and my posts and just see Steve’s:

Picture 2.png

Another, more advanced example: You have an organizational Twitter feed that you want to republish to your site But you only want to publish your posts, not your individual replies. In Twitter, a reply is always identifiable by the very first character, which will be an “@” sign. Twitter RSS items arrive in the format “yourtwitterid: tweet”, so any reply will start with “yourtwitterid: @”. Setting up a Yahoo Pipe filter to block any result with “: @” in the text will isolate your posts from the replies. You can add a “Regex” (e.g. Search/Replace) command to replace “yourtwittername:” with nothing in order to publish just the tweet. The pipe will look like this:

Picture 1.png

If you play with Pipes (Yahoo! ID required, otherwise free), I highly recommend starting with an example like mine or this one by Gina Trapani to get the feel of it. Save your pipe, and you can subscribe to it—it updates automatically, and you don’t have to make it public for it to work.

Google has it’s competing Google Mashups tool in private beta, and similar tools are popping up all over the web. I talk a lot about how RSS is the technology that allows us to manage the information on the web. Pipes let us refine it. It’s great stuff.

Look for more RSS talk on OPML files and Google Reader in my upcoming posts.

Share/Save/Bookmark