Risk Management in Video Game Development Projects

M. Schmalz, A. Finn and H. Taylor in 47th Hawaii International Conference

on System Science, pages 4325-4334, 2014
Background
In article Risk Management in Video Game Development Projects article M. Schmalz, A. Finn
and H.Taylor reports their findings in their research about risks in video game projects. They
discuss about differences between ICT projects and entertainment software projects and risks
related to them. According to writers there is lot of information about ICT-projects as general,
but specific research in context of games are not so common. The article itself focuses on risks
and research that was made by the authors about it. The article also descripts in general about
game projects and project management role in these projects. (p. 4325-4334)
In game projects project manager has usually a title called producer and his or her role in these
projects are usually to coordinate activities of other team members. In game projects different
kind of roles are usually involved including producer, publisher, game designer, programmers
and artists. Producer communicates with external stakeholders and is often responsible to a
publisher although in the era of electronic market places it is also possible to publish games
without publisher. Producers role is not well defined and especially in the smaller projects the
job description may include several roles in addition to project management. Game industry is
known about chaotic projects and as pointed out in the article it has been historically common
that persons that had unsuitable skills for the producers role were chosen to the job from
programming or artistic background. (p. 4326)
As about the risks of video game projects they include many of the same risks that concerns ICTprojects, but new risks are also introduced because of creative nature of games. In the article
entertainment software projects are compared to research projects where originality and
innovation are important aspects of them. (p. 4326)
The goal of the research about risks in the video game projects was exploratory and descriptive.
Researchers chose in-depth interviews as methods to full fill these goals. Interviews included
eight video game producers with different backgrounds and project sizes. Producers were asked
about challenges of recent projects. To analyze this data, researchers used modified Taylors
framework to code different risk source definitions. (p. 4327)
Original Taylors definition included four risk themes called as project management,
relationships, solution ambiguity and environment. Risk sources included vendor, client and third
party. In this new research risk sources were named as software studio, user, partner and
contractor to suit better in the environment of games. Different risk factors from the Taylors
framework were used without modifications and in the framework there are 43 risk factors in
total including for example staffing, business changes and understanding of requirements.
However in context of games researchers ended up to add three new risk factors that were
audience match, fun factor and extent of originality. In the target audience risk factor the game
may not fit for aimed audience and the game may be too hard for them for example. As games

are entertainment software they need to be fun and therefore there are risks involving for
reaching that goal. And because games are creative work they may bring something original to
the table, but creating something entirely new may cause increased risks in that risk factor. (p.
4327-4328)

Results
Research team identified all different risk factors based on the interviews and collected data was
compared to Taylors study and risk factors matched fairly close to them. Nine risk factors were
identified at least in half of the projects. These risk factors were development strategy, staffing,
schedule and budget management, inadequate specification, fun factor, change management,
expectations, trust and top management support. Most of the risk factors had internal source for
them from the software studio itself while other sources included users and partners. (p. 4329)
Researchers found two interesting findings about these top risks that are specific to entertainment
software projects in comparison to general ICT -projects. First finding was that development
strategy was the highest risk occurred while in Taylors findings it did not ranked to the top risks
at all. Second important finding was the new risk called fun factor achieved place five from list
of the top risks. (p. 43329-43330)
These top risks were defined as key risk factors in the video game projects. As said development
strategy inside the software studio was ranked to the most common risk factor in these projects.
In this risk specification for the game or game design may be well done, but technical decisions
caused problems during the project. These factors involved for example wrong choices in
development platforms or prioritizing the work in the project, issues in testing or failures in
prototyping the product before entering to production. (p. 43330)
Second risk factor was staffing. Staffing problems included all problems with project personnel
for example there were not enough staff or they possessed wrong skills. Game projects also had
problems with schedule and budget. This means that projects may not be able to deliver the
product in time and they may exceed the given budget, but projects were very different in terms
of schedules and size of the budged. There were clear distinction for projects with publisher as in
these projects producers had greater need to control budgets and schedules. Inadequate
specification was also among the top risks involved. In game projects game design document is
used to define specifications, but size of the documentation varied from non-existing documents
to large and formal game design documents. Producers preferred lighter specifications for
flexibility, but more precise documents are required dealing with external stakeholders. (p.
43330-43331)
The most unique key risk factor for video game projects was user based fun factor. This was
constant subject to worry for producers. Creating fun is not just having good usability that is
common to ICT-projects. Producers have to balance between technology and art to create a
product that appeals to customers (p. 43331). As researchers describes in the article game play
must be smooth and intuitive and draw the player into the world constructed by the game (p.
4331).

Risk management strategies for game projects were mostly informal that was surprise to
researchers. Producers used indirect practices instead involving prototyping and agile methods
that lowered risks in production. With prototypes game studio can test the game idea before
entering into production and stop development before investments become too big. Distributing
games through Interned also allowed making small-budget games and developing them further if
the game becomes popular. (p. 4332-4333)

Conclusions
Video game projects share much in common with traditional ICT-projects, but they include
certain context specific risk factor that project managers or producers should take into account.
Because of entertainment and artistic nature of games it has a requirement of being fun and there
is a risk that project may not achieve that goal. Entertainment software projects have also had
problems with development strategies. Risk management or having proper specifications have
also seen as artistic restriction among producers. However prototyping and agile methods have
been natural and good solutions for avoiding risks in video game projects. (p. 4325-4334)
Sami Pulli