In this article we present and analyze The Project Game; a board game used as a communication tool for the project plan in member register IT projects. The design of the game is based on the disciplines of service design, IT project work and game design. The functionality of the game is explained, and the experiences of use are handled. It was found that the game reached the goals set to it, by adding the player's knowledge about the phasing, resourcing, scheduling and risks of certain kind of an IT project. As a single event game, played in a business-to-business meeting, The Project Game differs from common gamification and game development projects, rendering it an interesting case on the field of gamification. Games and game like features have been used in training and simulation for at least 3000 years (Keys & Wolfe, 1990). More recently, applying game elements in non-game contexts has been called gamification (Deterding, Dixon, Khaled & Nacke, 2011). Gamification is often used to enhance users' long-term engagement (e.g. Zichermann & Cunningham, 2011, pp. XVI-XVIII) to certain product or service (e.g. Chou, 2016, p. 57). In this article we present The Project Game; a board game designed as a tool for communicating the project plan of a person register IT project, between the developer of the system and the keeper of the register. The game was designed to be played only once per client and it doesn't include any mechanics for enhancing the longer-term motivation or engagement of the players, thus it differs from the common uses of gamification. It features elements of interactivity, decision making and social interactions between the developers and clients, tied strongly into the process of going through the project plan. First, we take a brief look into related writings. Then we go through the background of The Project Game from the service design viewpoint. After that we explain the functionality of the game and go through the results of playing the game, from the perspective of IT project management. In the end we take a look at the game through the lenses of game design and gamification.
Outside of academic world, there are plenty of companies offering different ways to gamify
services or using games in organizational improvement. While gamification is quite commonly
used in customer services and education, its applications in industrial processes and
interorganizational work is rather uncommon. Thus, any documented cases of gamification, that share
the use-case of The Project Game were not found. It is possible that companies don’t reveal or
publicly document their internal processes, but more probably gamification has not been seen as a
viable way to improve business-to-business processes. This problem of discovering relevant
examples is also discussed by Augustin, Thiebes, Lins, Linden and Basten (2016).
Hamari, Koivisto and Sarsa (2014) studied 24 peer-reviewed empirical research papers on
gamification and found out that beside the common points, leaderboards and badges, also levels,
story, clear goals, feedback, rewards, progress and challenge were used as motivational affordances
in the documented cases. They also listed the contexts of the cases, which were, in descending
commonness order: education/learning, intra-organizational systems, work, innovation/ideation,
commerce, sharing, sustainable consumption, health/exercise and data gathering. (Hamari et al.,
2014.)
Korn and Schmidt studied the gamification of business processes. They found out that while
gamification has already established its status in service industry and health and education,
adaptation of gamification elements in production work is still in an early phase. Gamification of
the actual production work seems to have positive effects, but the number of standards and the
“safe and slow” mentality of the stakeholders makes the adaptation difficult.
Augustin et al. studied the use of gamification in enterprise systems. They found six commonly used mechanics and dynamics in enterprise systems: feedback, goals, badges, point system, leaderboards and user levels. They also defined five different clusters of mechanics and dynamics, based on the different ways gamification elements are used in attempt to motivate users. These clusters are system design, challenges, rewards, social influences and user specifics. (Augustin et al., 2016.) DuVernet and Popp studied the gamification of workplace practices. While most of their findings and thoughts consider motivating the user through common reward mechanics in training, recruiting and sales, they also talk about gamification of the content of the work, using e.g. simulations or interactive media. (DuVernet & Popp, 2014.)
The basic idea for The Project Game was invented when service design methodology was applied
on the work of project management at the IT system developer Avoine Oy (Ltd) in 2013, as a part
of a master’s thesis work “Palvelukokemuksen parantaminen tietojärjestelmän
käyttöönottoprojektissa” (Improving the Service Experience in Information System’s
Implementation Project) (Pousi, 2014). The goal of the thesis work was to find service ideas for
enhancing the client’s service experiences in Avoine’s IT systems’ implementation projects.
The thesis project was done utilizing Stefan Moritz’s six phase service design process. In the first
phase (Understanding), the context, possibilities and constraints of using the service are defined.
In the second phase (Thinking), the possibilities for the service are found and a strategic direction
is given for the research. Innovative ideas and solutions are created in the Generating phase. These
ideas are evaluated and the best ones are selected in the Filtering phase. The goal of the fifth phase
(Explaining) is to provide different interest groups an understanding of the service under
development. The last phase of the service design process is Realizing. In this phase the final rules
and directions are formed to make it possible to deploy the selected service ideas.
The Project Game is designed to be played only once per client, in a meeting usually reserved for going through the project plan. The goal of the game is to get through the software project within certain constraints of scheduling and personnel resources. The game is co-operative and noncompetitive, so both the client’s and the developer’s project teams work together to win the game.
• • •
Project task cards, which are the main tool for communicating the project phasing. Each task card includes a short description of the phase and its effect on the schedule and personnel resources. They are organized in chronological order, so the first card is the Start meeting and the last one is the Approval of the project. (Figure 1c) Event cards for different phases of the project. Each card presents a typical surprise in an IT project, which can be positive (e.g. database integration went easily, which saved a day from a programmer), but usually they are problems, causing delays or requiring extra resources. For example, a surprise in the database formatting could be solved either by adding programmer resources or extending the project deadline. (Figure 1b) Resource cards for the client and for the developer. Each card represents one day of work of a certain expert, like programmer or client’s project manager. The game is played by going through the project task cards and following the instructions on the card. The progress pawn is moved on the timeline board according to the effects on the schedule, and the players play resource cards from their hand on each Project task card. Meanwhile, the facilitator of the event, who also works as the project manager on the developer side, can tell more details about the project phases.
When a project task card implies surprises, an event card is drawn from a pile dedicated for that phase of the project. The project team should discuss about the surprise. If solving the issue requires either more personnel resources or time, the time pawn should be moved or resource cards played from corresponding player’s hand. Event cards include the only explicit decisions in the game, when the players need to choose their way to solve the problems.
The game ends when all the Project task cards are played and all the problems are solved. In the
end, all of the project tasks, surprising events and used resources are present on the timeline board
(Figure 1d). If there was more time or resources used than was planned, this is a good spot to
discuss the real-world effects of that. It is also common to go through some of the other event cards
and discuss about the possible problems in the project.
Typical game session takes about two hours, which mostly consists of discussions between the
project participants and the facilitator explaining the tasks and events. One of the players is chosen
to be responsible of moving the time tracking pawn on the timeline, another one is given a task of
managing the event cards. Each player also performs her own role, which corresponds her role in
the project. Although the serious games are often used as instruments of switching the viewpoint
through role-playing different roles
Each game session can be modified to match the project in hand. This modification is done by the game facilitator. The game can be modified by removing non-suitable project task cards, altering the deadlines, limiting the amount of resources and ordering the event cards. In some cases, completely new and customized project task cards can be produced to better match the needs of the project and the game session.
Because The Project Game was developed as a service design tool and it was used as a tool in actual project work instead of being a research object, exact metrics or qualitative data about the efficiency and experiences of the users does not exist. Following experiences are based on the personal memories of the designer and facilitator of the game. The effects of the game are estimated by comparing the perceived user experiences and success of the projects where the game was played with previous and later similar projects where it was not used. In the comparison group, the project plan was communicated in a traditional way of going through a slide show and other documents in a dedicated meeting.
The project game was used in at least five person register implementation projects. The clients were different Finnish labor unions, social/health or student organizations. The average project scale was less six months. Typically, the client-side players consisted of the administrator of the system, the financial manager and the organization leader - who usually acted as a client-side project manager. From the developer’s side, at least the project manager and main programmer were participating in playing.
Typically, the client-side participants didn’t have much of IT expertise. Thus, it was very important to concretize the phasing, scheduling and potential risks of the project, by playing The Project Game. Especially the personnel of the student organizations were usually quite young, with no relevant working experience. Playing the game was very natural way to learn new things for the young project members.
In 2014, 83.8 % of all IT projects were challenging, or failed completely, if measured by the
features of the IT system and usage of time and money in the project
In complex group work it is important that the information flows “all round the network”, instead of via the central person (in this case, the project manager). This lessens the overburdening of the central person and leads to greater success. (Huczynski & Buchanan, 2013, p. 365). Playing The Project Game helped the project members to understand the connections between the roles and responsibilities of each other. This helped with the sharing of information, as only the people relevant to the task were communicating together. The excess communication of the project manager was diminished, leading to savings in her workload and overall costs. A lot of information about the processes in the organization is required in the planning of an ICT service. Often this information is undocumented. Finding the right people for the planning process, beside applying and reasoning of the found knowledge lead to early design of required features, lessening excess work and unnecessary iterating. This helps with the resourcing and scheduling of the project. (Hyötyläinen, 2010, p. 8). The phases of the project are gone through and discussed when playing The Project Game. This helps with choosing the right people with the right information about the client’s processes, to participate in the project.
The implementation of an ICT service is a social process (Hyötyläinen, 2010, p. 66). When playing The Project Game, the project participants get to know each other in a relaxed atmosphere. A common experience of willing to reach the goal within schedule and available resources is gained during the play session, which leads to better team spirit. Later on, discussing the possible problems during the project was done in friendlier atmosphere, since similar issues were already handled while playing.
The design of The Project Game relies on the game and service design traditions, rather than the
conventions of gamification. The design was based on the findings of the preceding service design
phase. This differs from the common practice of games designed purely for entertainment or art,
which usually starts from narrative, game mechanics or personal motivations of the design team
(e.g. Fullerton, 2014, pp. 165-167; Adams, 2014, pp. 125-128; Rouse, 2005, pp. 41-47). Mission
or message-based design is a common practice among service design, as there is some external
goal, or need, for the game, which it has to reach
These qualities functioned as the “focus” (Rouse, 2005, p. 70) of the game development, as every rule, game mechanic, piece of content and other part of the game should support these goals. The game has only a few explicit choices during a play session, but it incorporates many patterns of game design, such as clear goal, use of limited resources and feedback of progression. Richards, Thompson and Graham (2014) write about the importance of context in gamification. When designing The Project Game, a lot of thought was put into the typical clients who will play the game. As Avoine usually works with different (non-)profit organizations, the average target audience was profiled as middle-aged non-gamers. This directed the choice of the medium and the selection of the game mechanics, so the game would be easy to approach and not too complex or time consuming to play.
Since there were no competitive elements in the game and the facilitator was always present, the
rules of the game were bent, if they contradicted with the desired message. Essentially there were
no correct answers or optimal solutions to the events, but the best solution was found through
discussions, which sometimes lead to “outside of the box” solutions. In a way the game was closer
to a playful experience than a strictly formalized game, or if applying the thoughts of Caillois,
interpret by
Since The Project Game game is used just once in a business-to-business meeting, it differs from the common uses of gamification (e.g. Chou, 2016, p. 57; Zichermann & Cunningham, 2011, pp. XVI-XVIII), as it gamifies a part of an industrial process, rather than a product or a service. The Project Game is a good example of explicit gamification (Chou, 2016, p. 53), or exclusive gamification (Ferri, 2014), as it incorporates a familiar form of board game and is played in a dedicated gaming session, instead of in-between or aside of other tasks.
When comparing the functionality and features of The Project Game to the commonly applied gamification mechanics, presented by Hamari et al. (2014) and Augustin et al. (2016), we can find that it lacks the long-term motivating and engaging mechanics of extrinsic rewarding. Hyrynsalmi et al. (2017) mention these features as possible reasons for problematic behavior - like acting only when rewarded, focusing on the game features instead of the gamified process, unwanted competition within a work team etc. Instead, the game provides the players the story, goals and potential challenges (see e.g. McGonigal, 2011, p. 21; Chou, 2016, p. 7; Hamari et al., 2014) of their own project, thus integrating the playing of the game strongly to the actual project at hand and providing a simplified and concretized model of it.
Using resource cards from hand and making occasional decisions engage the players strongly to the common goal. Since the game features correspond strongly with the actual project features, the game was felt to utilize the intrinsic motivations of the participants rather than the extrinsic ones, which are often targeted in the gamification critique, discussed thoroughly by e.g. Daphne Dragona (2014) and Ian Bogost (2011). 7.
The Project Game was developed by two experts; a service designer and project manager of Avoine Oy, and a professional game designer. Multidisciplinary approach provided a deep understanding on each element of the process: IT projects, service design and game design. Defining a clear goal for the design, based on the requirements found in the preceding service design phases, the features of the game enhanced the players’ abilities to work together in the project. The game was used in several real-world projects, and it was seen as an efficient and engaging way to communicate the project phasing, scheduling, roles of the participants and possible problems.
The Project Game proves that the methodology of gamification can be utilized to gamify businessto-business processes, which is a missing use-case in the classifications of Hamari et al. (2014) and Augustin et al. (2016). It concretizes the usage of resources, phasing, scheduling and problematics of a certain type of IT project, so the participants on both sides of the table can practice communication and collaboration during the project. They also gain a better understanding of their role and engage stronger to the project.
As a rather cheap medium, quick to produce and modify, the board game methodology could be utilized in other kinds of projects too. It formalizes and simplifies a process, which is repeated rather similarly with multiple clients. Although the features of The Project Game were tied strongly on the project work of Avoine Oy, in projects of a very specific type, the structure and mechanics of The Project Game could be generalized, to handle different types of IT projects. Certain amount of content and gameplay customization is required, for which at least an IT project expert need to assign some time.
Adams, E. (2014). Fundamentals of Game Design (3rd edition). San Francisco: Pearson Education. Augustin, K., Thiebes, S., Lins, S., Linden, R., & Basten, D. (2016). Are We Playing Yet? A Review of Gamified Enterprise Systems. In PACIS 2016 Proceedings. Chiayi, Taiwan: AIS. Retrieved from http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1002&context=pacis2016 Bogost, I. (2011). Persuasive Games: Exploitationware. Retrieved from https://www.gamasutra.com/view/feature/134735/persuasive_games_exploitationware.php Chou, Y. (2016). Actionable Gamification Beyond Points, Badges and Leaderboards. Fremont: Octalysis Media.
Deterding, S., Dixon, D., Khaled, R., & Nacke, L. (2011). From game design elements to gamefulness: Defining "Gamification". In Proceedings from MindTrek '11. Tampere, Finland: ACM. Retrieved from http://www.rolandhubscher.org/courses/hf765/readings/Deterding_2011.pdf DuVernet, A. M., & Popp, E. (2014). Gamification of Workplace Practices. In The Industrial Organizational Psychologist. 52(1). 39-44. Retrieved from https://pdfs.semanticscholar.org/dd09/ac9ba686ae77e9884e37dc803f84e982a481.pdf Dragona, D. (2014). Counter-Gamification: Emerging Tactics and Practices Against The Rule of Numbers. In Fucs, M., Fizek, S., Ruffino, P., & Schrape, N. (Eds.) Rethinking Gamification (pp. 227-250). Lünegurg: Meson press.
Ferri, G. (2014). To Play Against: Describing Competition in Gamification. In Fucs, M., Fizek, S., Ruffino, P., & Schrape, N. (Eds.) Rethinking Gamification (pp. 201-222). Lünegurg: Meson press.
Hamari, J., Koivisto, J., & Sarsa, H. (2014). Does Gamification Work? - A Literature Review of Empirical Studies on Gamification. In Proceedings of the 47th Annual Hawaii International Conference on System Sciences (pp. 3025-3034). Waikoloa, Hawaii. Retrieved from https://people.uta.fi/~kljuham/2014hamari_et_al-does_gamification_work.pdf