Engineering your System

Those of us who work in an agency environment, at some point resign ourselves to the fact that even the best laid fundraising plans can be choked or put in purgatory by software and vendor decisions.

Young people like to use PayPal for payments and purchases, but we can't use it because whatever company our clients pay monthly fees to for online donation hosting and processing doesn't support it. We'd love to know how many of our donors give a gift online and via direct mail, but guess what, the people who "own" online and direct mail are in two different departments and their databases don't talk to each other. Want to set up a Twitter? Can't, because the IT department has blocked all websites that are not "pre-approved" by the board of directors so the people we need to post the Twitter feeds can't access it. And so on.

The reason I bring this up is not just to vent at the way we operate-this happens all the time in the private sector as well-- decisions are made, policies are developed, often with unintended consequences.

I think at the root cause of many of these bottlenecks is when people think "how" before "what" or don't take time to define the "what" seriously.

When I was getting my graduate certificate, I took a class called "systems engineering." At the time, I was working as an editor and I found myself in a room full of engineers, developers, and other "scientific types," most of them employees of Lockheed Martin. I was petrified. I knew nothing about engineering, systems, never mind the two combined.

To my surprise, this turned out to be one the best classes I ever took. We discussed the steps of designing a system and it dawned on me that everything is a system, not just rockets (the newsletters I was editing at a time were a system (contributors, articles, me the editor, the printer, the advertisers). I learned things like how to identify project deliverables and goals, budget, establish time lines, monitor, revise, etc.

We spent a lot of time discussing the design of "functional specs." This is a diagram of the system you are trying to create, from most general to more specific level, that outlines WHAT you are trying to accomplish.

The biggest takeaway lesson to me from this class for me was the importance of this step in designing your system. If you first decide HOW you are going to do something (let's say you decide to go with Kintera for your event management system), you are going to lock yourself into the WHAT you can accomplish with it--say Kintera doesn't allow PayPal processing, well if one of your goals was to say, reach out to younger people, and say we've established they like giving thru PayPal, you have now locked yourself out of the WHAT with the HOW you decided to do it. (Let me just clarify here that I am not trying to knock Kintera, just used it because it's fairly well known).

So the moral of the story: first decide what it is that you would like to do-reach new audiences, create an online community that allows people to share videos, offer repeating donations online. Take this seriously. I would even suggest creating a formal functional document, and only then go look for vendors and systems that can meet your needs, rather than trying to fit your needs into the specs of your vendors (now I am not saying there is no room for compromise, sometimes you just can't get everything you need or you just want to go with one vendor etc).

In Direct Mail terms: should the lettershop be dictating our packages, or should we be finding a lettershop that can execute the packages we want to send?