Having worked on only mini games, I know first hand creating a game can be a huge undertaking.
Creating solid technical specifications is a crucial part of the whole process. They provide an opportunity to make objectives and constraints explicit during the phases of design, construction and use. The specifications can become a pragmatic list of concerns that the game designer should address during the construction of the game. The objective is to delineate constraints and expectations for the project and also to raise and address specific questions that anticipate the conditions that will govern the design and use of the exercise. The responses, if carefully delineated, provide detailed specifications at the outset of construction against which the final product can be evaluated. Hence, it is important to consider each of the design steps and to anticipate what specifications will be required to ensure that the design process progresses smoothly.
I find that specifications should spell out the chain of command, project management procedures, budget and financial arrangements, deadlines, critical dates, personnel arrangements, procedure for reporting changes, deliverables, sign-off authority, and similar concerns. Ground rules should be established for the circulation of reports (who receives them, confidentiality concerns, deadlines for response, etc.). Clarity and completeness here will contribute to a smoothly run project.
Particular care should be given to the financial resources available for the development and use of the exercise. The budget for the project should be specified separately for each of the major phases: setting the scene, clarifying the problem/challenge, designing the solution, developing the solution, and the implementation activities.
From experience, final game costs often exceed initial estimates, particularly when precise goals are not stated and approved by the client before construction begins. Similarly, the cost of using a game may vary greatly. With costs so difficult to estimate, it is incumbent on the client and designer to agree on what resources will be made available during construction and for normal use of the game. A product may have reduced utility because the unit cost per run is beyond the capacity of the organization to sustain. If each use of the game has a new set of participants and/or a new game facilitator, the cost will be high. In those instances where the game will be used frequently by the same highly trained facilitator and where audience characteristics are consistent, the cost of each run will drop markedly.
Allocation of time is no less important than dollars both in the development and use of a game. The time required for the development of a game will be the product of the clarity with which the problem has been stated, the appropriateness of gaming for the problem, the clear specification of goals in the concept report, and the range of skill and experience of the game designers. Task Scheduling and great Project Management is required (timeline for the project design, construction, testing); this demands the identification of critical due dates.
These notions are intended to suggest a reasonably comprehensive set of questions that the client and designer should specify before a game is commissioned. Since each game is to fill a specific need, these thoughts can only be used to prompt a careful search of conditions appropriate in a particular context.
Finally, specifications should be signed off by the Key Sponsor before beginning construction of a game.
Campbell Craig 