56 THE GAME PRODUCTION HANDBOOK, 2/E
4. Quality Management (planning, assurance, control). That quality/
testing is executed on an ongoing basis throughout a project rather than
waiting until the end of a project is a strong PMBoK value. I find that
this is one way that iterative software development shines in regards to
standard PM methodologies. The constant testing cycles aligned with
the sprints give us real-time information on what’s what, and since the
iterative process is designed to incorporate the quality/testing feedback
as part of the living cycle, I think that this is one area in which PMI and
game development have an easy analog.
5. Human Resources Management (resource planning, acquire, de-
velop, manage project team). With both the iterative and non-iterative
projects we do, there is HR planning we do at the start of the project.
We are generally able to forecast staff requirements for the duration of
the project in the planning phases. Proper HR planning prevents/allevi-
ates the need for crunch time as a project concludes, which employees
appreciate tremendously. I find that by including dedicated attention to
the HR Management as a project management process, we have more
accurate budgets and better employee satisfaction.
6. Project Communications Management (communications planning,
info distribution, performance reporting, stakeholder management).
Again, the structure of iterative/scrum is really well suited to communi-
cations management. The teams communicate daily, there are product
back log and sprint review meetings at specific intervals, and who knows
what when is pretty clearly spelled out. For the non-iterative projects, the
producer and our project office work together at the start of the project
to work out the communications plan for the project and this is shared
team-wide at kick-off. The projects do differ enough that there is not one
template that we use.
7. Risk Management (planning, identification, analysis, response plan-
ning, monitoring, control). We are just now implementing a robust risk
management system and we’re already seeing the benefits. Regardless
of the nature of your project or your methodology, RM can and should
be implemented. Around here it has improved transparency and morale,
and the security of preparedness for potential risks has kept our budgets
in control. The best thing we’ve done is naming the risks up front and
assigning cost thresholds for decision-making should the risks occur. The
team usually appreciates the opportunity to brainstorm and then rank the
risks to the project. It is interesting to see how the different perspectives
on the team provide a diverse risk brainstorming. The team brainstorms
the risks, then rates them in terms of likelihood (inevitable, probable,