Collective Wisdom from the Experts 63
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.