Project and Software Management

This research extends the project and software management literature by demonstrating how the fundamentals can be applied to the unique case of video game development, where creativity is as much a contributor to project success as successful software development.

Kerzner (2006, p. 4) provides a useful definition of project management as “the planning, organizing, directing, and controlling of company resources for a relatively short-term objective that has been established to complete specific goals and objectives.”

In the video game case, game development projects are typically a few years in duration with budgets for hit “AAA” games in the tens of millions of dollars. Projects are the preferred method of production in creative industries because they allow for a limited, focused concentration of resources to a creative endeavor. (Ruth Eikhof and Warhurst, 2013) As Lorenzen and Frederiksen (2005) noted for the music industry, projects are a form of experimentation – if the project succeeds, further development continues, and if the project fails, further support is canceled.

Software project management is difficult, even outside the realm of game design.

As far back as Brooks (1975), engineers have known that estimating projects is one of the most difficult tasks to get right. Most software projects fail to complete on time, larger projects are more likely to slip, and complexity underestimation is a core problem.

(Kemerer and Patrick, 1993) Jenkins et al. (1984) discovered that only 9% of the projects they observed were finished with the scheduled manpower effort and the average additional effort required was 36%. Of the projects DeMarco and Lister (1987) surveyed, 15% were so late they were cancelled and 25% of large projects were cancelled.

Several of the core risks inherent to software development include: scheduling flaws, requirement inflation, exiting staff, specification break downs, and lowered productivity.

(DeMarco and Lister, 2003)

The research agrees that the size of projects can lead to problems. One of Boehm and Papaccio’s (1988) four strategies for improving software productivity was, “writing less code.” When Vosburgh et al. (1984) analyzed 44 programming projects, they noted that productivity falls as the number of lines of code involved increased, in addition to noting that both accurate and stable requirements and specifications could improve productivity. Charette (2005) provided examples of how software project failures have

33

cost considerable amounts of money. He listed many of the problems that cause projects to fail, noting that it is often multiple, intertwined factors at work. He also noted that larger projects carry more complexity, which increases the likelihood of errors. Curtis et al. (1988) described three issues that occur in large software development projects: thin spread of domain knowledge, fluctuating requirements, and communication breakdowns. They mentioned several problems, including the hidden cost of feature creep and the difficulty for stakeholders to see the cost or complexity of the systems they require. Reducing content and functional scope, and thus complexity, to the minimum required is critical for project success.

Under the Capability Maturity Model (Figure 3-1), as software management matures, it goes from the initial chaos to being repeatable, defined, managed, and finally optimized. (Humphrey, 1988) Especially for being manageable, having agreed-upon metrics as to the effectiveness of a development process is what allows this management to occur. To improve software development, an understanding of the current process is required, followed by a vision of the desired process, a list of improvements to be made, a plan to accomplish those improvements, and commitment to executing the plan. The need for more objectivity is summarized by Paulk et al.

(1993), “In an immature organization, there is no objective basis for judging product quality or for solving product or process problems. Therefore, product quality is difficult to predict.”

Figure 3-1. The Capability Maturity Model with the “Managed” level highlighted.

1 - Initial

(chaotic, unpredictable) 2 - Repeatable

(project-based processes) 3 - Defined

(organization processes) 4 - Managed

(indicators of success)

5 - Optimized

(tailoring for success)

34

(adapted from Humphrey, 1988; Paulk, Curtis, Chrissis & Weber, 1993)

Any project is going to require a balance of quality, time, and costs and software project managers must be aware of each and decide which has the most strategic value for their company. (Yourdon, 1995) Although there is a tendency to strive for large scope and high quality by default, not all software has to possess such ambitions. Yourdon stressed that accepting “good enough” as one possible outcome could lead to “a more rational way of negotiating with our customers and managers on what constitutes success.” He also stated that, “It is the customer who decides what the proper balance is,”

and that balance might change over time, which is why project managers may need to readjust priorities after the project is underway. Project managers must, therefore, find ways to understand what their customers value.

The role of a product manager, like a producer in video game development, is deciding what content to deliver in which timeframe to what market at what prices and cost. (Ebert, 2007) However, determining the value or cost of individual requirements in software can be very difficult and complicated. (van den Akker et al., 2008) Product releases often fail because they misinterpret customer needs. Ebert also stated that any incoming requirement should be reviewed for cost versus value added. Determining which efforts lead to value is important, for as much as 25% of software activities may not contribute to value and 50% of developer time may be wasted, with much of this waste due to overspecification and overdesign. (Coman and Ronen, 2010, Pass and Ronen, 2014, Ronen and Pass, 2008)

Boehm and Papaccio (1988) concluded, “understanding and controlling software costs is extremely important, not just from an economic standpoint, but also in terms of our future quality of life,” and “the better we are able to understand software costs and qualities, the better we are able to control them – and vice versa.” This philosophy is present in Boehm’s (1984) Software Engineering Economics.

Project and organizational management in the creative industries have largely gone neglected and have received limited attention from researchers. (Lampel et al., 2000) One problem is that management in creative organizations is not often considered central to business success or a core competency. (Jeffcutt and Pratt, 2002) Most of the

“managers” in a creative enterprise are drawn from successful content producers and have had no formal management training before taking on the role. (Deuze, 2016) In place of any formal training, they are often forced to learn while they go, and, as Armstrong and Page (2015) put it, those in senior roles are in a similar situation, resulting in a situation where they are the “blind leading the blind.” With few creative

35

employees having formal management or project management training, they are likely to focus on the creative aspects of their position. However, leaving creative projects uncontrolled is dangerous because controls are a key to project success. (Maier and Branzei, 2014) The need to be an effective project manager cannot be ignored. Lundin and Norbäck (2016, p. 379) insisted that media managers needed to become more

“project fluent” given the growing complexity of projects and teams.

Although one approach to balancing the need for management with the need for creativity is to split the two roles, Wilson (2009) made an argument that introducing artificial divisions between those who are creative and not is not a helpful concept, but rather what is important is to focus on the value of the results – a core concept in an economic approach to business decision making. Of course too much control can inhibit the autonomy needed to experiment and be creative, but “too much creativity” and a lack of discipline are as much a problem. (Townley et al., 2009) There is certainly a balance that must be made, but, as Lampel et al. (2000) argued, creative organizations that want to survive “must reconcile the demands of artistic production with those of the marketplace.” Bilton and Leary (2002) even went as far as to argue that creativity is not a quality of people but of systems and that proper management can help rather than hurt creative efforts. This research agrees with this viewpoint, and particularly the viewpoint of Peltoniemi (2009a), who argued that “the purpose of control mechanisms, such as budgeting and definition of responsibilities, is to keep people within acceptable alternatives.” Controls may not necessarily make a creative project successful, but they can help prevent failure – something that is growing riskier in the current video game industry. Proper management of creative projects prevents wasted resources, which allows those resources to be devoted to creative efforts.