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 last week’s question of what are the processes that we use? What are the deliverables that we have? And this week is what is the reality of a gamification project? Because last week, we went through the five steps in our process phases: business specifics, 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.

We just finished a major project which took us nine months to get to where we are today.  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, thanks to lengthy terms and contract negotiations and setup negotiations. That’s something which in a lot of cases, and a lot of projects is forgotten about. Procurement typically has a say about everything. Commercial terms, we may have a say about too. In gamification and game design, what we aim to do and how we work is that we aim to retain the IP which is what makes it a win/win for everyone. That way we’re not limited because of one game design that we used for one client, which would tie us 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.

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,  that is retained by the client. We just put that into different shapes and formats.

Always expect to have negotiations in terms. That is one thing. The reality of a project may mean that you spend a lot longer in the procurement and negotiation of the terms phase.

Originally, we had nine months, and then that got shorted down to five months thanks to the lengthy procurement process. 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 client’s people. So yeah, there is a lot of factors in there.

Did it compromise the level and depth of research? Absolutely. And, you know, that’s the 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 the budget, because of the due date.

I come from the broadcast sector and in the broadcast sector, you often have a go-live date where the promotion has already started for a program or a movie or a production to go-live on a certain date, even a channel at times. Everything else has to backwards fit into the timeline. Sometimes that’s not too dissimilar to a lot of our game design processes and project. Often the client has a very definite time.

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 in what time frame? 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.

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 all our five processes running smoothly and consecutively… Reality is different.

The other side of reality is that certain things come up.

I’ve had in the middle of user research 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 when 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.

In any given realistic project 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, they still happen and the deliverables attached to them typically still happen.

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.

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 deliver in the business objectives?” And then the iterations would come from, “How can we make it from good enough to better ?” And budget will decide some of that. Tools will decide some of that.

The availability of the client is another component where reality may throw a spanner in the works. One of our corporate clients asked me at 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 the space of six months. But that means you need to be ready to make decisions when we present you with the documentation or shortly after. She looked at me, and she said, “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 had 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. We had to set deadlines like 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, there is a bit more to do”. “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. 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. Slippage is something to be mindful of.

From day one, keep an eye out for slippage with that I mean time slippage, but also budget slippage, and scope creep.

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 comes in: 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.

From my perspective, I always think about project reality. In the recent project, we had a demonstration in front of the client for it one day.  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 to most of our projects, bless him is he’s fantastic. He does love games, thankfully. And he’s also a very patient man.

The reality of a project, how I best best describe it, it’s like you see the duck gliding 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.

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 should have been like this. But when you look back over a project, when you look back at it, and you’re satisfied to say, Wow, we pulled it off!

This recent demonstration was one, where we had 10 games in a quest for recruitment to showcase employer branding, recruitment and an experience of what a real role would look like for an organisation. When I look back and see 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 the budget that we were given, because we were still working on a very tight budget to deliver the level of delivery that we made.

From one perspective, that is something to always consider.

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. Know your budget may have limitations, if you can find more, you can get more done. If you have time to start as early as frickin well possible and in the corporate world that always easy to say. But give 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.

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.

I hope this gives you an insight into what reality on a gamified project is like.

I love to talk to you more about our experiences. I hope you’re enjoying the show, 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. Thank you for listening!