On Tuesday, I'll be talking about technology planning for nonprofits and public libraries at the National Conference on Volunteering and Service as a part of the Interactive Strategy Forum. If you're at NCVS, be sure to stop by; I'd love to chat with you.

In talking with nonprofits about their tech infrastructures, I've come to understand tech planning not as a one-time process, but as more of a wheel. Organizations with healthy IT infrastructures are continually making iterative improvements based on their program needs, documenting those improvements, and monitoring for future iterations. I eventually stumbled on the acronym DARA:

If you can't remember DARA, just think of Dara Westling, vice president of development at TechSoup Global. She's great.

For organizations with scattered or disarrayed IT environments, it's amazing how different your tech infrastructure can look after you've spent some time documenting it. For example, you might be running a constituent relationship management (CRM) database, but are all of your organization's constituents in it? Perhaps your donors are in the CRM, your advocates and evangelists are in an Excel spreadsheet, and your program beneficiaries are in paper files. Maybe some of those constituents are on the laptop of an employee who works remotely and can't connect to the CRM. Document all of those lists and take note of how much overlap there is among them.

Document all of the servers, desktops, laptops, and mobile devices that staff and volunteers use for the organization's work. That may be trickier than you'd think. For example, is there a volunteer doing design work on her personal laptop? If staff members work at home, do they store their work on home computers? What does your backup strategy look like, and what machines doesn't it cover?

If you haven't thoroughly documented your IT infrastructure in a long time, it's likely that in the process, you'll uncover some messes. That's OK: you'll prioritize and clean those up later. The goal of the documenting phase is just to get everything on paper.

Auscultation is the process whereby doctors and other medical professionals listen to the body's behavior, usually with a stethoscope. It's also a great way to think about monitoring your organization's tech infrastructure. Don't impose your own model for how technology at your organization should look; listen to the organization's performance and learn where the problem spots are. It's also significant that auscultation is non-invasive; just as your doctor doesn't need to put you under the knife to see if you have a heart murmur, you don't have to disrupt the organization's day-to-day activities to see that there's a problem with its tech.

Speaking of problems, I like the rubric don't start with a solution; start with a problem. When you ask people in the organization where the problem spots are, you might get answers like "We need Salesforce" or "we need Convio." The problem with those sorts of requests is that they might reflect the needs of only one staff person or department. If you were to implement half a dozen new donor databases to serve different departments' needs, you'd end up with a more splintered, worse organized office than you started with.

Once you've listened to what's working smoothly and what's working poorly in the organization, you can find the right solutions to meet your organization's most pressing needs. One thing I like suggesting is that rather than starting from the most ambitious solution you can imagine, start with the most basic solution. Build up from the ground, not down from the sky.

When I spoke at NCVS last year, I said that sometimes in tech planning discussions, people will start with a sort of blue-sky, unlimited-resources blueprint:

The problem is that once the realities of budget, staffing, and compatibility issues set in, that blueprint starts to look like a mess:

Instead, try starting from the simplest path. What data does your staff need to be able to access and share? Could a cloud-based, packaged solution like Microsoft Office 365 or Zoho meet all of your needs? Which needs can't it meet?

Align has two important meanings. First, it means implementing technology changes in a way that's consistent with your organization's mission, programs, and workflow. Second, it means giving IT a voice in programmatic planning and decisions. Easy, right?

On technology implementation, try 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 might mean 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. (Sorry.)

#3 should be a no-brainer, but it often isn't. At NCVS last year, a woman told me that although her organization provided training for a new email system, it wasn't personalized or tailored to the organization's needs. The experience left the staff feeling like IT had selected the cheapest "off the shelf" system rather than auscultating the current infrastructure and needs, and it sounds like they were right.

I've often heard nonprofit IT people complain that technology isn't given a voice in their organizations' decisions. It's a huge problem, but it's also a two-way street. If staff members and volunteers don't feel like they've been listened to in the tech-planning process, then there's little chance of any new systems you implement working.

The other side of alignment has to do with making sure that IT is appropriately resourced within the organization, and that IT needs are included in program plans and budgets. That's a tall order in any nonprofit, but it's particularly tricky in smaller organizations that don't have dedicated IT departments. As an "accidental techie" who handles IT on top of a full-time job, it's difficult to make any headway. Mark Shaw addressed this problem head-on in his essay on the purposeful techie:

 A major issue the Accidental Techie has with her responsibilities (however informal they may be) is that they conflict with her core job function. Not everyone is a natural born multitasker, but the Purposeful Techie puts in place parameters that allow her to balance competing needs. It’s basic, but scheduling time in her calendar for maintenance and individual computer-user assistance at appropriate intervals in the day, week or month will bring order to the support role and create boundaries.

What Happens Next

The DARA system is a wheel, or maybe it's an ouroboros. As you document the changes that you've implemented over the last cycle, you'll already be continuing the process of listening to the organization's performance and identifying places that need rebuilding. It's a model that's based on iterative change and adapting to new challenges that come along. With each new problem, each change, and each rebuilding (successful or not), your organization will grow in its ability to use technology to meet its mission.

Additional Resources

Photos: Liz West (CC), Nottingham Vet School (CC), hijukal (CC), d.billy (CC)

Elliot Harmon
Staff Writer, TechSoup