Podcast 15: Reality in Gamification Project

Welcome to A Question of Gamification, a podcast where gamification expert An Coppens answers your questions.

Welcome to a question of gamification. My name is An Coppens. I’m the show host and chief Game Changer at Gamification Nation. And this week’s question is a build on on last week’s question of what are the processes that we use? What are the deliverables that we have? And this week is what about project reality? Because last week, we went through the five step phases, so business specific user research, gamification, design, development, and support. And this week, I want to delve deeper into what is the reality like in a gamification project.

Now, we just finished a major project took us nine months to get where we are today. And I have to say, I’d love to say it was a smooth and easy process and everything worked according to plan. But hey, that’s not reality. In fact, we had from day one, a delay of a number of months, actually, in terms of contract negotiation and setup negotiations. So that’s what that was one. So that’s something that in a lot of cases, and a lot of projects is forgotten that, yes, procurement typically, has I say about everything, commercial terms, we may have a say about too, because in gamification and game design, what we aim to do and how we work is we aim to retain the IP so that it’s a win win for everyone so that we’re not because of one game design that we used for one client, that we’re tied down to never ever be able to use that, again. It would be crazy for us to sign away. Let’s say the intellectual property for a crossword or an unlocking of content game mechanic, and then to never be able to use that again with future clients.

So obviously, we’re kind of tied to what we want to create, when we are looking at game design and intellectual property, obviously, anything like branding, graphics narrative that we take from the client or that the client already has, even content that the client already has, obviously, that is retained by the client. We just put that into different shapes and formats.

So there is always negotiable there. So that was one thing. So the reality of a project may mean that you spend a lot longer in the procurement and negotiation of terms phase. Then we do before we start to the fact that we had, like, originally, we had nine months, and then that got shorted down to five months. That meant some of our design processes had to really work concurrently and in very rapid succession.

I remember doing the business scoping phase in two weeks, at the same time, we launched the user research phase, which had already been started, but because nothing had been signed off, we didn’t have access to the clients people. So yeah, there is a lot of factors in there. So did it compromised the level and depth of research? Absolutely. And, you know, that’s reality. You know, I’d love to say for every project, we do user research with 10% of the target audience, or idealistically, that’s fantastic. In reality, we may only get a fraction of that because of time, because of budget, because of due date.

I come from the broadcast sector and in broadcast sector, you often have a go live date where already promotion has started for a program or a movie or a production to go live on a certain date, even a channel at times. And you know, everything else has to backward fit into that timeline. And that’s not very dissimilar in a lot of our game design processes and project. Often the client has a very definite time. So I recall one of the board games we designed, there was a definite conference date. So we had to work backwards from there and say, okay, which printer can still deliver on what time? How far can we push the deadline before it has to go to print? And how quick can we work then to make sure that we deliver, so it’s fine. And it’s a great achievement when we do deliver in those very sharp deadline situations, but sustainably over the long run, we can’t do that for every single project. Plus we’d burnout our people, the client may be compromised in quality as well.

So because, for example for the board game, although it won us awards, the first version of the game still needed to be tweaked. And I think we had, if I recall correctly, we had two more or three more iterations before the the final box that the client is now happy with. And they are still building extensions to the existing pack, which is not unusual for board games, for example. And the same with most of our designs, they go live and then new snags are spotted or new feedback comes back and we may iterate we may add on or we may take away parts. So the reality of you know, all our five processes running smoothly and consecutively. Reality is different. So the other side of reality is that certain things come up.

I’ve had in the middle of user research, the the survey server go down. I’ve had, in the middle of our graphics experience the graphic designer going missing in action. I have to say, we have the graphics covered with in-house graphics now. So unless something seriously happens to our guys, at least we have coverage there. But it doesn’t always be the case. With developers, we have had developers saying they can do stuff and then finding out that they can’t. The same with platforms. We’ve worked with platforms who sold us “Oh Yeah, we have all these bells and whistles. And then we wanted to use the bells and whistles. They weren’t actually ready yet, or they weren’t actually there at all. They were just oh no, no, it doesn’t work like that it should work like this, where we had to adapt our designs.

So in any given realistic projects. And in any given real experience, there will be things that don’t run so smoothly. The process whilst we still actually stick to the five key headlines of business specifics, user research, gamification design, development and support, what they still happen and the deliverables attached to them it typically still happen.

The timeframes could vary. The level of access we get to do user research may vary. The level of time we have available to actually do the whole thing may drive, how quick things are done, and how low our good enough bar has to be set. Because, you know, I’m a slight perfectionist, and people that work with me will know that ask anybody on the team. You know, there are certain points that I’m not willing to compromise on. There are others that I would say, yeah, this is good enough, it has to be like this to be accepted. And good enough is a variation of Will it be accepted by the client? Is it playable? Is it delivering on what we set out to do to deliver on the business objective? And then the iterations would come for, “Okay, how can we make it from good enough to better ?” And budget will decide some of that. Tools will decide some of that. And then availability of the client is the one components and one of our corporate clients asked me one, one point during the proposal phase, they said, Okay, so how long will this process take? And I said, Well, we can get everything you want to get them done in this space of six months. But that means you are ready to make decisions when we present you with the documentation. She looked at me, and she said, Yeah, add three months.

So realistically, the decision making cycles also play a part. For the nine month project that ended up being a five month reality, we have to fast track some of the items and also go back to the client and say, Well, sorry, we cannot accept any further input for now, because we have to move forward. And you know, we had to set deadlines as to Okay, if there’s no feedback in that we move forward with what we’ve got. Because some of the time, the feedback loop between client and design and development is also where a lot of time is lost. One thing I’m always recommending against is designed by committee or development by committee, because the more people that have to look into something, the more I suppose, variety of inputs you have. What I do recommend in most projects, is to have a core project team that has access to the decision makers who can then decide “Yes, we could work with this or no, there’s there is a bit bit more to do”. And, you know, or this is not acceptable based on our influencers or decision makers.

If you have a decision maker, one of them on the team that can group all the other decision makers ideas together, that’s an ideal situation. Some of the time what we know is that decision makers don’t want to be part of the project team with them.

In those situations, the person and the people on the team need to have access to them in order to confirm, validate, and make sure that you get decisions out of them. So slippage is something to be mindful of. From day one, everything and slippage with that means time slippage, but also budget slippage, and scope creep.

You know, usually when people start to see high level concepts and storyboards, then people get excited. “Oh, could it also do this? or Ah, yeah, maybe we can use it for that too. But then it would need a little.” And that’s where our Moscow scenario is, well, it must have this, it should have that, it could have that. But it won’t have such. Those things are important before you even touch the vision and the storyboard because yes, everything’s possible. But typically, the everything’s possible happens with more budget, more people, more time. And in any given project, delivering on time, on budget and for the project to do what it’s set out to do is more critical than to have a scope that is so vast that you have no idea where it might end up.

So from my perspective, I always think project reality. And you know, the recent project, we had a demonstration of it yesterday. The night before one of the guys pulled an all nighter, the guys in development, pulled several working weekends, bank holidays were forgotten about. I was testing. I had my family testing. You know, my partner is his core, and most of our projects, bless him is he’s fantastic. He does love games, thankfully. And he’s also a very patient man.

So, the reality of a project, how I best best describe it, it’s like you see the duck sliding over to water and below it, there is a whole bunch of people treading water like crazy to stay afloat. Because that is often reality doesn’t have to always be best.

In every given project, there’s always a snag, there is always something that pops up that you said how that could have been better, or this, this should have been this. And you know, when you look back over a project, when you look back at it, and you’re satisfied to say, Wow, we pulled it off. And this recent demonstration was one which was 10 games in the quest for recruitment to showcase employer branding, recruitment and an experience of what a real role would look like for an organization. You know, when I look back and say where we started nine months ago, and where we got to, I’m actually mega proud that we got that far. And that it looked that good, given all of the constraints that we were dealing with, under budget that we were given, because we were still working on a very tight budget to deliver the level of delivery that we made.

So from one perspective, that is something to always consider. So when you’re a client, looking at the reality of the project, what you see in the proposal, yes, it is, what the phases are like and what we strive towards. Also know that your budget, if you can find more, you can get more done. If you have time to start as early as frickin well possible. No incorporate that story, always easy to say. But given off feasible deadlines, three months from start to finish can be done. But it’s tight. Nine months for a big employer branding, recruitment exercise is doable, but take it down to five and it becomes a stretch.

So, you know, be realistic in the possibilities. And the keep on dreaming up projects and looking for budgets, we’d love to help you achieve those visions.

So I hope this gives you an insight into what is reality on a gamified project like. And yeah, love to talk to you more about our experiences. And I hope you’re enjoying the show. And if you do do give us a good rating and share it forward with friends and people who you think may benefit from hearing this. I love speaking to you and I hope to meet you soon in either real life or on social media. So thank you for listening,.

The post Podcast 15: Reality in Gamification Project appeared first on Gamification Nation.

An Coppens