Michael Stein's NON-PROFIT TECHNOLOGY BLOG

PCI compliance anxiety ratchets up

2009-08-19T04:37:00.034-05:00

In the last few weeks our office phones have been ringing with calls from clients concerned about PCI compliance. A mounting realization that enforcement of these credit card standards is indeed coming, the October deadline to use compliant applications, and widespread confusion about what the standards are and who they apply to, is bringing the issue of credit card security to a boil. [UPDATE: I've created an entire page of PCI information at: http://membersonlysoftware.com/pci ]

The background: PCI is an association of the major credit card issuers. The PCI Data Security Standard (PCI-DSS) is a list of twelve security requirements that merchant account holders must meet. According to the standard, "PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply." In other words, if you ever send a credit card number through to the bank for processing, you've got to pass muster. Validation of compliance may require an on-site audit, or may be done by self-assessment and a notarized attestation. And while 12 requirements does not sound like much, the sub-points of each requirement make it clear that the standard affects pretty much every aspect of your IT system and your payment processes.

The biggest misconception we see among our clients is the idea that if they are using the right credit card processing system or software, they are compliant. Of course there are requirements that payment applications must meet. Failure to use compliant software is a sure path to flunking your compliance audit. But using compliant software does not begin to guarantee that you the merchant are yourself compliant. The entire security of your computer system comes under the purview of the PCI. In addition, any paper systems that might contain account number data are also involved.

Failure to use compliant software is a sure path to flunking your compliance audit. But using compliant software does not begin to guarantee that you the merchant are yourself compliant.

Let's look at one example. Requirement #1 reads "Install and maintain a firewall configuration to protect cardholder data." You might think the fact that you have an industry standard firewall product installed gets you a pass on this one. But that is just a starting point. The requirement's details indicate that you need

a written policy on how any change to the router or firewall configuration is approved and made.
a network diagram that shows all connections and all devices and a process to make sure the diagram is up to date.
documentation of the business case for all ports that are open and all protocols that are in use.
a formal review of all firewall and router settings every six months.

But back to the your software applications. Requirement 6 simply reads "Develop and Maintain secure systems and applications." How is secure defined here, and how do you prove it in a PCI audit?

Software applications that are sold "off the shelf"" can apply for the PA-DSS certification. (The Payment Application Data Security Standard - this is a separate standard governing just the software that management credit card payments). Software that is customized for a user organization cannot receive the PA-DSS designation. Instead custom software comes under the scope of each user's PCI compliance audit and may require a code review.

The best solution for a customized application is for it to avoid ever coming into contact with a credit card account number, and simply delegate all card handling to a certified PA-DSS compliant application.

This is a bigger deal than you might think. For example, if you want to capture the credit card number for a donation in page you have carefully designed and branded, you will need to code review and validate this page as part of your compliance even if all it does is pass this number to a PA-DSS certified payment app.

But your greatest exposure arises if you store credit card numbers for any reason after the moment of the transaction. For example, many non-profits charge sustaining donors' pledges against their credit cards on a monthly basis; YMCA's often charge for their dues this way. The requirements for protecting credit card data of this sort are daunting. Maintaining this sensitive data in an encrypted database using the latest encryption technology may not be enough if you cannot document your procedures for controlling access to the keys, monitoring physical access to the server, and so on.

The best solution, is to hand off ALL credit card storage as well to a PA-DSS certified application that stores the numbers out in the internet cloud, far from your server, and your liability. We've selected to partner with CAMcommerce, for example, whose PA-DSS certified xCharge application is a dream to integrate with and will provide Members Only users with the security they need.

All of this demands that custom applications find new ways of interfacing with payment software. For example, a very widely-used method for interfacing with payment applications involves the business application creating a batch file that is submitted to the payment app. This file contains credit card numbers written out in plain text. And the application returns a batch of response data, again with the number in plain text. This approach is certainly not compliant with the new security requirements. Like Y2K a decade ago, PCI and PA-DSS compliance are going to keep programmers busy for a while.

Additional Information: The PCI Security site is full of information about the standard and compliance testing. "Navigating PCI-DSS" is a fifty page introduction to the terms of the standard and the meaning and intent of each clause. It's the best thing to read to get a sense of what this is all about. The Full PCI_DSS specification can be downloaded from this page. And when you are ready, you can also find the self-assessment questionnaire here.

Capability Stairsteps

2009-07-15T05:56:00.018-05:00

When we begin a new deployment of our software applications at an organization, we always ask the users "How will you know if this project was a success or not?" We're usually expecting to hear things like "Our staff will spend significantly less time putting together monthly reports" or "We will finally have agreement between the membership lists on the website and in the AMS." But at a recent project kickoff the bar for success was really low: "Our staff will actually use the system."

Problems with the adoption of new IT tools can rob an implementation of much of its ROI. And the the solution is not simply making sure you've picked the right tool and delivered the proper training. There are specific steps that need to be taken to encourage user adoption.

My friend Russ Eisentstat of TruePoint uses the phrase "capability stairsteps" to emphasize the incremental nature of such transitions. These steps may involve partial use of the new tool, use by a subset of the eventual target user community, or both. But before you can climb these steps you need to design them - adoption will not necessarily spread naturally or completely unless the organization creates a plan and monitors it.

The example Russ and I discussed related to the use of a wiki to capture organizational knowledge. One of my long-standing contentions is that an enormous amount of organizational knowledge exists in emails between stakeholders. If these emails were simply captured and organized, a great deal of knowledge documentation could be managed with little or no new writing. But both of us had limited success in encouraging our own organizations to use our wiki.

What would a stairstep model for adoption of the wiki look like? First we need to put someone in charge! This is a step that is often ignored in this type of change management. Someone needs to take personal responsibility for the effort to develop the wiki into a useful tool. As soon as we have identified the wikimaster, we have at least one more committed user.

The next step is to identify the barriers to adoption so we can plan to eliminate them. Russ and I both agreed that the main barrier is the catch 22 of social sites: the wiki is not attractive to users if it is not yet rich with useful information -- but this will not happen until people begin using it. This barrier can be reduced by "priming the pump." Step two is that the wikimaster takes active responsibility for getting the first fifty articles on the site. He can poll users frequently to get them to send him any material that would be apporpriate for inclusion. This spreads some buzz about the wiki without asking people to utilize it themselves in any way.

A second barrier: it takes a bit more learning to become adept at posting than just to read the site. So this suggests the next increment. Step three is to encourage the use of the wiki as a passive repository of information, without leaning on people to post. People can still rely on the wikimaster to post their articles, but can begin to turn to the wiki to look for information they might need.

Only now do we tackle active contribution - again a step at a time. In Step four might the wikimaster to encourages people to comment on exisiting articles - reminding them of this capability, and having existing champions comment to prime the discussion on this forum.

Step five might be then to put in place rules for how others should post their own articles - how to tag them, how to deal with the home page, how new articles are announced, and so on. At this point a training or informational session might be held for new posters.

So what I had thought was a one step procedure - "let's start using this new tool" - has become a five step staircase. This model of identifying barriers and building a step to climb over each one in sequence can be used to encourage adoption of systems of all kinds.

Earth Day Roundup

2009-04-22T09:53:00.008-05:00

Links to some interesting reading this Earth Day:

Green IT. A couple months ago I posted about "Green IT" and the growing awareness that information technology demands fuel and creates emissions like all other energy consuming activities. But this article in the BBC took me by surprise... email SPAM is a major contributor to IT energy consumption, utilizing 33bn kilowatt-hours of energy every year, enough to power more than 2.4m home, and in the process contributing 17 million tons of carbon dioxide to our greenhouse gas burden.

Green Education. A bit of good news for all the non-profits making efforts to educate their constituency about green issues: it makes a difference. The EPA reports that there is a measurable improvement in air quality associated with environmental education.

Nearly half of the surveyed institutions hosting education programs reported an improvement in air quality at their facilities due to actions taken by students, including doing service-learning projects and fostering community partnerships. Examples include decreased levels of carbon monoxide and mold, and enactment of a policy that decreased car or bus idling.

Green Markets? Free-marketeers have been extolling the value of "Cap and Trade" solutions to control emissions... but there is mounting evidence that it is not so simple. An article in the British New Scientist reviews the results of the ETS (Emissions Trading Scheme) currently in place in the EU. The approach works when the price of permits is high. But if the value falls, the incentive to improve emissions falls right with it:

As heavy industries mothball factories, energy use drops and demand for permits goes down. At the same time businesses try to raise cash by selling their unused permits, flooding the market and further depressing prices. French energy company EDF recently complained that carbon markets were failing just like the market for subprime mortgages. As a result, all kinds of green energy schemes are grinding to a halt.

Daily News, Daily Blues

2009-03-21T12:25:00.015-05:00

In the last few months, it seems that at every social gathering I attend, the conversation gets around to "Newspapers - what's going to happen to them?" The closing of the Seattle Post-Intelligencer's print operations a few weeks back, coupled with Hearst Corporation's announcement that may close the venerable San Francisco Chronicle as well, has brought the plight of print journalism into focus. And I've been finding that my friends get really worked up about it -- it's clear the newspaper as it exists today has real meaning in people's lives.

It's not a problem that suddenly snuck up on us. Back in the summer of '06, The Economist was already talking about the decline of print, and predicting that the future would see the closing of most local papers, and a new mix that consisted of "an elite group of serious newspapers available everywhere online, independent journalism backed by charities, thousands of fired-up bloggers and well-informed citizen journalists..."

The problem of course is the collapse of the traditional business model of the newspaper. In that model advertisers pay publishers enough to support the news-gathering operation because advertising in a newspaper with decent reporting was the best way to get their copy in front of readers. As essay by new-media guru Clay Shirky points out, this is no longer the case, because

"...the core problem publishing solves — the incredible difficulty, complexity, and expense of making something available to the public — has stopped being a problem."

The Internet has disrupted the old economic realities of information distribution. Because of that, advertisers have migrated to the net in droves. In the past, classified advertising was the most lucrative source of advertising revenue for the publisher - Rupert Murdoch referred to it as "a river of gold" - but that river is now reduced to a trickle, leading the Economist to say that Craigslist has done more than anything to destroy the newspaper. And publishers' reponse to that loss of revenue has been to cut expenses by shrinking the paper and reducing the news staff - in other words, by making their product less desirable.

Shirky says, "Society doesn’t need newspapers. What we need is journalism." But the newspapers have provided a concentration of resources for serious journalism that the new media alternatives, such as The Huffington Post, let alone individual bloggers, have not yet demonstrated an ability to replace. Walter Isaacson, former managing editor of Time and former CEO of CNN, assumes that the print edition is dead but the institution need not perish with it. He proposes that the solution is for the major pappers to begin charging for their websites.

Even an old print junkie like me has quit subscribing to the New York Times, because if it doesn't see fit to charge for its content, I'd feel like a fool paying for it. This is not a business model that makes sense.

Isaacson envisions both a subscription basis (as the Financial Times and Wall Street Journal currently have) as well as a micropayments model where individual articles have a small fee (five or ten cents each) for non-subscribers. Conventional wisdom is that people will not pay to read the newspaper online, but Isaacson is convined that it can be done. After all, he points out, people pay to text.

Some resources:
"Who Killed the Newspaper", The Economist, August 24, 2006.
Eric Alterman, "The News Business: Out of Print," The New Yorker, March 31, 2008
Clay Shirky, "Newspapers and Thinking the Unthinkable",March 13th, 2009
Walter Isaacson, "How to Save your Newspaper", Time, Feb 5th, 2009
Scott Adams, "The Future of Newspapers", Oct 1, 2007

What is Green IT?

2009-01-27T06:05:00.007-05:00

For a couple of years now we've been seeing talk of Green IT, and as early as 2007 management consulting giants Gartner and McKinsey were addressing Green issues as a major issue facing IT managers. The McKinsey report offers a concise statement of the issue:

The rapidly growing carbon footprint associated with information and communications technologies, including laptops and PCs, data centers and computing networks, mobile phones, and telecommunications networks, could make them among the biggest greenhouse gas emitters by 2020. However, our research also suggests that there are opportunities to use these technologies to make the world economy more energy and carbon efficient

So Green IT is really two issues: making information technology itself more energy efficient, and going beyond that to using IT to reduce the carbon footprint of other operations. Today's EnergyWise announcement by Cisco underscores the growing concern managers have in both these areas.

The EDS blog The Next Big thing devoted eight posts last autumn to an in-depth look at the idea of Green IT and lays out a path that considers both of these issues in detail, focusing on the green data center.

Many of these ideas seem more appropriate for a Google or Microsoft than for a medium-sized non-profit or association. Techsoup offers some suggestions for Greening the smaller workplace. These include virtualizing your servers to use fewer boxes, and using your technology to minimze travel.

Has your organization grappled with these issues? Have your solutions saved you money, added complexity, or both?

Three common security pitfalls

2008-10-07T07:11:00.010-05:00

Security is a growing concern in the non-profits community. The requirements may be legally mandated, as in the case of HIPAA and client health care information. The issue may be competitive -- you do not want to hand out your grant applications to the other orgs in your building before you've even sent them off to funders. And everyone has finally woken up to the need to secure supporters' credit card information and comply with PCI standards.

Organizations are putting increasing pressure on vendors of applications and networks to assure security through the use of encryption, https, and user specific access to data fields and tables. But we see three simple security flaws over and over again in the smaller non-profits.

Inadequate physical security of the servers. Is your database server sitting in the unlocked phone closet? Is your web server in a room shared by three programmers? I know one group with real privacy concerns who keep the server on a counter in the break room. It doesn't really matter how much you lock your network down with the latest firewall technology and encryption techniques if the servers can be waltzed out of the building without causing a stir.

Inadequate password security. I see this everywhere I go - users know each others passwords. It may even become part of standard operating procedure: "to do this, I log in as Eileen." Let your OS help you with this: require users to change their passwords frequently. Require complex passwords. Beat up on people who tell others what their password is. And if you have legally mandated privacy concerns, consider adding biometrics to your user authentication procedure - USB thumb scanners are widely available these days.

Improper Disposal of Computers. When the time comes to dispose of a pc, what do you do with it? All your security efforts were for naught if you just sit the machine in the trash. Wipe that drive! Reformatting the drive does not do it - it just clears the directory structure. Any snoop can still read your data after a reformat. There are numerous software packages on the market for just this purpose - a number of government agencies have standardized on cyberCide. You can destroy the drive with a few well-placed drill holes - but the software approach is easier - and then you can still donate the old.

Thanks to Sean Henriques for a tweeting a link that made me start thinking about this!

The Summertime Blues

2008-07-22T04:50:00.012-05:00

You'll love those lazy hazy crazy days of summer - those days of hot dogs and pretzels and beer... remember that old tune? I can remember listening to it on the radio as we drove to the Catskills in my Dad's old Dodge. But vacations are different now - everywhere I'm reading articles about how we Americans don't really get away from our work anymore when we go on holiday. We go loaded with smartphone and laptop and a plan to get six weeks of special projects done during six days on the beach. I know that's how I made my last trip miserable.

But I don't think we should get too new-agey about this one. For the techie in the non-profit or association space, taking a guilt- and anxiety-free vacation is not about state of mind, but about preparation. It's about making sure your organization, your clients, your users, really will be OK during your absence. Its a sort of preparation you need to be thinking about in one way or another before any absence - whether its a day off to paint your kitchen or a month-long trip through India.

Prepare your users. Your users depend on you on a daily basis for solutions, for advice, for troubleshooting. The longer your absence is going to be, the earlier you need to let people know about it. Make sure all your key users understand when and for how long you will be out, and give them a good understanding of the limits on your availability during your vacation. Encourage them to think now about needs that might emerge during your time off. Make sure they factor your absence into their timeframes for special projects! And let them know where to turn for help while you are gone.

Prepare your backup. The folks who are going to be filling in for you during your vacation need to know exactly where your major projects are at, how to find the information they might need, and who they can turn to for further help. Make sure they know exactly how and when they can contact you, and when you be unavailable. What should you prepare them for? Look through your last years log of issues you've had to resolve. And be careful: documenting your network is useless if you have not made sure the right people know where to find that document.

Don't have a backup person? - no wonder you and your coworkers are anxious! Take care of this first. If its not someone on your staff, make arrangements with a consultant.

Prepare yourself. Your work pattern needs to change as you get ready to leave. We did a project several years ago for Deutsche Bank in Frankfurt. Frequently our partner Jochen would fly there for meetings. Pressed by the users to make enhancements to the application on a short time frame, he'd crank out code in his hotel room in the evening and install it the next day. Then he'd get on a plane to come back to D.C. Inevitably the user would have some huge issue with what he had done while he was on his seven-hour flight home. None of us back in the office had a clue what the requirements were or what the discussion had been. We've identified this as the Friday Install problem. Now we know to wait until we are in a position to support before we change. When your absence is going to be longer than seven hours, this issue becomes much more sensitive. Make sure you are not adding to the support burden in the days before you leave.

And send me a postcard!

Building your Donor base on Facebook - The Nature Conservancy's experience.

2008-07-13T20:37:00.008-05:00

There's been a lot of excitement in the last year about social networking in general, and about Facebook in particular. And a lot of talk about the value of social networking for non-profits. But is there really a return on investment for non-profit participation on these sites?

Here's a success story. The Nature Conservancy (TNC) is a 501(c)3 organization that works in the U.S. and over 30 other countries to protect ecologically important lands and waters. Using tools readily available on Facebook, the organization has raised almost $48,000 in the first six months of their social-networking effort. They did this by creating a Cause and a Fan Page for the org, and by forming a relationship with an ecology oriented game on Facebook, (lil) Green Patch. Six months later the (lil) Green Patch application is one of the most popular on Facebook, with of 6 million users!

Jonathon Colman , TNC's Associate Director for Digital Marketing recently developed a slide presentation that summarizes the organization's experience using Facebook as a marketing tool.
You can find the presentation here. The slide presentation raised a number of questions in my mind, so I messaged Jonathon on Facebook and we chatted about (lil) Green things.

Me - How did (lil) Green Patch come about? Was TNC involved in the creation of lil green patch or was it already on line when you formed your relationship with it?

Jonathon - No, the Conservancy was not involved with the creation of (Lil) Green Patch. It was already on Facebook when we found it by doing a search on our name (hence my first recommendation to organizations seeking to use Facebook for marketing purposes).

At that point, (Lil) Green Patch already said that they were going to donate a share of their advertising revenue to the Conservancy, but had trouble connecting with the right people in our organization. I immediately wrote them and we started the conversation. From the very first conversation, we encouraged (Lil) Green Patch and other Facebook application developers to donate to us directly through our Facebook Facebook Cause.

Me - Can you explain the business model of the application? How does it make money for you?

Jonathon - The application is supported by advertising on the site. It's a share of their advertising revenue that's donated to the Conservancy's Cause at http://apps.facebook.com/causes/2979?recruiter_id=1833869 on a month-by-month basis, depending on the application's usage and ads impressed/clicked on. It tends to be somewhere between $6000-$9000/month.

Me - how can a consumer be sure an app actually is providing the social benefit it claims? The other day I got several messages in my inbox accusing another app (oceans-related) of not really having a relationship with any non-profit.

Jonathon - This is why we're asking (Lil) Green Patch and other Facebook applications like Stop Climate Change Now to donate to us directly via our Facebook Cause -- it provides a complete change of accountability to the application developers and to the Conservancy.

When an application donates via the Cause, it's very simple for everyone to see how much was donated: just visit the Cause and scroll down to the "Hall of Fame". You'll see that, to date, (Lil) Green Patch has given $44,650. Clicking on their name of the amount that they've donated yields a graphical chart containing the people that they've recruited and/or recent donations that they've made.

Me - So do you need to have folks on staff to oversee the maintenance and ongoing development of the app?

Jonathon - Not at all. The Conservancy is in no way involved with the ongoing maintenance nor development of (Lil) Green Patch. Anyone can participate in this process, actually - There's a discussion board and links to the developers' profiles off of the main application page where you can talk with other users and get in touch with the development team.

Me - This is all very exciting. But what skills do you think a non-profit needs to bring on board to develop a marketing program built on social media?

Jonathon - My team at the Conservancy has incredibly talented editors, producers, a designer, and even a project manager. I couldn't do anything without them. In terms of social media, I think that organizations need to find people who can bring the right balance of:
- Writing for the web (specifically writing for members)
- Engaging in search engine marketing and optimization;
- Marketing to verticals and other segments
- Researching marketing and communities
- Testing and documentation
- Recording metrics and interpretation of "actionable" data
- Taking the "long view" on building a social media program and not expecting success right away

The right person could come from a direct mail background or from a marketing communication background or even a business information/analytics background... They just need to have some intuition and be willing to fail a few time sin order to succeed. That said, my background is actually not in marketing, but in technical writing .

A new chapter.

2008-07-02T21:11:00.006-05:00

The other day a friend dropped by the office to talk to us about how we manage chapters in our software. For example, he wondered if we assumed that the national organization did the dues billing, and distributed revenue to the chapters? Or the reverse: that chapters collect the dues and send it upstream to headquarters? The conversation led me to think about the forces that make organizational policies so often unwieldy and complex.

We've learned that there is no general pattern that governs the relationship between an organization and its chapters. These relationships are not structured by logic but through the working out of real conflicts of interest and mission between national, state, and local bodies. And these conflicts are resolved differently in every case. The challenge for IT is to model the internal reality for the specific organization.

Chapters are interesting because they are a very clear-cut example of what goes on in the definition of almost any organizational policy - a process of compromise between interest groups within the org. Streamlining inefficient or irrational policies is so much harder than one would expect because the differences between groups are so rarely spelled out. In the case of chapters, it is just easier to see these interest collisions.

It works like this. Not surprisingly, chapters want as much independence from the national as possible. And specifically, financial independence. But at the same time, they would like as much service from the parent org as they can wrangle. So the more successfully independent the chapters become, the harder administrative life is in Washington or New York.

For example a national conservation group we work with manages all the dues billing for its chapters and state divisions. These very autonomous chapters and divisions each create their own membership structures and dues levels. Thus the membership database mus t be able to store three membership types for each member: one each for National, State, and Chapter levels. And they must allow a person to hold multiple chapter and division memberships. All of these dues amounts must be reflected on each member's renewal notices. It's clearly an enormously complex system for the national to maintain. But this approach works in the interest of the chapters - and the chapters have the upper hand in this case.

So when the policies you are trying to model seem resistant to simplification, remember you are dealing with real conflicts, not just procedural craziness.

Social media and the Surveillance Culture

2008-04-11T05:57:00.007-05:00

Living as I do right in the heart of D.C., things like this happen: I had lunch the other day with a friend who is very knowledgeable about the hacker world within in the so-called "intelligence community".

This is a world where it's common to get your secret clearance before you are old enough to buy a beer. And a sizable crew of these young folks are deployed to monitor - and participate in on behalf of the agency - all sorts of social media activity. Our conversation focused on Facebook, Second Life, and Skype.

"The Agency is deeply involved in Facebook," I was told. This includes both developing techniques to pierce the Facebook's security, and active communication with persons of interest. "Security and Privacy are non-existent on Facebook" my informant told me. The same with Second Life. Organizations hold meetings on Second Life, I put on a sexy female avatar with my breasts hanging out, and I'm just accepted. All the guys have learned to use female avatars and personae on the sites. People will tell you anything" More ominously, I was told they have had some success accessing the computers of people connected to Second Life.

As for Skype, the e-bay owned internet phone service: "There is basically no security employed by Skype. You can use an ordinary packet-sniffing software like any network engineer might buy to detect calls from a specific IP address and reassemble them. We've been working on editing them on the fly to change the content of an active conversation."

Just something to bear in mind, eh?

Control and Flexibility

2008-04-03T05:40:00.012-05:00

Control and Flexibility. These might be two of your goals in in working with your personal trainer. But in configuring your network and key applications, there is always a tension between these ambitions. How much do you lock down to prevent error and occasional malfeasance? How much do you leave open so that each staff member has the greatest ability to work freely and serve your community without running into roadblocks? It's one of the key areas where we see organizational culture influencing Information System design

For example, board members and donors are hoping you keep good track of the comings and goings of their dollars. So there is a pressure to lock down access to financial records to one or two highly qualified individuals. On the other hand, if it takes the CFO to issue a five dollar refund check, you've created a real bottleneck. Somewhere between these two is your financial control balance point.

This fulcrum won't be in the same place for all organizations. For example, a YMCA with it's hectic point-of-sale environment and fifty or sixty part-time or volunteer front-desk staff will arrive at a different solution from a trade association with a full time staff of ten professionals.

The same dichotomy between control and flexibility arises when you start to push out e-commerce capabilities to your community. We see some organizations who are loathe to let a member change his own address. "Do you really work with organizations who do that? What if they make a typo or something?" And at the other extreme, there are organizations who say "If someone calls and wants to register for our workshop, we direct them to the website to enter it themselves. We genlty insist they do it themselves. Staff time is a scarce commodity". Again, your organization needs to find its own comfort point along this scale.

You should rethink this balance periodically though - it is not a simple issue. Too little flexibility and you weaken your staff, your donors, and your membership, diminishing commitment they bring into the organization. Too little control and time, money, and energy flow out the door.

Timeboxing Risks

2008-03-27T08:08:00.007-05:00

Before I got delayed we were talking about delivering software projects on time. Using the Timeboxing approach, the delivery schedule is the one absolute in the implementation plan. What features will be included in the delivery can slip, but never the date.

New requests from the user are added to the queue, but the date is not modified to accomodate them. Unexpected technical problems may delay a feature, but never an install. With this approach, progress may be slower than anticipated, but it never halts, as it can with traditional scheduling, where an installation might be put on hold until all the planned features are completed. We've outlined the benefits to this approach, but there are also some risks.

The most critical risk is safety. If Timeboxing is taken to mean that we just work away at the application until the scheduled delivery date, and then install whatever we have, users can get some nasty shocks. A major new feature might be only partially implemented. Spurious messages meant only for the programmers might appear. Untested calculation might charge people incorrect fees.

The solution is release planning. Timeboxing is not a come as you are party. Sometime before the due date, the team needs to decide what requests can actually be included. Testing on those items must be completed. Features that are not ready for prime time need to be hidden. Changes that should not be delivered need to be rolled back out. This is where a good version control system comes in. Even the sacred install date can be slid by a day or so - not more -- to assure that the work already done is ready to debut. What this really means is that internally the timebox needs to end a day or two early, so the app can be cleaned up for its public appearance.

The Humane Society's LOLseals

2008-03-21T05:57:00.012-05:00

But before we get back to delivering IT projects on time, let's look at some funny pictures.
Certainly none of us have been spared the LOLcats phenomenon - where folks photograph cats and give them funny captions. Here's one my god-daughter Leah posted on Facebook, for example:

Taking off on the popularity of this craze, my friend Carie Lewis, the dynamic internet marketing manager for the Humane Society of the US - one of the most savvy non-profits around when it comes to interactive and social media - has launched an LOLseals contest on the HSUS website. Take a peak.

The idea is to create your own caption for one of the seal pictures. A panel of celebrity judges will announce a winner, who will take home a bunch of great HSUS seal gear. It's a great idea to encourage engagement and awareness of the ongoing plight of Canadian seals.

What is exciting about this contest is the way it changes the images used in educating folks about the seals. The Canadian Seal Hunt is still the worlds largest slaughter of marine mammals. And it happens every year. We are all used to seeing images of baby seals being clubbed. This campaign reminds us of how appealing these animals are, rather than forcing us to look at violent images we've learned to shield ourselves against over the years. It gives the community a new way to engage with the issue, a new way to feel about these animals. It can be hard to find a new way of presenting the same old story - HSUS has found a way here.

Timeboxing your Development Efforts

2008-03-20T06:06:00.010-05:00

How can you make sure you meet your promised deadlines when implementing software projects at your organization? And without late night pizza-driven coding sessions? One approach is Timeboxing.

Timeboxing, quite simply, is an approach to IT implementation planning where the one thing that you do not allow to shift around on you are delivery dates. Everything else may seem totally out of your control. The users have eighteen new features they absolutely need. Your best programmer quits suddenly because she was offered a bit part in a horror movie. You just can't find that bug where new members are going in without their addresses. But you will install SOMETHING on March 18th.

When I first read about timeboxing more than a decade ago, it seemed a nearly impossible technique to explain to the user community. Folks in our client organizations had a list of fixes and enhancements they wanted, and they were not interested in seeing a new version until these were done. But software methodologies have grown to emphasize a more iterative approach to development. In these so-called agile methodologies, fixing the schedule for each new delivery makes perfect sense.

In the Scrum development model, for example, a new version is typically delivered every thirty days. At the beginning of the cycle, the team agrees on what outstanding requests will be included in this release. But if the work does not proceed as smoothly as planned, some of the requests will be left out to allow the iteration to complete on time. The ones that were not completed will be included in the next round.

The advantages of this approach?
1. Users are not left waiting for new features already written as a delivery date keeps moving out to accommodate incoming requests.
2. By getting more features into users hands more quickly, the feedback cycle is tightened and the applications improve more quickly.
3. By allowing feature lists to slip, the "Death March" pressures around deadlines are alleviated, allowing programmers to perform work of a higher quality.

Of course there are risks to timeboxing as well. We'll look at what they are and how release planning can mitigate them in the next post.
------
More reading on timeboxing can be found here.

Policing your Online Image

2008-02-07T06:25:00.000-05:00

The other day I noticed one of my clients had an account on Facebook and I asked her how she was using it. "Mainly", she said, "to police our staff to make sure they haven't posted anything that would reflect badly on our organization".
-- "You could also take the opportunity to post stuff yourself that would promote your organization and mission", I prompted.
--"I don't think so." she chuckled. Then I'd have to be on here twice as much patrolling the responses to my posting."

With a growing number of non-profit communicators finding a powerful role for the social media in their online strategy, it's disturbing to realize how many of their peers still approach things this way. Another client of our voiced this same fearful approach when I was urging them to set up an intranet for in-house conversation and information among their several hundred employees. "Impossible - who will read each of those postings to keep an eye out for inappropriate language or content?"

The fallacy here is simple. These managers believe they currently have control over the organization's image and they don't want to loose it. The fact is, people are already saying whatever they want about them - in private emails, on blogs, on Facebook walls.

Marketing guru Seth Godin in a recent post compares classic brand management to what he calls "tribe management".:

...what people really want is the ability to connect to each other, not to companies. So the permission is used to build a tribe, to build people who want to hear from the company because it helps them connect, it helps them find each other, it gives them a story to tell and something to talk about.

In other words, when non-profit communicators give up and join the tribe that already exists around their organization, they discover that participating in the conversation is far more powerful than policing it.

VRM: CRM's flip side

2008-01-29T17:39:00.001-05:00

Every non-profit now talks about needing to improve their CRM. But thanks to a post by Jay Deragon, I've been doing some reading this week about the emerging concept of VRM, or Vendor Relationship Management -- If CRM refers to software-based tools for organizations to manage their relationships with customers, constituents, and supporters, VRM is the complimentary set of tools, helping those individuals to manage their relationships with companies, organizations, and communities. The idea is appealing - but its actual application still seems quite hazy.

The center of the VRM hub-bub seems to be Project VRM at Harvards' Berkman Center for Internet and Society. Their wiki states that

CRM systems until now have borne the full burden of relating with customers. VRM will provide customers with the means to bear some of that weight, and to help make markets work for both vendors and customers — in ways that don't require the former to "lock in" the latter.

The goal of VRM is to improve the relationship between Demand and Supply by providing new and better ways for the former to relate to the latter. In a larger sense, VRM immodestly intends to improve markets and their mechanisms by equipping customers to be independent leaders and not just captive followers in their relationships with vendors and other parties on the supply side of the marketplace.

Any system that will allow particpation of both vendors and customers (or donors and fundraisers, or politicians and supporters...) starts to point toward the more collaborative environments that are being termed "social media" these days. And indeed, we find VRM being discussed on sites like "The Social Customer" blog by Christopher Carfi, which is trying to evolve models of customer service and marketing that assume a more empowered and participatory customer base.

We are all both customers and vendors. But what does a VRM/CRM collaboration look like? This still seems an open question. I'm not yet seeing anything much more concrete than Carfi's call for "a robust way for customers to manage their own online identities without getting trapped in any vendor's silo. " CRM systems today are offering concrete Return on Investment to their users. The VRM conversation needs to focus on how to provide concrete measurable benefits for customers if this paradigm is gain traction.

Systematizing User Support

2008-01-06T19:02:00.000-05:00

When I started this "Help-Desk" series I wrote: "A great step forward for your informal user support desk is to provide them with a few procedures and tools that can help them be effective and efficient in this function." But so far all I've talked about is the toolkit: putting a ticketing system in place. What about those improved procedures?

Actually, for our little company developing a ticketing system proved to be the key to process improvement: the system made it easier for us to describe, refine, and enforce our approach to support. Turns out it's easier to think calmly and rationally about tickets than about this crisis or that.

The key was the Status field in each the ticket. I know this sounds obvious, but it took us a while to realize it: giving each ticket a well-defined status makes the status if each ticket clear. So as we have made improvements in our process, we've added, removed, or renamed statuses, and made changes to the rules governing status change.

In the early days of our company, we had a customer support process that Jochen Heyland, our CTO, jokingly describes like this. "When a ticket comes in, determine if it is urgent or not. If it is urgent, panic. Drop everything else and address it immediately. If it is not urgent, just forget about it." I still see this panic-driven approach in play at numerous small non-profits. It arises when no other process is defined and you need to think about how to handle each request as it comes over the transom.

How do you improve this? We've moved to a system where any defect reported by a user -- if all goes well -- will pass through 9 statuses. These are Submitted, In review, Approved for action, In progress, Ready to test, In testing, Ready to install, Client testing, Completed. We will also decide if it has Urgent or Normal priority. You might come up with a different process path. That's fine. But having clear terminology for each step helps make the entire process repeatable and controllable.

For example, we used to mark an item Completed once we'd tested it and made it available to the user. But we realized that at that point we were still waiting for the user's final words that a problem had indeed been corrected. So we added the Client Testing status. When items languish in this status for too long, we can take action - like calling to see if the problem has indeed been corrected.

You also need to define the steps on various side paths. For example a defect report might end up with the status Cannot Replicate. Or a request for consultation or training might need to go through Needs Estimate, Estimate Ready, Estimate Pending Client Approval before it gets to Approved.

With this in place, a great deal of your internal administrative work can be accomplished just by calling up a list of items with a particular status. You can sit down as a team and do this. Check what is in progress and see how they are coming along. See what has been approved but not tackled yet -- and find out why. Look for items witht he priority urgent and make sure they jump to the top of the queue. Voila: Order out of chaos.

Turning Help Desk Tickets into Business Intelligence

2008-01-03T06:28:00.000-05:00

I was claiming that getting your informal help desk operation organized with a ticketing system does more than streamline that operation - it provides information that can increase your organization's effectiveness. It can have a real impact on mission. So what information do you want to track in your help desk ticketing system?

Of course you need to know who reported it, how they described it, when it came in, who worked on it, and how it was resolved. But the key is to know what type of requests you are getting, and how much time you spend on each. The values you allow for request type, and whether you allow for a single type or multiple tags, depend on the knowledge you hope to gain. You are trying to partition your universe here, so that you can learn how many and what kinds of problems each area spawns.

You might begin for example with a very simple set of issues.

Networking and Hardware Issues.
Office Suite Issues.
CRM and Database Issues
Website Issues

Then break out areas you have specific questions about. For instance, if you are trying to verify that you spend far to much time on new user setups, you might want to break that out on its own. Or if you feel you are inadequately protected against vius and malware attack, add malware protection and recovery to the list. Maybe you want to distinguish between problems that had to be resolved by a vendor (like software bugs) and which you could resolve in house.

Which types of problems you worked on gains more meaning if you log the amount of time you spent in each ticket. Then you know things like: in the first quarter I spent 10 hours helping people search for documents they misfiled, for a cost to the organization of $400.00 of my time and an estimated additional equal amount in lost productivity. So finding a tool that helps with this problem could be worth up to $3,200 a year to us.

Of course you won't know today what questions you want to ask of your data six months from now. So you really ought to allow for multiple topic tags. For example, if a user reports a problem with scanning credit cards, you may want to tag the request with numerous related terms - Point of Sale, Credit Card, Payment Processing, and Accounting. And you probably want to allow for a full text search of the description, in case you are looking for a term you had not thought to use at the time. Now you are really set to answer questions about the support your IT infrastructure has required.

Next we'll look at how the ticketing system can help you deliver that support most effectively.

The Non-Profit Help Desk.

2008-01-02T05:57:00.000-05:00

Every organization -- no matter how small - needs to have an IT Help Desk of some sort. Actually, every organization already has one, because everyone on staff has figured out "Who ya gonna call?" when hardware or software refuses to behave. A great step forward for your informal user support desk is to provide them with a few procedures and tools that can help them be effective and efficient in this function.

I'm not saying your help desk needs more technical skill. Not at all. As the Wizard of Oz might say, "The non-profit sector is full of help desks that have no more technical skill than yours has. But what they do have that you do not is a Ticketing System.

It's remarkable what even the simplest ticketing system for tracking user requests will do for your informal help desk operation. The users benefit because their requests are less likely to slip through the cracks. Having a formal queue of requests reduces the panic element in support, and this immediately makes the system more efficient. for the entire organization.

But it's the knowledge you gain over time from the ticketing system that is the real benefit. A ticketing system lets your organization track what kinds of support requests are coming in and who submits them. It allows them to know how much time is spent in the aggregate, and on specific types of support. This information provides real business intelligence pointing towards I.T. improvements that you know in advance will save staff time and thus have a positive impact on mission.

What should a Ticket include? More coming up.

Happy Holidays!

2007-12-21T07:03:00.000-05:00

It's been a quiet month on the blog -- because it has been anything but quiet here at Members Only Software.

The YWCA of the National Capital Area launched their Members Only installation this month - so we've been up and down 9th Street quite a few times, working with NPower to get their new server up, talking to the bank to make sure our software was handing Electronic Funds Transfer the way they want, getting the register drawers set up, and a million other details. This is a great organization with the motto: Eliminating Racism, Empowering Women. So how can we not be excited to work them? Last time I checked, that goal hadn't been quite reached yet, so I guess we'll be busy in 2008 as well. I know we will be revamping their fundraising and helping them set up a new website in the next few months.

We've also been hard at work on several new projects we're hoping to launch in February. These organizations are working in diverse areas and show at a glance the wide contribution non-profits are making. The February launches will include the Program for Energy and Sustainable Development at Stanford University, The Danforth Museum of Art in Framingham Massachusetts, and the ARC/Michigan.

We've also finished a pro-bono project. Using a donated CMS from our good friends at Orchid Suites, and a beautiful design by Erica Trauba, we've built a new website for the folks at the Mali Health Organizing Project, a group that is helping a community in Mali to build its own clinic.

Closer to home we've said good-bye to our Technical Ops Coordinator of many years, Raven Matthews, who has moved on focus on security issues on federal computer systems. In her place will be Mildred Blanco, who will be starting with us mid-January.

So have a great holiday, and we'll be back with more news in January!

One Laptop per Child meets the Competition

2007-11-27T06:30:00.000-05:00

A lengthy article in the Wall Street Journal highlights the effect that the One Laptop per Child Initiative has had on the pc industry. The background if you haven't been following: OLPC is a non-profit venture started by the MIT professor Nicholas Negroponte to create laptop computers that could be sold for $100 each and put them in the hands of millions of schoolchildren in less developed countries. The program has had it's critics in the past - educators have worried that the initiative would compete with scarce dollars needed for books and classrooms in the third world, and that the pcs would simply pass through the hands of schoolchildren and be traded on the black market.

But the current article points to one of the unexpected results of the initiative... competition from mainstream vendors who do not want to miss out on this possibly lucrative market. In particular, Intel, whose chief rival AMD provides the processor for the OLPC machine, has launched its own "Classmate" laptop, and is winning support from the governments of many countries OLPC expected to sell to. In addition, education ministries in some of the target countries have been wary of the Linux OS and custom-written open source applications on the OLPC, fearing that their students will not learn the Windows and Office applications that are so prevalent in the business world. The result is that low-cost laptops are being sold to schools in many developing countries today, but surprisingly few are OLPC units.

Asthma Free School Zones

2007-10-30T06:36:00.000-05:00

One really simple way to use less fuel and improve air quality is to avoid using your vehicle's engine - except when driving. Seems simple enough, but our friends at New York's Asthma Free School Zones have been finding it quite a challenge to get this message across. Focusing on the idling of school buses in front of elementary schools, the organization has been able to demonstrate that the air quality at the schools is measurably worse than just a few blocks away. And statistics show a mounting rate of childhood asthma. So remember - idling gets you nowhere. Here's a recent clip about the organization's work from News 12. For more information, you can contact AFSZ at 212-533-6615

Networking and News Sites scramble to keep up with Facebook.

2007-10-19T04:32:00.000-05:00

So in this blog and elsewhere there's been a lot of hullabaloo about Facebook lately. If you weren't sure that this was a herald of a real change in how people expect to use the web, take a look at these four announcements from other major web players.

1) Google: Back last month, TechCrunch reported that google was getting ready for an announcement about an open developer's API that would compete with the attention that the Facebook Platform is getting from developers.

The short version: Google will announce a new set of APIs on November 5 that will allow developers to leverage Google’s social graph data. They’ll start with Orkut and iGoogle (Google’s personalized home page), and expand from there to include Gmail, Google Talk and other Google services over time.

2)LinkedIn, the professional networking site that often seems like little more than a sharable rolodex, has an announcement of its own. BITS reported on October 12th that LinkedIn CEO Dan Nye is "rushing to copy the electronic underpinnings of Facebook’s elegant application programming interface, or A.P.I., that allows outside developers to weave their own programs into its site." But to preserve the all-business-all-the-time feeling of the popular site (current growth is at 1 million new accounts every 25 days) Nye has vowed:

“We have no interest in doing it like Facebook with an open A.P.I. letting people do whatever they want,” Mr. Nye said. “We’re not going to have people sending electronic hamburgers to each other.”

3) MSNBC meanwhile ran a report that it had purchased social news site Newsvine. Newsvine is not as well none as social news innovator Digg, where users rank stories and push them to the "front page". But as MSNBC reported,

the site has generated significant buzz since its launch in March 2006 because of its inventive merger of mainstream reporting from The Associated Press and ESPN; the contributions of individual users, who are paid for their writing; and the social media model of user-driven ranking of the news.

4) MySpace, Facebooks's most direct competitor, has decided that it too needs to be more like it's college-educated sibling. They've recently announced a Myspace platform, with structures and capabilities strikingly like those of it's rival.

The new developer platform... will essentially be a set of APIs and a new markup language that will allow third party developers to create applications that run within MySpace. Developers will be able to include Flash applets, iFrame elements and Javascript snippets in their applications, and access most of the core MySpace resources (profile information, friend list, activity history, etc.). Applications will need to be hosted on MySpace servers.

Measuring the Return from of Social Media.

2007-10-16T05:45:00.001-05:00

A few years ago, when web tools were just beginning to allow the interactive environments we're seeing everywhere today, I wrote a piece called Bread and Butter 2.0. In it I juxtaposed the excitement technologists were trying to communicate about web 2.0 features with the more prosaic "bread and butter" technology issues that non-profits were struggling with. But times have changed - and more organizations are learning that social media can help deliver those bread and butter goals of building and maintaining a base of donors, volunteers, and supporters. And importantly, the return on investment in these technologies can be measured in terms of donations, page views, and names who receive your updates.

For example, the ASAE (American Society of Association Executives) just ran an article called Expand your Audience through Social Media. Largely an interview with Jonathon Colman of The Nature Conservancy, the article focuses on how building trust and presence in online communities can build actual, countable page views on your website: Jonathon describes a campaign where his social networking promotion of a website article earned it 16 thousand views in a single day. Seems pretty bread and butter to me.

Fundraisers are starting to pay attention to social media as well. An article in Fundraising Success describes the efforts of numerous organizations in integrating special media into their marketing and development plan. Life Rolls On Foundation is an L.A. based charity that serves people with spinal chord injuries. Their efforts focused around starting a MySpace page and delivering news, updates, donation requests, and invitations to events to their MySpace community. By now, that community totals over 11,000 friends! This is a list few development directors would turn up their noses at.

Involvement in these new media should not be seen as a hazy excursion into a new-age realm of vaguely possible intangible benefits. Social media involvement can be a core part of your marketing and development efforts. And you should expect to use simple metrics to assess their success - donations, subscribers, page views. You may discover these new tools are pretty bread and butter after all.

Facebook Developers Garage

2007-10-14T06:49:00.001-05:00

Last week I attended the Facebook Developers Garage in DC. I'd pictured it as a room with a bunch of developers at tables, laptops open, showing off the ways they'd managed to build useful tools using the Facebook Platform or API. Instead, it was largely a presentation by folks from the Facebook Platform team - Ami Vora and Ezra Callahan. The evening made clear the excitement, both inside and outside Facebook, that the open platform is generating, as well as the general confusion about what would constitute a truly useful Facebook app and how a developer would monetize it.

Facebook's rate of growth alone make developers want to be associated with it. Currently at about 45 million users, the service is adding about 250,000 users each day. Half of all Facebook users visit the site every day. And despite Facebook's origins as a university-based site, these new users are predominantly older. To attract the developer community, the vc's associated with Facebook have created fbFund, which makes small seed grants ($25K-$250K) to help development groups get a project launched.

Success with the Facebook framework brings its own challenges. TJ Murphy of Freewebs spoke about the experience he had with the Warbook game he wrote. It rapidly picked up 87,000 users, half of whom played ever day. Third party developers are required to host their own apps. So TJ found himself scrambling to scale up: currently the game is hosted at Amazon.

It's the chance of getting in front of audiences this size that is attractive to organizations trying to build their brand. How to do it is the open question. Most third party apps to date have been social entertainments: tools to share music, or book reviews, for example, or utilities to enhance the poking and posting functions of the site. Some of these are quite nice: I really enjoy Christain Montoya's Social Tags application.

But when a member of the audience took the mike to ask how many of the developers in the room were thinking of using the platform to develop a customized presence for individual client organizations who wanted to leverage the popularity and stickiness of the site, I saw no hands but mine. And the people I chatted with at the event seemed to be primarily developers... I met only one representative of a non-profit who was there to explore the possibility of extending the presence of his org via Facebook.

Despite the confusion at this early point, I think it is clear that social networking is going to play an increasing role in non-profit strategies in the near future - and that Facebook, with its developers platform and huge user base, will be a focus of this networking.

To err is human.

2007-10-08T08:13:00.001-05:00

Michelle Murraine, of The Zen of Non-Profit Technology, is hosting the non-profit blog carnival this week and wrote to remind me of the topic. It's a good one:

We all make mistakes in our work with clients. What mistakes have you learned the most from? How do you deal with making mistakes?

We develop application software for non-profit clients. In our work, there are three basic kinds of mistakes we can make. And being human, of course we've made all four. We can make a technical errors: a bug in a program, or a server that is incorrectly configured. Or we can give a client bad technology advice -- for example researching and recommending a third party product that proves to be inadequate to the task.

Errors of these two types this are bound to happen now and then in technology consulting. When everyone involved knows from the very beginning of the engagement that errors can and will occur -- and that errors will be fixed -- these technical errors really present no problem to the long-range consulting relationship.

A written procedure that discusses how such problems are to be reported and how errors will be corrected can go a long way toward building customer trust that the vendor or consultant is poised to fix anything that goes wrong in a complex project. And at times when error discovery might be particularly worrying to the client - during a training, or right at launch - describing problem detection and correction as an integral part of the process will lower client anxiety if a problem is found.

Finally, totally honesty on the part of the vendor or consultant is essential. By doing so you are not only helping to fix the immediate problem, but setting a tone that will improve the entire relationship. Remember, the next mistake might be made by the client. And you certainly want to create a context where they feel free to admit their mistake to you.

But far more serious than technical errors are mistakes that arise out of flawed ways of working. Paradoxically, this third type of mistake -- procedural errors - can often come from unrealistic or ill-thought-out efforts at pleasing the client.

Sometimes you may over-promise in order to land a hot new project. Or you may find yourself bending the truth about budgets and schedules to alleviate a long-time client's anxiety. "Its going to be hard to have the website ready to launch by the 15th, but we will try". Or you may be giving in to what we like to call the Hot Dog syndrome, where you are blatantly showing off how quickly and easily you can do something the client has asked for. It's just human nature to find yourself a flirting with a client or co-worker now and then - , but don't issue a SQL Delete at such a moment! I speak from experience.

You can't always tell that you are giving in to these bad instincts when you are in their grip. It just seems that you are trying to do what the client has asked for. So we've learned that it's important to have procedures and practices in place that force your brain into gear. Small consultancies are typically very light on such procedures -- they slow you down and involve more people at every step - but they can save you and your clients a lot of pain.

For example, we have a rule that two people must approve any estimate for software development. Or that before your run a script to do some manipulation to a client's production database, you need to try it on the TEST installation. Or that someone other than the programmer needs to test any customizations before we release them. These structures help guarantee that clients really get the fruit of our experience.

International Bloggers Day for Burma

2007-10-04T06:08:00.000-05:00

For resources on the struggle against the repressive military government in Burma in the US go t0 the US Campaign for Burma.

Some useful links:

Brian Alexander has an interesting post on the role of mobile phones and web technology in the mobilization of the movement within Burma. Among other things, he points out the YouTube channel of video's from the Burmese struggle.

The Mizzima News is a site specializing in information, photographs, and multimedia coming out of Burma.

To track Burmese bloggers, at home or abroad, keep your eye on Global Voices.

Network Neutrality and AT&T

2007-10-03T06:02:00.001-05:00

The fight over Net Neutrality - the idea that Internet providers should remain neutral regarding the information or applications served over their networks, has been dealt an explicit blow in the new AT&T terms of service, as brought to my attention in a Boing-Boing post by Cory Doctorow. Paragraph 5.1 of this document warns that service can be cut "for conduct AT&T believes tends to damage the name or reputation of AT&T, or its parents, affiliates and subsidiaries."

So AT&T customers aren't allowed to write/podcast/vlog critical things about AT&T, its billing-practices, or its cooperation with illegal NSA wiretapping, on pain of having their connections disconnected.

Generally we've thought of this issue in terms of what services and programming would be available over a vendor's pipeline. But when a major corporation like AT&T simply protects its own reputation -- at first glance an irreproachable act -- the freedom to communicate over the net is significantly compromised.

The wikipedia article on Network Neutrality gives a nice introductory survey to this issue.

Tools and Tips

2007-09-14T05:48:00.000-05:00

Here are a few items brought to my attention recently.

Non-Profit Blogging. Bill Freeman has been writing a blog for about a year on Tips and Tools for NonProfits. You can find him at 501cweb.wordpress.com. One of two non-profit technologists I now know with degrees in theology, Bill brings to his current roles as blogger and consultant an impressive history of non-profit leadership.

Social Bookmarking. Mashable recently posted this index of over 180 tools for use with del.icio.us, the popular social bookmarking site. I've been using the official delicious Firefox extension for over a year now, and consider it Standard Operating Procedure. But taking a look at some of these third party tools makes me forsee a rainy Sunday afternoon of experimentation in my near future. Thanks to photograher and painter Serena Konig for bring this to my attention. If you so any significant amount of online research, and do not yet use del.icio.us, you really ought to look into it.

Email Tools. Speaking of Mashable, back in early August they also published a toolbox of more than 60 add-ons for Gmail. I've only looked at a few of these, but have completely adopted Better Gmail, a repackaging of several earlier Greasemonkey scripts for use with Gmail. Better Gmail provides a host of small improvements to gmail capabilities - my favorite is that finally I can use HTML in my signature. Several of the tools -- this was bound to happen - hide the ads on the right hand sidebar.

And now for something entirely different, here's antisocial networking!

Hot-button telepathy

2007-09-11T07:02:00.000-05:00

Agile methodology Guru Alistair Cockburn wrote that software development is "a cooperative game of communication and invention." But as George Bernard Shaw told us: "The single biggest problem in communication is the illusion that it has taken place." And so we arrive at the challenge when software guys sit down with organizations to make the system do what their users need.

Recently we'd been having a number of conversations with a prospective client. Everything seemed to be going well, and I was pretty sure we were going to get the gig. When we didn't, we of course asked our prospect what particular issues had led them to buy elsewhere. "Well, we loved your software, but there were a few aspects of your approach that really turned us off. One was that you mentioned several times you deliver all the source code with the application. But none of us are programmers; we wouldn't know what to do with it. So we decided we wanted a vendor that did not make us take the source code."

Like so many times in business and life, our first thought was "Boy, these guys don't understand anything! Sheesh!" But then if you want to communicate, you've got to take responsibility for being understood. What mistake had we made that allowed this misunderstanding?

Our mistake was to assume what I call "hot-button telepathy" In our business, openness of applications is a hot-button issue. "Can I have the source? Can I get at the data? Can I host it on my own server" are big questions in our world. So it never dawned on us for a minute that someone might not "just know" that having the source code is a good thing.

Hot-button telepathy is an error users can make too. Your technology vendors do not know the hot-button issues in your non-profit work. You may think every day about the issues involved in fighting malaria in West Africa, or educating girls in Central Asia. But your technology vendors are not. And this can lead to all sorts of miscommunication.

I was at a meeting once where one of the YMCA's we work with was interviewing a prospective networking firm to install a Citrix farm for them. The sales rep, in summing up his presentation, said, "You guys know how to run a health club - you shouldn't also need to learn how to run a wide-area network". Well, saying this almost cost them the gig. Doesn't everybody know that private health clubs are fighting in the courts to have the Y's 501c3 status revoked on the grounds that they are just another health club, and to refer to Ys as health clubs is therefore to deny all the other valuable work the YMCA does in the community? What an insult!

Of course this networking professional was not familiar with this issue, and meant nothing of the sort. After a brief cool-down period the conversation resumed and they won the project. But it just goes to show how right ol' G.B. Shaw was.

Image of George Bernard Shaw from Wikipedia Commons. Description and Attribution.

Summers Over Once Again

2007-09-04T05:32:00.000-05:00

Over the long weekend I finally managed to get started on a new project I've been excited to get involved with - a new website for the Sigida Keneyali health project in Mali that I blogged about in January. Our good friends at Orchid Suites were kind enough to donate the software and hosting for this group, which is tackling public health in the poorest part of the Bamako area. I'll let you know when we launch the site. Meanwhile, here's a post labor day assortment of tidbits that have been brought to my attention by friends over the long weekend.

1. IT at NPOs: Non-Profit Tech Recruiting. Via my friend Marnie Webb's blog, I happened to read this article from Information Week. Reporting on a survey conducted by Johns Hopkins University of recruitment at 790 organizations, the article reports that non-profit organizations find recruiting technology staff particularly difficult. Perceptions that non-profits pay less, provide less attractive benefit packages, and offer less chance for professional advancement were cited by the recruiters as reasons candidates were reluctant to sign up. The study also noted, however, that only 37% of non-profits surveyed were trying to recruit tech staff, while 84% were trying to recruit professional staff in general.

2. Blogging: Why Full-text Feeds Actually Increase Page Views. Tinu Abayomi-Paul points out this little piece that argues that people who put only snippets in their blog's rss feed instead of the full text of their postings, hoping to lure people into their site to finish reading, actually diminish the number of real visits to their site. The article is fairly convincing, and led me to immediately change my feed to provide the full article.

3. Mobile: An Open/Standards-based phone to debut. I got twigged to this offering waiting in the wings by a posting by Riche Zamor on Facebook. OpenMoko is a GNU / Linux based platform for mobile device software development. The company will be releasing their phone, the Neo1973, sometime in November. The Economist says

OpenMoko, an initiative aimed at developing all the technology for a mobile smart phone based on non-proprietary Linux software, is everything the iPhone could have been but is not.

4. And now for something completely different. Just in from Wired: Powerpoint-based Pecha-Kucha takes Tokyo by storm.

Thinking about Software Requirements

2007-08-28T04:41:00.000-05:00

Is your organization getting ready to think about its software requirements?

Sometimes when organizations approach us about their software needs, we are struck by how poorly they have thought out what it is they are looking for. We cannot even guess from their few pages of notes what major pieces of functionality they are seeking, or why they are seeking a new system. Other times we find ourselves staring in dismay at a 100 page Software Requirements Statement detailing field lengths and report structures, to which we are expected to respond in detail. These guys have gone to a lot of effort.

But both of these documents are nearly useless in the context where they are usually handed to us - where an organization's staff and ours are trying to decide if we are a good match for their critical software needs. It's not a problem of having to much or not enough of a requirements statement. The problem is misunderstanding what requirements are, and what they are for.

Following a link in a sidebar of an article in the current issue of Dr Dobbs Magazine, a venerable developers journal, I found a great piece by Karl Wiegers - 10 Requirements Traps to Avoid -that should be a great help to anyone trying to write a requirements statement.

Trap 1 is as far as we are going today. It involves failure to recognize the type of requirements you are setting down. Wiegers identifies three distinct levels of requirements. Business Requirements lay out the needs from the standpoint of organizational problems and goals. From this standpoint there is one actor - the org - with one set of needs. User Requirements look at the information system from points of view of the different staff roles within the organization, and specify what tasks each actor demands of the the software in order to meet the Business Requirements. Finally there are Functional Requirements - detailed descriptions of individual functions the software is going to perform in meeting each user requirement.

For software selection, keep your focus on your organization, not on the application's buttons, checkboxes, and fields. If the task at hand is to distinguish between vendors, the statement of functional requirements is the wrong tool. Instead your starting point ought to be how the vendor and its software will help you address your key business requirements. Ask the vendor how their tools and their approach will help you meet your organization's articulated information systems business requirements, rather than have them check-off whether or not they have certain sorting abilities in a certain report you may not really need. A focus on the micro level can give you the feeling you are doing your due dilligence, but really you are taking your eyes off the prize, which is selecting the software that best supports your mission.

Nuggets from the Information Hailstorm

2007-08-22T05:31:00.000-05:00

One of the more common uses I see my friends making of Twitter is to post a link to an interesting web-based resource. Since the one-line nature of the Twitter post limits the amount of effort that can go into polishing these "miniblogs", I'm getting a virtual hailstorm of information this way. And then there are all the articles, blogs, and videos that my Facebook contacts post every day. There's no way I can begin to keep up with the flood of valuable information my friends are incessantly calling to my attention.

Here are some highlights form the past few days...

1. Grantmaking 2.0 link
[via Holly Ross at NTEN]. Here's an article posted by Amy Luckey at GEO (Grantmakers for Effective Organizations) that talks about the use of collaborative web tools to strengthen the relationships between funders and organizations.

2. Fixing Wikipedia Articles link
[via Michael Gilbert's weekly Nonprofit Online News]
More and more often we find that wikipedia is the first place we are pointed to when seeking information about a person or organization online. Suppose you look up your NPO and find incorrect information in the article? What's the most effective way to correct the article? That's what this piece is about. Just changing it yourself is not always the most effective solution, since Wikipedia staff monitor the IP addresses of people making changes and will often disallow an edit from the organization the article is about.

3. Legal Guidance for e-Commerce link
[via SBTV.com, which I learned about through a post by Tinu Abayomi-Paul]
I'm sure all developers have this happen to them - you are involved in what seems to be the straightforward technical process of setting up an e-commerce site for a client, when the legal questions start. Is a credit card sale binding if the buyer is under 18? What is the legal force of terms and conditions the buyer agrees to by clicking a checkbox? I don't know the answers to most of these. I'm not a lawyer. But the American Bar Association has built a resource to answer your e-commerce legal questions. Built around the kinds of questions that need to be answered when designing and launching a new e-commerce site, safeselling.org is full of answers to questions I'm often asked. [You'll learn for example that courts may consider the size of the font your terms and conditions were in when deciding if they are valid!]

image originally uploaded as http://www.flickr.com/photos/sookie/94778946/

Members Only Software for Free! for an Arts Org

2007-08-17T11:09:00.000-05:00

We're doing it again. If you are a small arts organization, you might qualify to get our software for free. See the announcement on our web site for the details.

Risks and Benefits

2007-08-15T07:34:00.000-05:00

The other day I followed a link on a friend's site to an article about How to Clean up a Broken Compact Fluorescent Light (CFL) Bulb. Turns out that because these increasingly popular bulbs - which use far less energy than old-fashioned incandescents, are made with mercury, there is a small risk of exposure any time one of them breaks. The article gives detailed instructions on how to clean up after such an accident.

So often a piece of technology which is a solution to some major problem brings new risk of its own. In deciding to adopt the new technology, we need to weigh the risks against the benefits. Is wind power worth the risk to birds caused by those rotating blades? But the need to manage the risk continues after the decision is made. I often try to talk to our clients about risk management for the Information Technology advances within their organization.

There are risks are attached to every positive step you make. Suppose your non-profit is emerging from a start-up period, where pretty much every department had its own little contact management solution, in excel, or access, or ACT. Now you're putting in a system that will provide integrated CRM and other functions for the entire organization. It's a great step forward for you. But it adds some new risks, because now you have a new single point of failure. Actually some of these possibilities could be disastrous. If the new system goes down, or becomes corrupt, or loses data, what will you do?

Risks management writers discuss three angles on confronting problems like this.
1) Mitigation: Lowering the likelihood that the unwanted condition will occur.
2) Monitoring: Detecting as soon as possible if an unwanted conditions has occured.
3) Resolution: Managing the situation if it does occur.

For example, suppose we identify the risk of accidental corruption of data through user error as something we are concerned about. Here's an example fresh on my mind - the other day a user of ours changed the last names of a good many of their contacts to LastName. Oops.

How can we address the risk of this kind of accident?

Mitigation might mean: making sure users are properly trained on risky database operations and that most users do not have access to perform them. Monitoring might mean maintaining a log of all database changes for a day that can be glanced at by the db admin for any peculiar activity. Resolution might mean having a plan and utilities in place for selective restoration so data can be loaded back from a backup without losing all the other valid data entry made that day.

Risk Management should be included as a part of the planning for each of your technology projects.

The book that many years ago sparked my interest in Risk Management is Waltzing with Bears, by Tom DeMarco and Timothy Lister.

Voice to Post

2007-08-14T15:33:00.000-05:00

I'm playing with the Voice2Page system that I stumbled across today... It let's you add a voice message on any page -- using the telephone as the recording instrument. Once you have a message you can change it, like changing your voice mail, without touching the code on your page. Sort of cool.

8 random facts about myself

2007-08-03T22:46:00.000-05:00

The lovely Soha El-Borno of the Wild Apricot blog tagged me to play the eight-random facts about myself meme.

First the rules:

1) Post these rules before you give your facts

2) List 8 random facts about yourself

3) At the end of your post, choose (tag) 8 people and list their names, linking to them

4) Leave a comment on their blog, letting them know they've been tagged

Then the facts:

1) One of my great passions is playing old-time fiddle. Every summer for the last seven years Doria and I have gone to Ashokan Southern Week for a musical vacation. Well almost - this summer we went to Ashokan Western-Swing Week instead.

2) While my usual whisky is Jack Daniels because it is better suited to my budget, I adore Talisker - the older the bottling the better.

3) I'm a great fan of the films of Peter Greenaway - especially Prospero's Book's, his envisioning of The Tempest, with the late John Geilgud speaking ALL the roles.

4) I devour mystery paperbacks - recently Doria and I tore through all of Lisa Scottoline's books in less than a month.

5) From 1972 to 1975 I worked at the Berkeley Free Clinic, in Berkeley, Ca. It was my first non-profit, but back then then we thought of it as an alternative institution.

6) In high school my friends and I put out a magazine called Odd. It was issued in a single copy, usually with elaborate covers made of an unusual material - foam rubber, or hinged stainless steel. Each issue passed from hand to hand down the subscription list until it was confiscated by the administration.

7) The first computer I ever used as an IBM 1130. It was about the size of a combined washer-dryer and had 16K of memory. The first program I wrote simulated traffic arriving at an intersection to determine the optimal length for the left turn early lane.

8) The first computer I owned was a TRS-80 Model III in 1981. I wrote a program I called Freelancers Assistant to track and bill my technical writing clients. One of them asked if he could by the program. Oh, this could get good, I thought. But I didn't really get into it full time until the company developing software for my sister's business went bankrupt, and she asked me to finish the project.

Finally: here are the eight people I'm tagging.

The West Coast Michael Stein: http://michaelstein.typepad.com/michael_stein/

Amy Kincaid: http://changematters.blogspot.com/

Marshall Kirkpatrick: http://marshallk.com/

Morra Aarons-Mele: http://womenandwork.org/

Peter Brinkerhof: http://missionbased.blogspot.com/

Susan Reynolds: http://susanreynolds.blogs.com/

Paul Hyland: http://www.paulhyland.com/

Kami Huyse: http://overtonecomm.blogspot.com/

The Dog Days of August

2007-08-02T07:21:00.000-05:00

My Technorati page gives my bio as "I'm a big brown shaggy dog"! I'd like to change this -- some aspects are not quite true - but I do not seem to able to do a thing about it. Selecting edit my account, I see a text box for my bio. I delete the pooch blurb, and replace it with something somewhat more professional:

I write for NGO staff trying to integrate technology more centrally into their strategic planning. And I write for the technologists trying to help them. So we explore new technologies, technology and organizational development, and issues of tech planning, purchasing, and troubleshooting.
My company, Members Only Software, provides applications for a wide rage of non-profit clients, from major public policy think tanks to local YMCAs.

But when I click save, woof! its back to the stuff about the brown dog. Bad Boy!

Which reminds me -- if you have room in your homes, you should adopt a pet this week- (not me - I just checked my food bowl and its lookin' good) -- but the humane societies are bursting. And speaking of them, doesn't the US Humane Society deserve a big tail-wag for bringing focus on the abusive dog-fighting being run by some major sports figures. This is important work. And you can say you heard that it from me: I'm a big brown shaggy dog.

Now let me tell you what I want this thing to do....

2007-08-01T00:00:00.000-05:00

A friend of mine likes to tell this story from his early days as a software consultant. His team had spec'd out a system for a client, and implemented it in somewhat more than three the time they'd included in the contract. Even though they'd lost their shirts, they were full of excitement as they delivered their shiny new application to the client. After the walkthru, the big guy tipped back in his seat, smiled, and said: "This is great. Now let me tell you what I want this thing to DO."

The other night over Indian food I heard the same story from the other side of the desk. A friend who works with a non-profit here in DC was talking about the nightmare installation her group had been suffering through for a year now. They are still waiting for the developer to understand the sort of features they need to really support their workflow. He does deliver a new version every few weeks, but each change seems to break something else. "But I'll bet they're really sorry they agreed to do this for a fixed price" she concluded.

I'm sure they are. But so is she.

When Members Only Software was just starting out, we frequently sold our product in a fixed price engagement - basically saying "We will do what it takes to customize our application for your organization. We will do this for an amount of money we will agree on now, even though we have only a vague idea of what it is you will need." This approach created good clients, who had few special needs; and problem clients, who had many needs.

Later we learned to charge for all of our time. We used to think this would make it difficult to give the client a clear project budget. But that's not true. It's easy to stick to a maximum figure - its just that in this reality the user may not be able to afford everything they would like. This reality encourages everyone to prioritize, and by setting a fixed number of hours to the engagement, makes it much more likely a defined project actually reaches completion.

Amazingly, it also made all clients good clients. The ones with lots of special needs were suddenly sources of revenue, not drains on our time. This in turn was a benefit for our clients with smaller budgets, who could not afford customization but were excited to see the new features that would show up in our service packs as the fruit of someone else's custom need.

Facebook for grown-ups: a first look

2007-07-27T05:58:00.000-05:00

It's a wonder I have any time left to blog at all now that I've signed up for Facebook. But I felt I really ought to give it a test-drive, now that I see so many people urging non-profits to look into it. This post is for those of you who have not even peeked into it yet.

I'll tell you my conclusion up front: For non-profits looking for ways to get their message in front of new audiences, especially a younger tech-friendly community, maintaining a Facebook presence is definitely worth exploring. With 30 million members and growing rapidly, it's going to get you in front of a lot of people.

If you have used any of the business networking sites that have appeared over the years - Ecademy, Xing (formerly OpenBC) or SoFlow (slated to close its doors in just a few days) you'll be familiar with the basic model. It's one that is quite different from the LinkedIn approach - allthough LinkedIn has been making incremental moves in this direction. Compared to these other sites, LinkedIn is just an online Rolodex, while Facebook and sites like it make it easy for you and your contacts to stay in touch.

How does it work? Users create a profile page describing themselves. This is your "home page", as it were. Facebook provides tools for messaging other users, and allows any user to create groups with discussion forums. In addition, you can post links, photos, and notes that can be shared with your Facebook network. When someone in your network posts something or messages you, the system wil also send you an email, so users do not need to check Facebook constantly to see what's new.

But the real promise of Facebook comes from its "application" model. Facebook allows developers to create third party applications -- widgets -- that can be attached to member's profiles - tools for calendaring, say, or advanced messaging. So the capabilities of the system just keep growing. Many of these to date have been "just for fun" - there are at least a dozen tools for listing and rating books and movies for example. But then there are tools that allow a user to make a donation to a cause, or spread the word about an issue. And these tools are viral - if you click on one you find on a friend's profile, it will offer to install itself on yours.

Facebook is free, of course - supported by advertising, including classifieds members can place in the Facebook Marketplace. So there is really no reason not to at least take a look at it. You can find me there by clicking the Facebook link I've added to the left-hand sidebar of this blog.

How does a non-profit organization use Facebook? Some create a personal profile under the organization name. Others have members participate as individual's, and create a group page to represent the organization. I think this latter is more in keeping with the medium - it's far more personal.

You will want to assign the task keeping up your Facebook presence to a specific staff member. If you create your account and leave it there untended, like your old static webpage, it will do you no good at all. Someone needs to participate in discussions, answer messages, update the profile regularly, and make decisions about fundraising tools and so on.

But does anything ever come of it? Well, in the two weeks since I established my account, I've volunteered to help one organization with their website, been asked to bid on a project, donated to a friend's personal fundraising effort, arranged to have lunch with a high-school friend I haven't seen in years, and exchanged emails and notes with at least fifty local non-profit folks I'd never met before.

What I haven't done is find time to blog.

Weekend Links

2007-07-22T06:44:00.000-05:00

1. Tools: Web-development plug in for Firefox
If you do any web-development work, you'll want to get a hold of the Web Developers Extension for Firefox. This capable tool lets you view -- and more importantly, modify in real time -- the css, scripts, images, cookies, and form elements in any page you are viewing. It was the CSS features that got me to install the plug-in. My friend David from Orchid Suites was helping me debug a style sheet, and I was blown away when he brought the css up in a sidebar of the browser and modified parameters, watching the displayed page change instantly as he did so. Really, this thing can save you hours. Give it a try.

2. Management: Mythical man-month and non-profit workloads.
It's almost thirty years since Fred Brooks published his now-classic book "The Mythical Man Month", which revealed the fallacy that throwing more people (called manpower in those benighted days) at a technology project that was getting late would help bring it in on time. About thirty days ago Michelle Martin made some similar observations about non-profit workloads. Michelle's point is that most organizations could more usefully focus on the inefficient use they are making of their current staff resources.

Before we start thinking that if only we had more staff we could do so much better, I think we need to take a look around at our operations and decide if we're doing everything we can to run "lean and mean" with our current resources. Adding more people to a poorly-run organization only means you have more people doing poor work.

3. Social Platforms: Facebook's Future
In the last couple months there's been a growing interest in the university-centered Facebook platform in the non-profit community, especially as organizations ponder outreach to the Millennial generation. Facebook currently has 25 million subscribers and envisions growing to four times that size within the year. Part of Facebook's appeal stems from its open development platform, which allows third parties to create software extensions that users - and soon groups - can choose to install. On this video I found via Nick O'Neill's blog, Facebook's 23 year old founder and CEO Mark Zuckerman - discusses Facebook's future plans for the platform with a group of developers.

4. And now for something completely different
Looking for a summer tech project to while away the time you should be using to do something productive? This looks like fun.

Is your printer going to turn you in?

2007-07-15T19:31:00.000-05:00

A twitter posting from Andy Carvin alerted me to this unnerving situation. According to Threat Level, a blog on security and privacy issues at Wired magazine,

Manufacturers of color laser printers quietly cooperated with the Secret Service to print nearly invisible tracking codes on every color page printed through laser printers individuals buy, ostensibly as a way to track down forgeries.

According to a page maintained by the MIT Media Lab, a pattern of nearly undetectable yellow dots is printed on each page:

The yellow dots are hard to see with the naked eye, but can be seen under bright blue light or with a microscope. Their arrangement reveals which printer was used to print a particular document, and sometimes also shows when it was printed. Some of the codes have been understood while others are still mysterious, but none of the printer manufacturers has denied that the dots are intended to help track a particular document to a particular printer (or that they can actually be used for this purpose).

The Electronic Freedom Foundation (EFF) has posted a list of the printers and manufacturers known to support this surreptitious tracking.

Industrial-Strength Software

2007-07-13T08:15:00.000-05:00

Via Twitterer par excellence Geore Dearing and his Enterprise Content Management blog, I found this article by blogger Nick Carr published in the Guardian. Nick focuses on a rarely discussed side-effect of the move towards internet-hosted applications: the need of software companies to maintain their own vast server farms. Pointing out that firms as diverse as Google, Microsoft, and Salesforce.com are all in the midst of plant expansions to boost their online capacity, Nick comments that.

..today's software companies are finding that, as more computing tasks move online, they have to compete not just on the elegance of their programs, but on their ingenuity and efficiency in buying and deploying physical assets - land, buildings, computers, and other gear - as well as managing the huge amounts of energy required to keep all the machines running.

As Nick points out, one of the industry-shaking implications is that the capital barrier to competing in the software field is beginning to change. Traditionally this was a field that did not demand a backbreaking investment from a start-up, but that may be changing.

Another implication is the energy footprint of computer use. As server infrastructure grows (just glance at these articles on Google's development projects in Iowa, and North Carolina) energy use increases as well. According to a study done at the Lawrence National Laboratory at Berkely, in 2005 server farms already consumed a whopping 1.2 percent of the total electricity produced in the U.S. Clearly online computing is destined to be an even greater consumer of energy. Read more about the energy implications of computing in The Green Wombat.

image of Google Campus originally uploaded as http://www.flickr.com/photos/tedsblog/29719214/

Agile Software Development for Non-Profits

2007-07-10T16:31:00.000-05:00

"When the road bends, you cannot walk straight." It's an old gypsy proverb. I ran into it as the epigraph to Gypsy Caravan, a great film by director Jasmine Dellal, documenting the six week U.S. tour of gypsy musicians from all over the world. But it's also the secret of effective technology project management.

When I first started out building software, one of the books I read was Tony DeMarco's Controlling Software Projects. It helped me understand the real forces that lead developers and other stakeholders to underestimate timelines and generally plan poorly. But somehow, (maybe it was the title) it left me with the feeling that when I got really good at this I'd be able to map out the path of a project in advance and steer it right in, exactly as imagined. All we needed to do was perfect our techniques at requirements analysis, estimation, coding, testing, deployment, training, documentation, and coffee-brewing.

But it seemed that no matter how hard we tried on each project, the road always took an unexpected turn somewhere. At testing time the clients suddenly thought of an unanticipated set of requirements. At training time, a horrible bug surfaced. On the day the client was going to deploy, their network was brought to its knees by a virus. No matter how hard we tried to control the process, something went wrong that forced us to regroup.

Gradually we were forced to surrender to the reality that significant software projects were always going to take us by surprise now and then. Others have discovered this too, and it's led to the approach referred to as Agile Software Development. Agile development recognizes that the road is going to bend - indeed it is rarely going to be straight. So agile methods stress responding rather than controlling.

For example:
We used to try desperately to assure that during training no bugs would be found and no specification changes would be offered. It was futile. Training rooms, with ten novice users banging at the keyboards are in fact perfect software testing labs that will inevitably find some lurking defects. And a roomful of your staff getting their hands on the new software for the first time are bound to come up with some new ideas.

The fact is there will almost certainly be change requests and problem reports during my training sessions. So let's learn to manage them wisely. Today, at the beginning of a training session, we put up two flipcharts -- one to record any reported problems, and one to park any requested change or enhancement. These items can be acted upon later, but by capturing them here, we have turned what used to be a disruption in the training into added value that moves the project on, around the bend.

In a way, all the repeatable improvements we've made in our methodology are no more than this -- to anticipate the unavoidable bends in the road, so we can take them at speed without leaving the roadway.

Image originally posted as http://www.flickr.com/photos/improveit/525851663/in/set-72157600298986170/

Beyond the user experience

2007-07-07T13:14:00.000-05:00

This week the e-newsletter put out by consulting giant McKinsey ran a piece about how Merrill Lynch, the global financial services firm, has combined its Information Technology and Operations departments. Their purpose: to enhance the delivery of service to the customer, which more and more depends on the IT infrastructure.

Diane Schueneman, who is overseeing this integration, says:

So the whole reason to combine technology and operations rests on the customer’s needs. And to deliver against those needs requires the best operational processes and the best technology. But you can’t start with one and graft on the other. It’s the integration of technology and operations, from beginning to end, that really allows you to serve customers effectively.

It got me thinking about the structural placement of IT in non-profit organizations. In a great many of the non-profits we've worked with over the years, Information Technology is situated in the finance and administration wing of the org chart. Yet any one of these organizations would probably agree with the statement that the purpose of IT is to enhance mission, not simply to improve administration.

One of the YMCAs we work with recently removed responsibility for our Members Only applications from the CFO's office and gave it to the Marketing Director. Our app is used to manage every one of their programs, and directly feeds their financial system. At first I thought the move was irrational. But I've changed my tune.

The person directly responsible for outreach and retention of clients at this organization is now also responsible for their mission-critical applications. In the past, evolving software requirements were often phrased as "Here's some new information we need to track" or "Here are some business rules we need the application to enforce." These needs are not forgotten about now, but under the new regime we also hear things like "We are trying to improve the experience of the member at the front desk, so we'd like to... "

There is a lot of talk about "user experience" in IT these days. But the focus on experience needs to be expanded beyond your direct users. There is a wide community -- donors, clients, board members -- who are not users of your information system per se, but whose experience with your organization is profoundly affected by it. Delays, user errors, down time, incomplete information - these all interfere with program delivery, client service, and fundraising efforts. Shouldn't more non-profits consider organizationally tying the evolution of their IT infrastructure to the development of their programs and services?

Image originally uploaded as http://www.flickr.com/photos/knobil/75758280/

Keys to success in technology projects

2007-06-20T08:05:00.001-05:00

This week Jeff Atwood has a great post in his Coding Horror blog, excerpting from Steve McConnell's 1996 book Rapid Development. He quotes a list of "36 Classic Development Mistakes" that can doom your project. I've had to extricate teams (and I admit it, myself) from many of these over the years. Jeff and Steve are thinking about software development efforts, but any technology project is prone to these mistakes. Avoiding these mistakes are the keys to success.

Three biggies I've struggled with are:

Heroics. This is probably the most common software mistake of all. A project looks like its going to need four more weeks of work. There are two weeks left to delivery date. Solution? The team works 16 hours days for 15 days. The result? The deadline needs to be slipped after all, a lot midnight code needs to be reworked, everyone is raw and ragged, and developer-user relations are frayed. Programmers are by temperament very prone to heroics, but users can encourage it by reluctance to modify deadlines when necessary. Key to Success: when schedules start to slip, accept reality and make adjustments.

Insufficient Risk Management. As the authors of "Waltzing with Bears" note, every worthwhile software project carries significant risk -- or it would already be done. Developers often gloss over risks due to what my wife Doria calls "the hot dog factor" - the assumption that nothing will go wrong because they are real hot dogs. And users hide from risks because they do not want to confront them, plan for them, or call them to their superior's attention. When a problem emerges, it blindsides everyone. Key to Success: you really do need to plan for those unpleasant possibilities.

Feature Creep. This one has be written about so often that it is easy to forget about - then you see it happening again. Users and developers put in a lot of hard work together to specify the desired behavior of the some new application. The as release date looms, there are more and more features user's can't live without. It may seem like its just correcting design shortcomings or adding flexibility. But release dates are missed, new bugs are introduced, and unintended consequences of these late change are discovered at the worst possible times. And when features do not seem to cost anything to users, all bets are off - there is no way to consider the return on investment of the development effort.

It's easy to blame feature creep entirely on the users. But developers can encourage creep if they do not have clearcut process in place for tracking and accepting user requests. And they're setting themselves up for last minute change requests if they don't check in frequently with users as they work to make sure they are on the same page.
The moral: You need a well-defined process, and supporting tools, for tracking and managing your user's requests.

image originally uploaded as: http://www.flickr.com/photos/nicohogg/344155950/

Getting your Message Across: : A Link Roundup

2007-06-15T14:16:00.001-05:00

There's a lot of talk about accidental techies nowadays. But the non-profit world is also full of accidental marketeers: people who are experts in their subject but struggling beginners when it comes to selling their organization's programs to donors. This first half of June the blogosphere has been full of tips to help the accidental marketeer.

1. Underpromising
A few days ago The Agitator talked about the current marketing maxim advising companies to "underpromise and overdeliver" and wondered how this applied to non-profits.

How do you understate or modestly state your need, its urgency, the unique effectiveness of your approach, or the impact you expect to have, without getting drowned out by your more shrill or flamboyant competitors?

An interesting question. It would seem to me that that underpromising does not mean to play down the need, or the quality of your approach. It means only to avoid making specific quantitative promises you might fall short on. There is no need to understate the devastating effects of Malaria. And by no means play down your great idea of placing health aides in popular cybercafes to provide information and sell treated nets to customers waiting for a p.c. But if your goal is to train and place 50 of these folks in the first year, promise 35 in your literature. Then do better.

2. Headlining
A List Apart, a site devoted to website design and technique, focused recently on some very non-technical aspects of online marketing: the effective writing and and layout of web pages that sell your message. As they say,

A lot of web copy is written by copywriters who aren’t trained in writing for the web—and much of the rest is written by people who aren’t trained writers at all.

The article begins with simple advice on writing headlines and moves on to discuss an entire menu of techniques for writing online marketing messages.

3. Getting people talking
The book is sandwiched between a forward by Seth Godin and an afterword by Guy Kawasaki... how can you not want to check out what these two communication gurus are endorsing? Word of Mouth Marketing: How Smart Companies Get People Talking, by Andy Sernovitz is a quick read that will get your head buzzing with ideas about how get your communities buzzing. For example, they remind you to reach out to all those bloggers you read, and tell them your news. They just might pass it on. Like this. But the book is full of far more surprising ideas that organizations have come up with to get their message out there.

4. And helping others talk less.
While it's your goal to get your community talking more, some of us tend to talk on and on. Kivi Leroux Miller says she's found that about 60% of people complain that their writing is to verbose, and she provides six smart tips for pruning your prose. If you find yourelf doing more and more writing on behalf of your organization, you ought to pay attention to her blog, Non-Profit Communications.

5. Non-Profit Market Research.
But whoa! Before you start writing, editing, and launching campaigns, do a little research first. Think market research is only for rich organizations? Check out Katya's Non-profit Marketing Blog. She can show you four things you can do for free without leaving your office that will leave you with a good bit more information than you started with about your organization and its brand.

image originally uploaded as http://www.flickr.com/photos/dewayne_smith/433951055/

When is an email campaign SPAM?

2007-06-14T15:29:00.001-05:00

I wrote about this a while back but I still frequently hear our clients worrying that every email they send out might be violating the CAN-SPAM act. Calm down. The law does not prohibit the sending of unsolicited commercial emails. It does not require people to opt-in to an email list in order for you to communicate with them. What it does do is set some very clear requirements that your unsolicited commercial email must meet.

You must provide real, working FROM and REPLY-TO email addresses.
You must provide an opt-out mechanism so users can request an email stop. You have ten days to act on such an opt-out request.
You must provide your full postal address.
Your must not use a deceptive subject line - it must make it clear the email is an advertisement or a solicitation.

The law also prohibits the automated harvesting or generation of email addresses.

But what the law terms "transactional" or "relational" emails are exempt from the CAN-SPAM law's requirements. That means a follow-up to a transaction (a confirmation, thank you, receipt, etc) does not require an opt-out or a working reply to. Nor does an email sent to someone you already have a commercial relationship with, if it is not a solicitation.

In the last few months, one of our clients worried they were spamming if they emailed overdue notices to their members. Another was afraid that they could not send an email touting the launch of a new program to their existing donor list. Both of these are quite legal. The first is a transactional email not covered by the law. The second is an advertisement or solicitation and requires that you meet the opt out and other guidelines.

But just because you meet the legal requirements doesn't mean everyone will be happy to be downstream of your communications. As a marketer, that should worry you even when there are no legal issues involved. As Wendy Roth says,

Recipients hold email senders, whether political, non-profit or commercial, to a higher standard than what is required by the law.

So use some common sense when launching an email campaign. Limit the frequency of your unsolicited messages. Target your communications so they will be genuinely useful and interesting to the recipients. And make sure you meet the CAN-SPAM guidelines when they apply.

There is a nice synopsis of the CAN-SPAM act posted at the Federal Trade Commission website.
Spam image originally uploaded as: http://www.flickr.com/photos/pe5pe/59398685/

Estimating Programmer Time

2007-06-11T07:12:00.000-05:00

I've had a few questions in my mailbox recently about this subject -- and as leader of a company that provides software development services, it's one that is dear to my heart. Our usual way of working with our clients is to estimate the time required for any requested programming task, and to guarantee we will come in within 20% of that estimate. So arriving at an inaccurate projection can really hurt.

The good news is we've gotten better at it over time; the bad news is that it is not easy, and there will inevitably be occasions when a task takes much longer than expected to complete. Here's what we've learned over the years.

1. The starting point - look at how often you underestimate and compare it to how often you overestimate. You aren't really surprised, are you? All developers have a tendency to underestimate how long a task will take. Programming provides one of the most clear-cut examples of that oft-stated law: "Everything takes longer than you think it will, even when you take this law into account." Understanding the factors that lead to this is the heart of becoming a better estimator.

2. The most important tool you can have handy when trying to estimate is a database of how long things have actually taken you in the past. If you do not track your time - your entire group's time - against specific development tasks, you should start doing that now.

3. Estimate in pairs. Your accuracy will go way up.

4. Here's the key: remember that the bulk of a programmer's time is not spent actually writing the new code, but in (1) figuring out how the existing program works, (2) determining where to make the change, (3) verifying that the change actually works, and (4) debugging any problems found. These are the times that are hardest to control, and are the most often overlooked: novice programmers habitually underestimate the likelihood that problems will emerge in testing.

5. To manage this, include estimates of "design and analysis" time, and "testing" time, and assume some time will be needed for debugging -- even in what seem to be the simplest modifications or enhancements. Remember to include time for defects found not just by the programming team, but by customers and end users after the item goes into production.

6. Be willing to revise the estimate after the initial few hours of the work. Perhaps the estimate was based on the idea that some new components could be dropped quickly onto a form. But it turns out the form is so crowded with widgets and gizmos that it needs to be completely re-structured. If good estimates are needed to track costs or delivery dates, programmers need to become alert to the fact that discoveries which will affect development timelines need to be reported immediately so other stakeholders can revise their expectations.

image originally uploaded as http://www.flickr.com/photos/aarongeller/360135019/

Five tips for software systems training

2007-06-03T16:02:00.000-05:00

My good friend Adriano Pianesi, the former trainer at Members Only Software, has taken the bull by the horns and announced the creation of his own training consultancy, Participaction. Take a look at this site - you'll see his approach goes way beyond drilling users on what button to click when. Adriano and I have had some long conversations over the years about how to best provide the training organizations need to make effective use of their information systems, and he led us in experimenting with a lot of different ways of doing training. We've led some awful sessions and some great ones. Eventually, we found that traditional classroom training was rarely the solution. Here are some of the things we learned:

1. Information Systems training needs to focus more on organizational policy and business practices than on technology. It's easy to teach someone how to issue an invoice. But who is the customer? When are invoices issued? What should you do if the system warns that an account code was not set up properly? Without this kind of knowledge, your users will have a long slow climb to productivity on the new system. But its not the software guys who know this. So the training needs to be a collaboration.

2. Information Systems rollout trainings need to include a change management component. Mission critical software rollouts have broad implications for the way people work. Otherwise, why bother? But to say "this will make our work easier" or "these tools will help our teams collaborate" just skims the surface. The users know the new system will alter their day-to-day lives. They may be eager for the change, afraid of it, or just plain resentful of the disruption. The training is a time to prepare for procedural upheavals.

3. Training needs to be active and interactive. Presentation and drill on the workings of the system are boring and ineffective. Training sessions need to actively engage the user from the first minute. We found, for example, that a treasure hunt -- plopping the users in teams in front of the new system and asking them to figure how to find things was far more effective than a presentation of where key information is to be found.

4. Your organization needs a plan for ongoing training. This is an area we see most organizations neglecting. Everyone knows they need new system training. But how will you deal with staff turnover? After a couple years, some of your key users will move on, and you will have new staff members who come in and find the system already in place. You need to create sustainable plan to train these new staff members without constantly paying someone from the outside to do it. You need ongoing training for other reasons, too. Staff forget things they learned but have not been using. And the software has seen a few updates by now - are you sure you are getting the full use out of your applications?

5. The answers to most of your ongoing training needs are already in your organization. The ongoing training is not as difficult to organize as you might imagine, because someone in your organization knows the answer to almost every question someone else has. The challenge is to make the knowledge accessible to your users. We did an advanced users training a few years back at one of our YMCAs. People were asked to submit questions in advance - and we got 56 of them. At the training, we broke the sixteen participants into tables of four and randomly distributed the questions to the tables. Each table was to present to the group the answers to the questions they'd been dealt. If no one at the table new the answer, they'd solicit help from other tables. On only 6 out of the 56 questions was our help needed at all. So the real issue had not been training in the traditional sense - but simply setting up a structure for sharing the information.

image originally uploaded as http://www.flickr.com/photos/leighblackall/76202405/

Keeping the magic in technology consulting relationships

2007-05-20T14:52:00.000-05:00

There are obviously some real benefits for a non-profit in building lasting partnerships with its technology vendors and assistance providers. But as in any long-term relationship, the are also special challenges that can emerge after a long association.

When an organization puts in a new enterprise software system, the process spurs excitement, collaboration, and communication. Users from all over the organization are sought out for their input, and leadership strives to win a high-level of buy-in from stakeholders of all sorts. The users are galvanized, attending requirements sessions, reviewing documents, participating in walk-thrus, and coming to training.

But fast-forward five years. Many of the staff who brought in the current vendors have moved on. To new staff members in leadership positions, the technology seems no longer a taste of the organization's future, but just what they found in place when they were hired. Upgrades and enhancements are made to the hardware and software without much fanfare, and without much end-user involvement.

And the excitement fades for the vendor too. The big new client everyone pulled together to win is now just another user with a support contract. As in a marriage, the technologist and the users have begun to take each other for granted. And this starts to take a toll on the solution itself. How can the old magic be put back into the relationship?

Here's what we've learned over the years:

1. Increase the opportunities for communication. Don't only hold discussions about specific requests or problems; sit down at least once a year -- developers and users - to evaluate the work done in the recent past and look down the road together at what is coming up in the near future.

2. Frequently re-assess requirements. Remember as staff has changed over the years, neither party any longer has the project history at its fingertips. Seven-year old user requests may be seen by today's staff as just the weird way their software works. Periodic discussions about specific domains - financial reporting, membership tracking, program management, etc - can make sure these processes are re-engineered before they lead to frustration.

3. Weed out needless complexity. Don't just focus on new requirements: Stay on the lookout for parts of the system that are no longer used. Software projects have a tendency to grow over the years, since user requests are almost invariably to add - almost never to remove - fuctionality. Pruning away functionality that is no longer required makes the entire system easier to use and friendlier to users. Remove needless fields from forms, tables from databases, columns from reports, and functions from menus.

4. Get physical. Webinar software and remote support tools have made it ever more easy to support technology from afar. But it's hard to maintain a relationship of such critical importance without sitting across the table from one another from time to time. Have a meeting. Go to a restaurant. Sit at the same workstation. You'll be surprised at the level of communication you've been doing without.

image originally uploaded as http://www.flickr.com/photos/bb_matt/306544780/

Efficiency in non-profit operations

2007-04-30T15:59:00.000-05:00

There's been some discussion on the boards recently about paradigms of non-profit management that gets phrased "Should a non-profit be run like a business?" It's a funny phrasing. There are well-run businesses and poorly run businesses. Honestly run businesses and criminally run businesses. I'm not sure what it means to be run like a business -- but it's clear that question is asking something about to what extent fiscal considerations should govern non-profit operations.

So lets begin by asking, "how high are such considerations currently on the agenda of the non-profit leader?" I'm glad you asked. The answer is, right at the top. In a study I've quoted before, the consulting firm Accenture surveyed more than 200 non-profit executives. When asked what the top five issues were that they confronted in managing their organization, the execs listed:

Expanding the current donor base
Recruiting high-impact board members
Increasing donations from current donors
Attracting and retaining skilled staff
Increasing donor loyalty and retention

In other words, increasing revenue and retaining staff - issues that would certainly be high on the on the agenda of any small business owner as well. So you could say these non-profits are already being run like businesses. But maybe they could be run better. What the execs did not list were ways to increase the use they got out of their existing resources by increasing operational efficiency. The study recommended the following approaches:

Make better use of technology.
Overcome inherent limitations in headcount by more effectively organizing and managing volunteers as an extension of paid staff.
Explore and adopt new collaborative business models with complementary organizations.
Convince corporate and private-sector donors to fund general operations instead of “signature” or “vanity” programs.
Adopt appropriate metrics that enable organizations to evaluate the success and impact of their delivery of services and programs.
Engage board members to ensure quality governance structures.

All of these in effect are efforts to allow more of the existing financial and human resources to flow directly into mission by lowering administrative costs, eliminating procedural barriers, and tapping underutilized organizational and community assets. If this is taken as a definition of efficiency, I think it's something both businesses and non-profits could use more of. I know mine could.

Image originally uploaded as http://www.flickr.com/photos/joelmutate/46795031/

One Laptop Per Child

2007-04-29T13:10:00.000-05:00

Stu Leigh of Real World Productions sent me a link the this video, in which Hakon Wium Lie, the CTO of Opera Software, demonstrates the hardware for the new OLPC (One Laptop Per Child) initiaitve. It's pretty impressive. Opera, if you didn't know, is providing the web browser for the OLPC effort.

It's hard not to be enthusiastic about the OLPC project, originally conceived by MIT's Nicholas Negroponte. But my thinking was focused a bit by a posting I stumbled into that offers some criticisms of the project from a basically supportive stance.

Hold my calls

2007-04-26T05:34:00.000-05:00

Technology Review published a survey of the role of mobile technology in the developing economies this past January. Going beyond the merely anecdotal, the article tried to put some metric on the role mobile technology plays in growth in these countries.

Based on market research in China, India and the Philippines, consulting firm McKinsey & Co. found that raising wireless penetration by 10 percentage points can lead to an increase in gross domestic product of about 0.5 percent, or around US$12 billion for an economy the size of China.

The economic power comes from the ability to communicate with suppliers and customers across greater distances, often allowing unproductive middlemen to be cut out of the process.

To we technologically inclined folks this may seem obvious, but not everyone sees it. Last weekend I met Canadian filmmaker Sylvain l'Esperance, whose wonderful documentary about life in the Niger Inland Delta region of Mali was showing at the Toronto Hot Docs film festival. Chatting after the screening, l'Esperance was saying that he thought the sale of cellphones was an economic drain in the regions he visited: people seem to be spending cash they could be saving for economic betterment to chatter on the phone. But the preponderance of what I read convinces me he's wrong.

What moved me to think about mobile technology in the developing world today was this report of mobile activism in the developing world: a young girl arranged her rescue from a forced marriage by texting her schoolmates.

Folks like The Other Michael Stein have been blogging for a while now about the value of cell phones in mobilizing advocacy campaigns. Because of my personal distaste for phone interruptions I've tended to pay very little attention to what people are doing in this area. I think I need a wake up call.

The Browserless Internet

2007-04-19T15:08:00.000-05:00

It's not really a new a idea - here's a Network World article from more than six years ago talking about the idea. But I think we are going to hear lot's more about it real soon now. This week, Adobe Labs released the first public version of its much-heralded Apollo development environment, a cross-platform tool to build internet applications that live on the desktop, with all the additional solidity and security that can provide. Here's a video of a wee demo: a desktop application that manages e-bay auctions.

We've been thinking about such applications for over a year here: last May I wrote in this blog

The idea of the Internet and the browser have been welded together in our minds, but really the Browser is just one way to display the content we pull across the network. Developers are just starting to realize that what used to be thought of as desktop apps can access data and content from anywhere on the net just as a browser can.

I'm convinced that this technology - not Apollo in particular - but internet delivered desktop apps using the public net rather than your office LAN as their infrastructure - are going to bring a lot of power and security to non-profit applications in the very near future. The major development platforms have been working with components that handle internet data and document access for years now; browserless internet apps can be built in virtually any of the existing desktop development environments popular today.

So stay tuned.

Tooth-fairy economics

2007-04-17T07:41:00.000-05:00

The discussion of Open Content I joined last week has continued. In an articulate polemic Laura Quinn of Idealware lambastes what she calls the "tooth-fairy" idealism those who maintain that all content in the non-profit sector ought to be free.

I think we as a community also need to consider possible negative impacts of advocating that all content ought to be open. It’s already very difficult to pay for the effort of creating great content. If in addition we promote in people’s mind the idea that all content ought to be free, it’s hard to escape promoting the idea that no content is worth paying for. Which puts us in danger of tipping an environment in which it’s very difficult to support good content into one in which it’s downright impossible.

Let me emphasize one phrase of Laura's: It’s hard to escape promoting the idea that no content is worth paying for. In a sense it boils down to the value of content. No one is advocating that all staff of non-profits work for free, for example. A person's time has value! What one is willing to pay for something reflects the value one places on it. David Geilhufe comes out and posits this directly, in a posting in his Social Source blog. He writes:

Content is no longer a value generator... it is a consumer capturer. You need to capture the consumer with your free content and then extract value through alternate channels... ads, products, services, memberships, etc.

I've always thought the word content itself leads us in this direction. Content is just so much stuff - as in "We need a stream of content for our website." Contents may settle during shipping. When it is seen as content, it's just something you can buy by the pound. I'd like us to throw the word out!

Content economics places sharp limits on what kind of media will be created, since it makes it difficult to pay for creating media that might take weeks or months to prepare. And it eliminates, for the creator, the ability to take advantage of the economies of reselling their work to finance additional creation. This devaluation of text and media will lead inevitably to a paucity of high quality materials. And keeps the non-profit world in charity mode, supplied by creators who do not need to earn a living.

Laura's comments are important because her project has tried to create just this sort of serious media - pieces of work that are not created in in just a few days. Pieces of work that are of direct value in themselves. Laura is not creating media, as David suggests one ought, to lure you into her site. The media here IS the service. So how do we propose to pay for it?

Image uploaded as http://www.flickr.com/photos/mikebabcock/58508023/

News from Members Only Software

2007-04-13T08:36:00.000-05:00

As many of you know, we were sad this week to see long time Project Manager Krista Bocus decamp to tackle an opportunity in a very different industry. She was getting burned out by her at-least-an-hour commute into DC every day. And having been with us for over a decade, she felt the need for a new challenge.

Krista was very involved in our efforts to find just the right person to fill her slot; and we're very excited by the results. Next week Gale Mamatova will be sitting in Krista's seat as Project Coordinator. (Or at least someone's seat - we have a tendency to play musical offices every time someone joins or leaves)

Gale comes to us after several years of experience in the association and non-profit world here in D.C. Most recently she was at the American Academy of Child and Adolescent Psychiatry (AACAP), and before that at the Eurasia Foundation. Gale has worked with a number of non-profit software packages in these positions. Not a techie at heart, she's worked in development, grants management, and program development. So she brings a much needed user's viewpoint into our team.

Gale is currently working towards a masters degree in public administration with a focus on non-governmental organizations. Her passion for the non-profit and association world will bring real value to our users! She'll be starting on April 18th.

Open Source Economics

2007-04-10T07:43:00.000-05:00

At a session on Web2.0 at last week's NTC conference in Washington, a woman took the microphone to comment on a conundrum her non-profit is facing. About 40% of her organization's revenue comes from the sale of educational video's in the K-12 market. They suspected they could significantly increase their visability by posting content for free on the internet - but this would destroy their sustainability. How can they take advantage of these new web-based distribution tools without going broke?

It's the same problem the record labels are facing. New distribution technology is forcing new business models. Independent Software Vendors (ISV's) have been wrestling with this for years, as the success of the Open Source movement places a downward pressure on the value of software.

While the Free and Open Source community has always stressed that Free in the FOSS context is "Free as in Free Speech, not Free as in Free Beer", the reality is that much open source software is available at no cost. To adopt or compete with this model, independent developers who must generate revenue to meet payroll have created new business models. Some vendors, such as MySQL, have a split model - a free license and a commercial license, for example. Others, such as Red Hat, expect to make their money from implementation and support services.

But generating enough cash to amortize software development this way is a challenge. A few years back,Steven J. Vaughan-Nichols wrote a piece in eweek called Going Broke with Free Software that documented the stress the developers of open-source software were under to produce revenue, and he interviewed several who had taken positions in proprietary firms like Microsoft to pay the the bills. Just yesterday, I spotted this programmer's blog post about why he has opted NOT to provide his work as Open-Source. Vaughan-Nichols concludes

Yes, you can pay nothing for most open-source software, but if you want to see the next and better version of it, you'd better start paying something for it.

This week, Michelle Murraine in her blog takes non-profit pundit Michael Gilbert to task for charging for his new journal, Journal of Information Technology in Social Change. Michelle also publishes Michael's response, where he cites the necessity of raising revenue to sustain publication. Since Free and Open Source groceries and housing don't seem to be on the horizon, I think this tension between free distribution and the need to sustain organizations will be with us for while.

image posted as http://www.flickr.com/photos/loneprimate/451169287/

Varieties of Membership Management

2007-04-01T18:02:00.000-05:00

A naturalist studying non-profit membership organizations would quickly identify two principal subspecies.

One sort of specimen is the type of organization that NTEN classifies as the "mutual benefit organization". The organization exists primarily to serve its members; the members join specifically enjoy the benefits the organization will provide to them. They want the journals and publications, the professional seminars, the reduced prices on publications or classes. This subspecies includes trade associations and professional societies. But it also includes groups like JCCs and YMCAs.

The other sort are organizations that exist to serve a broad social or cultural goal. Membership here is a way to package fundraising. Members join primarily to offer financial support to the organization, although a well designed program will offer benefits or premiums that help to draw people in. Museums and cultural organization tend to be organizations of this sort; many advocacy and political groups also structure themselves in this way.

Dues Billing is managed very differently in the two sorts of organizations. For the first type, the dues represent is a fee in advance for services. Each member will receive a renewal notice for a specific amount. That amount might be determined by the membership type (corporate, individual, academic, etc). For organizational memberships it might be based on the members revenue, or number of employees or even -- in the case of one leather-industry trade association, the average number of hides processed each week. And the dues may be due monthly, or quarterly, or annually, depending on the membership type.

The second type of organization has a mirror image set of billing business rules. Rather than bill people based on their classification, members are classified based on what they pay(i.e. $25-$50 members, $50-$100 supporters, $100-$250 sustainers, etc). And rather than tell members when their dues must come in, development teams struggle to understand when people tend to renew.

The staff and board need to articulate quite different sorts of business rules and practices for these two subspecies. So it is critical they understand which type of membership program they are developing. Every now and then we see an organization stuck in the middle. This uncertainty leads to in ability to settle on membership policy and practice. And not surprisingly to confusion in marketing and development messages. After all, no one ever joined their public radio station because they really needed a tote bag.

We often first hear the signs of "membership ambiguity disorder" as an organization debates software requirements for membership and development support. But it's not a problem of deciding what you want your software to do. You need to first understand what sort of beast your membership program is.

Membership Management Software and CRM

2007-03-24T14:18:00.000-05:00

What is the difference between CRM and Membership Management? Isn't the latter just CRM for a member-based organization? This is the kind of discussion you hear over Italian cold-cuts on a ciabatta at our office.

The answer is: not really. Membership is where CRM meets Business Process Management. Typically we find that Membership is the part of our system that needs to be customized most intensively for an organization, to meet the complex business rules in place governing the membership plans.

We have found that the business rules governing membership tend to be more complex and less easy to generalize than in other areas of non-profit operations. It wasn't rocket science, for example, to create a structure that allows users to set up virtually any sort of discount scheme for their order entry and sales operations. It's way harder to generalize membership logic.

There are three sorts of business processes users want to incorporate into a Membership module:

Dues Amount Calculation
Dues Billing and Accounting
Membership Application Process.

Because of the centrality of these processes to the life of a membership organization, they tend to vary widely between organizations, to grow in complexity as time goes on, and to change relatively frequently as the board debates better ways to attract, retain, and serve members. Indeed, membership business process rules can reach what I consider the breaking point of complexity: where users are confounded by the behavior of the system because the rules are too complex to keep in mind. When this starts to occur, it is time to simplify.

Simplification can occur in two ways.

One is simplification the business process. Minimize the number of different member types. Use a uniform billing process across all your members. Simplify the algorithm for computing dues. Eliminate programs that support tiny numbers of members.

The other is simplification of the software. Don't require the system to handle cases that are really exceptions affecting very few members. For example, allowing the dues amounts in special cases to be entered by hand may eliminate a number of formulae for dues calculations that are used only in a few cases each. The tendency -- if the budget is available -- is to try to automate the full complexity of the board's mandated membership process. You may make everyone's life easier if you just say no.

Organic Non-profit SEO

2007-03-19T18:22:00.000-05:00

SEO - Search Engine Optimization - has been a consulting hotspot for years. Everyone wants their website to come up near the top of the first page on major search engines. How is this magic done? A few years back, SEO professionals emphasized keywords... words hidden in the page that would match likely search terms. And knowing that engines like Google rank pages by "authority" -- by how many pages link to them - site owners were engaging in link exchanges and other less honest games to increase this statistic.

Organic SEO. Nowadays I'm seeing more emphasis on "organic SEO" -- using the actual semantics of the page, rather than arcane techniques, to increase page ranking. The fact that Google has backed away from keyword ranking is a major part of this. Organic SEO emphasizes correct titling, identifying each page as a landing for specific terms, and so on. And in terms of linking, this approach stresses the importance of social networking tools as well as Search. This posting by Daniel Riviong explores some of these social networking issues.

Many writers have emphasized the importance of blogging to SEO. The daily posts to your blog increase your site's "cross section" and thus the likelihood that a search will hit one of your entries. Then you just have to hope the reader will be pulled further into your organization's site by bait in your sidebars and headings. And of course, a well marketed blog can generate links. Wendy Boswell offers several tips along this line in her article on blogs and SEO.

Unintended SEO. But blogging also generates a great deal of what I call "unintended SEO." These are pages that rank highly on subjects only marginally -- or perhaps not at all -- related to your central focus. Some of the most highly read pages on this blog are found because of their high ranking on unlikely searches. Such hits make your page load count look good. But they do not get you donors, or customers, or regular readers -- whatever it is you are looking for.

I've been able to isolate "clever" titling as the real culprit here. Since the title is weighed heavily in searches, use of simile or metaphor in your title pulls lots of lost souls into your site. For example, I have a very high ranking for Bricklaying Technology. Great. I also get hit daily by people trying to learn the meaning of the English idiom "Like Pulling Teeth." They don't stick around either. It's painful to lower your literary standards to please some stupid spider that could give a damn about your subtle use of irony. But if your goal is to pull in readers who will support your organization, not masons, or dentists studying English as a Second Language - it pays to use straightforward titles.

Unintended SEO can also arise when you write an article on a popular subject somewhat removed from your usual subject matter. For example, I wrote a piece a while back on how to embed a YouTube video in blogger. Through the vagaries of search patterns, this always ranks very near the top of a very common Google search and accounts for about 25 percent of my page loads every day. But it is only remotely connected to my central focus on CRM and CMS for non-profits. So stay on topic.

Unless of course, you just want the gratification of seeing your numerical stats soar. Then by all means, mention Twitter and Paris Hilton in every post. It works.

[Update] Whoa. I just noticed there is other talk about blog headlines lately... more from the human than machine angle. CopyBlogger has a long discussion of choosing headlines to pull the reader in. (Thanks, Kivi)

Users, Causes, and Technolgy

2007-03-18T17:29:00.000-05:00

This bite-sized movie by videoblogger Raymond Kristiansen doesn't answer any questions - but it does shine a bright light on a lot of the questions that come up in our work, discussing technology with non-profit organizations. Stylish and intense. Maybe I will have to start video-blogging... this stuff is really cool!

Twitter update

2007-03-17T16:49:00.000-05:00

Just came across this much more positive view of Twitter from Chris Brogan posted on LifeHack.
It's worth reading, as he discusses five specific uses of Twitter.

And Rafe Needleman has written a nice "Newbie's Guide to Twitter" to speed you evaluation of this latest craze.

Twitter is all the rage.

2007-03-16T12:46:00.000-05:00

Twitter is all the rage, it seems. This year-old site -- sort of a world-wide chat room -- seems to be really taking off. Social-media maven Ross Mayfield, in his Many-to-Many blog, shows a page-load chart of Twitter over the last year that demonstrates its recent near-exponential growth.

What do you do on Twitter? Some people refer to it as MicroBlogging. With the emphasis on Micro. You can exchange information... but you only have 140 characters. You can flirt... but the whole world is watching. You can chat with your friends... but your boss might be online. You can meet new folks... but the profile bio is also a mere 140 characters long.

Since this new networking site is so popular, you'd think it would be easy to find people explaining just how valuable it is. But instead, the general tone is "This is SO COOL. But kind of annoying. And I'm not sure it's of any value".

So Charlene Li can say in one breath:

Here's our take: Twitter is going to be overused, overloaded people, who will then get turned off. There is just simply too much noise and not enough valuable "signal" to be worthwhile. I run into a case of TMI - too much information -- in that I don't really need to know that you're heading to the bathroom, etc.

and in the next

Intrigued? I certainly am. I still take the current Twitter-mania with a huge grain of salt, mostly because in its current state Twitter is going appeal only to a small subset of people who enjoy publicly sharing what they are doing. But watch out -- I think that like IM, blogging, and social networking, services like Twitter will evolve with new features and functionality to actually become useful communication and information tools. Want more examples? Check out the Twitter Wiki for the latest.

The same dichotomy is evident in Beth Kanter's post where she ponders whether Twitter is of any value to the Non-profit sector. She's got links to quite a few interesting posts about the site, by the way.

My experience? Well, forget the IM or phone updates - I don't want to be beeped at every few minutes. I've written here before about how I detest the current fondness for "constant partial attention" -- meaning incessant interruption. And anyhow, my attempt to get it working with my phone failed miserably. But in the two days since I've set up my account, I've already met a few interesting new people, been pointed to a couple useful websites, and reconnected with a few folks I haven't talked to for a year. Give it a try... set up an account at http://www.twitter.com, and connect to me: my username is michaelatmo.

Navigating complexity

2007-03-14T08:56:00.000-05:00

Maybe I'm just thinking out loud here. In the last post I mused about the complexity of striving for simplicity in design. For every effort to simplify, you discover you have made another user's life more complicated.

Usability means several things.Tasks should be easy to learn, quick to complete, and hard to screw up. Data displays should be complete, uncluttered, and easy to comprehend. But even these straightforward goals can work against each other. Do we show less information on a page to make it easier to read, or do we show more, so users do not need to click or scroll? The jury is always out on this one - we once recieved an email asking us to use a larger font, allow more white space, and add several columns of information to a particular display.

At the heart of the problem are the complex business requirements that organizations create. I've written before about the importance of weeding out needless complexity. But non-profit staff can only go so far in eliminating requirements from government, insurers, the board, and the ultimately the nature of their work itself. So the software designer's task is to mask or conceal this complexity.

Here are some of the trade-offs I've run into as we work with our users to make software more usable.

Design Approach	It's simple because	It's not simple because
Context sensitivity: only show inputs and options when they apply.	The user does not find herself clicking buttons only to get a message like "You cannot Place a Hat on this Zebra" . In situations where zebra's do not wear hats, the button is hidden. For sessions where transporation is unavailable, the transportation link is hidden.	Users are never sure when a menu choice or option will appear. "There used to be a button for Putting a hat on the Zebra", they report.
The WIZARD Approach: have users perform tasks through a series of simple forms that step them linearly through the process.	Little or no training is required. The stripped down dialogs on each page come with instructions and are not threatening to the user.	Getting through the process requires many clicks. Worse, making a mistake requires the the user to click BACK repeatedly to find the page where the correction can be made. So work is taking twice as long.
NOVICE and EXPERT forms: Have stripped down pages for users performing simpler tasks and more complex pages for the advanced users.	Everyone wins. The simplified pages require no training, and allow less skilled users to perform a majority of possible tasks. The Expert pages provide access to all capabilities.	Everyone prefers the simplified pages but are constantly frustrated that the one other capability they need is not there.
User configuration: Let users configure the capabilities and elements available on their view of complex forms.	This is even better. Each user gets exactly what they need and no more.	This is even worse. Users need to learn how to configure the pages. Users remove items from their page they actually need. Support staff find their life has been complicated because each user is looking at a different page.
Strict Enforcement. Make it virtually impossible for the user to make a mistake by building in rules to enforce all data entry and setup requirements. If each customer MUST have a date of birth, for example, require it to be filled in for the form to be saved.	Users do not need to know all the decisions of management about data requirements. The system will enforce the rules and pop up messages to tell you what you need. It's what computers are for!	No one can get their work done. The system is constantly complaining that they cannot use this membertype or you must enter an employer. People are entering 01/01/2000 for everyone's birthday. The data is in terrible shape because people are forced to work around the system.

It seems no design idea is a panacea. Each must be employed judiciously as users and developers navigate the seas of complexity.

'Tis the gift to be simple...

2007-03-12T17:47:00.000-05:00

There is a lot of discussion of "usability" in software design circles. Everyone knows usability has a lot to do with simplicity - but as the old Shaker song tells us, it can be tricky to hone in on what true simplicity is.

For example, I've been thinking about a piece of our YMCA program that has been through a lot of evolution over the last decade. Back in 1997, a group of users at one of our Ys requested that we create a simplified process - a Wizard - for front-desk staff to register people for YMCA activities. They wanted a process that ignored most of the only occasionally used "special options" and provided a slimmed-down and streamlined way to handle most sign-ups. More advanced users could go to administrative screens in the relatively few cases where the Wizard did not suffice.

Let's make it SIMPLE! said the users. For example, it's great that Members Only lets us record unlimited addresses and phones on each person. But to enter a new registrant, we just need their home address and phone. And let's make it like a public web app - each screen should tell our users exactly what to do on that page, so no training will be needed. You don't need training to buy a book on Amazon, after all.

We were sold. We held tons of design meetings with the users, and unveiled the express registration to great oohing and ahhing.

Of course, as people started to use it, some design problems were found. One address and phone number were really not enough, for example. So we allowed both home and work. And special scholarships and discounts couldn't be left to the administrative pages after all: everyone needed to be able to add them as they took a registration. And for those special classes where YMCA buses were used, there should be a way to assign the participants to buses on the express reg. Going to the admin pages for bus route assignment was inconvenient.

You know where this is going. Users felt that the slimmed down pages had turned out to make registration more complicated - because users had to go elsewhere for all kinds of special cases. Over the years we've had to allow unlimited addresses and phones on the express registration - two was not enough either. We've had to allow the selection of specific days and weeks for people who cannot attend the entire session. We've had to let users override the system-determined pricing for a host of special cases.

What was really sad is that along the way, we we agreed to a request to remove the instructional text on the pages, because it was taking up valuable real-estate that could be filled with the buttons and links that give access to a host of special functions. They didn't want them hidden in menus where the were hard to find. They wanted them right on the page where it would be SIMPLE to find them.

Only now users are asking again why the Express Registration is so complicated. I'm looking forward to another round of simplifying this process - but this time I know that simplicity is not so easily attained!

Patent Office goes Webby

2007-03-05T09:53:00.000-05:00

The non-profit community has had a special romance with a variety of collaborative tools that have often been lumped together under the rubric of Web 2.0. This includes wiki-style collaborative posting, social bookmarking and "voting" on the importance of article or comments alla Digg. Now this sort of public participatory use of the web is going mainstream in an experimental program by the U.S. patent office to involve the public in the approval or rejection of patent applications. Here's the story from this morning's Washington Post. Most interesting, I thought are the comments on "reputation management" and the role it plays in opening up a process like this.

Reach for the common denominator

2007-03-02T16:59:00.000-05:00

Problem solving, how to get better at it, and how to teach it, remains a concern with me.

In looking at problem solving heuristics in IT the other day, I mentioned that one important rule for me is that when several problems start up at once, odds are they are related. So one of my approaches is to investigate the most transparent of the problems, and see if that leads to a general solution. But I realized while helping a client solve a problem the other day that there is a second approach I use all the time that also stems from this rule. When several problems crop up at once, look for possible common denominators and test those possibilities.

The real life scenario: At one of our YMCA clients, things seemed to be going from bad to worse over a period of several weeks. Problem one: the serial-to-ethernet converters that let all the door access-controls communicate with the server kept crashing, and would have to be reset frequently. Since this system is slated for replacement, no one worried about it too much.

A few weeks later, the web site started periodically loosing its connection to the database. Some calls were placed to the hosting to service to see what was up. No real results came of this.

Then a third problem started: The credit card software was timing out on a regular basis. So the users started looking into upgrading that to the latest version of that program.

Three problems, three attempted solutions. What if the problems had a common cause? What might it be? Well, all of these diverse processes are driven by services on one central box - these things could all happen if the server was periodically loosing its network connection. We checked the event log on the network, and indeed found that the door-control software was reporting frequent loss of network connectivity. Our hypothesis looked even better.

But here I fell victim to the bias of "availability". All of the tools my company developed are resident on that one server - so I assumed that problem was located there -- it's the box I'm most familiar with at that site. So we checked the obvious things - the cable and the port on the switch-- and the less obvious, looking for a rougue process running on the box, but everything seemed fine. It's a network problem, in my mind, became synonymous with "This server is messed up," even though we could not find anything wrong with it.

To the rescue came their network guy, who took a broader view of the network. He spent some time looking at their network traffic and found the firewall was being swamped by messages from a random PC that had been possibly taken over by a virus or bot-net scam. That machine was removed from the net, and all the problems went away.

So here's another rule of thumb - it really does help to get additional minds on the problem -- someone else will see past your blind spots.

Some Africa Links

2007-03-02T07:03:00.000-05:00

Those of you who have been following me for a while have noticed that I've become interested in West Africa. Here are a few blogs I've been reading since my return...

SocioLingo's Africa Blog: Written by an Englishwoman living in Mali, this blog's frequent posts - many times a day - cover all of Africa and point out articles and reports on linguistic, cultural, archeological, economic, and political developments on the continent. Malilady, as she calls herself, has created a great resource here. And her Flickr photostream is well worth perusing.

SocioLingo's Mali Blog. Covering all of Africa isn't enough for this prolific writer. The Mali blog brings a much sharper focus to Malilady's everyday life in Bamako. Even the occasional recipe shows up here.

Timbuktu Chronicles. This blog, written by New Your City entrepreneur Emeka Okafur, focuses on privately held enterprises on the African continent. Sometimes he writes about innovative appropriate technology projects, but often it's a more typical industry he discusses - a successful iron foundry in Nigeria, for example. When I came back from Mali this winter, my friends would ask - yes, but what kinds of businesses COULD they start? This blog helps us see the answer to that.

AfricaBeat. Global Voices blogger Jennifer Brea has her own Afri-focused blog here. Like many other writers, Jennifer focuses on political and economic development. One of her special interests is the impact of non-Western powers on African development, such as China and India. Certainly when we were in Mali, the evidence of Chinese investment was everywhere.

IRIN News Africa. This is the Africa desk of IRIN, the news site of the UN Office for the Coordination of Humanitarian Affairs. I've found it the most frequent source of news on the current crisis in Guinea.

Medieval Help Desk

2007-02-28T13:13:00.000-05:00

For all of us who help users.... I love how both the techy and the new user struggle to control their irritation and keep a friendly tone.

Biases that block effective problem solving.

2007-02-22T15:50:00.000-05:00

All the best problem solving techniques can be defeated by biases that get in the way of clear thinking. And the worst of it is, we can't often tell when we are in the grip of these patterns. There are three we've seen often in our work that having a major impact on technical problem solving.

One is what my wife refers to as "The Hot Dog" syndrome. Michael Anissimov calls it "The widespread tendency to categorize oneself as above average ". Certainly we techies tend to think of ourselves as a clever lot; this can cause us problems when it encourages us to disregard input from others, to discount the possibility that we made a mistake, act without due dilligence, or so often to underestimate how long it will take us to do something. It also contributes to the oft-cited failing of Not-Invented-Here, where a techie will devote a week cobbling together a solution to a problem rather than buying a two-hundred dollar utility to accomplish the same task.

A countervailing bias is the "Cover your Ass" syndrome [CYA]. Since in real life a large number of the problems a techie is called upon to solve are problems she may have played some role in creating, the need to defend one's reputation really is inherent in every IT crisis. It affects problem solving: I really don't want to find out that the reason no credit cards have been processed for three weeks is because I reconfigured the firewall. So I instinctively look for changes other people, other vendors, or other departments made.

In organizations where blame is a big part of the culture, CYA can have a major effect on problem solving. Organizational culture can play a significant role in keeping people from thinking straight. I was talking to a client the other day who referred to the change log in our application as the "Blame" table - you go there to see which of your co-workers is to blame. Really striking. I've heard other users in their in-house training say "This is how you can find out who knows why a particular change was made". Quite a difference. Be on guard in particular for teams that need to affix the blame before attempting to solve the problem.

Another important bias is one Groopman in his article called "Availability." This bias is more cognitive than emotional, and reflects our tendency to stop at the first two or three possible solutions that come to mind, that are the most available to us. It can mean that it does not occur to us to seek additional information when we should, because we immediately apply one of the first few solutions that come to mind.

I'm thinking of a time when I was given an old mainframe printer. I wanted to hook it up to a computer, but it used the pins in the parallel interface differently than the PC did, so it would not work when I connected it. I'm a software guy. So the solution that occurred to me - that was available, was to write a routine that hooked into the interrupt handler for the parallel port and changed each character's pin out as it was transmitted. It worked fine, but it had to be loaded when the computer was booted, and then prevented any other printer from being used on that port. What I should have done was make a custom cable. Duh.

What is the value of categorizing these harmful patterns? Giving patterns names can help us recognize them. For the negative patterns or biases, this enhanced recognition can help us avoid falling into them. The first two biases often have feelings associated with them -- if I'm sweating bullets while I work on something, I'm vulnerable to CYA. If I'm showing off to my client, I might be a Hot Dog victim. The third one is most insidious, and leave fewer traces. If we are moving very quickly to a time-consuming or expensive solution with a sense of certainty that we know what to do, or if we are feeling a sense of time pressure, we may be in the availability trap.

Rules of Thumb

2007-02-20T16:17:00.000-05:00

Jerome Groopman is a physician who frequently writes on medical topics for the New Yorker. His stuff is always fascinating. A few issues back, they ran a piece of his called What's the Problem, where he looked at the heuristics, or rules of thumb, that physicians use when making a diagnosis. And at certain recognizable errors doctors make that lead to incorrect conclusions about a patient's ailment.

Ed Batista, in a post called When Heuristics Go Bad, immediately picked up on how the same kind of analysis Groopman uses can be applied to management decision making. And I thought, this explains so many problems I see in non-profit IT teams, especially those consisting of Accidental Techies.

Where's the buzz?
There are three heuristics that guide me through 90% of the problem solving I need to do. The first is one I learned when I was 12. I call it the "Where's the buzz" rule. If your stereo is buzzing, how do you decide which component is buzzing: the speakers, the cd player, or the amplifier? By removing each component from the mix and seeing if the problem goes away. Try using the same speakers and cd player, but another amplifier. If the buzz goes away, the problem is in the amplifier. This same approach is a great tool to apply to IT problems like why your meetings registration web pages no longer will charge credit cards. I'm always surprised to see people who have never added this trick to their toolbox.

What did you break this time?
Everyone knows that half the time when you try to fix something, you break something else. When I change a light bulb, I scratch up the walls carrying the ladder back to the basement. When I refine the security settings on the firewall, ecommerce goes down on the website. This is not just an annoying fact of life - it is a valuable trick for problem solving. When a new problem emerges, the first rule to apply should be "What has changed?" Odds are the last changes made to your software, to your network, to your pc, have caused the new problem.

When sorrows come, they come not single spies, but in battalions
The Bard can add a third heuristic to this set. So often, several problems emerge all at once. I've found that when this happens they may well have the same cause, even if this seems really unlikely at first glance. So pick the one that looks easiest to solve, and see if this resolves the other problems as well!

But as Dr Groopman points out - even with a some useful heuristics at your disposal, things can still go wrong. Tomorrow we will look at a few common patterns that defeat effective problem solving.

Daylight Saving Time and Windows

2007-02-16T08:45:00.000-05:00

A number of my clients have asked me recently if they need to be worried about the early change to daylight savings time this year. You remember, don't you: clocks get rolled forward on March 11th this year as the new law lengthening Daylight Saving Time takes effect.

Here's the deal: The Windows operating system assumes it knows when to start Daylight Savings Time in the United States. If you have installed all your OS updates - and you are on XP, 2003, or Vista - you should be fine. But if you are still running Windows 2000, your clock will not change properly. No daylight savings time update has been released for Windows 2000. According to the always helpful Geeks are Sexy blog,

Microsoft is releasing patches to update 2003, XP, and Vista to the new 2007 Daylight Saving Time. They will not release a patch for 2000, and customers are told to manual patch their OS via a few registry tweaks or to simply upgrade to a newer version of Windows.

If you have a large Windows 2000 installation, you might want to look at a utility from IntellAdmin to handle this for you.

There's even bigger worries for is users of Microsoft Exchange Server 2000, for which no free patch will be made available at all. Check out the links on that Geeks are Sexy post for much more information and lots of links on how the time change will impact Windows, Outlook, and Exchange Server.

The Dixie Chicks and Hambo in the Snow

2007-02-15T06:41:00.000-05:00

I don't usually pay much attention to the Grammys, but there was so much reason to this year. National attention was focused on the resounding show of support for the Dixie Chicks and their right to speak their mind those many months ago about the president and his war. The endless stream of "bests" was clearly political - but quite gratifying. Nonetheless, I wouldn't have minded if they had lost in just one category - Best Country Vocal Performance by a Group or Duo: my friends in The Duhks were also nominated, and I would have loved to see them take home a prize.

I'd never been aware of the extent to which traditional and folk music is both honored and slighted by the Grammy's. Honored, in that there are a world of catagories for the kinds of music I love. Slighted, as these are never mentioned from the podium and rarely in the press. I'm only aware of it this year because our very good friend Andrea Hoag was nominated this year in the World Music/Traditional genre, for the album Hambo in the Snow along with with Loretta Kelly and Charlie Pilzer. Here's a great NPR piece about them. Andrea is my wif'e's fiddle teacher! Click their picture above for a bit of their music.

Other traditional musicians we love were also nominated for awards. The insanely innovative Casey Driessen was nominated for Best Country Instrumental. Sadly, neither he nor Andrea went home with the victrola. But the New-York based Klezmatics took the World Music/Contemporary prize for their up-to-date take on the traditional Jewish Klezmer sound. And in other victories for traditional music, Bruce Springstein was rewarded for his venture into the folkie world: he took home Best traditional Folk Album for his all-Pete Seeger venture, We Shall Overcome: The Seeger Sessions.

Monday Morning Links

2007-02-12T06:39:00.000-05:00

Management Tools 2007
I found through Steve Shu's Blog a link to the Bain and Company Management Tools 2007 Guide. Food for thought for anyone working to re-imagine their organization, the guide consists of single page introductions to each of 25 management tools or processes, with an extensive bibliography on each.

Just ask your users?
In a recent post, I pointed to some writers on software testing who suggest that users are not the best testers of the applications they are going to use. They are just too close to the whole project. In a related vein, Neill Archer Roan suggests that getting too much input from your current customers can stifle innovation. Again, because they are too close to the product.

Asking customers about what they like or dislike about the current product or service will cause them (and you) to focus on incrementally improving what’s current. While I’m not against incremental improvements in products and services (I think they are very important, indeed), this focus won’t lead to innovation.

We've seen this in our own little company. Those of us meeting with prospective users are hearing feature requests and other feedback that we've never heard from our current clients. So if you are trying to make a quantum leap in the appeal of your products, services, or campaigns, you've got to solicit input from outside your current community.

Pondering Windows Vista.
Windows Vista has been available commercially for a few weeks now. We've been running a beta version on a few machines for about six months, and just last week I purchased a new laptop for myself with Vista Home Premium installed. We've had to wrestle through some compatibility issues - and some of the vendors whose tools we use have still not solved all their Vista problems. If you are pondering an upgrade for your organization, I'd recommend setting up Vista on one machine and verifying that all the software you routinely use in your organization is happy before you consider a company wide rollout. Confused about all the flavors of Vista out there? Get your bearings by consulting Windows Vista: A FAQ for Non-Profits posted on the TechSoup website. And expect a bit of a learning curve - even the Start menu works differently. Members Only run fine, I'm glad to report - although of course the Windows Help files no longer are supported.

Media that Matters.
My cousin Julilly let me know about a short documentary by a 17 year old American filmmaker that is really quite disturbing. Take a look at A Girl Like Me by Kiri Davis at the Media that Matters online film festival.

Software for Free?

2007-02-09T06:42:00.000-05:00

We've seen some vendors price their software by the number of contacts in your database. By the number of emails you send. By bandwidth used. We've chosen to do it by the staff size of your organization, licensing the software by user count. The idea is to be fair - to charge less to the smaller organization. To charge more to the organization making more use of the tools.

But sometimes this doesn't work. There are organizations with quite a few full-time staff members, squeezing by on a very tight budget and doing very valuable work. Our pricing plan just doesn't help them. They really need the software - but they need way more licenses than they can afford.

To enable some organizations in this bind to obtain the software they need, we've decided to give away one system each quarter. Here's the full announcement. Drop Doria a note if you are interested.

Improving Public health in Mali

2007-02-08T13:32:00.000-05:00

Last month I wrote about my stroll through Sikoro, on the northern outskirts of Bamako, Mali, and the community health project Siguida Keneyali we learned about there. Today my friend Britt Bravo posted an in-depth interview with Caitlin Cohen of Siguida that looks at the project and its community-based orientation in some real detail. I'm sure you'll find it a worthwhile read!

Testing more than the features

2007-02-02T17:25:00.000-05:00

One issue you can never discuss too much is testing. How do you test a software application before turning users loose on it?

Dr Dobbs, one of my favorite software magazines for almost two decades, had a nice piece by Scott Ambler on test in the December edition. Scott has emerged as one of the principal evangelists of the agile development movement, and in this issue he discusses testing from an agile perspective. Like much current writing on testing in the Extreme Programming and Agile universe, he talks a lot about unit testing and the test-first strategy. This approach stresses writing automated tests for every bite-sized chunk of program logic. Automated unit testing can more than double the amount of code that needs to be written, but provides a mechanism for detecting when new code breaks old features. And don't you hate when that happens!

Ambler also stresses a new concept: what he terms investigative testing. Most of today's testing literature emphasizes testing the specified functionality. Investigative testing takes a different tack:

The investigative test team's goal should be to ask, "What could go wrong," and to explore potential scenarios that neither the development team nor business stakeholders may have considered. They're attempting to address the question, "Is this system any good?" and not, "Does this system fulfill the written specification?"

A blogger I've been quoting a good bit lately, Jeff Atwood, similarly advises us this week not to limit testing to confirmation of the specifications. His post on Lo-Fi Usability Testing takes off from a book he's recommending to all software designers, Don't Make Me Think, by Steve Krug. His point: the users' agreement that you've met their requirements has very little to do with their ultimate satisfaction with the application. The users, like the programmers, are too close to the project to be the best testers. The best bet is to rope in a few people who know next to nothing about your project.

Usability testing doesn't have to be complicated. If you really want to know if what you're building works, ask someone to use it while you watch. If nothing else, grab Joe from accounting, Sue from marketing, grab anyone nearby who isn't directly involved with the project, and have them try it. Don't tell them what to do. Give them a task, and remind them to think out loud while they do it. Then quietly sit back and watch what happens. I can tell you from personal experience that the results are often eye-opening.

Its official!

2007-02-01T16:40:00.000-05:00

Last year at the NTC conference in Seattle we met some folks developing some innovative web products right around the corner from us in DC. Over the intervening year we've had countless meetings, IMs, lunches, dinners, brainstormng sessions and afterwork drinks. And today we are announcing a strategic partnership with Orchid Suites.

Here's the announcement copied from the Members Only website.

February 1, 2007
Washington DC

Members Only Software, Inc is pleased to announce that we have entered into a strategic alliance with Orchid Suites Inc., a D.C. based developer of Content-Management and Community-Building Tools.

"This alliance enhances Orchid’s ability to deliver best-in-class integrated online management tools for communications." said Tanya Renne, Orchid Suites CEO.

The view from the Members Only side of table: this partnership will allow us not only to provide our users with a state-of-the art CMS system, but one that will be closely integrated with the entire suite of Members Only products, allowing an organization to tie its web presence to its basic operational activities. Doria Howe, our Marketing Director, adds

"Orchid Suites is more than a traditional CMS - it's a web-suite technology with collaborative tools that are very exciting for Non-Profits. They allow organizations with multiple chapters or interest groups to have integrated sub-sites, while organization staff can easily take control of look, feel and content."

The first product to emerge from this partnership, the Orchid Suites - Members Only Link, will make it a snap for our users to give their constituents access to a wide range of Members Only activities on their Orchid-based website, including profile management, event registration and online donations. Orchid is able to do this by supporting the Members Only API, which allows software developers to access a wide range of Members Only functionality from other applications.

The Orchid Suites - Members Only Link will debut at NTC 2007, a national conference for non-profit technology to be held in Washington, April 4-7,2007. D.C. For more info visit http://www.nten.org/ntc

Learn more about Orchid Suites at http://www.orchidsuites.net
Learn more about Members Only Software, Inc at http://www.membersonlysoftware.com

If you are coming to the NTC, be sure to see us at the Science Fair!

The permanent Beta?

2007-01-24T17:06:00.000-05:00

Browsing through some old posts in the always worthwhile Creating Passionate Users blog, I came across this interesting post from last March: Ultra-fast release cycles and the new plane. The post is about the growing popularity of extremely short turn arounds between versions that has become characteristic of web2.0-type development - what O'Reilly called the permanent beta. This is an issue we discuss in our office quite a bit.

We have some users who demand rapid release. They feel that if they find a small bug on Monday, dream up a new piece of functionality they'd like on Wednesday, and want the menus reorganized on Friday, they should certainly be allowed three versions that week. After all, they're paying. What about the increased risk of defects? Well, they don't mind... they'll report them and they will be fixed in the next rapid release.

On the other hand, we have users who despise the rapid release. These clients expect us to organize their requests, implement them all, test them all, and give them an upgrade once or twice a year at most. Installing any more often, they've told us, complicates user training and increases the risk that a new release will break something that was already working. Far from demanding rapid release, they see it as a lack of professionalism.

How do we understand this difference? In the Creating Passionate Users piece, Kathy Sierra talks about the short-release trend as a "cultural" one. She's focusing on the youthful subscribers to the Myspace website, her model of the rapid release project. So she focuses on factors relating to youth culture. What she does not dwell on is that Myspace is fundementally different from business software - it is not critical to most users' bottom lines.

Let's look at this "cultural" difference among the staff of non-profit organizations using our Members Only software. It seems to me the difference here hinges on the perception of real costs and real risks associated with installing a new version. These costs and risks actually differ significantly between organizations, so the evolution of different cultures around software installation is not at all irrational. It has to do with the organization's size (in number of users, and in number of locations) and the level of activity (How many transactions go through the software in an average day.) Large organization using software for mission critical purposes are aware of the costs of training and of the bottom-line impact of a significant defect, and therefore want to minimize the number of training and testing cycles they expose themselves to.

Where does you organization fit on this spectrum? Are you happy to use a permanent beta? Are new features on a regular basis worth encountering bugs you will need to report? Are you the kind of user who is always pushing for the next update, or are you loathe to install them? What factors have shaped your attitudes?

Siguida Keneyali

2007-01-20T17:15:00.000-05:00

When Doria and I were in Mali earlier this month, we found that our nephew Fodé Camara had started to work with a group called Siguida Keneyali - Health in Our Homes - an organization working to improve health in Sikoroni, the poorest Quartier in Bamako. While we were there, we had a chance to talk to Fodé and his colleagues Caitlin Cohen and Modibo Niang about the organization and its approach. And Fodé and Niang took us on a stroll through the neighborhood, where we were always surrounded by the exuberant kids of this village.

The organization is guided by a local board with deep roots in the community.Fodé emphasized the grassroots nature of the organization:

Siguida is a shift from the top down practices common in this type of development effort to a more participatory approach where the community is involved in identifying project goals, and in the design and the management of the project while taking in to account the local cultures and traditions.

A preliminary health survey showed that by far the most serious problem confronting the village is malaria, and that is the area where work will begin. In an email, Caitlin shared the survey results with me and pointed out a group of questions that revealed the low level of health knowledge and information among Sikoro residents. There's no doubt a health education component will be key to the project's success. The renovation of an old community center to serve as a library and discussion place should help in this effort.

Check out the Siguida ' website - there are lots of ways you can help this great community effort.

Andrea Parhamovich

2007-01-19T14:47:00.000-05:00

Everyone on our office was saddened to learn today of the death of Andrea Parhamovich in Baghdad. Andrea was there working with the National Democratic Institute, training on election norms and other democratic practices. She was 28.

Three members of the NDI security detail were also killed when their convoy was attacked as they left a meeting with Sunni politicians - the names of the security personnel have not yet been released.

Former Secretary of State Madeline Albright, currently the chair of NDI, is quoted on the NDI website as saying:

There is no more sacred roll of honor than those who have given their last full measure in support of freedom. Yesterday, in Iraq, Andrea Parhamovich and our security personnel were enshrined on that list. They did not see themselves as heroes, only people doing a job on behalf of a cause they believed in. They were not the enemies of anyone in Iraq; they were there to help. Now, the prayers of all of us at NDI are with them and with their families. We pledge to do everything that is within our power to see that they did not die in vain. We will honor their example, keep alive their memory, and carry on their work.

NDI sent us a link to this story about Andrea in the LA Times. The article quotes a former co-worker of Andrea's at Air America, the liberal comedy radio network as saying:

She had to go to the heart of the war and create change and understanding. She was so obstinate in her efforts to create change. Nothing could stop her."

The National Democratic Institute "works with democrats in every region of the world to build political and civic organizations, safeguard elections, and promote citizen participation, openness and accountability in government." NDI has been a client of ours for many years. The tragedy of Andrea's death underscores for us just how important their work is.

Microformats anyone?

2007-01-18T15:33:00.000-05:00

The 2007 Non-Profit Technology Conference is coming to my town! Yup, it's April 4-6 in Washington, D.C. I had a great time traveling to Seattle for last year's meeting, but it will be very pleasant to just roll out of my own bed and wander up the hill for muffins and coffee! Members Only Software will be participating in the science fair (nothings changed in my life in 50 years, has it?) and I've been asked to host a session on Microformats. Here's what the organizers have in mind:

Microformats Are the New Tags

But are they a flash in the tech pan, or are they here to last? Microformats are the latest attempt to address the most important hurdle in technology - data sharing. This session will address how they work, why they may be better for data sharing, and whether or not they will last.

Takeaways:

Definition of microformat
Understanding of how they can be used with tags and other similar technologies
Examples of how and where microformats are being used now

Session Tags:

Web2.0 Webmasters Opensource

I've already got cautions and quibbles with this intro - but that's what gets discussion going. Speaking of which: I'd love to find a few collaborators for this session. So if you have experience using Microformats, or if you have strong ideas about the should be or could be used, please drop me a note as soon as you can. I've written just briefly about microformats here and here in this blog.

Over my morning coffee

2007-01-17T17:13:00.000-05:00

Five Things, redux
I felt vaguely weird responding to the five-things game yesterday... so I was pleased to see that Jeff Atwood, author of the Coding Horror blog, also had complex feelings about responding. Which he did in a novel way. Look at that office: I guess he isn't working primarily for non-profits! He writes a great blog on software engineering and design though. He has a tendency to stop and ponder issues that are easy to pass right over, like last week's thoughtful post on the selection of default values in software applications. It really makes sense. When we add new features, we usually set them off by default. But if a particular setting is one you think best for most of your users, shouldn't that be the default configuration?

The digital life
Kilkat at Geeks are Sexy points readers to an article in Information Week that documents of the use of cell phones and pcs by toddlers as young as two. According to this piece, 15% of children age 2-5 in the United States use cell phones.

A Washington Post story, just a day earlier, focuses on the surrender of privacy that is implied in many of the high-tech conveniences that have become commonplace over the last few years - from EZPass to GPS to online shopping.

Security vs Panache?
The non-profits we work with are always trying to pack more punch into their communications with supporters. We've seen more and more of them adopt graphics-rich HTML mailings newsletters to help them get their message across. Which is why I felt that Brian Krebs' position in this Washington Post blog just wasn't going to sway a lot of readers. It's true that active emails can try to sneak around security measures - but I don't think users are going to go back to the plain-text for their critical constituent communications. It's Windows fault if just reading an email can trash my pc, and Microsoft needs to fix it - that's what I bet most users will say. What do you think?

I've been tagged!

2007-01-16T17:06:00.000-05:00

Still catching up on reading all my blogging chums last month's posts after my big trip, and I just noticed that I've been tagged by Michelle Murraine of Zen and the Art of Non-Profit Technology in a game of revealing five things most people don't know about me / and then I've got to tag five others - who hopefully have not been already caught up in this excercise.

Well...
1) I've been practicing zazen (zen meditation) since I was in my twenties.
2) The two things I miss most about my month in Africa are the call to prayer, and being awakened by roosters every morning.
3) I've never seen a single episode of any TV show considered a reality show!
4) Between the two of us, my wife and I have four fiddles, four drums, a banjo, a guitar, a mandolin, and a uke, not to mention various whistles, shakers, harmonicas and jew's harps.
5) For several years I was a bagel baker in a commercial bakery

So whom should I tag? It seems many many of the people in the nptech community have been hit by this one already... I'll try to find five who may not know I read their blogs - people I've never linked to or contacted directly...

Siel, the Green LA Girl
Andrea Rusin, from A Small Group of Thoughtful, Concerned Citizens.
Rachel Barenblatt, of The Velvateen Rabbi
Ed Batista
Emeka Okafor, of Timbuktu Chronicles

GeekCorps Mali

2007-01-12T15:08:00.000-05:00

It was my last afternoon in Mali, as I started psychic re-entry process into my normal existence, that I remembered that in real life, hey, I'm a geek. So I dropped by the offices of GeekCorps Mali, which as it turned out was just around the corner from where I was staying at Rebecca and Fode's house in the Quartier Hippodrome. And project director Matt Berg took time to show me around their labs and talk to me about their work.

GeekCorps Mali (GCM) is a USAID-funded project whose mission is to provide appropriate technology, technology transfer, and technical assistance in Mali. Matt showed me some of their innovations in the "appropriate technology" arena and they knocked my socks off. Like Bottlenet - a Wifi antenna built out of low-cost, locally available components and assembled in one of Mali's ubiquitous 1.5 liter mineral water bottles.

When we visited some villages in the Malian countryside I was surprised that children always asked us for our empy water bottles, till I saw them in use at local wells, where girls were refilling them from the pump. In the village of Amani in Dogon Country some Fulani women sold us a few liters of fresh cow's milk in a couple of these water bottles. (wow - was that good - and really helped to settle my stomache, which was somewhat agitated after days of pouring hot Malian pepper sauce on everything I ate.) Then I saw them being used with their bottoms cut off as funnels and as spigots on wells. But using them as a wave guide takes it to an entirely new level.

Another problem we witnessed first hand in Timbuktu is the near impossibility of keeping the Sahelian dust and sand out of computers. Geekcorps has addressed this by designing the Desert PC, a completely sealed system unit employing a low-power CPU and a heat-sink system that in effect uses a built in "radiator" rather than a fan to cool the device. Largely based on Geekcorps award-winning desgin, Via Technologies, whose components Geekcorps used in their prototype, is now selling the PC1 for use in desert conditions.

Matt also stressed that on all their projects GCM uses Malian volunteers - so that the tech skills employed will be transfered to folks living in the country. The big success story in this area is a young man named Moussa Keita, who has gone on from his volunteer work with GCM to found his own web development company, Zirasun.

On Vacation!

2006-12-17T09:08:00.000-05:00

Well, no sooner do I manage to start blogging again then it's time to go traveling. So there will probably be no posts on this site until my return in Mid January. I'm sure when I get back I'll just be bursting with thought about software development, tools, problem solving, knowledge management... but while I'm gone, hopefully I'll fill my head with new sights and sounds... every now and then I'll post to the Travel blog Doria and I just set up at, so do give it a look. And check back in here after MLK day!

Energy Conversations

2006-12-09T16:08:00.000-05:00

Imagine its the future, and somehow we've managed to avoid eco-catastrophe or the complete depletion of our planet's energy resources. If we've arrived here, it must mean that somehow "green" concerns at some point came in from the cold and the fringe and found a home among mainstream decision makers. How did that happen? How did the concern for these issues move beyond the community where they first emerged to become a concern of both major parties, of government, of the financial sector, of industry, and even of the military?

Maybe it started through efforts like Energy Conversations. Midwifed by Mitzi Wertheim at the CNA Corporation, a federally-funded non-profit research center in the located D.C. burbs, this project is bringing movers and shakers from the executive branch, the military, and the private sector together to think innovatively about energy issues. A monthly program features a diverse list of speakers tackling energy concerns from different perspectives; recent programs have been headed by policy pundit Jeremy Rifkin, green entrepreneur Brian Appel of Changing World Technologies, and free-market theoretician Amory Lovins of the Rocky Mountain Institute.
Complementing these face-to-face events is the Drupal-based website, which hopefully will encourage ongoing conversation and collaboration among participants.

Indeed the entire project is based on the idea of social networking, on encouraging collaboration and discussion. It's no accident that the word Conversation is used in the title - because that is what is sought here, not high-pitched advocacy of one view or another.

We've been involved ever since Mitzi walked into our office one morning to talk about our events-management software, and there's no doubt its one of the more exciting things we're working on.

More travel notes

2006-12-07T17:57:00.000-05:00

Another thing that's kept me away from blogging: we've been travelling to Lansing to work with our newest user, United Cerebral Palsy of Michigan.
Project kickoffs are always exciting - and working with a human services organization that provides so much direct assistance to its community is especially gratifying. And it gives us yet another chance to stretch Members Only capabilities: we'll be building a module to track the delivery of these services, not just to assist in the work of the organization, but to meet the reporting requirements of the United Way and other funding sources. We'll also be building in some ways to track the outcome of each intervention - another area I've been wanting to tackle in our software. So stay tuned! We've known Linda Potter, the executive director, for years - but this is the first time we've had an opportunity to work directly with her.

The Blogger Returns

2006-12-06T17:08:00.000-05:00

Whoa! I've been absent from these pages a long time. There's so much going on my blogging has just gone by the wayside. Let's get back on track. What have I been up to?

Well, for one thing, planning a trip over the holidays to Morocco and Mali. I've never been to the African continent before, so you can imagine how excited I am. The Moroccan part of the trip is the briefer leg - we'll be there about a week, in Casablanca and Marrakesh. We'll be travelling in Morocco with some good friends. The Malian trip will be over two weeks long. We'll start in Bamako, where we will be staying with our niece Rebecca and her family -- Rebecca is there heading up a project of the Educational Development Center -- but then head up north to Segou, Djenne, pays Dogon, and Timbuctou. The up-country travel was organized by Karen Crabbs of Toguna Tours, a former New Yorker who has been based in Bamako for years. Rebecca's husband is from nearby Guinea, so we're counting on getting a good introduction to West African culture - especially music.

Needless to say - if any readers of this blog are anywhere along our itinerary, we'd love to get together. Maybe even talk about Information Technology and learn about the challenges facing NGO's in your part of the world.

Who says there's no such thing as a free lunch?

2006-11-14T15:34:00.000-05:00

Our PolicyOrg collaborative is having a lunchtime "meet-and-greet" presentation for non-profits in the Washington DC area this coming Monday, Nov 20th. If you work with a non-profit in the public policy arena and you feel you could be making more effective use of Information Technology, both internally and on your public-facing web site, come on by, meet our partners, get treated to a great lunch, and bend our ears about what your organization needs from vendors like us.

Where
American News Women's Club
1607 22nd Street NW
Washington, DC 20008
202-332-6770
Show me a map!

When
Nov 20
11:00 am - 1:00 pm

Using the right tool

2006-11-13T21:46:00.000-05:00

I muse about the issue of problem solving from time to time: in my work, it's clear to me that some users of technology are good problem solvers and some just aren't. But I have had little success breaking out the skillsets required to be a good general problem solver. I made some progress on this the other day after my friend Gilles attacked my old sofa-bed with his chain saw.

I'd arranged for the city's bulk trash pickup to collect the ancient sagging mildewed thing the next morning, but first I had to get it out of the basement - a task that would be greatly simplified if I could take the bed apart. After failing repeatedly on my own, I called in Gilles, who solved the problem in minutes once he fired up the saw.

I what did I learn? That effective problem solving goes beyond some abstract analytic skill. We agreed on the analysis: the thing was too big to get through the basement without tedious relocation of all the junk we'd dragged down there since the sofa bed had its debut. And the fasteners holding it together were too many and too tight to remove adequately. What I lacked was enough familiarity with the available toolset to select the chainsaw. I knew the goal was to rend the couch into smaller pieces, but I failed to even think of the proper tool!

I often see users stymied because they are not familar with the tools at their disposal - tools which might help either with analysis of a problem, or its solution. The "computer guy" at one of our non-profit clients calls: he's asked everyone to get out of the database so he can do some maintenance, but someone still has a file open. He's spent an hour calling his users, trying to figure out who it is. Do I have any advice? Sure. How about opening the database control center and terminating all users? Oh, I never think of going there. Your workbench is full of powerful tools, but you've got to be like Gilles. You've got to be familar with them and know when to use them. They need to just spring to mind, the way a hammer comes to mind when you're confronted by a nail.

So what did I learn about teaching pc and network problem solving to users? That a "Guide to ten software power tools you should be familar with" is a better start than a focus on sharpening your analytic skills. And it will make a good series of blog entries too!

PolicyOrg Resource makes its debut!

2006-11-09T11:08:00.000-05:00

I generally shy away from tooting my own horn on these pages, but this news is too exciting to ignore. My company, Members Only Software, has joined a consortium of three groups in Washington that have been working with public policy think tanks. Our goal is to offer a more unified approach to technology for this very specific type of non-profit.

At Members Only we're so pleased to be working with Tanya, Cindy, and all the other folks at Orchid Suites on this project: their offices are right around the corner from us, but we had to go all the way to the NTC conference in Seattle last March to meet them! And Ziv Gil, from Vizualle bring to our team the branding, visual and design insights so important in public facing sites - factors we techies can sometimes overlook.

We've put up a little website to annouce our existence - it will grow over the next few months. I hope you'll take a look. Over the next few months, we're going to be hosting events in various cities to introduce ourselves. Maybe you'll be able to stop by!

Penny-wise or Pound-Foolish?

2006-11-04T11:58:00.000-05:00

This morning we woke up to find that our furnace had died, and the house had cooled to 57F. Morning coffee under the quilt, and then a call to the heating folks. Turns out we need to replace the valve that controls the gas intake - parts and labor come to about $600. The furnace is over 20 years old. This could be the first of a long line of repairs. But $600 is a lot less than $6000, and we are planning a big trip later this year (more on that in these pages soon) , so we opted to conserve cash and make the minimal repair. It could turn out to be a bad gamble if the system needs to be replaced soon, but we are only betting six hundred bucks.

This is the kind of gamble smaller non-profits are forced to make all the time in their IT planning. And the problem is, the amount of their wager is often hard to compute. Last year I posted about this as it affects harware lifecycle planning. You may think you are saving money by replacing pcs only when they die - but what is the cost of this approach in terms of lost work time, hasty purchasing, too many OS versions, and vanished documents? Its a cost that does not appear on anyone's invoice, but it impacts your mission.

For-profit companies talk about the return on investment of their IT projects. "Because of this new system, we anticipate 15% less downtime, which should translate into 10% increased sales."
"Because of the new online registration system, we can lower the staffing in the call center. "
But the non-profit, especially the smaller organization, is less likely to have their hands on the metrics that enable this sort of ROI calculation. It's hard to cram "impact on mission" into a spreadsheet cell.

For example, we've just started to work with a small disability group who is very excited to be finally building a central database of their donors, volunteers, and service recipients. But the E.D. was a bit taken aback when their network guy called me to make sure I didn't go cheap on disk drives on their new database server. He wanted some level of redundancy to protect this new information asset. And to her credit the E.D. agreed that it made sense. She saw that while moving all their separate data sources into one repository will alleviate a lot of inefficiencies, it also adds a possible "single point of failure" and something needs to be done to mitigate this new risk.

But in the absense of hard metrics, it's just as easy for a non-profit exec to see these infrastructural issues as just another expense. Especially when he's not particularly tech savvy and on guard that his IT guru just wants new toys to play with. In ths case he can look for another warning sign that he is being penny-wise and pound-foolish: when he can't keep tech staff on board.

Ya gotta have the chemistry.

2006-10-29T15:10:00.000-05:00

There's a little article in the Economist dated October 12th that cites research published in the Proceedings of the National Academy of Sciences. Researchers at the National Institute of Neurological Disorders and Stroke in Bethesda, Maryland -- part of the N.I.H -- who have been searching for the biological basis of altruistic acts have observed neurochemical correlates of a complex social act of great interest to most non-profit organizations - the act of making of monetary donation. The substance involved -- the hormone oxytocin -- has been found in other studies to be involved in various forms of social and interpersonal bonding and trust-building in humans and other mammals.

Fascinating. But short of injecting your prospects before asking them for a donation, how can you get this love juice flowing? Well, the old fashioned way, of course - by building real trust. Guidestar interviewed San Deigo philanthropist Malin Burnham recently. Burnham says that the sense of trustworthiness he gets from a fundraiser is the most important quality that person can bring to the table:

"Nothing is more important than integrity," he says. "I look for it every time someone calls on me. If it's not there, I can spot it immediately."

Integrity in fundraising runs deeper than just "Is this fundraiser lying to me?" It rests on our sense of whether the program as a whole has an honest foundation. We get a queasy feeling from campaigns that just don't feel right, that seem to lack some fundemental integrity. Joe Waters of Selfish Giving explores his queasiness about Bono and his RED campaign in a provocative post that demonstrates how leaving people not sure they believe in you can really backfire as they start discussing their unease in public.

Thanks to Ken Goldstein of The NonProfit Consultant Blog for pointing out the oxytocin research, and Amy Kincaid of Fundraising Breakthroughs for noticing the Burnham interview!

Tagged: fundraising

The Rise of Private Blogs

2006-10-27T15:14:00.000-05:00

For those of use who blog on technology, politics, marketing, fundraising, and other issues, the public image of the blogger as a teenaged diarist or bored young mom giving the whole world way too much personal information is one we combat daily. But a recent study by the Pew Charitable Trust's Society and the Internet Project suggests that maybe we are the odd ones out. By far the largest single group of bloggers are online diarists.

The study found that that there are a lot of blogs:

Eight percent of internet users, or about 12 million American adults, keep a blog. Thirty-nine percent of internet users, or about 57 million American adults, read blogs – a significant increase since the fall of 2005.

And what do they blog about?

37 percent of bloggers cite “my life and experiences” as a primary topic of their blog. Politics and government ran a very distant second with 11 percent of bloggers citing those issues of public life as the main subject of their blog. Entertainment-related topics were the next most popular blog-type, with 7 percent of bloggers, followed by sports (6 percent), general news and current events (5 percent), business (5 percent), technology (4 percent), religion, spirituality or faith (2 percent), a specific hobby or a health problem or illness (each comprising 1 percent of bloggers).

What does the fact that so many people are blogging about their personnal lives say about changing concepts of privacy? Maybe less than we think. I suspect that a lot of people assume that no one see their blog except the friends they have explicitly told about it. According to a piece in the Washington yesterday, Mena Trott, co-founder of Six Apart, the company that now owns blogging platforms TypePad, Movable Type, and Live Journal, sees increasing interest in prvacy options. Her newest venture, Vox, allows a blog to be published to a specific group of members. The newest version of Google's Blogger platform (still in Beta) also allows this sort of controlled readership.

Hard to understand for those of us who live to see our hit counts climb.

Tagged: blogging, privacy

Monday Links

2006-10-23T17:45:00.000-05:00

My friend Michelle Murraine took me to task for the presumption that all coders are male in the pronoun choice in my last post, How does a programmer spend his time? To atone, here's a set of links for this week, all from female bloggers.

Open API's.
Let's start with Michelle herself, who posted some comments on the NTEN-sponsored discussion of open API's last week to both the NetSquared site and her own blog. The on-line discussion brought together some of the larger software vendors in the non-profit space and a few very savvy users. API's - Application Program Interfaces - refer to an interface made available by one piece of software to allow other software programs to call its functions, manipulate its data, and so on. I'm convinced that open API's add immensley to a product's value and a vendor is a fool not to provide them: we provide SOAP-based APIs for our Members Only applications, so users can access the data and remote-control Members Only from their own web-based or desktop applications. Michelle's comments raise a lot of good questions about the meaning of openness in this context, the relationship between openness and price, and how security fits into the mix.

Code Like A Girl.
Speaking of programming and women, how could I not point in this post to by Kathy Sierra in her remarkable Creating Passionate Users blog? What does she mean by Girl Code? Kathy quotes from "Morton", who wrote in a comment on another blog.

'As for spending too much time on making the code look right down to the last indentation - my code has been called “girl code” for the same reason...' And there you have it. I think "girl code" is quite a compliment.

Kathy's point is that elegance in design -- down to how the code is typed -- plays an important role in making that code understandable when it needs to be looked at later, or by another developer. Code that "does the job" and is banged out as quickly as possible may end up costing more, when the time it takes to maintain it and enhance it later gets factored in. This really fits right into my post last Friday that talks about how programmer's actually spend their time. (I understand CafePress now has Code Like a Girl T-shirts available!)

Google Heaven: Search Engine Optimization
Nikki Pilkington runs a U.K. based Internet Marketing business, and often has some very nice articles posted there. Just today I got her newsletter pointing to this article on Search Engine Optimization. So often improving your position in Google seems like an arcane art that you can either ignore or spend a fortune on. Nikki gives us a list of ten clear directives for improving our website SEO, including great advice about link exchanges:

It's simple; a good linking campaign is like great sex. You take it slowly, make sure it's focused on great results, and choose your partners wisely. Jumping on anyone and everyone is rarely satisfactory.

In general, Nikki's advice is that there's no magic here: the more text-rich the site is, the simpler the navigation, and the more phrases you think people might search on actually occur on the site, the higher your ranking will climb.

Quick: Tell me what your organization does!
Beth Kanter is one of my favorite bloggers, in part because she so often does interviews of very interesting people in her postings. Recently she interviewed Laura Allen, who runs a consultancy called 15second pitch. If you've ever found yourself stumbling to explain what you do -- or what your non-profit stands for -- in a quick encounter at a meeting or a supermarket checkout line, a look at this interview might be useful. Laura's focus is on distilling the essence of what you do into a fifteen second speech. And you've got to find that essence first!

Blogging Basics for Women
Women have been quite forceful in claiming their space in the Blogosphere; perhaps the best known women's project in this space is Blogher. My friend Britt Bravo - a contributing editor to the site -- has just started a new blog with the sole purpose of providing technical assistance to women entering the world of blogging. With pieces on how to read blogs, how to set up a feed reader, and how to select a blogging platform, Blogging Basics for Women is turning into an ongoing university for those just entering this powerful new medium.

Britt - like Beth - is also a great interviewer. Scroll down her page on Blogher and read some of the "Solutionary Women" series of interviews with non-profit movers - like this one with Nola Brantly.

Tagged: nptech

How does a programmer spend his time?

2006-10-20T14:13:00.000-05:00

I just read an interesting post about programmer productivity in Peter Hallam's blog. Peter is a developer for Microsoft; I found his blog via Jeff Atwood's Coding Horror blog. Peter is writing about how to make programmers more productive and suggests that all the emphasis on helping programmers write new code faster is misplaced, because programmers don't really spend much of their time writing new code. His estimate is that the typical developer spends about 5% of his time writing new code, 25% of his time modifying old code, and 70% of his time understanding code he needs to modify. Atwood's posted a nice graphic of this division of labor. Once you realize where the time is being spent, you realize that tools that speed up the writing of new code have very little impact on overall productivity - while anything that make old code more readable and understandable leads to big improvements. Peter uses this argument to suggest his employer is focusing on the wrong features in Visual Studio, Microsoft's flagship development environment.

The 5-25-70 task breakdown also explains why programmers so often make utterly unrealistic estimates of how long a task will take them. They estimate it as if they were writing a tiny application from scratch. But in actuality they are modifying or enhancing an application they need first to understand. You've seen those developer tool demo's where the salesguy writes an entire self-contained application from scratch in 30 minutes. Peter writes:

This does not even remotely resemble real world professional coding. The last time I had a coding project like that I was in college. Early in college. A much more representative task would be to send a coder an existing piece of code that they'd never seen, that was undocumented, badly written, badly architected and had several bugs. Then tell them to add a new feature while maintaining the existing behavior as much as possible.

I think anyone who has worked professionally on large applications will recognize this scenario. We just don't usually recognize its full implications.

Tagged: nptech, programming

Mike Wyatt's Cone of Uncertainty

2006-10-16T07:31:00.000-05:00

Anyone providing any sort of IT assistance to organizations encounters this problem: you've spent an hour or so discussing some emerging need with your users, when they ask,"So what exactly will you do to solve this problem? When will it be done? What's it going to cost us?" And you have no idea yet; you've barely scratched the surface. How do you answer?

Over the weekend I ran into the weblog of Mike Wyatt, who blogs about identity management solutions at Sun Microsystems. Last Monday Mike posted a piece about what he calls the Cone of Uncertainty model, and provides a tool that shows users how the level of uncertainty - uncertainty about requirements, technology, timeframes, and budgets - is steadily reduced as a project lifecycle unfolds.

Mike points out that failure to recognize the level of uncertainty by vendors, consultants, and users leads to unkept promises, missed deadlines, and cost overruns.

Even with good change control processes and governance procedures, what both the vendor and the customer think the project will be in terms of cost, time, and functionality at the beginning of the project and what it actually turns out to be at the end of the project will at times differ by a wide margin.

The Cone concept and accompanying graphic strike me as effective tools to educate user communities about the advantage of postponing firm ideas of budget and schedule until a suitable stage in the process. This in turn will lower the pressure on implementors to make promises they very likely will not be able to keep. The events on the horizontal axis of the Cone graphic should be replaced with the steps in your particular implementation methodology and trundled in to your first project meeting!

Tagged: nptech, project_management

More on Accessibility

2006-10-11T04:32:00.000-05:00

Just a quick note - TechSoup has posted another resource relating to website accessibility. Four Web Accessibility Myths adds a layer of relfection to some of the more common recommendations and guidelines.

For example, most checklists begin with the admonishment to provide alt text for every image. This document points out that if the site is full of decorative images that add little semantic content, alt text on each one can actually make the site less accessible to a user working with screen reader. Three other common recommendations - avoiding javascript, avoiding tables, amd providing titles for all links also go under the microscope.

In each case we arrive at the same conclusion - that the guideliness must be applied with common sense or they can actually impede site access. Counting tags or relying on software generated accessibility scores is not going to do the trick -- you need to test your design. Nate Koechley, Senior Engineer and Design Liaison at Yahoo, is quoted as saying: "There's no real substitute for testing and putting it in front of users."

Tags: nptech, techsoup, accessibility,