Failure. That’s an ugly word, right? It’s a word that we do not like to talk about in business, much less Learning and Development. Failure can make or break projects and careers alike, and yet we still do not like to talk about it, it stays taboo. Well, not anymore. Today I am going to talk about what can cause an L&D project to fail, and what you can do to either learn from that failure, or avoid it entirely.
First, I want to make something clear. Failure does not mean that the project does not come to completion. Most of the time a project, once started, will be completed. What constitutes a failure is what that project looks like when it crosses the finish line, which brings us to our first way to avoid failure – knowing what failure looks like. We would all like to say that you must explain what success looks like in the analysis phase of the project, but I am here to add something to that. You also need to know what failure looks like, so you can avoid it. Does failure mean going over budget, or does it mean missing the launch date by a month or more, or does it mean something else? These are questions that should be asked in the analysis phase so that you can plan for your contingencies. Knowing what failure looks like to your stakeholders lets you see where you can adjust to ensure that you can avoid failing.
This brings us to our second point – have contingencies. Build in buffers and backup plans. If there is one thing that I have learned working in this field, in every project something will go wrong. In my experience, there will always be something that does not go according to plan. A SME that takes an unexpected vacation, or a process that is being updated in three months, or even a stakeholder that is not on board with the new training plan. Whatever the change is, it will cost you time, and time is the one thing you cannot make more of. So, build in buffers, and have backup plans. Use the failures that you identified in your analysis to assist you with planning for these things and have some additional time ready for when something goes wrong. Trust me, you will not regret it.
Now you have your potential failure points identified, and your backup plans and buffer time ready. But is your entire project team bought in to the plan? This is the next failure point I see most often. Due to whatever reason, there is someone on the project team that has a different view of what the end goal should be, and they are pulling the project in a different direction. This is where you need to identify the root cause of the differing opinions and address it before it can derail the entire project. Remember that no one (usually) is just being a pain to be a pain; there is a reason they are speaking up. Typically, they have real concerns and feel that they are doing the right thing. With that in mind, address their concerns and find the best path forward while hopefully allowing them to come back to the project with even more enthusiasm. Everyone is the hero of their own story, so allow them to be that, if possible.
This is where I like to redefine the term ROI. I know, I know. ROI means return on investment and is notoriously hard to prove when it comes to learning and development but hear me out. Keep ROI in mind when dealing with stakeholders and SMEs as well. What is their ROI when working with you on the project? What do they stand to gain from this project launching? They are doing project work that is in addition to their normal duties, and usually for no additional pay, so what do they get? Find out what that is and remind them of it. Will it be that the problem they are always having to fix will be less prevalent? Will it be that the new hires they must help will be more knowledgeable? Will it be that the new process launches sooner? Find that ROI and let them see that by helping the project, they are helping themselves.
These are some of the more common examples of why projects fail, and how to avoid them. There are more, and I could fill pages and pages with stories and anecdotes about the lessons I have learned, many the hard way, about how and why projects fail. But the main thing I have learned is that failure is not always a bad thing. I have learned more from my failures than from my successes. I still remember the lessons that each failure has taught me, and that has made me a better Instructional Designer. Remember that no project will be perfect – deadlines will slip, feedback will come hot and heavy, and there will be disagreements. The key to a successful project is to keep learning and keep getting better each time.
