A Voice from the Other Side

While it's great to hear from developers and software project managers, you might find it equally advantageous to hear from the guy with the metaphorical purse. I'm the customer.

Software developers have now infiltrated the realm of non-profit and government sectors, with promises of low-cost, web-based ways of doing business using fancy technologies that have heretofore have been too expensive, too elaborate, and beyond the comfort level of our employees and constituents.

Non-profit and governmental agencies, subsisting on a shoestring and a few paper clips, can be seduced by these automated possibilities, but there is a trap. In an attempt to have it all, you can end up with nothing workable and long for the days of a shoebox and a pack of 3x5 index cards to house your data.

For example, my agency decided to move from a paper-based grant application process to an online one. Forms would be submitted directly to the agency and downloaded into our database, avoiding manual data entry errors, lowering cost, and bypassing mailing inconveniences for constituents. We could also view applications online during their preparation process and provide assistance before submission.

Our software developers were eager to point out how they could automate additional aspects of the grant application process, such as vetting potential organizations against eligibility criteria before allowing them in to the system, insuring that deadlines were met, and forcing expenses and income to balance before allowing the Submit button to activate.

Our core needs were simply to import data, verify its accuracy, and communicate back via e-mail that we had received their proposals. However, we were encouraged to program our system so that applications submitted after the deadline would be rejected. By building in rigid requirements, we lost the flexibility to be responsive and service-oriented. Plus, once the system blocked an application after the deadline passed, we were totally unable to import it into our database without contacting the developers to perform a special override.

We should have started with a simpler system and added levels of complexity as we became familiar with its capabilities. Instead, we ended up with part of a non-functional spaceship when all we needed was a complete bicycle.

We walked away from that system and now use a vendor with a more stable system that has fewer features. We adjusted our internal procedures to fit the system rather than building software from scratch to keep our old procedures intact. We now see our online grants system as a way to receive data and manipulate it in our own database, rather than a monument to all that is technically possible, but not necessarily useful.

To avoid leading your non-for-profit clients astray:

• Allow them to plan, build slowly, and test, test, test.
• Resist the temptation to advise them to over-automate simple tasks.
• Be the development team who cares about understanding your user's needs.

Please try to understand what your not-for-profit client can successfully implement, before exhausting your entire technology toolbag on an emerging market.