Game developers often abhor project management when making games. The battle cry of “It shouldn’t ship until it’s ready” sounds great to gamers, but projects managers and businessmen cringe. How do you know if the changes, the extra features, will really generate enough extra income to compensate for the extra cost? Veterans from game publishing are especially gun-shy because they’ve heard it dozens of times about games that went on to weak sales despite the extra effort – if those games even finished at all (Duke Nukem Forever, anyone?)
The sad tale of Tabula Rasa is a case in point. Despite a star-studded development team and deep-pocket backing from one of the strongest MMO publishers in the world at that time (NCsoft), six years of development yielded about one year of live operation before shut-down. Some reports suggest that translated into $106 mil in development for less than $20 mil in income (see “Tabula Rasa took Too Long”).
This is not a new problem. In the business world “projects” are business activities that have a clear start and end – like developing and running an MMO. There are well-established methods for organizing and running projects to keep them on schedule and on budget while achieving a certain level of quality and profitability. These methods are called “project management.”
The Project Lifecycle
According to the “bible” of project management (the PMBOK 4th Edition, published by PMI in 2008), projects have lifecycles. Here’s an overview of the major “Process Groups” in the project lifecycle:
Initiating: Project startup, charter, initial scope, initial team formation, etc.
Planning: Defining work breakdown structure, determining resources, defining activities, scheduling, risk planning, communication planning, etc.
Executing: Resources perform the planned work, including QA.
Closing: Product acceptance, recording results, performance analysis and postmortems, release of resources.
Monitoring & Controlling: Oversees the other activities; typically concentrates on scope, cost, schedule, quality and risk issues; reports status to management and customer; insures proper business administration occurs.
As the diagram illustrates, “monitoring and controlling” occurs most heavily during “planning” and “executing” activities. In my experienc, “monitoring and controlling” is typically the most difficult activity, especially during “executing.” A well-understood development process helps, but a skilled producer who wisely manages development tradeoffs is invaluable. Sadly, the industry still has some producers who can’t monitor progress quantitatively. Without such tools informed tradeoffs are nearly impossible.
Notice that multiple planning-execution cycles are possible within a project. Methodologies such as scrum actually formalize this into 2-4 week sprints, with each team planning at the start of a sprint and then executing during the sprint. In fact, a miniature of that process occurs each day, with planning issues surfacing (hopefully) during the 15-minute daily status meetings.
Game Development Lifecycle
Game developers frequently talk about “continuous development” and the need to iterate and refine for good gameplay. Merging this with the business needs of games resulted in a commonly accepted lifecycle for MMO game development. A version commonly used for MMOs is:
Prototype: Select, test and use engines, tools, software languages and build processes. Define design concept and art style; create initial design outline & first draft design doc; create initial concept art, gameplay prototypes and 3D art/animation prototypes.
Pre-Production: Build two to three fully playable zones (levels) including rewards and advancement. Build one zone using the same methods used in production – its the only way to accurately gauge production costs. Complete key concept art. Finish design doc. Complete production specifications (for programming, design, art, sound and QA).
Production: Build all other zones and gameplay so the game is code complete, including all data entry and scripting for AIs, quests, tables, art assets, sounds, etc. This typically involves additional resources (often via outsourcing) all working simultaneously on various tasks pre-production specifications. Create specifications and prototypes for billing, CS tools, and update systems.
Beta: Tweak the game for better gameplay, find and fix bugs, operational chokepoints, resulting final software stabilization (i.e., “no more fixes unless it’s a show-stopper crash bug”). Finish the billing, CS, update and other support systems. This beta does not end on the launch date, but when the day promotional “open beta” begins
Live: Game operates 24×7, typically starting with a promotional open beta. This is supported by at least two tiers of “live team.” The short-term tier handles day to day operational issues for the weekly patch. The long-term tier builds monthly updates and longer-term expansions.
Mapping Project Processes to Game Lifecycles
First, avoid the “noob” error and listen to the wise old Jedi (PMBOK 4th edition), “Process Groups are not project phases.” Do not equate the “Initiating” process group with prototyping, planning with pre-production, etc.
It is possible to map the project lifecycle against the game lifecycle, with Project Initiation at the start of Prototype and Project Closure at the end of the Live. This could work for small projects such as casual games. However, for traditional solo games (with or without multiplayer components) and almost all MMOs, the nature of the work in each phase is different. Furthermore, entering a new phase without finishing important bits of the previous phase becomes the road to disaster (see “An intervention”).
For example, scrum methodologies work extremely well for prototype and pre-production. Here scrum’s backlog priority system is ideal of tackling the mass of disparate possibilities, needs and goals. Scrum is wonderful for combining creativity and flexibility into tangible results.
The production phase is different. Now the development group must manufacture literally thousands, often tens of thousands of small items (art assets, quests, mob layouts, AI scripts, UI components, etc.). Each item has a multi-step process for construction, approval, QA and testing. Scrum struggles with vast numbers of small tasks. It really struggles if each is a multi-step activity. In large games the wise course is traditional tracking tools, from spreadsheets and databases to the oft-maligned MS Project. Similar issues can apply during beta if thousands of inputs and bugs must be prioritized and appropriately handled.
I advocate viewing each game phase as a separate project. In PMBOK-speak the game is a “multi-phase project.” This reinforces the need to finish one phase before starting the next, thus preventing the “intervention” situation described above by Eric Heimberg. Starting a new project for a new phase allows a clear, clean “change in how we work” for the development team. Finally, a clean exit for each phase improves the developer-publisher relationship.
The diagram below illustrates this mapping of multiple projects with their process groups to game phases.
The multiple project iterations during “Live” represents a series of game updates/expansions, each treated as a project.
The diagram also shows that initialization and planning for the next phase starts during the later part of the current phase. For example, during pre-production the producer might need to find and qualify an art outsource subcontractor to help handle the mass of art assets needed during production.
Irrespective of my preferences and the above examples, professional project management methods can coexist with almost any development process, be it scrum, agile, iterative, waterfall, with or without attention to CMMI “levels.” The important goal is how the general rubric of project management, applied intelligently, can prevent games and dev studios from experiencing another “crash and burn” event.
