Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Objective

The objective of this paper is to present a prototype design of a project management application which has been designed to leverage the power of gamification. The specific set of gamified features contained within the prototype follow the model set forth in previous work which attempted to aid gamification designers in the selection and implementation of the most effective mechanics for whatever the intended purpose. This was done by mapping a number of gamification mechanics to existing effects in behavioral economics, which allows designers an unconventional insight into the behavioral reasons as to why various methods of gamification affect a user-base. It should also be noted that unlike some gamification implementations which can, at times, be seen in a negative light by being excessively game-like, the focus here is on bringing gamification into the business setting in a serious and professional manner in order to ease adoption among all users.

2 Significance

Gamified mechanics are increasingly being integrated into the software that we use every day, both in subtle and more obvious ways. While these tactics often hold the power to affect our behavior, it can be difficult to predict the exact change that such mechanics will have on a system or its user-base. Unintended consequences can be very serious at times, and a gamification designer must recognize that there is typically a tradeoff when encouraging any behavior. This isn’t necessarily to say that these tradeoffs should be avoided (or that it would even be possible to do so), but it is certainly necessary to recognize the potential consequences and to plan for them. However, by working with a model based on existing behavioral economic theory, the presented product intends to improve on typical gamified implementations through theory-based design. By using such a framework, the designer would ideally be better at both eliciting the desired behavior as well as recognizing the tradeoffs involved. If proven successful, this could inform future attempts at gamification, especially in the business software area.

3 Method

This paper draws on previous work which analyzed a number of the core concepts within behavioral economics through the lens of gamification, attempting to create a mapping of gamified mechanics to behaviors that a designer may want to elicit within a user. This essentially created a behavioral model of gamification which was used to design a prototype of a project management application which attempts to leverage a theory-based design and implementation of a set of gamified mechanics. In order to accomplish this, the design took into consideration the typical outcomes desired from the use of project management tools and then considered the employee behaviors likely to optimize the chances of those desirable outcomes. The behavioral model of gamification was then used to identify and develop the specific gamified mechanic implementations best suited to support the intended behaviors.

3.1 Supporting Concepts

As detailed and categorized in previous work, here are nine behavioral economic concepts which are common in game mechanics and gamification and were selected for their potential impact in non-game products and business environments (Butler 2015).

Loss Aversion. This is the tendency of people to exhibit an aversion to loss which overpowers a desire to acquire a disproportionate amount of gain (Kahneman and Tversky 1984).

Maintaining Intrinsic Focus. This concept contends that the addition of a tangible reward to an activity previously performed for its own enjoyment replaces that enjoyment with a form of payment (Heyman and Ariely 2004).

Pseudocertainty. This is the tendency of people to make decisions that treats an uncertain outcome with undue certainty (Tversky and Kahneman 1986).

The Paradox of Choice. This is the tendency of people to almost universally see an increase in the number of available choices as a positive change even though making a choice becomes much more difficult as the number of choices increases (Iyengar and Lepper 2000).

Scarcity/Urgency. This is the tendency of people to irrationally value an item seen as having limited availability or when the time available to act is limited (Cialdini 2006).

Variable Reinforcement Schedules. Rewarding a user for a certain action or behavior, but doing so in an irregular pattern (Lee and Fields 2007).

Commitment. The tendency of people to want to fulfill agreements that they have made in order to avoid the cognitive dissonance that occurs when breaking these commitments (Cialdini 2006).

IKEA Effect. This is the concept that one’s valuation of an item is disproportionately increased by the personal labor one has invested into its creation (Ariely 2010).

Sunk Costs. This concept implies that even though money or effort invested in the past has no bearing on future decisions, these past investments still carry significant weight when considering those decisions (Arkes and Blumer 1985).

3.2 Relevant Mechanics

The following is a list of the previously defined concepts with a description of how these are leveraged in the following product design discussion.

Loss Aversion

  • Decreasing the value of a task if the time to complete it exceeds the estimate (thus losing both the expected points as well expending additional time to do so)

  • Losing a potential bonus by breaking a streak of desired actions

  • Losing a top leaderboard slot

  • Losing in-app benefits such as task selection order

  • Losing potential points if your feature is cut or incomplete

Maintaining Intrinsic Focus

  • Non-monetary rewards are implemented and suggested, such as social rewards or status rewards

  • If monetary rewards are to be given, it is suggested that they be team-based

Pseudocertainty

  • Giving users rewards that are likely to be minor but which have a small chance of being very significant

The Paradox of Choice

  • Ensuring that the user always has a choice in how to proceed but minimizing the available options or complexity in order to help the user focus and prevent them from being overwhelmed

Scarcity/Urgency

  • Using a countdown timer to keep the user aware of the time left before a task exceeds its estimate

  • Ensuring that the user is aware of the sprint or milestone progress

  • Ensuring that the user is aware of the number of days left before the project deadline

Variable Reinforcement Schedules

  • Giving the user a random chance at a reward each time a task is completed

Commitment

  • Giving the user ownership of a feature

  • Allowing the user to create and design the tasks for that feature

  • Allowing users to place estimates on their potential tasks

  • Allowing the user to choose their own tasks to work on

IKEA Effect

  • Giving the user ownership of a feature

  • Allowing the user to create and design the tasks for that feature

Sunk Costs

  • Points and progression accumulate over the course of a project

  • Investing considerable time and energy into the design and implementation of features

4 Product

In designing the product features around the behavioral economic principles outlined above, the features were broken into functional segments based on the workflow anticipated in a project management scenario. The planning segment is primarily concerned with the development of the various tasks that a project requires, the estimation of the complexity or time requirements for the tasks, and the selection of tasks by team members. The progression section deals mainly with the points system, which is core to the gamification of the product. Finally, the status segment deals with continuous feedback to the team members about the current state of the project and the tasks therein.

It should be noted, however, that these features are focused around the interactions that a team member would be expected to have with the project and a project management tool. There would also be significant additional functionality that would be required at the management or supervisor level, including but not limited to configuration, initial setup and population, and reward structuring. This management interaction is largely outside the scope of this paper as its goal is to focus on the behaviors of the end users of project management software, namely the individual team members. This also means that the functionality described below is largely tactical in nature. The more strategic issues are expected to happen largely outside the realm of a project management tool.

4.1 Planning

The planning stage is among the most crucial of times in any project, and any errors made here can manifest themselves in a myriad of ways throughout a project’s development. The suggestions here, while not too far removed from that of typical project management software, are intended to impart ownership of the project as a whole, as well as its tasks, to the team members. This is somewhat conflicting with agile methodologies, though it should be noted that the intent is not to prevent a user from working on the most useful task available but simply to give each part of the product an internal stakeholder who feels personally responsible for it.

Preliminary Preparations. An initial planning phase would be assumed to have already taken place with the client or product owner to determine the scope and the features that the project in question should encompass. An initial priority level should have also been set for each feature. The project management tool would have also been pre-populated with these along with user accounts for each team member, with each member being responsible for a certain set of features. Ideally, this would be a process of self-selection in order to impart the greatest sense of ownership to the team members. Afterwards, the members would each assume an informal stakeholder role in the design and development of these features. Ideally, the number and difficulty or complexity of features would be evenly distributed between members, though that could be difficult in practice due to the available feature-set and the varying levels of experience and skill-sets of the team members.

Task Creation. After the creation of the initial feature set the feature owners would be responsible for taskifying all work required to fully implement the feature. This likely requires considerable cooperation among the team, especially in multidisciplinary environments where any one person would be unable to implement an entire feature themselves. This is likely to cause friction initially, but it encourages communication and collaboration within the team. Ideally, the feature owners would also have access to the client or product owner in order to ensure that the features being developed are actually the features that are needed or desired. Maintaining sufficient client communication is a commonly cited problem in project management, and this would ensure that the client is kept involved (to the extent that the client is available or willing).

In addition, it moves some degree of organizational responsibility onto the team members, which serves to help them understand the project from a management perspective and gives them the room to grow professionally. Obviously, this phase would necessitate considerable supervision with all but the most competent and experienced teams, though once through this phase, the management overhead would likely be reduced considerably.

Estimation. Once all tasks are created, team members should review the tasks for all features and put a time estimate on each. If a team member would be unable to complete a task due to a difference in expertise, that member should abstain from estimating. Each task would then have the estimates and the estimator openly listed, and discussion and revisions could occur if desired. The appropriate typical and maximum task estimates are likely to vary with the type of project and the experience of the team members though it is suggested that tasks taking long than one-third or half of a working day be broken down into smaller tasks. Larger tasks may more easily hide unforeseen risk or complexity, and even in best case scenarios, multi-day tasks may not provide sufficiently granular progression data.

4.2 Progression

Progression, both of the project and of each team member’s effectiveness, is tied to an integrated points system which comprises the core of the gamification of the project management tool. The exact values and weightings should be configurable by the project managers, but we will discuss the intent of the values in general terms.

Point Accumulation. Though a team member may gain points in a number of ways, completion of tasks is the core driver of the points system. A team member essentially gains a certain number of points based on the time required to complete a task versus the average time estimate. It should also be possible to modify the value based on feature or task priority in order to encourage team members to work on the highest priority tasks first. Additionally, the further solidify a team member’s ownership over the features they have purview over, a member could receive a bonus percentage of any points earned on that feature’s tasks, regardless of who completed it.

As another way to progress, awarding bonus points for repeated performance of desired behaviors should be supported. For example, one might track the number of days in a row that a team member has completed a task. This might provide an increasingly desirable points bonus as the successful instances accumulate, while at the same time providing additional encouragement to continue the desired behavior.

Aligning Incentives. Of course, team members will seek to use any incentive system to their advantage, so the onus is on the designer of the system (and potentially the manager who is configuring the values) to ensure that the incentives offered to the team members are aligned with the success of the project. The overarching goal for a project management tool should be the efficient utilization of a team’s resources, and so the team should be rewarded for working quickly and effectively together towards the completion of the project. Again, while there are strategic issues that likely complicate this overly-simple explanation, at the tactical level, a project management tool should encourage team members to complete the most important remaining tasks as quickly as possible while still achieving whatever quality level that the client desires.

To reduce opportunities for abusing the points system via intentionally faulty estimates, all team members capable of completing a task enter their own estimate, and the effective value of a task is based the average of those estimates. However, after selecting a task, the team member’s effectiveness is judged based on that member’s own estimate. Additionally, any team member is able to choose any available task to work on, so if a task ends up overvalued, it may be any member who can take advantage of it. Furthermore, completing a task ahead of schedule shouldn’t impart much more of a bonus, if any at all, than completing it exactly on time. The real bonus from completing a task early is essentially in optimizing the points earned per unit of time. However, exceeding the estimate could cause a considerable reduction in the awarded points, which causes an effective double loss due to the task taking longer than anticipated and earning the member fewer than the anticipated number of points.

Rewards. It may be natural to assume some level of monetary reward when discussing incentives, but it is suggested to find non-monetary means of rewarding team members for performance in the vast majority of cases to help keep them focused on the intrinsic value in what they are doing. In addition, yearly or end-of-project bonuses are often so far away that hyperbolic discounting comes into play and causes the reward to be valued far less than a manager might anticipate. To further complicate this type of reward structure, once a project starts to go off-track, the members may begin to think that the bonus is a lost cause, causing it to actually have the opposite effect.

As an alternative to using cash bonuses or similar monetary rewards based directly on a member’s performance, it is suggested that other means be used on a much more frequent basis. The goal is to keep the member focused on the work instead of on the money. (If monetary rewards are to be used, it is suggested that they be team-based in order to promote teamwork and cooperation instead of competition.) The project management application should maintain overall and weekly leaderboards as a display of status and effectiveness. The leaders of these lists gain recognition simply from being at the top of the list, but management could go further and publicly recognize their effectiveness and contribution periodically.

Some types of rewards can even be implemented directly into the project management tool. For example, the point leader at the end of a week could get first choice of tasks each day the following week, and task selection could continue in that order (though this could encourage a positive feedback loop). To go even further, a variable reinforcement schedule could be created by randomly giving out a reward when completing a task. These bonuses could also leverage pseudocertainty by having a very small change to be a very large reward. The project management tool could incorporate a point bonus with adjustable values and weighting, but it could also allow for manager created rewards which could extend the potential bonuses outside of the system.

4.3 Visibility

Status. A key point to the effectiveness of this proposed project management tool would be keeping the team members aware of the status of the system at any given time. They need some indication of how the project as a whole is doing, how well the current sprint or milestone is progressing, and how much time is remaining on their current task. They also need some degree of visibility on the performance of their teammates, both to gauge their relative performance and to see if any of their teammates are having problems or need assistance.

In order to accomplish this, the project management tool should have a main view which keeps the member informed of the project’s status but also serves to impart a sense of urgency. The weekly and overall leaderboard leaders should be displayed (likely the top three positions) along with the viewer’s weekly and overall score. In addition the following should be displayed to offer a sense of progress at all levels of the project: the number of days left in the project, a timeline of the progress remaining in the current sprint or milestone, and a countdown timer showing the amount of time remaining on the viewer’s currently selected task. In addition, a user should be able to easily find a list of all tasks currently being worked on as well as a list of tasks remaining in the sprint or milestone sorted by priority.

Control. The amount of control to give to a team member at any given time is a difficult design decision. A user may want to have complete control over the environment, but given the paradox of choice, that may not be the most effective approach. It is suggested that each screen of the project management tool should be kept very simple with only the options that are absolutely needed by the user. Some popular project management tools can be initially overwhelming to users due to the number of options presented to them, even though many of those options are only commonly needed by managers or supervisors. By keeping the end user view as minimalistic as possible, the adherence to the project management tool is expected to increase. Even for those members who dutifully engage in the project management process, the less time that it takes them to use the software effectively, the more time they will have to spend working on their tasks.

5 Conclusion

5.1 Implications

The end result of this research is a well-documented example of product prototype developed via theory-based design which can inform future attempts at gamifying other software within the business setting. As gamification becomes more prevalent, similar products will begin to emerge in any spot where performance needs to be optimized. By paving the way with research and testing, it could be possible to improve future attempts, increasing the pace of progress in this area.

5.2 Potential Issues

By its nature, gamification capitalizes on our innate reward centers and encourages us to perform certain actions while discouraging us from performing others. This can, at times, cross into territory that many find uncomfortable or even unethical, where designers may be, intentionally or not, toying with the compulsions of people. Gamification designers must keep this in mind and, when appropriate, ensure that stakeholders are aware of the issues. In addition, certain techniques are likely to be more effective on some people than others, so implementing a gamified process in a workplace may unintentionally select for employees who are most susceptible.

5.3 Future Work

Future work would involve further testing and development of the application including its introduction to a real-world environment where its results could be compared to industry-standard applications.