What makes a nonprofit technology project successful?
I've been working with a variety of nonprofits on different types of technology projects, and I think I'm getting better at "picking the winners" right out of the gate. So I figured I'd let you all in on a few of the secrets that I've learned after doing this for about 8 years. Here goes:
1) Make sure management is bought in to the project from the start. This includes ED's, board members, senior staff, and anyone who could possibly throw a wrench into the process at a higher level. Obviously this isn't always possible, but recognizing that you might have to do an internal "sales pitch" is much easier up front than down the line when you're ready to go and someone holds up the process.
2) Make sure there is a defined budget for the project. I can't tell you how many times I've heard, "We need to know how much it's going to cost, and then we'll find the money for it somehow." The problem with that strategy is that you're going to need to fundraise or take money from other things to fund this project. If you're not budgeting for technology, then you org has larger problems than just this single project.
3) Make sure there are at least 2 staff members who have "system administrator-level" knowledge. More often than not, one person leaves over the duration of the project and since this is a "tech thing" you can bet the project was handed to the youngest staff member (since they "you know, use Facebook or something") who is either a VISTA or an intern returning to school in a few months).
4) Make sure there is adequate training time for all staff members. Often one of the last things to be considered, training is one of the most important ingredients to success of any nonprofit technology project. Your new website may look totally mind blowing, but if no one can change any of the content ever, then it's not going to be super useful. Your new donor management system is the bees knees, but if the development director can't find that one major donor with the last name that starts with "Czy", you're going to be in a tough spot.
What are some of your keys to succesful nonprofit technology projects?


Comments
Goals = win!
@Johanna YES yes yes! clearly spelling out your busienss goals at the outset can help you know what you're trying to achieve, and can be a guidepost when you're in the midst of the project and aren't sure where you're heading, you can revisit to make sure those goals are still working for ou.
@Bryann, I wholeheartedly agree with sending out a staff survey to get an idea of people's skills and where they need improvement/assistance. Sometime, however, it can feel like the doctor asking the patient, "what kind of medicine do you want?" You need to be clear what things are skills/training-related issues and what things are workflow/process issues. You can usually help with the "how do I use X software" but not necessarily with the "how do I do my job?"
Great points. I always find
Great points. I always find myself doing a sales pitch ANYWAY for techy solutions before it's all-systems-go. It also seems that lots of management are already aware of cloud solutions; they know it'll save money, but they're just usally concernced too about how to actually scale these things throughtout the entire organization.
You bring up a another great point about budgeting. I think it goes both ways for marketing too: if something new is going to take considerable amount of money, they'll either seek the funds externally or pull it out from another dept. And also, time and manpower is another "resource" to consider: if the org doesn't already have proficient staff, time will need to be taken out to train or find people.
I usually do a survey of staff, just to find out people's strengths and weaknesses. I find this is a decent way to out if it makes sense to delegate certain things to the right staff member. Most times all you gotta do is ask. :)
Clearly articulated goals
Excellent post, Marc! In my experience, this is all right on. I might add that--whether you're working with external consultants or just an internal team--some clearly articulated goals at the outset can help, too. Much like an organization's mission statement, these goals or "project mission" or objectives or whatever you want to call them should serve as a touchstone throughout the project. If new features are proposed, you can check back in with those goals and ask: "Is this really needed to accomplish what we are aiming to accomplish here?" And those goals can also be whipped out when you need that "internal sales pitch." They don't need to be fancy, but at the end of the project you should be able to say whether they were met or not.