I’m at an interesting intersection in my career path. I just concluded eight years at a small, statewide health care reform nonprofit in Massachusetts called Community Partners. I was Technology & Strategy Director there. Like so many orgs around us, we went under a month ago due to the bad economy. Though I am sad to lose my wonderful co-workers, it was coming for a long time, so I was somewhat prepared. A long time ago, other organizations and foundations started asking me lots of technology questions. This has naturally parlayed into consulting.
At this juncture where I have a sense of what it's like to work in a small org and am also looking at and helping larger orgs and foundations to make decisions about tech and use it in smart ways, I’m thinking a lot about something I call "supported open source."
"How do I choose a CMS?" is one of the most frequent questions I get. "Should I go with a closed but well-supported system or should I venture out into the Badlands of Open Source?" There is another way! That is supported open source.
The perception is often that if you choose open source—even if you hire additional expertise to initially build your site—you have to have skills in-house to keep it going after launch. I think the perception that you're on your own with open source is one of the barriers to its adoption for many businesses and nonprofits. But there are companies and consultants that will stick around, long after your site is launched, to give you the help and support you need. And there are different ways of doing this based on your org's budget.
At Community Partners, we ran things on a shoestring. I build web sites, but I don't write custom PHP code. When we wanted to use a profile module to collect contact information from users on our Drupal site and sync it with our Access mailing list database (yes, I know... Old Skool...), I found the module. It didn't work right. This functionality was a priority for us, though. Luckily, we maintained a contractual relationship with a Drupal consultant who would help us out with our site when our budget allowed. We only paid him to help us when something was broken, or when we wanted a new feature we couldn't implement ourselves and we had the funds to do it.
Having someone you can pay to give you support only when you need it is clearly cheapest way to go. If you're rolling in money, however, having a company on-call 24-7 to support you with anything you need is the other end of the spectrum. And everything in between exists. I want to disclose here that at present, I have a paid relationship with a consulting firm called OpenIssue LLC, which offers a spectrum of services for open source CMS platforms. I am working with them because I am becoming increasingly convinced that supported open source is has some serious advantages for our sector.
I am dogmatic about not being dogmatic, and the needs and mission of an org should always determine what technology they choose, not the other way around. You're never married to a piece of software and you should change platforms if and whenever it serves you. But particularly during this time of economic uncertainty, there is something comforting to me about software that's being developed by a worldwide brain trust. Open source software can't be yanked out from under you if funds (temporarily) disappear, or if a contract expires, because we all own it.
Though this community code base can be messy, open source development specialists know how to clean it up for you. So you get that worldwide scope of innovation, plus the focused attention on your org's particular needs. For orgs that want to stay innovative but don't always have cash flow, this can be a great solution. Ongoing support can be stopped and re-started as needed when there are budget troubles.
I know of a few companies out there that explicitly offer ongoing support for open source platforms. My fave among these is PICnet. Non-Profit Soapbox is designed to be an affordable, fully hosted, software-as-a-service (SaaS) way for nonprofits to build sites quickly and easily in the Joomla! CMS. PICnet has been around for a long time, and honestly I don't know why more companies aren't offering open source SaaS for nonprofits. Seems like a great idea to me. Here are a couple more companies that offer ongoing support:
I predict more of these companies will emerge in the coming year, and I think it will be a great leap forward for our sector. Do you know of a company or a consultant that offers ongoing support for open source software platforms? If so, I'd love to know about them. Please add them in the comments.
Domain Name Management: not a very sexy topic. This will be a rare post for me that won't mention popular search engines, the latest "superphone", content management or rumored tablets. But I hope I can provide a good glossary on a geeky subject that anyone with a web site sporting their organization's name has to deal with.
You have a web site and you have a domain, and as long as the web site is up and running, everything is fine. But what happens if your domain is hijacked? What if you need to make changes to your domain registration, or register a new one, and your registrar is simply disinterested? What if they go out of business? Your domain name is a valuable property, and you should keep it in pro-active and trustworthy hands.
How Domain Registration Works
Domain registrars provide the service of keeping your domain name mapped with current information so that it can be found on the web. Domain names are meaningful aliases for numeric IP addresses, and aren’t technically required in order to host a web site. But, the internet would be hard to navigate if we could only find things by their numeric addresses.
The primary thing that a registrar does is to keep your contact (whois) data maintained; point your domain to the appropriate name servers; and allow you to move your domain to another registrar if you choose to.
Domain Services
In addition to domain registration, most registrars offer additional services, such as:
DNS Management (address mapping) for subdomains (which allows you to host your main domain on one server, but, perhaps, an online store called “store.yourdomain.com” on another server),
Aliasing of Addresses (so that both http://yourdomain.com and http://www.yourdomain.com go to the same place),
Backup Mail Handling, so, should your primary mail server go down, messages sent to you will be stored until they come back around;
Web Forwarding, so you can, say, register yourdomain.org, yourdomain,.com and yourdomain.net, but forward all visitors to the .com and .net sites to your website at yourdomain.org.
SSL (Secure Socket Layer) Certificates, to encrypt sensitive data, like online donation forms.
Things to Look For in a New Registrar
Are they accredited? ICANN, the organization that oversees domain management , accredits registrars. If they aren’t on ICANN’s list, they aren’t trustworthy.
Do they add a year to the existing expiration date, or charge you for a full year as of engagement? They should do the former.
Do they offer automated access to all functions (via web forms), including locking/unlocking domains, retrieval of authorization (EPP) codes, and modification of all whois records? (Some registrars prefer to list themselves as the technical contact. It should be up to you whether they can have an official name on your domain, not them).
Do they list a telephone number, and is it promptly answered during business hours?
Do they respond promptly to emails and support requests? The ability to communicate with your registrar is rarely needed, but, when it is, it’s critical - you don’t want them out of the loop if your domain is subject to an attempted hijack.
Do they offer the ability to manage DNS for mail servers and subdomains? While this is an added feature, it’s common enough to be worth expecting.
Do they have any additional services (examples above)? While these supplemental services are far from critical, they are convenient. More to the point, a company that is engaging in a robust suite of services is more likely to be focused on their business. The truth is that anyone can be a domain registrar, if they make the proper investment, but whether it’s a going concern or a neglected piece of extra income for them is a question you’ll want to ask.
Next week: Safely transferring domains and a word on web hosting completes the topic.
Ask most any developer what's the worst part of a software project and mostly likely you'll hear, “data conversion.” And what's most magical when working a project spec? “We're going to start fresh with new data.”
Reflecting back on the year gone by, clean or messy data migration definitely has a huge impact project success as a whole.
What makes the data migration part of a project so hard?
You look at old data on screen, in reports, or with tech specs. That's often all you get to look at before starting, and that's not enough to judge its true quality. You can't fully judge how well its going to work until you do real trials into the new system. And you can't really do that until you have that new system ready.
So here are painfully accumulated tips about data conversion. I'm writing this from the point of view of the “joint planning team”--lessons to both client and consultant/developer. And I'm not going to say which ones I have the most success sticking to. I'm doing this partly as therapy and partly as New Year's resolution. I promise to reread this myself on every new 2010 project.
Data conversion and the project plan
Do as much clean up as possible in the old system. The data will look familiar there, and staff who have to do it will be faster on the old.
Don't wait until the end. Put time in the schedule to for clean-up straight through the planning and configuration of the new. Reflect each decision about the new back to the old. Understand how you will get there and when the route can be opened.
It's often hard to reserve enough time for clean-up. Explore whether you can effectively use volunteers, interns, or temp staff to do routine clean up work instead of taking consultant project time to do it or burdening organizational staff beyond what is reasonable or essential for each side to do.
Data conversion and the budget
Here's a tough one: See if you take data conversion outside of the rest of the project estimate and work it as time and materials. That protects the consultant and focuses program manager attention on only doing as much as is necessary.
The fall-back choice is to allocate a specific, reasonable number of hours, say as a percent of the whole project, and agree that the consultant will do much and as best they can within that block of time, and no more.
Data conversion and "letting go"
A corollary to the last: Consider converting the essential top level stuff—the primary contact lists—and not all the historical details (all donation or membership history, services rendered, etc). The top level lists are often cleaner, easier to check, more essential, and less encumbered with old-to-new data structure changes.
For historical data you really do need, consider adding special new fields to summarize the old. For example, instead of importing an entire “trainings” history, can you live with aggregating “total workshops attended” for each contact? And remembering preferred training topics, how about just tagging the contact with “attended series A workshops” or “workshop B series”? You might be surprised how much headache this saves where the old data turns out not as clean as it now appears on screen.
Data conversion in stages
It frequently makes sense to plan on a data migration way station--a temporary clean-up and check-me database. It could be Excel, Access or something else that has strong query and reporting tools. Maybe all the status categories need to be remapped, or collected from three different current places. Maybe the notes field holds way more than notes and needs analysis
On the other hand, the new system may have fantastic clean up tools available, such as address correction and verification, or deduping. Maybe it specifically has importers for the old donor database you are moving form. Check them on sample data and use them where you can.
What about all the rest of the details of the old? If keeping the old system around does not incur licensing or hosting costs, why not just leave it up, frozen as an archive for historical data. Again, only convert what is really needed.
Data conversion and testing
Count on doing at least one trial conversion for staff to test before the day you go live. Once you have worked that into the plan, it makes sense to do it as soon as a trial version of the new software is up. Let folks test the new software with some real, existing data. It improves the testing and improves the data migration. And make sure you have put time on the calendar for that checking. Discovering gaps six months into a new system, say when quarterly or annual reports first have to run for real, really will mess things up.
Do have a series of benchmark queries to run on old and new system to quickly check results. For example, maybe the count of contacts by status group has to match exactly. Maybe the total dollar value of donations by year will not match 100% for this, that and the other reason. Make an agreement in advance, the new system will vary by as much as 3% earlier than the last two years.
Conversely, agree on a couple representative accounts you will use as a standard base line for checking the conversion. I remember one large scale donor management system with a huge master contact list mostly sparsely populated and just a handful with tons of details. Running overall lists just wouldn't cut it. Every step in the development process had to be run against one particular wealthy donor with a 28-page single spaced personal profile. Each new iteration of the software had to pass muster on him or it was back to the cubicles for us.
Data conversion documentation
Data conversions usually involve a lot of steps. List them out in a shared document and explain what each does. When you have a series of scripts that have to run, number them in order, like “step100_clear main contact table,” “step 200_import from spreadsheet xyz,” “step310_relink contacts table to database X_manual step,” step 315 _import from database x,” “step 400_run dedup query,” “step510_extract priority A people to excel and give to ED to check personally.” By putting that first step in there, you have already set things up for running the conversion process as a whole more than once. Get every step, manual or automated, in there. Consider counting by 10s at least so you insert more steps as you fine tune the overall process.
Use a shared Google doc or some other collaboratively editable document to hold the conversion steps. Even if your steps lean toward the technical, take the time to go through them collaboratively, understand what they mean, and sign off that this is the plan.
Data conversion therapy
Accept that data conversion has a therapeutic component. You can count on the staff person who is most impatient with the old system to miss data and procedures that don't show up exactly the same in the new. Hmm. My Tai Chi sensibility says maybe the framework is more meditation than therapy: it's all about grasping the essence firmly, remaining calm to find the path from the old to the new, and letting go of what you can.
And through it all, be reasonable and patient with each other. This means the organizational lead needs to look at the raw underbelly of the data and appreciate whatever is giving he consultant the most trouble. The consultant needs to sit with users and understand the consequences, workarounds, new ways of doing things if new data doesn't 100% line up with the old.
Data conversion sounds like such a mine field that you might ask, why would anyone ever agree to do it? Well, you often have to, to get the project at all. In addition, I have to say, data conversion does have a creative appeal. Its almost always unique. Unlocking old data is like unraveling a mystery. It requires real detective work. It requires knowledge of multiple systems, which takes time and experience to accumulate. If both sides agree to a reasonable plan, it is possible for all to find satisfaction and joy when the new reports line up with the old.
And speaking of the therapeutic and the meditative, just writing this has been both therapeutic and meditative for me. hope it helps you as well, and best wishes for the New Year.
Last week, I reported that Nonprofit assessors like Charity Navigator and Guidestar will be moving to a model of judging effectiveness (as opposed to thriftiness). The title of my post drew some criticism. People far more knowledgeable than I am on these topics questioned my description of this as a "sea change", and I certainly get their point. Sure, the intention to do a fair job of judging Nonprofits is sincere; but the task is daunting. As with many such efforts, we might well wind up with something that isn't a sea change at all, but, rather, a modified version of what we have today that includes some info about mission effectiveness, but still boils down to a financial assessment.
Why would this happen? Simple. Because metrics are numbers: ratios, averages, totals. It's easy to make metrics from financial data. It's very difficult to make them out of less quantifiable things, such as measuring how successfully one organization changed the world; protected the planet; or stopped the spread of a deadly disease.
I used to work for an org whose mission was to end poverty in the San Francisco Bay Area. And, sure enough, at the time, poverty was becoming far less prevalent in San Francisco. So could we be judged as successful? Could we grab the 2005 versus 2000 poverty statistics and claim the advances as our outcomes? Of course not. The reduction in poverty had far more to do with gentrification during the dotcom and real estate booms than our efforts. Poverty wasn't reduced at all; it was just displaced. And our mission wasn't to move all of the urban poor to the suburbs; it was to bring them out of poverty.
So the announcement that our ratings will now factor in mission effectiveness and outcomes could herald something worse than we have today. The dangerous scenario goes like this:
Charity Navigator, Guidestar, et al, determine what additional info they need to request from nonprofits in order to measure outcomes.
They make that a requirement; nonprofits now have to jump through those hoops.
The data they collect is far too generalized and subjective to mean much; they draw conclusions anyway, based more on how easy it is to call something a metric than how accurate or valuable that metric is.
NPOs now have more reporting requirements and no better representation.
So, my amended title: "We Need A Sea Change In The Way That Our Organizations Are Assessed".
I'm harping on this topic because I consider it a call to action; a chance to make sure that this self-assessment by the assessors is an opportunity for us, not a threat. We have to get the right people at the table to develop standardized outcome measurements that the assessing organizations can use. They can't develop these by themselves. And we need to use our influence in the nonprofit software development community to make sure that NPOs have software that can generate these reports.
The good news? Holly Ross of NTEN got right back to me with some ideas on how to get both of these actions going. That's a powerful start. We'll need the whole community in on this.
Here at Idealware, an organization that's all about nonprofit-focused software, we understand that the success or failure of a software project often has far more to do with the implementation than the application. So, in addition to discussing software, we talk a lot about project management. To many of us, it seems like the only thing worse than devoting our scant resources to the task of building and maintaining a complex project plan is living with the result of a project that wasn't planned. While I'm a big a fan as the next guy of PMP-certified, MS Project Ninja masters, and will argue that you need one if your project is to build a new campus or a bridge, I think there are alternate methodologies that can cover us as we roll out our CRMs and web sites, even though I know that these projects that will fail expensively without proper oversight.
The traditional project planning method starts with a Project Manager, who plays a role that fluctuates between implementation guru, data entry clerk and your nagging Mom when you're late for school. The PM, as we'll call her or him, gathers all of the projected dates, people, budget, and materials, then builds the house of cards that we call the plan. The plan will detail how the HR Director will spend 15% of her time on a series of scheduled tasks that, if they slip, will impact the Marketing Coordinator and the Database Manager's tasks and timelines. So the PM has to be able to quickly, intelligently, rewrite the plan when the HR Director is pulled away for a personnel matter, skewering those assumptions.
My take is that this methodology doesn't work in environments like ours, where reduced overhead, high turnover and unanticipated priorities are the norm. We need a less granular methodology; one that will bend easily with our flexible work conditions. Mind you, when you give up the detailed plan, you give up the certainty that every "i" will be dotted, every "t" crossed, and every outcome accomplished on schedule. But it's possible to still keep sight of the important things while sacrificing some of the structural integrity.
First, keep what is critical: clear goals, communication, engagement and feedback. The biggest risk in any project no matter how well planned, is that you'll end up with something that has little relation to what you were trying to get. You need clearly understood goals, shared by all internal and external parties. Each step taken must factor in those goals and be made in light of them. All parties who have a stake in the project should have a role and a voice in the plan, from the CEO to the data entry clerk. And everyone's opinion matters.
Read up on agile project management, a collaborative approach that is more focused on the outcomes than the steps and timeline to get there. Offload the project management by focusing on expectation management. The clearer the participants are about their roles and accountability for their contributions, the less they need to be managed. Take a look at the Cult of Done (their manifesto is at the top of this article). Sound insane? Maybe. More insane than spending thousands of dollars and hours on an over-planned project that never yields results? For some perspective, read The Mythical Man Month (or, at least, this Wikipedia article on it), a book that clearly illustrates how the best laid plans can go horribly wrong.
Finally, my advocacy for less stringent forms of project management should not be read as permission to do it haphazardly. Engagement in and attention to the project can't be minimized. I'm suggesting that we can take a more creative, less traditional approach in environments where the traditional approach might be a bad fit, and for projects that don't require it. There are a lot of judgment calls involved, and the real challenge, as always, is keeping your eye on the goals and the team accountable for delivering them.
In an earlier post, I talked about two challenges which fuel cloud computing: the capital and support costs of network infrastructures and desktop anarchy. I want to pick up here where I left off, with more discussion of three cloud computing opportunities.
Software as a Service probably has the most familiarity. The wispy tendrils of Software as a Service reached into my Thanksgiving this year. Usually, we don’t host, and this year we will. To reduce operational costs, frustrated with the support costs involved with email, I put the family invite list, arrival and departure logistics and food contributions up on doodle.com.
It’s off my desktop and phone system into their system--simple, collaborative, low cost, centrally maintained, reliably backed-up, eminently scalable (hopefully won’t need that for our thanksgiving), platform independent, secure (enough for this), environmentally sustainable (carbon offsets for how much we may eat).
Doodle is a light weight alternative to meetingwizard.com or more elaborate reservation systems, and though its light-weightedness caused some other problems, it helped.
Meanwhile, Linda tapped into foodie SaaS epicurious.com to supplement the menu planning. Yes, we also have the 3-ring binders of family recipes and a shelf of cookbooks. Epicurious (OK, I prefer allrecipes.com) brings a world of collaboration, search, on-demand, pay as you go to the meal planning type of project. Print magazine co-sponsor Gourmet magazine is about to close its doors, but no doubt SaaS Epicurious will continue.
Holiday photo-sharing? Facebook, Flickr, Google web albums and not bring-your-own laptop, flash drive or photo album.
At the consumer level, Google has championed this approach more than any other company. Google entices millions to leave the desktop behind and do our daily work with on Gmail, Google Documents, Calendar, YouTube, Maps, Groups and more. Yahoo and others add to the offerings.
Once you get comfortable, you may find yourself surrounding yourself with other services. You may well use a hosted pay as you go service like Basecamp, Zoho or Central Desktop to mange projects. You may use Mozy, Carbonite, Dropbox or other web based services for back-up. You may use webex, adobe connect, or logmein to provide hosted screen sharing or web conferencing services.
Going back ten years, at the corporate level, Salesforce championed the software as a service approach to managing contacts, leads, business relationships, and all things related to the sales process (and now support and other business functions). Instead of network installing Act, Goldmine, Microsoft stuff at the low end or Siebel and other systems at the high end, they invited customers to use their web service. Pay according to what you need month-to-month, and let them take care of security, back-up, support, upgrades and the like.
The SF foundation charitable donation and “starter pack” has extended Salesforce’s appeal to nonprofits as well.
As I suggested earlier, these types of services typically may get justified on cost basis. Specifically, they transform long term capital and human resources costs into operating expenses. Today’s recession favors this calculation. Instead of figuring out the total cost of ownership of a new server, new software, support costs, licensing, periodic version updates, desktop upgrades, back-up, security and other ancillary utility purchases, SaaS lets organizational planners focus on one thing—the monthly usage cost. They also favor collaborative approaches to getting things done that are not as easy or natural on traditional network installed systems.
As critical applications move up to the cloud, the desktop does not matter very much. All that matters is having a standard browser.
Yet, to get to those web software as a services, you still have you to boot up that familiar personal computer and land on your personal desktop. Google hopes to go further, turning its Chrome browser into an entire web-facing operating system. More about that another time.
For now, for most of us, the desktop still matters a lot. Most of us still do our daily work there—word processing, maybe email, maybe other stuff. It matters for installed donor and contact management systems, network accounting software, critical long time installed databases whether Microsoft Access or some giant client server application. It matters when you want to print, scan, archive, share files, and avoid malware all the while. When these issues come up, the costs in time and support in monitoring and managing desktops come into play.
IT as a service (or Infrastructure as a Service) looks at things from this end. If the premise of SAAS is to make the desktop matter less, with IT as a Service, the idea is to tame it.
IT as a service has levels and gradations. It often begins with combining and rationalizing network servers using virtualization. VMWare and other companies have popularized the idea of running mutual virtual machines on the same hardware. Many businesses and organizations today have more than one server. They may have a basic server for sharing files and printing. Another for Exchange email management. Another for their fund-raising software or other special applications. Virtualizing servers takes advantage of increased computing power to reduce the total number of servers, and focus on keeping those few up and running well.
A related trend is to centralize and standardize the user experience. You start up your machine and then connect via Microsoft Terminal Services or Citrix into central server which then gives you a new, fresh, controlled desktop. For larger companies, creating that standardized network infrastructure makes it easier to then have IT infrastructure specialists manage everything from afar using elaborate diagnostic tools such as Kasaya.
The higher level next step is to move the whole infrastructure up to the web. If everything is centralized, virtualized, standardized, why not seek even higher efficiencies of scales by running the whole operation on someone else’s servers, where bunches of other organizations also are getting managed at the same time in the same place.
Ask you local network support organization if they have this kind of offering and compare prices with what you are doing and planning now. I recently got a major taste of this approach at a day-long business summit run by Zumasys, a West Coast infrastructure company which has helped some of our larger clients, and I see other partners heading in this direction.
Of course, like SaaS, IT as a Service come at a cost. Both point in the direction of flexibly supporting organizational expansion, especially in a recessionary era, reducing support costs, and reducing user woes and problems, and also reducing the cost of a desktop computer.
The goal is usually not to reduce on-site IT staff, but to keep that staff from burning out and to keep it focused on strategic support and innovation. By commodifying basic support issues, IT staff can focus on what is critical and distinctive about what you need and do.
Sometimes it feels like the bane of my existence is my office phone. It's so bad that I rarely answer it, preferring to forward it to Google Voice where I can peruse the barely readable transcripts just well enough to filter out the 90% cold sales calls I receive. So what a pleasure it was to answer my desk phone on Thursday and have an illuminating conversation with my Microsoft Licensing representative. He called to tell me that I own some awesome benefits that come with my Software Assurance program. I'm betting that I'm not the only one who was clueless about these benefits.
Microsoft Licensing, as you know, is the little-known tenth circle of hell. It's a conceptual labyrinth of terms and conditions that was likely conceived by a team of the writers of the original "Prisoner" series with the advice of contract attorneys that graduated from law school 30 years ago and have never since seen the light of day.
Software Assurance is the tax we pay on our MicroSoft purchases that allows us to upgrade to the newest versions without paying upgrade fees (as long as we've paid our software assurance fees, of course). I assume that this is of interest to Idealware readers because most of us pick up a lot of our MS software from Techsoup Stock, and the Techsoup Stock donations come with Software Assurance, not without.
But Microsoft isn't evil; they're just bureaucratic, and every now and then a few smart people step up out of the morass and do things that I appreciate. These Software Assurance benefits include:
The Microsoft Home Use Program provides staff with ridiculously steep discounts on MS Office. Register this benefit, and the allowed number of users (which I'm unclear as to how they calculate) at your company can purchase MS Office 2007 Ultimate Edition (or Office 2008 for Mac) for $9.95. That's not a trial edition, and it's the opposite of crippled -- Ultimate is the "everything but the kitchen sink" edition and it comes with a license key.
Microsoft ELearning is a series of online classes in standard MS products like Word and Excel, and Server products like MS SQL Server or Windows 2003. I did note that the list of available classes that my rep sent me looked a little behind the times; no 2008 or 2010 products covered, but many of us aren't on the bleeding edge anyway.
Microsoft Technet gives you access to forums and experts, as well as evaluation copies of new technologies. For example, as I write this, I just learned that I can pick up Office 2010 and Sharepoint 2010 betas via my MSDN or Technet subscriptions to try.
This isn't fluff. We've been paying full price for Office at home (more than we do at work) and I've purchased E-Training on MS products and an MSDN subscription (fairly equivalent to Technet) because I had no idea that I already owned them. It makes me feel much better about what seemed like a pre-emptive insurance program that makes me commit to the next version of MS products before I'm ready to make that commitment, at times.
Of course, this is smart business for Microsoft. With Google announcing that their Google Apps offering will be on a feature par with Office within a year, and OpenOffice under active development as a pretty comparable alternative, you don't want your business customers to get too comfortable with those free alternatives at home. It's just surprising to me that, for years, this was buried in the small print section of eOpen, and not broadcast widely. So I'm doing MS a favor and blowing the horn on this one.
To access these benefits, log onto eOpen (which I hope you're using to manage MS licenses!) and once you've signed in and clicked "unhide licenses", find your last Techsoup order (or a similar large purchase) and open it up. The very first link in the license detail should be "Start and Manage your Software Assurance Benefits". Clicking on that will pop you to a paragraph that includes a link to the "Software Assurance Benefits Management Tool". Click on that to get the benefits. The more MS software you've bought, the more tedious this will be: there are benefits associated with each Software Assurance purchase, so you'll need to register this way for every relevant order. But it sure beats paying for these things at Best Buy!
Last week, I kicked off this series on setting up a basic web site with Drupal, the popular open source Content Management System. This week we're going to take a closer look at Modules, the Drupal add-ons that can extend your web site's functionality. One of the great things about Drupal is that it is a popular application with a large developer community working with and around it. So there are about a thousand modules that you can use to extend Drupal, covering everything from document management to payment processing. The good news: there's probably one that supports the functionality that you want to add to your web site. Bad news: needle in a haystack?
A potentially easier way to add extra functionality to Drupal is to download a customized version, such as CiviCRM or Open Atrium. We'll discuss those options later in the Drupal 101 series.
Core Modules
Drupal comes with a number of built-in modules that you can optionally enable. Some are obviously useful, others not so much. Here are some notes on the ones that you might not initially know that you need:
Primary content types like blog, forum and book offer different modules for user input. They can be combined, or you can pick one for a simple site. Since the differences between, say , a blog (individual journal that people can comment on) and a forum (topical posts that people can reply to) are less distinct than they are in other CMS's, you might want to pick one or two primary content types and then supplement them with more distinctive ones, such as polls or profiles.
Enabling contact allows your users to send private messages to each other on the site, as well as allowing you to set up site-wide contact forms.
OpenID allows your users more flexibility and control as to how they log into your site. I can't see a good reason not to enable this on a public site. Since more and more people have profiles on social networking sites and Google, tools like Facebook Connect or Google Friend Connect should be considered as well.
By default, Drupal asks new users for a name and email, but not much else. With the Profiles module, you can create custom fields and allow your users to share information much as they would on a social network.
Taxonomy is also recommended, and I'll talk more about that next week.
Throttle should be used on any high-traffic site to improve performance.
Use Trigger if you want to set up alerting and automation on your site.
More than some CMS's, Drupal is a content-centric system. It doesn't simply manage content, but the web interface is structured around the content it manages: content types, content metadata (taxonomies), content sources (RSS feeds). Out of the virtual box, Drupal has content types like blog entries, pages and stories. Each content type has a data entry form associated with it. So, if you create a number of stories, and you want to read them all, then you can browse to the page "story" and they'll all be listed there. CCK helps you create additional content types and use a fairly robust form-builder to customize the screens.
The Views module lets you customize the appearance and functionality of many of Drupal's standard screens, and to add your own. Unlike CCK, which is limited to the default layout of content types, Views lets you seriously customize the interface. One easy reason to install Views is in order to take advantage of the Calendar view, which gives you not only a full page, graphical calendar to add events to and display, but also sidebar calendar widgets and upcoming event lists.
Here's a tip: setting up the calendar view is reasonably tedious. The best write-up explaining it (for Drupal 6) is here: http://drupal.org/node/326061. Drupal's documentation is okay, but this is step-by-step. It does miss one step, though, which is to add the "Event Date - From date" and "Event Date - To date" to the Fields listing (with friendlier titles, like "From" and "To"). Otherwise, calendar items show on the day they were submitted instead of the day that they are occurring.
There's a good case to be made that these two modules should be folded into Drupal's base package, because, in addition to providing very powerful customization features to the core product, there are a whole slew of additional modules that require their presence. If you plan to install a number of modules and/or customize your site, these are pretty much pre-requisites, so just grab and install them.
What-You-See-Is-What-You Get, or Rich Text Format (RTE) editors transform Drupal's default data input boxes into flexible editors with Word-like toolbars. The WSYIWYG module lets you install the editor of your choice. I've done well with FCKEditor (recently rebranded CKEditor, thank you!). The WYSIWYG module lets you work with multiple RTE packages and strategically assign them to different fields and content types. Most RTE editors are very configurable, but note that, in addition to installing the modules, you need to install the editors themselves, so follow the instructions carefully.
If you're building a community site, with hopes of having lots of interactive, social features, Organic Groups gives you the flexibility to not only create all sorts of groups and affiliations on your own, but let your users create their own groups as well, much like Facebook does. For an interactive site, this is essential.
E-Commerce/Donations
Many modules are available for either integrating with Authorize.net or Paypal, or setting up your own e-commerce site. The aptly named e-Commerce module and Ubercart are among the better known and supported options.
Drupal fans: what modules do you recommend? Which do you install first? Leave your recommendations in the comments.
Next week, we'll talk about menus, blocks and taxonomies: Drupal 101: Navigation.
Idealware's blog is not the best place for me to talk about my kid. There's Facebook and Flickr for that sort of thing. But I want to talk about him anyway, and open a discussion, if possible, about children and the nptech community.
My career is in nonprofit technology (nptech). My plan is to continue working for nonprofits (or, if for profit, a for profit with a mission and a socially beneficial bottom line) until I retire or expire. While my ten year old boy's stated goal is to become a NASA engineer, and that's great, I want him to understand why I chose my path of purposeful work and understand what's involved in it, should he, at age 15 or 25, decide that NASA isn't the only option.
A few year's back, former NTEN CEO and current MobileActive CEO Katrin Verclas suggested adding a program for teenagers at the annual nonprofit technology conference. This is a brilliant idea. We have a great opportunity to educate children in the work we do: advocating for social justice and good; raising funds and resources in order to act effectively and independently; and collaborating in a supportive community to accomplish our varied, but sympathetic goals. Whatever our children end up doing with their lives, we have something worthwhile to teach them.
When I was a teenager, I was active in a youth group called Liberal Religious Youth (LRY). LRY was an independent group affiliated with the Unitarian Universalist Association, but it was not a particularly religious group. The themes were more along the lines of addressing social concerns and building community. At ages sixteen and seventeen, I was creating flyers, renting facilities, giving presentations, leading sessions, planning menus and taking a leadership role that prepared me far better for my current career than high school actually did.
When I look at our nptech community, I see a similar environment, where our commitment and excitement regarding our work is bolstered by a natural adoption of supportive camaraderie and peer development. We definitely model something of value to our high school age kids who will face career choices and challenges like ours. We can develop a mentoring program that passes on our expertise in resource management, activism, fundraising, community building, nonprofit technology and social media as a social activism tool. This would provide them with an early introduction to the skills that will be needed when we retire to continue the important work that we do. As much as a grant, donation, or volunteer effort, this is an investment in our work and our world that we should be making.
I want my son to develop his skills and community with socially-conscious peers and mentors. I want his generation to be more effective than we are at solving problems like poverty, pollution and social injustice. It's not enough for us to try and save the world. We should be prepping the next generation to keep it protected.
Last week, I shared my impressions of Google Wave, which takes current web 2.0/Internet staple technologies like email, messaging, document collaboration, widgets/gadgets and extranets and mashes them up into an open communications standard that, if it lives up to Google's aspirations, will supersede email. There is little doubt in my mind that this is how the web will evolve. We've gone from:
The Yahoo! Directory model - a bunch of static web sites that can be catalogued and explored like chapters in a book, to
The Google needle/haystack approach - the web as a repository of data that can be mined with a proper query, to
Web 2.0, a referral-based model that mixes human opinion and interaction into the navigation system.
For many of us, we no longer browse, and we search less than we used to, because the data that we're looking for is either coming to us through readers and portals where we subscribe to it, or it's being referred to us by our friends and co-workers on social networks. Much of what we refer to eachother is content that we have created. The web is as much an application as it is a library now.
Google Wave might well be "Web 3.0", the step that breaks down the location-based structure of web data and replaces it completely with a social structure. Data isn't stored as much as it is shared. You don't browse to sites; you share, enhance, append, create and communicate about web content in individual waves. Servers are sources, not destinations in the new paradigm.
Looking at Wave in light of Google's mission and strategy supports this idea. Google wants to catalog, and make accessible, all of the world's information. Wave has a data mining and reporting feature called "robots". Robots are database agents that lurk in a wave, monitoring all activity, and then pop in as warranted when certain terms or actions trigger their response. The example I saw was of a nurse reporting in the wave that they're going to give patient "John Doe" a peanut butter sandwich. The robot has access to Doe's medical record, is aware of a peanut allergy, and pops in with a warning. Powerful stuff! But the underlying data source for Joe's medical record was Google Health. For many, health information is too valuable and easily abused to be trusted to Google, Yahoo!, or any online provider. The Wave security module that I saw hid some data from Wave participants, but was based upon the time that the person joined the Wave, not ongoing record level permissions.
This doesn't invalidate the use of Wave, by any means -- a wave that is housed on the Doctor's office server, and restricted to Doctor, Nurse and patient could enable those benefits securely. But as the easily recognizable lines between cloud computing and private applications; email and online community; shared documents and public records continue to blur, we need to be careful, and make sure that the learning curve that accompanies these web evolutions is tended to. After all, the worst public/private mistakes on the internet have generally involved someone "replying to all" when they didn't mean to. If it's that easy to forget who you're talking to in an email, how are we going to consciously track what we're revealing to whom in a wave, particularly when that wave has automatons popping data into the conversation as well?
The Wave as internet evolution idea supports a favored notion: data wants to be free. Open data advocates (like myself) are looking for interfaces that enable that access, and Wave's combination of creation and communication, facilitated by simple, but powerful data mining agents, is a powerful frontend. If it truly winds up as easy as email, which is, after all, the application that enticed our grandparents to use the net, then it has culture-changing potential. It will need to bring the users along for that ride, though, and it will be interesting to see how that goes.
--------
A few more interesting Google Wave stories popped up while I was drafting this one. Mashable's Google Wave: 5 Ways It Could Change the Web gives some concrete examples to some of the ideas I floated last week; and, for those of you lucky enough to have access to Wave, here's a tutorial on how to build a robot.
Google is on a fishing expedition to see if we're willing to take web-surfing to a whole new level. My colleague Steve Backman introduced us to Google Wave a few months ago. I attended a developer's preview at Techsoup Headquarters last week, and I have some additional thoughts to share.
Google's introduction of Wave is nothing if not ambitious. As opposed to saying "We have a new web mashup tool" or "We've taken multimedia email to a new level", they're pitching Wave as nothing less than the successor to email. My question, after seeing the demo, is "Is that an outrageous claim, or a way too modest one?".
The early version of Google Wave I saw looked a lot like Gmail, with a folder list on the left and "wave" list next to it. Unlike Gmail, a third pane to the right included an area where you can compose waves, so Wave is three-columner to Gmail's two.
A wave is a collaborative document that can be updated by numerous people in real-time. This means that, if we're both working in the same wave, you can see what I'm typing, letter by letter, as I can see what you add. This makes Twitter seem like the new snail mail. It's a pretty powerful step for collaborative technology. But it's also quite a cultural change for those of us who appreciate computer-based communications for the incorporated spell-check and the ability to edit and finalize drafted messages before we send them.
Waves can include text, photos, film clips, forms, and any active content that could go into a Google Gadget. If you check out iGoogle, Google's personal portal page, you can see the wide assortment of gadgets that are available and imagine how you would use them -- or things like them -- in a collaborative document. News feeds, polls, games, utilities, and the list goes on.
You share waves with any other wave users that you choose to share with. User-level security is being written into the platform, so that you can share waves as read-only or only share certain content in waves with particular people.
Given these two tidbits, it occurred to me that each wave was far more like a little Extranet than an email message. This is why I think Google's being kind of coy when they call it an email killer - it's a Sharepoint killer. It's possibly a Drupal (or fill in your favorite CMS here) killer. It's certainly an evolution of Google Apps, with pretty much all of that functionality rolled into a model that, instead of saying "I have a document, spreadsheet or website to share" says "I want to share, and, once we're sharing, we can share websites, spreadsheets, documents and whatever". Put another way, Google Apps is an information management tool with some collaborative and communication features. Google Wave is a communications platform with a rich set of information management tools. It's Google Docs inverted.
So, Google Wave has the potential to be very disruptive technology, as long as people:
Adopt it;
Feel comfortable with it; and
Trust Google.
Next week, I'll spend a little time on the gotcha's - please add your thoughts and concerns in the comments.
Internet culture addicts like me have taken gleeful note of Mashable's campaign to rid the world of Microsoft's Internet Explorer version 6. Anyone who develops public web pages (and cares if they are compatible with other and/or modern browsers) is sympathetic to this cause. The hoops that we have to jump through to make our pages look acceptable in IE6 while taking advantage of the nearly decade old CSS positioning commands are ridiculous. When I was doing web consulting a few years back, IE6 compatibility coding generally took up about 20% of the total project time.
Microsoft's response to the Mashable campaign was to defend the brontosaurus-like pace of corporate IT Departments in performing application updates. Here's the pertinent MS Spokesperson quote:
“[Corporate IT departments] balance their personal enthusiasm for upgrading PCs with their accountability to many other priorities their organizations have. As much as they (or site developers, or Microsoft or anyone else) want them to move to IE8 now, they see the PC software image as one part of a larger IT picture with its own cadence.”
Huh! This from the company that kept threatening to drop Windows XP support in order to force us to Vista.
But, sarcasm aside, this is a flawed argument. The "cadence" in which an IT Department upgrades software should be influenced by changes in the general technology landscape. Business (and nonprofit!) networks use the Internet. Those networks are already integrated with the world at large. Since the web browser is one of the primary interfaces to external data, it's easy to make the case that it needs to be upgraded more often than word processors and spreadsheets.
Many major webs sites are designed with CSS 3.0 formatting. IE6 doesn't fully support the 11 year old CSS 2.0 specification. IT departments that aren't prioritizing this upgrade are providing poor support for users who need such websites. They're also creating more work for themselves supporting the workarounds. Large companies might have far more computers to upgrade, but they also have software that automates that process. The key issue is training. Microsoft dramatically changed the user interface of Internet Explorer with version 7, but there are options to default back to the IE6 layout. The hassle of learning the new interface is certainly not as bad as not being able to properly use websites that are designed for more modern browsers.
What really irks me is the way that Microsoft has described the "IE6 must die" campaign' as being intended to appease "technology enthusiasts". The push to move users to modern browsers is not about my desire to use non-business applications like Facebook, Digg and YouTube (and classifying these web sites as "non-business"is a pretty debatable point as well). It's about my desire to benefit from advancements in web technology, and provide my staff with new tools that promote their mission-focused work.
With the HTML 5 specifications about to become the new standard, IE6 is obsolete. The types of things that IE6 doesn't support are the things that are making web-based applications viable, affordable alternatives to traditional software. Microsoft has been in the driver's seat of the companies that set the pace of technology advancement. They should be consistent in supporting the migration and adoption to those new standards, given a reasonable amount of time. Eight years is reasonable. IE6 must die, and Microsoft should join the chorus.
In 2000, after spending 15 years at corporate law firms, I made a personal choice to start working for organizations that promote social good by reducing poverty and protecting our planet. I understood that this career move would put some serious brakes on what was a fairly spiraling rise in compensation - my salary tripled from 1993 to 2000. And that was fine, because, as I see it, the privilege of being compensated for doing meaningful work is compensation in it's own right.
We all know that we make less in this industry than we might in the commercial world, and we're all pretty okay with that. But how much, or how little, the discrepancy between "real world" and nonprofit salaries should be is a metric with little established thought behind it. We don't base our pay scales on any rationale other than what we determine others are paying and what we can afford. My concern is that, by not taking a strategic, reasoned approach to compensation, nonprofits are incurring far more unnecessary expense than they might, particularly when it comes to technology support, although these thoughts apply across the org chart.
The problem is that, when it comes to determining the market value of a nonprofit employee, we often go to nonprofit salary surveys, such as the one put out by NTEN and the Nonprofit times. But job seekers don't read those surveys. In San Francisco or New York, a good System Administrator can make $70-80k a year at a for-profit. Even if they come in to your org understanding that they aren't going to be offered the market pay ($75k), they have an expectation that they'll either be on the low end of it ($70k), or within 10% of it ($67.5k). The recent NTEN Staffing Survey puts the average nonprofit Sysadmin salary at $52k, which is about 75% of that market. So, given this scenario, here are my questions:
How many excellent candidates are eliminated from consideration because they can't afford to take a 25% pay cut?
Of the ones who can afford that pay, how many can afford it because they aren't qualified for the work required?
How many can afford it because they have other primary income sources, and therefore can take a low paying job and not feel very committed to it?
If a good Sysadmin takes a job at that rate, how long will it be before they decide that they need more money and leave?
What is the impact of having a heavy rotation among the staff that maintain and upgrade your technology?
What is the impact of having of having often empty critical IT positions?
But, let's get really into this. Unless the IT people that are hired at the 75% rate are extremely mature, then they might have some of the common failings of immature Sysadmins:
Many are often controlling and secretive. I've been in multiple situations where I've come into an organization and learned that the prior IT staff left with the key system passwords. I've also seen numerous situations where the IT staff left en masse.
Most Sysadmins are lousy about writing things down. What is the ramp-up time for your new staff when they have to research and guess how everything works on arrival?
The general instinct of a new IT person is to rip everything out and install their favorite things. Got Windows? They like Linux. Got Word? They like Google Docs. They don't necessarily understand that one platform is much like another, but imposing massive change on an organization can be dangerously disruptive.
Technology candidates need to be assessed not only for their technical skills, but also for their attitude and maturity. A very sharp tech, who can answer all of your Outlook questions, might have little patience for documenting his or her work or sharing knowledge with other technical staff. And those skills are the ones that will allow you to transition more smoothly when the tech leaves.
Mission is a motivator, and it has value that can be factored in to overall compensation, but not to the point where it's so unattractive that it knocks the pool of candidates down to a pool of uncommitted or desperate ones. The impact of paying poorly isn't isolated to the salary bucket on the balance sheet. In many cases, particularly with technology, it's tied directly to the ability to operate.
Yes I did just finish In Defense of Food by Michael Pollan, which has been really helpful to me in separating real food from cheap imitations. It's my newest filter for navigating the grocery store, providing an easy to follow set of best practices for avoiding nasty edibles that cause us more long term harm than good. And yes, this book can even help us with software selection.
Michael Pollan reinforces that we must be careful when we enter a unfolding situation, already having decided on certain outcomes. We software experts and users spend a lot of time grouping software into similar features, development models, support system, company backing and more. This work is extremely useful to helping our understanding of software, but must always be taken with a grain (or two) of salt.
So how do we keep our critical eye sharp without getting overwhelmed with the myriad of possibilities when evaluating software?
(1) Frame your context
Understanding your organization processes are key, we software geeks say this all the time. Also important is understanding your organizational capacity to change. Important factors include internal staff expertise, general workload, organizational growth pattern, and system of governance. Defining how you do the work you do helps eliminate features and services that are unnecessary or come into conflict with your organizational context.
(2) Use filters
Filters can help us make sense of complexity by removing some of the detail. Quality software reviews are very helpful filters as they provide both strong context describing who the review is for, and well defined categories to help you group software according to common and critical needs. Internal organizational experience with software are also great filters as they come with institutional knowledge of the organizational context, offering a unique opportunity to combine this knowledge with software experience to shape well fit decisions.
(3) Be discriminating, don't discriminate
Look behind the filter to understand what it does not include. Often filters will look at software from certain perspectives that hide important information. I often run into this problem working with nonprofit associations, for which many vendors have created "association management software". A smartly compiled list of best vendors in this space is a great filter to have. However, it turns out the needs of associations are far more diverse than these association management packages support well. By limiting the focus on association management solutions, nonprofits often miss out compelling offerings provided by donor, membership, constituent management and content management vendors. Vendors generally are one good source of information about their products, however it is much better when verified against independent sources with specific experience using the vendor services.
(4) Test assumptions
Keep a critical eye on your plan for a new system. How many "needs" are supported by assumption versus research? Some nonprofits face difficult change management issues by launching a new system where the core users were not adequately engaged in planning and implementation. Others are disappointed to find that features that claim to be present really are no good for their needs. Beware the salty snacks - some tools make it seem so easy to keep adding fields or new features, but they can make your system very sick with bloat if overindulged. Understand the source of any advise or reviews you receive - what is their context? Who is their intended audience?
For the past four years or so, at two different organizations, I've been evaluating Microsoft's Sharepoint 2007 as a Portal/Intranet/Business Process Management solution. It's a hard thing to ignore, for numerous reasons:
It's an instant, interactive content, document and data management interface out of the box, with strong interactive capabilities and hooks to integrate other databases. If you get the way it uses lists and views to organize and display data, it can be a very powerful tool for managing and collaborating on all sorts of content. As I said a year or two ago in an article on document management systems, it has virtually all of the functionality that the expensive, commercial products do, and they aren't full-fledged portals and Intranet sites as well.
Sharepoint 2007 (aka MOSS) is not free, but I can pick it up via Techsoup for a song.
It integrates with Microsoft Exchange and Office, to some extent, as well as my Windows Directory, so, as I oversee a Windows network, it fits into it without having to fuss with tricky LDAP and SMTP integrations.
All pretty compelling, and I'm not alone -- from the nonprofit CIO and IT Director lists I'm on, I see that lots of other mid to large-sized organizations are either considering Sharepoint, or already well-ensconced.
So, why does Sharepoint scare me?
What it does out of the box, it does reasonably well. Not a great or intuitive UI, but it’s pretty powerful. However, advanced programming and integration with legacy systems can get really complicated very fast. It is not a well-designed database, and integration is based on SOAP, not the far less complicated REST standard, meaning that having someone with a strong Microsoft and XML programming skill set on board is a pre-requisite for doing anything serious with it.
MOSS is actually two major, separately developed applications (Windows Sharepoint Services and Content Management Server) that were hastily merged into one app. As with a lot of immature Microsoft products, they seem to have been more motivated by marketing a powerful app than they were in making it actually functional. Sharepoint 2013 or 2016 will likely be a good product, kind of like Exchange 2007 or SQL Server 2003, but Sharepoint 2007 makes a lot of promises that it doesn't really keep.
Sharepoint's primary structure is a collection of "sites", each with it's own URL, home page, and extensions. Without careful planning, Sharepoint can easily become a junkyard, with function-specific sites littered all over the map. A number of bloggers are pushing a “Sharepoint invites Silos” meme these days. I stop short of blaming Sharepoint – it does what you plan for. But if you don’t plan, or you don't have the buy-in, attention and time commitment of key staff both in and out of IT, then silos are the easiest things for Sharepoint to do.
The database stores documents as database blobs, as opposed to linking to files on disk, threatening the performance of the database and putting the documents at risk of corruption. I don't want to take my org's critical work product and put it in a box that could easily break.
Licensing for use outside of my organization is complicated and expensive. MOSS access requires two or three separate licenses for each user - a Windows Server licence; a Sharepoint License, and, if you're using teh advanced Sharepoint features, an additional license for that fiunctionality. So, if I want to set up a site for our Board, or extend access to key partners or clients, It's going to cost for each one. There's an option to buy an unlimited access license, but, the last time I looked, this was prohibitively expensive even at charity pricing.
Compared to most Open Source portals, Sharepoint's hardware and bandwidth requirements are significantly high. Standard advice is that you will need additional, expensive bandwidth optimizing software in order to make it bearable on a WAN. For good performance on a modest installation, you'll need at least two powerful servers, one for SQL Server and one for Sharepoint; for larger installations, a server farm.
I can't help but contrast this with the far more manageable and affordable alternatives, even if those alternatives aren't the kitchen sink that Sharepoint is. Going with a non-Microsoft portal, I might lose all of that out of the box integration with my MS network, but I would jettison the complexity, demanding resources, and potential for confusion and site sprawl. I'm not saying that any portal/intranet/knowledge management system can succeed without cross-departmental planning, but I am saying that the risk of a project being ignored -- particularly if the financial investment was modest, and Sharepoint's not cheap, even if the software can be -- is easier to deal with than a project being fractured but critical.
if my goal is to promote collaboration and integrated work in my organization, using technology that transcends and discourages silos, I'm much better off with apps like Drupal, KnowledgeTree, Plone, or Salesforce, all of which do big pieces of what Sharepoint does, but require supplemental applications to match Sharepoint's smorgasbord of functionality, but are much less complicated and expensive to deploy.
After four years of agonizing on this, here's my conclusion: When the product matures, if I have organizational buy-in and interest; a large hardware budget; a high-performance Wide Area Network, and a budget for consulting, Sharepoint will be a great way to go. Under the conditions that I have today -- some organizational buy-in; modest budget for servers and no budget for consulting; a decent network, but other priorities for the bandwidth, such as VOIP and video -- I'd be much better served with the alternatives.
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.
A weekend thought about software and technology. At blogging buddy Heather Gardner-Madras’ suggestion, I’d like to return to a theme I started on earlier -- tai chi and technology planning. Doing tai chi or chi gung (qigong), it is remarkable how many design and software folks you find, part of the “walking wounded” of our high tech era. One thing these practices can help you work on is relaxing the eyes. Nothing like sitting in front of a computer screen for hours to put tension into your eyes.
There is a lot more to it. When we want to solve a problem, don’t we tend to say things like, take a hard look? “Let’s meet next week and take a hard look at our email newsletter now that we have done all that work revamping it.”
And we say, “keep a sharp eye out.” “When you meet on the web project next week, keep a sharp eye out for feature requests that will bust our launch schedule.” We focus in, we “head” in a direction and so on.
Check yourself next week. Do your eyes tense up in meetings and not just when in front of the computer?
By contrast, next time you watch Chinese or Japanese martial arts films (or those influenced by them), do an experiment. When the big fight is about to begin, look at who has the fiercest eyes and use that as a predictor of who is going to lose that round. Think Uma Thurman and Lucy Liu in the restaurant scene in Kill Bill Volume I. Watch their eyes change focus in the run-up to the mayhem. Check it out on youtube. just watched it again, and well, O-Ren Ishii is no slouch either. If the contrast isn’t so clear, check out the next scenes, facing the Crazy 88 (O-Ren’s personal army).
In Tai Chi, you practice softening your eyes as you move in order to take in more, to increase your peripheral vision. Not that I would know, but it makes sense that good peripheral vision helps when you face off with dozens of Crazy 88s at once. You neither focus so hard that you only see what is in front of your nose and ignore the context, nor turn so passive that you just receive information without being part. You learn to relax the eyes into a neutral place, so that you pay attention to everything going in and out in a more complete, holistic way.
I’m not going to compare my project meetings with facing the Crazy 88. Still, there is often a lot going on. If you mainly bring back a mess of details from a planning session, you may not be able make that synthesizing assessment the client expects from you. In software requirements planning and software selection exercises with teams of folks, I have found I do better when I take it in with a soft eye. A couple ideas:
As people contribute, pay attention to the speaker, and also take in everyone else at the table. Look around at everyone, not just in turn, but all at once. Can you take the pulse of the room as the discussion flows?
As documents and details get pulled up on screen, don’t let an entire table of people bear down on each data field or each separate component of a wireframe. You need those details –and tai chi is certainly all about working on the details!—but when you have the whole team there, ask yourself what you need to do to measure the whole effect.
During a break, try very gently massaging the front of the eyes, and let the attention of your mind also relax the back of your eyes. See if that doesn't help you to come back to the planning refreshed and able to take in more of the big picture.
Finally, a comment Steve Connell made in Rapid Development: Taming Wild Software Schedules, one of the classic books about software project management. This has always stuck with me, though I can't find the page now. He mentions that in an initial meeting about a big project, as senior architect, he sometimes finds it useful to come with no notebook. He recommends listening and looking, taking it all in, with the goal of summarizing and synthesizing the sense of the entire meeting in just one sentence only. Not a platitude, but one sentence that everyone walks away with feeling the whole strategy of the project has been captured. You cannot do that if you are taking a hard look at every feature request, every contradictory requirement that may come up. Do that over time, make sure the initial planning has the whole picture.
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.
Subscribe through Feedburner
