A Voice from the Other Side

A Voice from the Other Side

Marty Skomal, MPA Omaha, Nebraska, U.S.
WhIlE IT’S gREAT To hEAR FRoM DEvEloPERS and software project man- agers, 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 nonprofit and govern- ment 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.
Nonprofit 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 longing for the days of a shoebox and a pack of 3×5 index cards to house your data.
For example, my agency decided to move from a paper-based grant applica- tion process to an online one. Forms would be submitted directly to the agency and downloaded into our database, avoiding manual data entry errors, low- ering 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 into the system, ensuring 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 commu- nicate back via email 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 flex- ibility 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 nonfunctional 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 as a monument to all that is technically possible but not necessarily useful.
To avoid leading your not-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 imple- ment, before exhausting your entire technology toolbag on an emerging market.