9 - Managing For Success
Gamification projects generally require people to change - both those who play the game and those who administer it will need to learn behaviors different to what they previously did. While "change management" is a gangly topic that's well beyond the scope of the present book, Burke will consider some of the issues that are particular to a gamification project.
Gamification projects must be proposed, funded, and managed just like any other change initiative. The broader topic of managing change projects is outside the scope of this book, and there are many other excellent resources on the topic. For now, let's focus on the areas where gamification projects differ from other change initiatives. The most important difference in gamification projects is in the design approach, and the specifics will be explored in this chapter.
Selling Gamification to Business Leaders
"Gamification" is a unfortunate word - as its correlation to games makes some people dismiss it as frivolous - and as such it is better to avoid using the term altogether in favor of something more serious-sounding like "motivation." That is the goal of gamification. Likewise, dispel the word "fun" and use "engagement" or "focus" in its place.
Those who are interested in gamification are focused on its methods (which are game-like), but instead describe the process based on the benefits that leaders understand and wish to achieve, and back into the gamification practices.
(EN: Actually, start with "motivation" and decide if gamification is the right approach. A more serious issue is that gamification is a solution in search of a problem, and is often used instead of a more effective method just so that companies or developers can feel like they are playing along with the gamification trend.)
Particularly where leaders are less than enthusiastic about the gamification fad and are risk-averse, you will have to promise (and then deliver) real and measurable results.
(EN: In fact, you have to do this even if your decision-makers are itching to jump on the gamification bandwagon - because their enthusiasm will lead them to demand that you gamily where gamification is a bad fit, and get burned. A burned enthusiast is very hard to win back when there's a later effort that would genuinely benefit from gamification.)
Gamification Project Roles and Skills
Gamification is not a programming task - while it will be implemented in code, it requires a much broader range of skills to design the game experience and the underpinnings that tie it to your business.
(EN: The author rattles off a list of job titles, some of which seem like they were just made up, rather than listing the actual skills needed, which is entirely unenlightening.)
Of particular importance is that the sponsor of such a project should be the head of the business unit that stands to benefit from the solution. If the target market is prospective customers, the head of marketing; if it is employees, the head of human resources, and so on. (EN: everyone wants c-level executives and senior vice presidents to come to the table - but in truth, it should be right-sized. If you're doing a training solution, the vice president of human resources need not be summoned from his tower, but instead work with the director of employee development or even the manager of the training team.)
The IT department will ultimately be involved - but keep them in a servant role. If the guys who write the code are dictating the solution, the tail is wagging the dog and business objectives will take a back seat (and possibly be forgotten).
Selecting a Technical Approach
The author mentions that there are "gamification platforms" available from vendors who provide a suite of tools and services - however, they may or may not fit your specific needs. The technical approach should be selected after you have defined your solution and requirements, at which point you have three basic options.
Custom Development
Custom development means building your own system from scratch. Because it is "custom" it will do exactly what you require and it will be built to your needs and specifications. However, this also means that it will take a lot of time and money to deploy.
The author suggests that IT development teams often have no experience in developing gamified solutions - they have the technical skills but do not know how to encourage and motivate people (EN: this is not their job, and it's frankly better if they stayed away from that task. It would be more valid to state that lack of experience means you will have to spell it out for them. You can't be lazy and say "badges" and expect them to roll out a system that enables you to develop and deploy them, but instead must tell them every detail.)
He also suggests that analytics are often overlooked by internal IT development teams. (EN: Again, not their job, they should not be asked to define the analytics. It's also worth stressing that the IT team doesn't overlook it, but the project team overlooks it - because the developers will build what they are told.)
In all, it is catch-22: if you never let your IT team design a gamification solution because they do not have experience doing so, then they never gain the experience in doing so. If gamification is a strategic priority, it is worth struggling with the first few projects to build the in-house muscles to do the job.
Purpose-Built Solutions
The author mentions solutions that are available for generic kinds of tasks, like customer relationship management, that have gamification features that can be switched on. This means that a solution can be rolled out quickly and cheaply (EN: allegedly - I've heard "all we need to do is turn it on" too many times to believe it) but the disadvantage is that you must accept whatever functionality they provide, and run the risk that they may break your solution when the product is upgraded.
It's also suggested that a purpose-built solution is great for a me-too project, but will not give you competitive advantage. Chances are all of your competitors have the very same information systems or something that is extremely similar, so all firms that leverage these systems will have an approach to gamification that is essentially identical.
Gamification Platforms
There are a few niche providers who have developed solutions specifically for gamification, which the author suggests are so feature-laden that they can support a wide array of gamification initiatives. Vendors who develop these systems have expensive experience with gamification, and are generally willing to modify their products to suit your needs. (EN: another area in which I have had some negative experiences in general. They will charge you to customize the solution, then share the solution with your competitors with the next version upgrade ... contract verbiage that forbids this generally is not sufficiently definite.)
Caveat: It's Not the Technology
A technical solution provides the capabilities necessary to deliver a gamification solution - but that is all. The software won't design or operate your program for you, and will only do what you tell it to. It can be just as efficient at supporting a poorly-conceived program as a well-considered one, and the software doesn't know the difference.
There are a few technical reasons that a system will cause your efforts to fail:
- Your plans are compromised because the system you chose doesn't have the features you need (which is not really technology, but choice of technology)
- The gamification system does not communicate with or share information with the existing business systems that house data germane to the program
- The gamification system is buggy and doesn't work quite right, causing the system to fail on a fundamental level
- The gamification system is not robust enough to handle the volume of traffic that you load upon it
But it is a general principle that the majority of failures of gamification programs are not caused by the technology, but by the conception of the solution that the technology (successfully) delivers.
Promoting and Launching
Burke dredges up the hackneyed (but fitting) line from a 1980's baseball movie: "If you build it, they will come." That has been the assumption of a great many failures, and it never holds true in reality.
Users will not automatically become aware of your solution just because you build it, and the word that your new system exists will not "go viral" to make you an overnight success. Like any business operation, you have to do a lot more than just open the doors to the public.
Even if you have a captive audience for your solution, in instances such as rolling out a gamified solution for employees, word will not spread and you will have to undertake effort (more than just an e-mail to all employees) to make people aware of it, aware of the benefits, and aware of how to start playing with it.
Budget for it. Engage marketing. Set promotional goals. (EN: Burke goes into a little more detail, but this really is a marketing operation and should be planned just like any other advertising campaign, with budget to announce it initially and periodic effort to send reminders.)
A special note of gamified solutions that are social: beware the empty playground. Because the attraction of a social game is other players, you will have to work to gain a critical mass of players in order to have a community for others to join.
(EN: I recall advice on social solutions, which is not to start out social at all. Build a system that is engaging on an individual basis, and when you have a significant body of users, then implement social functionality to connect them. Not only does this start the "social" when there are sufficient users to make it a success, but it also makes sure that the game itself has sufficient appeal without relying on social to make it so.)
Managing the Benefits
Another critical aspect of gamification, particularly in commercial organizations, is measuring the benefits the firm is deriving. Even if your effort is a success, the firm may pull the plug at any moment if it senses it is not delivering real results - so sending this message, regularly, ensures the organization remains devoted to supporting the solution on an ongoing basis.
Consider the objectives of the project to be the "baseline" success metrics. Chances are it will fail some of them, and that you will discover new metrics along the way. Perhaps a gamification system that was intended to attract new customers fails to do so, but becomes popular with existing customers - such that customers who play the game purchase more frequently.
Burke suggests that "benefits realization is the responsibility of the project sponsor" (EN: but this attitude often makes others lackadaisical, making them order-takers who do not become personally invested in the program, because they realize that it will be someone else's fault if it fails.)
He also warns of meaningless metrics: things such as the size of the audience and their depth of game engagement is good for the game, but not necessarily good for business. The behavior of players in the game must be correlated to their behavior in their roles (customer, employee, or whatever) outside of the game in order for its "success" to be meaningful.
(EN: He provides no more detailed metrics for the success of gamification. Consult other sources for that, as it is a significant weakness of many technology projects.)