THE BOSS: A COMPETITIVE GAME THAT SHOWS SOME ASPECTS

OF THE MANAGEMENT OF A SOFTWARE DEVELOPMENT COMPANY

Fabio Ferman
Programa de Engenharia de Sistemas e Computao/COPPE
Universidade Federal do Rio de Janeiro
fferman@cos.ufrj.br

Geraldo Xexo
Programa de Engenharia de Sistemas e Computao/COPPE
Departamento de Cincia da Computao/IM
Universidade Federal do Rio de Janeiro
xexeo@cos.ufrj.br

Luan Barbosa Garrido

Programa de Engenharia de Sistemas e Computao/COPPE
Universidade Federal do Rio de Janeiro
lbgarrido@cos.ufrj.br

Tiago Santos da Silva

Programa de Engenharia de Sistemas e Computao/COPPE
Universidade Federal do Rio de Janeiro
tiagoss@cos.ufrj.br

ABSTRACT
This article presents an educational board game, The Boss, which simulates aspects of the management of a software
development company in a competitive market scenario.
The Boss stimulates the players to handle with different important business functions. During a game session, teams compete
for clients, hire employees, control workspace availability, and deal with market variation. The game aims at its classroom use
at undergraduate courses of entrepreneurship of a computer science or computer engineering curricula; however, one can
easily exchange its theme to focus on any human and knowledge intensive enterprise, such as advertising or architecture
companies.
Although designed for education, The Boss has shown to be fun and entertaining in tests, and has a high replay value.

INTRODUCTION
The Boss is an educational, turn based, board game that provides a simulation scenario where small teams of players,
organized in software development companies, face the challenges of executing the business functions of these companies in
an ever-changing market, as if they are their directors.
 Hunicke et al. (2004), present the MDA framework to develop and study games, where the acronym stands for mechanics,
dynamics and aesthetics. While mechanics describes the game components, as rules and possible actions, dynamics refers to
how teams and players use these mechanics and receive feedback during a game session. Finally, aesthetics describe the
emotions players feel while playing. Most of the discussion of the game is built upon this framework.
The Boss main dynamics is to balance the size and productivity of the software development team, and the company in
general, accordingly to the current and future portfolio of projects and clients. The game mechanics, further described in this
article, involve hiring and training staff, buying space and compete for contracts in the market. Aesthetically, as the game
develops, players have shown different emotional answers, including but not limited to fantasy, and challenge (Hunicke et al,
2004).
Most aspects of the game simulation are guided by the literature of software development economics and business in
general, such as the expected productivity of employees (McConnell, 2011), and the use of BCG Matrix (Henderson, 1970), to
describe the profitability of projects.
This article is divided in the following sections: design goals, which describes goals and constraints that guided the project;
usage methodology, which explains how the game is supposed to be used in a classroom; the game model, which describes
some characteristics of the game; debriefing, which points to important discussions prone to appear in a debriefing section, and
conclusions. The rules of the game is in an appendix, so that it can be printed separately.

DESIGN GOALS
The Boss main goal is its educational use as part of an entrepreneurship course of a computer science or computer
engineering undergraduate school, to allow for instructor and students to better understand and discuss some aspects of the
management of a software development company.
Based on these goals, some constraints limited the development: it had to be played by three to four teams, composed of
one to four persons, using about one and a half hour for a complete game. It was also important that it could be interrupted at
any time, with the provision that all teams have played the same number of turns.
Software development is a human and knowledge intensive activity, and the main production process of a software
development company uses human effort to create documentation and code. Actually, most costs in software development can
be mapped to the human effort used in it, usually measured in persons-month or persons-hour (Boehm, 2000). Therefore,
managing the development team size and productivity is the central dynamic of the game.
To provide parameters for this dynamic, two other dynamics exists: the management of the portfolio of clients and
contracts, and the control of the space available for the company to produce and grow. These tree dynamics were further
expanded to many activities available for the teams, which cover most of the primary business functions of a software house:
to find and maintain clients and projects, to maintain and train your staff, to develop what is contracted, to provide a productive
working environment, financial control, and to work in different market conditions. Specific board game mechanics, such as
rolling dice and drawing cards provide simulation randomness.
However, companies are not isolated entities. They live in a market that can be favorable or not to its survival, and they
must face competition. As in the real world, the game shows that the state of the market has strong influence on the difficulty
to fulfill the business missions. In addition, a controlled amount of interaction among companies simulates market competition.
Another goal was that it should be possible for all companies to have a successful outcome on its business. Actually, The
Boss design aimed at the Euro Game style (Woods, 2012), where most, if not all players, usually play the game up to its end.
Usually, in a Euro Game, every player stay in game up to the end, there is few or none direct attack between players, and every
participant can make points without taking points for their adversary, as opposed of more traditional games, which usually
follow as close as possible a zero-sum model found in mathematical Game Theory (Osborne & Rubinstein, 1994).
Replay value, immersion and fun are other important design goals; it should feel like a game that you could play with
friends outside of the classroom. Actually, playing the game more than once, and, as a result, experimenting with different sets
of events, should improve the understanding of the challenges to manage a software development company.

USAGE METHODOLOGY
As usual with educational games, when using the game in a classroom situation, an instructor should follow three phases:
briefing, play and debriefing. However, a previous step can be necessary: the revision of some concepts used in the game, such
as the BCG matrix (Henderson, 1970) or differences in programmer productivity (McConnell, 2011). This need is left for the
instructor to judge.
The first step is the explanation of the game's rules and goals. The instructor should have disclosed the rules at least one
week in advance, for the students to be able to read and take note of possible doubts. Since the game has different possible
goals, it is important to clarify what will prevail in that game. Other house rules that the instructor wants to insert to improve
the experience into the classroom also have to be explained, such as maximum time to perform the turn or the application of
local laws as new rules. Teams can be stimulated to play out of the classroom, even before the first classroom use, to get a feel
of the best strategies of the game. This step should take around 15 minutes of classroom time.
The second phase is the gameplay itself. The teams play a game session as far as they can in the available time or up to a
selected game goal, as described in the rules. Students and instructor should take notes to remember to discuss in the next phase
the main events of the game. Most of the classroom time should be used playing the game.
Debriefing, the last step, is important to consolidate learning and is described later in this article. It should take at least 15
minutes.

THE GAME MODEL

In this section, we describe some characteristics of the game simulation model, based on software development and
business literature: how we planned the software development companies to behave, the productivity of the employees and the
clients and types of contracts.

Software development companies

The mechanics of the game cover most internal business functions of a software company, with focus on sales, product
and administration (Weske, 2007).
Each team manages a software development company, and must act to maintain the company profitable and growing. Each
company should find clients and projects, close contracts, keep its reputation with their clients; hire, train and fire employees
as necessary, develop software to fulfill its contracts, have enough office space to support its workforce and be financially
sound during the game. Available projects and employees are not deterministic and, in this board game, playing cards provide
the necessary randomness.
Teams can organize their actions as if each member of the team manages one department. The suggested departments, for
a four players team, are: sales, development, human resources and administration. To each possible department, the game
assigns at least one mechanic. Sales is responsible to find new contracts and manage current ones, the development department
mainly deals with the workforce, controlling programmer assignment to contracts, and asking for more programmers or space.
Human resources should deal with hiring and training. Finally, the administration department should provide means for the
enterprise to work, and its main mechanic is the control of the workspace. The financial responsibilities can be assigned to
administration or even to a fifth player, if necessary.

Employees (software developers)

Each company will have many employees, who are the source of all the software production. As a knowledge intensive
task, software development is highly sensitive to human productivity. Moreover, there is evidence of a 10X difference in
productivity between a low productive developer and a highly productive one. (McConnell, 2011)
Therefore, the game differentiates its employees by experience points (XP), which represents in one metric the knowledge,
aptitude and production of an employee. Experience points can assume three possible values that are purposely non linear
increasing (1 XP, 3 XP and 8 XP).
There are two possible ways to get better employees. The first one is to start hiring a highly productive employee, which
will cost more to the company, since other companies would probably dispute she. The other possibility is to hire a not so
productive employee, and, possibly, evolve him. This is usually a cheaper alternative to achieve a reasonable productivity;
nevertheless, this will take an undetermined time, which vary from employee to employee.
Hamid & Madnick (1991) provided data that show that new employees have to adapt to the new company, having smaller
productivity than old ones. In the game, new employees must train, and rules assign zero production to training employees, to
simulate it.

Clients and projects, sales and competition

For simplification, there are only 3 types of clients in the game: government, supermarkets and telecommunication
companies. Each software development company has a reputation with each of the client types, which actually behave as a
single client for all rules.
 Every project has a preparation time, during which the software development company cannot charge for it. Project size
influences the preparation time (Eisenhardt & Tabrizi, 1994).
The profitability of projects are classified in the Boston Consulting Matrix (Henderson, 1970), allowing for faster decision
by the teams if they are taking them or not. Usually a team will draw a project as a card from a drawing pile. This is how the
game models a business lead. The team can accept the project as it is, but sometimes this decision is not economically sound
and it will decline the project. At this point, the game introduces an auction to abstract the idea that all companies can bid at
the project.

Other administration tasks

Although most of the costs and management tasks of a software development company are directly related with the
workforce, there is at least some additional effort to maintain the company, such as energy, computers and software. The game
abstracts all these costs by adopting the common practice of distributing administration by the number of workstations available
to the workforce. Therefore, incurring in a high level of abstraction, but using a common market rule of thumb, all
administration costs are mapped in the maintenance costs of the office.

DEBRIEFING
Besides the entertainment it provides, the game main goal is to support the student to learn about challenges faced when
trying to manage a small software development company. For this purpose, a debriefing is necessary at the end of the game to
discuss strategies and events, based on the game session just played.
One interesting aspect to discuss is how the players dealt with the inexperienced employees. It is somehow expected that
players invest in training its workforce, since there is a super linear effect of training in productivity, i.e., it is cheaper to train
than to contract an experienced developer. However, training time is the price to pay, and at some point the right decision will
be to hire a more expensive developer. This effect is sometimes enhanced during a game session by lack of space and the
possible lack of projects. Hiring employees is important to have staff to work in the projects and capacitate them is a first step
faced. On the other hand, a balance between the number of employees working and the number of employees just training is
important, once the two groups of employees receive salary, and the company has to have money to pay them.
Sometimes, teams will face the choice of breaking a contract with a client to initiate a more profitable one with another
client. The doubt between a more profitable project or a better relationship with your current client can generate different
opinions. It is always important to call attention to this decision if it ever appears in a game, even if all team members (or game
players) agree with the initial decision.
Another important topic to discuss is the selection of projects. First, since each project is classified in the BCG Matrix
(Henderson, 1970), the instructor should challenge the decision to accept question marks and dogs. Good picks of stars and
cash cows, and a correct, or incorrect, management of the project portfolio should be called to attention. In addition, there is
the need to discuss preferences to hold less, but larger projects, versus many, but smaller ones.
As an additional task, after debriefing, it is recommended that the instructor require the students to provide a report about
the game and the game session.

CONCLUSION
The game allows different kinds of play. It can be longer or shorter through varying goals, it can be harder or easier
accordingly to start conditions or luck on dice. The challenges presented during the game cover most of the internal functions
of a software development company. Using a more general denomination than used in this paper, the game supports
management of resources, production management, and sales. This cover most of the productive chain of a software house.
After the realization of all phases of the methodology, the students will acquire notions of the multitude of challenges, at
different levels of difficulty, in business areas that would be much more difficult to understand just reading the theory.

The Boss theme is a software developing company, but different themes can also be applied with the same rules, like an
architecture or an advertising company. The main requirement for a new theme is that it must be based on a human and
knowledge intensive task.
.

REFERENCES
Boehm, B. (2000). Software cost estimation with Cocomo II. Upper Saddle River, NJ: Prentice Hall.
 Eisenhardt, K., & Tabrizi, B. (1994). Accelerating Adaptive Processes: Product Innovation in the Global Computer
Industry. Administrative Science Quarterly, 40(1), 84-110.
Hamid, T., & Madnick, S. (1991). Software project dynamics: An integrated approach. Englewood Cliffs, N.J.: Prentice
Hall.
Henderson, B. (1970). The Product Portfolio. The Boston Consultine Group. Retrieved October 12, 2014, from
https://www.bcgperspectives.com/content/classics/strategy_the_product_portfolio/
Hunicke, R., LeBlanc, M., & Zubek, R. (2004). MDA: A Formal Approach to Game Design and Game Research. In
Proceedings of the Challenges in Game AI Workshop, Nineteenth National Conference on Artificial Intelligence.
McConnell, S. (2011). What Does 10X Mean. In A. Oram & G. Wilson (Eds.), Making software: What really works, and
why we believe it. Sebastopol, CA: OReilly Media.
Osborne, M., & Rubinstein, A. (1994). A Couse in Game Theory. Cambridge MA: The MIT Press.
Weske, M. (2007). Business process management concepts, languages, architectures. Berlin: Springer.
Woods, S. (2012). Eurogames the design, culture and play of modern European board games. Jefferson, N.C.:
McFarland.

ACKNOLEDMENTS
The authors would like to thank the Coordenao de Aperfeioamento de Pessoal de Nvel Superior (CAPES); and to
Conselho Nacional de Desenvolvimento Cientfico e Tecnolgico (CNPq). The authors also would like to acknowledge to
CNPq/Edital Universal program (482948/2012-4).
We would also like to thank our game testers and their important comments, specially the students of the Special Topics
in Game Design course at Programa de Engenharia de Sistemas e Computao: Carla Carvalho da Veiga, Carlos Pivotto,
Eduardo Freitas Mangeli de Brito, Glauber Marcius Cardoso Menezes, Luis Fernando Vianna Sobral de Magalhaes Oliveira,
and Marcelo Granja. We should also thanks the suggestions of Claudio Dipolitto, Bruno Lanzarotti, Rodrigo and Paulo Vicente
dos Santos Alves

APPENDIXA

Game Scenario
Your team is composed of the directors of a new software development company. You start with a small office and no
employees. As the market is currently blooming, many other companies are also starting, just like yours, and will compete for
the same businesses.
Your main goal is to develop the value of your company. To fulfill this goal you should pursue many others sub goals:
find and maintain clients and projects; hire, maintain and train your staff; fulfill your contracts; provide a productive working
environment; financial control, and to profit in any market condition.

Game Setup
The game is for three or four teams. Each team should have one to four players. Teams can divide the tasks and decisions
among players as they decide, but all should be aware of the goal and sub goals of the game.
Cards should be divided into piles: actions, large projects, small projects and surprises. Office tiles should also be set apart
to be used later in the game. Tokens can be printed or plastic tokens can be used. A 6-sided dice is necessary and not provided
with the printed parts.
Each team starts with an office (office board type 1) and $200. The starting office board (Figure 1) also have a space to
record the reputation of the company as viewed by the clients. The companies must always keep the initial office. If a company
loses its starting office it goes bankrupt and leaves the game.
At the beginning of the game, each team rolls the dice, the team who gets the higher value starts. The game continues
clockwise.
 Figure 1 - One of the four initial boards

The Market
The market is the representation of the current state of the market for software development companies. It has four possible
levels: blooming, growing, stagnant and recessive. Team actions will be highly affected by it. Be prepared to suffer at recessive
market and take the opportunities of a blooming or growing one.
The level of the market is marked on the Market Board (Figure 2). The initial level is blooming, the best for you and your
competitors. Besides the status of the market, the Market Board also resumes some other values used in the game, as reference
for the players.
At the end of every round, the market state will vary, affecting the next turn. Any player rolls the dice, and depending on
the result, the market vary as in Table 1. The variations are always of one level, up or down.

Table 1 - Variation of the market

Market 1 level down same level 1 level up

Blooming 1,2,3,4 5,6 -
Growing 1,2 3,4 5,6
Stagnant 1 2,3,4 5,6
Recessive - 1,2 3,4,5,6

The clients and your reputation with them

There are only 3 possible clients in this game, the government, a telecommunication company and a supermarket. Each
client has many projects, of different prices, costs and size, which should fulfilled by the software development companies.
Each company has a reputation with each possible client, that represents the confidence that the client has on its ability to
fulfill contracts. This reputation varies from 0 to 3. If the reputation is 3, the company can get any number of contracts with a
client. If the reputation is not maximum, the company cannot get a new contract with the client. Also, if the reputation is below
3 the company can have at most the same number of contracts with that client than its reputation and it must immediately
discard as many contracts as necessary to comply (without losing more reputation). These contracts will be auctioned to the
other companies, as in the auction rules. The reputation with each client starts at 3.
 Figure 2 - Market board

Offices
Each company starts with a small office, which has four seats, or workstations, in one desk. In the beginning of the game,
the companies have no employees and the office is empty. During the game the companies will hire (and fire) employees to
occupy not only these four seats, but also extra workstations that should be bought and maintained.
Each employee hired occupies one workstation, i.e., it is not possible to hire a new employee if there is not an empty space
for him or her to seat.
There are also other rules for occupying the offices:
each employee works at most in one project
each project has to have all employees sitting in the same desk
a desk can have different projects
employees and projects can be relocated to any desk or workstation at any point of a team turn.
teams can increase the office by buying extensions, at a specific phase of their turn.
Four types of extensions are available (two small offices and two large offices). For each extension type, four provisions
of desks are available. Each extension has a price to construct and a price to maintain (paid every end of turn).
The only restriction to buy a new extension is that is mandatory that the new extension fits with the current office, i.e., the
doors must match and tiles must be aligned. The disposition of the types is on Figure 7.

Table 2 - Prices for the office expansions

Office expansion Small Big

Buy $ 80 $ 150
Maintain $ 10 $ 40

Figure 3 - The four extensions of type 2

Figure 4 - The four extensions of type 3

 Figure 5- The four extensions of type 4

Figure 6- The four extensions of type 5

Figure 7- Example of a valid disposition of the offices types

The employees
The employees, such as software developers, are the core of the software development companies, since they execute the
projects. Each employee has an experience, which can assume the values of 1XP, 3XP or 8XP. Employees with small
experiences have smaller costs but their productivity is lower than the employees with higher experience, which, by their turn,
are more expensive to maintain.
Employees must pass a period of time training when hired. During this period the employee does not generate income, but
receive salary. A training token next to an employee represents that she is in training, therefore not allocated to a project. The
number of tokens denotes the number of turns that an employee will still be training.

Table 3 - Employees Representation

Tokens Small Medium Big

White Employee without a Employee without a Employee without a
project with 1 XP project with 3 XP project with 8 XP
Colored Employee allocated to Employee allocated to Employee allocated to
a project with 1 XP a project with 3 XP a project with 8 XP

Employees have a cost to hire and a salary (paid every end of turn), shown in Table 4, working or not, that is paid every
end of turns for all the employees of the company (including the new ones that just have been employed).
 Table 4 - Price to hire an employee and his salary

Employee 1 XP 3 XP 8 XP
Price to hire $2 $ 20 $ 50
Salary $2 $5 $8

The period of time to train is determined by the roll of a dice, shown in Table 5. After the number of rounds to train is
defined, the corresponding number of tokens are put next the employee. Every start of turn, 1 token is taken away, and when
there are no more training tokens for an employee, he can immediately start to work.

Table 5 - Turns of training determined by the dice and employee experience

Period of training 1 XP 3 XP 8 XP
Dice: 1, 2, 3 2 turn 1 turns 0 turns
Dice: 4, 5, 6 3 turns 2 turn 1 turns

Every initial turn, the player can try, at a cost, to increase the experience points of his employees that are not training. For
each non training employee, allocated or not to a project, the player can try one time in the turn to increase the XP. Employees
with 1 XP can evolve to 3 XP and employees with 3 XP can evolve to 8 XP, employees with 8 XP cannot evolve anymore.
Just like the real life, it is not guaranteed that an employee will evolve, and this is represented by a chance in the dice (Table
7). There is also a price associated with the trial (Table 6).

Table 6 - Price paid to evolution chance

Price to evolve 1 XP to 3 XP 3 XP to 8 XP
Price $2 $5

Table 7 - Chance to evolve a employee determined by a dice and employee experience

Chance to evolve 1 XP to 3 XP 3 XP to 8 XP
Evolve Dice: 5,6 Dice: 6
Does not evolve Dice: 1,2,3,4 Dice: 1,2,3,4,5
The termination of the contract of an employee costs the salary of that turn. When the game is played in Brazil, we suggest
doubling this cost, to represent some Brazilian laws. This can be adapted for any country.

Action Cards
At phase 3, the team rolls the dice and draws 1, 2 or 3 cards from the action card pile, accordingly to table 8. Then it must
select 1 card to play and put the other ones in the end of the action card pile, in any order.
Action cards define the actions teams must do in their turn. Each card have four actions, representing what is available for
the player in each market level. If the market is blooming or growing, the action will be good and profitable, if the market is
bad, so the action will be probably bad.
On the top right corner of an action card, it could appear a yellow square (see second card in Figure 2). When this square
appears and this card is used, the player can draw one surprise card.

Table 8 - Price to hire an employee and his salary

Dice Value Number of cards

1 1
2,3,4 2
5,6 3
 Figure 8- 2 action cards

Surprise Cards
Surprise cards can change some actions in the game. These cards can be collected by teams and can be used anytime,
subject to their description. At the end of a team turn, a team can have a maximum of three cards. If the team has more cards,
it should play or discard as many cards as needed to finish the turn with just three cards. The used cards goes to a discard pile.

Figure 9Examples of 2 surprise cards

Project Cards
Closing contracts on projects and fulfilling these contracts are how the companies win money. With more projects, more
chances to win the game, but there are projects that are better than others.
Every time that a player draws a new card project, as the result of an action card, it can choose if it wants a large project
or a small one. The projects cards should be previously divided in two different piles, one for small, other for large projects.
Every project card displays: a project name, a client, a BCG Matrix classification of the project to guide the teams, an
initial investment cost (paid immediately by the company if it decides to stay with the project), a minimum initial cost (used as
a minimum bid in an auction, what is explained later), a minimum employee experience need required by the project to start,
the maximum number of turns that a project can wait without all the need employee experience allocated to the project, the
income of the project by turn, and the cost of breaking the contract.
The income of a project will be received by the companies only when the project has all the experience needed allocated.
Until that, there is no income for the company.

Auction
When a team decide to not accept one project, or a project is lost by any company, it goes to an auction. The auction has
three turns, and start with the team next to the participant that lost the project or just decided not to take it.
The initial bid is the minimum initial cost showed in the project card. Each team, in order, can increase the bid. After three
rounds, the biggest bid take the project. In the case when a team had decided to don't take the project, its company can also
participate in the auction. In the case when de team lost the project it can't participate because it doesn't have maximum
reputation with that client. The team that wins the auction should start playing that project, but only in its next turn. Even taking
a project on a previous auction, the team can take all actions in its turn, including accepting other projects.
 Figure 10 Examples of small projects cards

Figure 11 Examples of large Projects cards

Game Sequence
The game is played by rounds, in which the players have sequential turns. At each round, the teams should follow 4 phases,
as in Table 8:

Table 9 - Phases of a team turn and their actions

Phase Valid Actions

1 Update employee status, taking away 1 training token from each training employee
Update project status, taking away 1 time token from each project waiting to start
Recover 1 reputation point, if need, and select the client to receive it
2 Buy new office expansions
Hire new employees
Try to improve the experience of as many employees as the player wants
o Must pay for each attempt
o Each employee can make one attempt only per turn
3 Throw a dice
Draw action cards
Select one single action card to play
4 Receive money from active contracts
Pay office maintenance
Pay salaries
If necessary, solve cash problems
 Coffee machine
In the action cards has an option that you get a coffee machine. That machine you can put on any table of your office. Each
table can have at most one machine. Every project that is allocated in a desk that has a coffee machine has 50% more income.
The coffee machine can't be relocated, but can be stolen by other player.

Figure 12 - Coffee machine token

Goals
Before start the game, the participants have to choose a goal. Some possible goals are available, and the choice of one of
them determines the duration of the game. The possible goals are:

After n turns, or m minutes, win the team that have more money.
After n turns, or m minutes, win the team that have the most profitable (gains-expenses) company at that turn.
The game stops when a team first reach some amount of cash, we suggest $3.000 for a short game and $10.000
for a long one. As this team reaches this amount, every player will have the right to play the same number of turns
than it. The team with the higher amount of cash wins.
Wins the team that, at the end of a round, has expanded all the possibilities, has at least four star projects and $
5.000. This is a long game.

Losing projects, reputation, employees and expansions

At the end of a team turn, if its company does not have enough money to pay for its expenses, it must loose whatever it
cant afford. Thus, all the employees not paid should be fired, what can incur in more expenses. Then the office tiles for which
maintenance costs cannot be paid are returned to the pool. Remember that no employee can continue without a workstation.
Moreover, if a player turn ends and a project that are not started yet does not have any more turns to wait to begin and is
still without the necessary allocation experience, the project is lost and the reputation of the company with that client goes to
zero. Another way to lose reputation is breaking a working contract, which has the effect of losing points of reputation
accordingly to Table 6. Every time a project is lost, it goes to an auction.

Table 10 Losing reputation by breaking contract

Dice Points Lost

1 0
2,3,4 1
5 2
6 3

Varying the Difficult of the Game

The game difficult can be varied in the following way:

If a team rolls a 2 in phase 3, it gets one action card instead of 2.

Start with reputation 1 for each client. Reputation will rise by 1 each time a different new project starts producing,
for each client, as a result the company will only get a second (or third) contract with a client if the first (or second)
is already producing. This rule overcomes the need for 3 reputation points to get a new contract.
Start at growing or stagnant market levels (recessive is not recommended).

Using the game

The prototype of the game is available both in Portuguese and English language. The print and play version is available at
http://theboss.xexeo.net.