On Tuesday, July 20, I'll be presenting in a TechSoup Talks! webinar, Tips and Tools for Technology Planning. We'll be joined by WebJunction program manager Kendra Morgan. Register now for what I'm sure will be a great discussion.

Last week, I had the opportunity to speak at the National Conference on Volunteering and Service about technology planning for nonprofits. We had a great discussion, and I left with a better understanding of the topic than I'd had when I came in. Check out my slides below or by clicking here; you can also download them as a PPT or PDF file and download the handout as a Microsoft Word document. Live notes from the session are available courtesy of The Extraordinaries.

We discussed the importance of tech planning and the unfortunate reality that for all intents and purposes, many nonprofits and libraries don't have a tech plan. To show the difference between an organization with a tech plan and one without, I used these two graphics:

In the organization on the left, there's a rather sophisticated tech infrastructure, but its elements are disconnected, both from each other and from their greater mission. The problem with that kind of infrastructure is that it's acquiescent to the "tyranny of the urgent" that plagues many  organizations: when there's no plan in place for building up your tech infrastructure, your IT staff will always be held hostage by the latest help desk request.

I stole this pyramid from a talk that Ed Granger-Happ gave this year at the Nonprofit Technology Conference. Ed was using the pyramid primarily to talk about where the nonprofit sector is moving as a whole in its technical capacities, but it's also useful for talking about individual nonprofits' technology plans. The top of the pyramid ' beneficiary ' represents the organization whose own technical aptitude is a direct asset to its community, offering information access and literacy to the people and causes it serves. Some nonprofits or libraries are stuck at the bottom of the pyramid, where the only time technology gets any programmatic attention is when something breaks.

It was interesting to see the difference in perspective between large and small organizations. One man said that in his organization ' a Habitat for Humanity chapter ' the IT department is devoted solely to supporting the tech infrastructure. Constituent-facing technologies are budgeted and sourced as part of Habitat's programs. That's ideal, but as others pointed out, it feels unattainable for many smaller organizations, where one or two people handle the tech for everything and aren't always consulted about the technical requirements of new projects.

Steve Heye of Chicago YMCA writes a lot on his blog about IT alignment. The secret, he says, is rather than always being the advocate for tech adoption in your organization, educate the stakeholders in your organization enough that they become the advocates. I used this great quote from Steve: "IT needs to stop being the ones asking for new money. If you have stronger relationships with the rest of your organization and you help them develop the business case, they can ask for the budget for the project. Notice I said ask for money for the project, not for the tech. It is just different when someone else asks to fund a project, rather than IT asking for more technology. Let the rest of your org become the champions for technology."

About implementation, I offered the three P's:

  1. Phased schedule: For each phase of implementation, have the entire system backed up and ready roll back if something goes wrong. If a component is broken, don't build something else on top of it.
  2. Publicize changes: This means publicizing changes within the organization, but it often means publicizing changes outside the organization too. As TechSoup learned during our own experience implementing Google Analytics, more decisions are user-facing than you might realize.
  3. Please train the staff (Oops.)

#3 should be a no-brainer, but unfortunately, it's not always taken seriously. People in the session told stories of major changes happening in their systems with very little warning, let alone training. One person said that although her organization provided training for a new email system, the training wasn't personalized or tailored to the organization's needs. This didn't bode well for the new email system, she said: it left the staff feeling like the organization had selected the cheapest "off the shelf" system rather than assessing the current infrastructure and needs.

This led to an interesting discussion about late adopters. I told a story I've told on this blog before about a very successful software development team that conformed to the archaic communications preferences of one member. I like this story a lot because it shows that while having up-to-date tools may be nice, it's more important to use tools that the entire organization understands and is comfortable using.

One executive director told us that she's tired of her organization's techie insisting that she upgrade to the newest version of Windows or Microsoft Office. "I have a lot of work to do," she said. "I don't want those distractions." Others in the room suggested that she ask the techie to explain what problem the recommendations are addressing. I think that's good advice. If you don't know what problem you're solving, it's possible that you haven't spent enough time looking at the organization's current tech infrastructure.

Technology Planning Resources

General Tech Planning Resources

IT Staffing and Mission Alignment

Technology Assessment and Asset Management

Budgeting for Technology

Technical Volunteers


Discuss This in Our Forums

What strategies have helped you with tech planning at your organization? What problems are you still struggling with? What would you like to learn in the webinar? Join the discussion in this Tech Planning forum discussion.

Elliot Harmon
Staff Writer, TechSoup