10 Education Technology Implementation Pitfalls and Ways to Avoid Them

With a little planning, many of these potential technology roll out and adoption issues can be avoided.

Failed or troubled implementations of instructional technologies can give the whole idea of ‘ed tech' a bit of a black eye and result in bad experiences that may take years to forget and move on from. The fact is, technology implementations struggle or flat out fail every day, but the good news is that many of the shortcomings that lead to problems can be foreseen and circumvented.

I've been running and overseeing technology projects for many years now. I've had the good fortune of experiencing many successes, often enabled through methodical planning. I've also experienced the occasional technology implementation failure. There's no substitute for experience, and I've tried to embrace those failures as the learning opportunities that they are.

Following are ten potential problem points for any tech implementation and roll out effort, and some thoughts on how to proactively avoid them, or at least be better prepared for them. These are basically fundamental concepts from the discipline of project management, adapted to instructional technology projects and the educational environment.

1. Insufficient budgetary planning: This is surely a tech-success killer. There's a lot of ways for this to go wrong – improper licensing, no planning for support or upgrade costs, not enough budget to provide enough training, etc. Remember, you're better off overestimating than under estimating. If something ultimately has to be slashed at budget approval time in order to keep the project moving forward, think very carefully about what you can give up without introducing a high element of risk to your project. You're better off doing a smaller number of properly funded projects, than a larger set of improperly funded efforts, so maybe this, or another project should be pushed back. This is an area where a strong project sponsor can be helpful with decision making or influencing other decision makers (a nice segue into no. 2 …).

2. Failing to secure senior administrator/executive-level buy in and sponsorship: To position your technology imperative to succeed, you must have buy in from your school's top administrators or cabinet level managers. Support and sponsorship from at least one upper level administrator can help ensure sufficient resources, and establish your project as a priority. Without it, that's an important support missing from your project's foundation.

3. Limited training: Another common implementation hurdle is planning to provide the training needed to really get users comfortable with the new or updated technology. Often there is some provision for training, but it simply isn't enough. If you want your technology project to succeed, you need to go out of your way to provide enough training and hand-holding to make users productive with it. While it is possible to go overboard with this, providing more training than might really be needed, this is an area where being over-prepared is better than falling short. If training is costly, then consider ways in which any over-purchase might be leveraged. Some companies will let unused training credits be applied towards other costs, or at least be kept active for a long enough time to let them be used (for future hires for example).

4. Inadequate technical testing/validation: This seems like such a no-brainer, yet it is not unheard of for a tech implementation to struggle or fail because of some undetected incompatibility, or other untested assumption. The technology you plan to use needs to be tested in real-world conditions. The more reflective your testing is of the ways in with the technology will be used when it is in production, the better your chances of uncovering potential issues and addressing them (or at least being aware of them before you “throw the switch”).

5. Failure to involve faculty from the onset: If your technology is going to be used by faculty, you must get members of faculty involved up front, and not just seek to bring them in after the project has moved through initial stages. This often makes the difference between faculty feeling they are being told what to do, and having them on board and sharing ownership and the desire for success. Moreover, well chosen faculty members can provide valuable insights into potential challenges, or angles to technology uses that others simply wouldn't think of. Even if a technology is indirectly related faculty (new tools for students, or parent portals, for example), you would be wise to seek faculty perspective early and often.

6. Not understanding the student's perspective. This is similar to the issue above, and the same basic approach can help to circumvent related issues, but I want to mention another aspect of this that is germane to the educational environment. Often a technology may be focused on one audience, like faculty, but have an impact on the students. Maybe a new attendance taking or grade management tool is being implemented. The student may never see or use the tools themselves, but their academic lives may very well be impacted by the technology (if either of the aforementioned types of systems result in improper information being stored this would surely impact students!). Make sure you take some time to consider this important angle.

7. Insufficient support: Once the technology is in place, users have to have a functional method for getting questions answered, and resolving issues. Users need to know who to contact and how to contact them, and they need to be able get their problems addressed in a timely manner. If you don't have a workable solution for this, it is highly likely that your users are not going embrace this new or enhanced technology, and your project is going to head in the wrong direction.

8. Failure to incorporate training into on-boarding for new users: This could easily fall under the category of “limited training” above, but it is really a long term consideration and it often seems to get overlooked. You may put a ton of resources into training during the initial roll out of a new technology, and it may get up and running right on target, but if you don't plan for how new users are going to get up to speed with the tools in the months and years that follow, you're going to have unhappy new users and your short term success can be tainted over the long haul.

9. No/limited risk assessment: One of the elements of project management that is often overlooked is consideration of assumptions being made and the risks that come from those assumptions not holding true. At a minimum, there is often an unspoken assumption that many things simply will not change. Can't you just hear it now? “Well, we assumed that …”. It's really not that hard to consider and document assumptions on which the success of your project is based (things like having adequate bandwidth, users liking the solution and feeling they have a need for it, related/dependent technologies being available, and so on). Once documented, circulate the list to stakeholders who can provide perspective on the possibility of any of these assumptions being mistaken or misinformed, then listen to what they have to say and put some thought into what to do if those concerns come to pass. This doesn't have to be a major effort – just take a little time to consider the possibilities so you aren't blindsided if something doesn't work out as intended.

10. Poor (or absent) long term planning: Okay, your technology is up and running, and has worked reasonably well for a year or so now. Time to re-up for support and maintenance, or pay the next licensing installment. What's that, you forgot to budget for contract renewal? Uh-oh. Or maybe your technology is so popular and well received that more users than originally intended vie for licensing, or the use of technology consumes more resources (like network storage or Internet bandwidth) than you planned for. Try to make sure you devote a little of your project planning to considering the long term possibilities (this ties into the risk assessment element above).

Of course, I haven't covered every possible pitfall, there are various other ways a project can go off track. Feel free to weigh in with observations of your own! Thanks.