Blog Listing

Nonprofits should build a culture of technology and training

This is a guest post by Stuart Boyd, the Chief Technology Officer of Marathon Kids, which “is dedicated to improving the health of children by providing them with the tools, motivation and support to live happier, healthier lifestyles.” This post first appeared on Stuart’s Medium blog.

Technology unlocks a nonprofit’s ability to scale its mission, and impact, in a cost effective manner. So why don’t more nonprofits successfully do it when tackling projects, especially for internal staff? In this post, I’ll examine key factors that contribute to that success but lie outside of the technology itself. Fumbling these pieces insures failure of your technology initiative. Hopefully this article helps all of us avoid these pitfalls and turn our plans into lasting impact.

You have internal customers

Too often people view internal projects with a lower bar than a technology product that is meant to be sold to the public. This mistake dooms many good solutions due to insufficient adoption and utilization. Organizations cannot rely on obligation or mandates to drive adoption of new technology. You must appeal to your internal users with the same crisp identification of problems and solutions used for selling technology to the general public. Failure to do so results in “shelfware” that never gains traction and results in wasted effort and investment.

Instead, follow the same process for internal projects that you would for an external solution. In many ways, the effort gets simplified because you have direct access to your staff/users and you have restricted competition since you only need to surpass the incumbent solutions. The ability to observe your target users as they do the work, greatly improves your chances of success. By watching your future project beneficiary you can ensure that your new solution actually delivers the value and problem resolutions that inspired the project.

It also creates invaluable opportunities to ask questions and create a dialog with these users. These conversations inform the specification for your project. You can also find champions for the new work. These champions help build enthusiasm with their peers, can help support others who may struggle with the new solution, and help greatly in a successful launch of the solution.

Don’t boil the water, just keep increasing the heat

Remember the anecdote about a frog in a pot of water gently brought to a boil? Although that anecdote turns out to be false, trust me, the lesson works in this case. You may see the vision for a brave new world, but introduce it to your users as a series of simple steps. In other words, give your users easily digestible pieces of new technology as opposed to changing many aspects of their daily work all at once. This helps whether introducing a new way to do an existing set of tasks or creating brand new capabilities. You can launch a large set of new capabilities, but communicate it in a series of concise pieces that clearly tie the new capability to an improvement in current workflow or a new and beneficial capability.

We’d love to spoon feed small, incremental change but some projects require a “flip the switch” approach in order to go live. In these cases, apply this strategy to inform your training and communication plans. You’ll want to balance making sure users know how to do the breadth of their jobs with the danger of information overload. Make sure that early training includes scenarios that clearly demonstrate the value of the change and present these early in the training. A couple of early and concrete examples of how the new system improves over the old tangibly shows your users how they benefit from going through this change, the associated training, and pulls them through the learning curve.

It may seem counter-intuitive to make 100% of a solution available but only do training on 15% of it every week. However, you are better off with 100% adoption of 30% of the solution after 2 training sessions than 30% adoption of 100% at the same point. That is because you can carry 100% of your audience through the remaining functionality. In contrast, if you lose your users early in the process, you’ll struggle mightily to bring back 70% of users who abandoned your monolithic roll out.

Projects end with success, not go live

You haven’t delivered a solution until users adopt it and recognize the value of your solution. Keep this front of mind as a project moves towards launch. Technical teams can get under a time crunch and all the work involved with meeting a deadline. However, you can’t lose sight of your end users and what they need to succeed with your new solution.

That means getting the communication in place to promote the new features and how to use them. It also means having time set aside to answer user questions, fix discovered issues, and solicit initial feedback. You don’t have to take my advice, trust the estimable Will Rogers, “You never get a second chance to make a first impression.” The momentum you establish when you start to deliver your solution will disproportionately influence the eventual success or failure of the project.

Work within these guidelines and you’ll see more of your internal technology projects deliver the desired benefits. This helps build an organizational culture that welcomes new solutions into the day to day workflows. You’ll see a growing embrace of new technology that reinforces each subsequent project and improves the overall value of your organization’s investment in internal tools and technology. This lays the groundwork for an organization that innovates quickly and can capture the advantages offered by ever-evolving technology.

Show Buttons
Hide Buttons