Podcast 14: What is involved in the gamification design process?

Welcome to this week's Question of Gamification. My name is An Coppens and I'm the show host for a Question of Gamification. And this week's question is one that on occasion crops up more from our competitors if nothing else. Occasionally, also from clients, but it's something we do always answer for clients in proposals. And that is: what is involved in our gamification design process? How does it work? What are the components? What are the deliverables? It may be one question split into a few elements. And I want to tackle that from the ideal project perspective in an ideal world where everything runs smoothly, where you have unlimited resources and unlimited timeframes, etc. Because the reality of any given project may be different. And I'll come back to that next week. The official steps in our process are understanding the business specifics. Now in this business specifics phase, we want to know, why do you want to gamify this project or this process? Why do you want to do this now? What else have you tried? We want to understand the reason behind it.  Then we also want to understand the success measures. How will you know that the project achieves what you wanted to do? How will you know that the project has been considered successful? Does that mean higher numbers recruited? Does that mean higher numbers in sales? What is it that you want out of it? Are there soft measures? Is that increasing confidence, increasing retention of knowledge, deployment in reality? Whatever the success measures are, we want to unlock those in our business specific phase. The other exercise we occasionally do, maybe not all of the time is the Moscow exercise and Moscow. It's a city, but it's also an acronym. And the M stands for: what must be included in the gamified process? What should the gamify process include? What could it include? And what Won't it include? So MSCW and the o's are the bits in between that make it Moscow: what must it have? What should it have? What could it have? And what won't it have? That sort of outlines the scope of a project, because not every project will need everything. Sometimes we also need as a measure of how we can get to good enough? How can we get to a project that will deliver but maybe not, you know, a project that has everything, all bells and whistles on it?  Often budget may drive this but also constraints of software that we have to work together with. That's sometimes gamification tools, sometimes it's actually existing software already in place. It could be existing constraints within a business. We recently quoted for something where people were hired and needed to be on-boarded very quickly into service and it needed to be done remotely. People had no access to the internet, but they did have access to some standalone computers, and it could be envisaged to have maybe some tablets without Wi Fi access, with the games uploaded on it, so that they could still onboard and learn the processes. There is an example with a lot of constraints to it. So in those cases, the must have, the should have, could have and won't have is absolutely essential. The other measures in the business specifics are key performance indicators, the current processes and the current experiences people have, then the as-is process and the to-experience. Because if you want it to be vastly different, we want to map that out. It comes from good process mapping and process analysis. Knowledge, I learned in my consulting days, are sort of to blame for this type of work. But we do want to understand, how does it currently work? Because if we're going to make changes, are we making changes that are so far removed up, we are potentially hitting rejection, or are there maybe processes that could be improved, and we should just go with the process. And in those cases, we also need to buy-in,