PROJECT MANAGEMENT METHODS 51
teams keep focus, which gets harder as teams get bigger. It also provides a common
language and structure for people to organize around. However, there are require-
ments in the game development process that tend to get lost in the rush to “be
agile.”
First, you need to make sure that a thorough initial pass is made toward scoping
the project and that the scope is re-evaluated and changes are communicated on a
regular basis. It’s very easy to allow items to accumulate on the backlog since ‘only
the important things will get done.’ This bit me badly on my second scrum project
when every single item in the original backlog was replaced by another ‘higher pri-
ority’ request. I didn’t clearly communicate that this impacted the deadline of the
original requests and consequently they would not be completed by the original
deadline. As each item got superseded, I tried to convey its individual impact, but
since deprioritized items tend to just sink in the product backlog instead of being
axed, upper management assumed they would all still get done.
Likewise, many teams seem to fall into the trap that scrum replaces up-front
and ongoing long-term planning. Scrum’s continual focus on rapid iterations can be
a problem for the team, because they may start working toward builds instead of
the end product, or they may start gearing their work towards the publisher’s de-
sires instead of the game, because the publisher needs to have a frame of reference
for understanding the progress being made in each sprint. Lacking that frame of
reference, it is difficult for people who aren’t part of the development team to un-
derstand the amount of work and effort that went into a milestone. For example, I
once used scrum on a portion of a project, but didn’t tell upper-management about
it. The team loved it, and they were very productive during the sprints. However,
when we showed the completed milestone to management, it was rejected because
management didn’t have a point of reference to measure the milestone against. As
far as management was concerned, the team should have had more to show for the
amount of work they said they did.
Another area where scrum and game development don’t work together ideally
is in team organization. One idea behind scrum is that collaborative efforts give
better results, so you create small teams of people to work together on a single
feature. But there are some highly specialized, repetitive tasks that occur during
development where a collaborative effort is not really needed. For example, what
happens when you have an animator who needs to create 300 animations in the
next 3 months? What is the value of adding more people to that group? There are
many things you can use in scrum that are great, but the interdisciplinary nature of
a group is less important when you are in full production and people are working on
actual game assets. So this is an area I think benefits from modifying the principles
of scrum a bit, so that it works better in a game development environment.
52 THE GAME PRODUCTION HANDBOOK, 2/E
3.5 PROJECT MANAGEMENT INSTITUTE (PMI)
Project Management Institute (PMI) is an international organization that fosters
the discipline of project management across all types of industries. It keeps track
of current trends and recommended methods for project management, acts as
a central repository for resources, and provides networking opportunities with
other project managers. They offer three types of certifications—the most com-
mon one being the PMP (“Project Management Professional”).
PMI has designated a specific set of requirements you need to fulfill in order
to obtain a PMP. The requirements are fairly rigorous, and include having up
to 7,500 hours of project management experience (only 4,500 hours are needed
if you have a Bachelor’s degree), 35 hours of specific project management
education, and a passing grade on the PMP Credential Examination. Once you
obtain your PMP you will need to maintain your active status by earning at least
60 professional development units (PDUs), during a three-year period, and by
submitting a renewal fee and application to PMI.
PMI also maintains the Project Management Body of Knowledge (PMBOK),
which is the main reference of the PMI standards for project management pro-
cess. It also lists relevant books, journals, and conferences that are related to the
discipline of project management. It is updated every three to four years. The
PMBOK is a general guide to the processes and methods endorsed by PMI, and
does not necessarily contain details of all the project management knowledge
that is available to PMPs.
Their website, www.pmi.org, has information on project management best
practices and provides information on how to become a certified PMP. If you
want to learn more about the basics of project management, this is a good gen-
eral resource with which to begin.
PMP CERTIFICATION
Karin Groepper Boosman
PMP, Aspyr Media, Inc.
The value of having a PMP is having standardized methods by which we ac-
count for our games in ways that are understandable to our investors, developers,
and all our stakeholders. It is my hope that using technical project management
methods in the game industry will bring more games to completion on time, on
budget, and with quality and improve working conditions for people.
PROJECT MANAGEMENT METHODS 53
Among the things I admire about PMI and the PMBoK is their own agility—the
idea that the discipline of project management evolves and grows as more industries
see the benefit of organizing work in this way. Were the games industry to widely
adopt project management, and we were to contribute our own needs and modifica-
tions, we would be able to contribute to the PMBoK ourselves.
Even though games differ from project to project, there are common pro-
cesses that occur on all projects. Keep in mind that the kinds of projects that
use PMI endorsed methods range from banking systems, to bridge-building, to
software development. It cuts across all industries and defines common ground in
a wide variety of projects. PMI understands that no two projects are exactly alike
and states so in the PMBoK. The expectation is that a certified and seasoned PMP
can consult the PMBoK and figure out which methods from can be best applied
to a project. Quality control, risk management, and so on all have common areas
in these projects. It depends on the level to which you drill down and use it. The
game industry tends to re-invent the wheel for each project, and can benefit from
seeing that other companies have gone down these paths already and solved these
issues.
At my company, we use the PMBoK approach for all projects, even iterative
ones to which we are applying agile/scrum methodology for the product devel-
opment. On the surface, it appears that the approach PMBoK suggests is strictly
waterfall and therefore 180 degrees away from agile methodologies—but I would
disagree with this. The PMBoK clearly states that each project, regardless of in-
dustry or project goals, has varying needs and that the depth or manner in which
each Process Group and Knowledge Area is used is to be determined by the project
team. Regardless of the team’s development technique or methodology, the vari-
ables described by the PMBoK apply. For example, the PMBoK recommends hav-
ing a Quality Management Plan. Whether a given game is developed iteratively or
not, a Quality plan is a necessary component for a successful game. For a very small
game developed by just a handful of developers, the Quality plan could be as simple
as “Everyone on the team plays the game for an hour daily then reports on the team
wiki/forum/whiteboard their findings, and then is responsible for making sure the
bugs they each find are managed.” The simplicity of this plan does not invalidate its
utility and is a valid Project Management Process. It would be just as valid as a 100-
page document outlining the test plan, with a 20-person test team augmenting the
efforts of a team working on a 2-year 6-week sprint cycle.
The following interview discusses the PMI process groups and knowledge
areas that exist in any project.
54 THE GAME PRODUCTION HANDBOOK, 2/E
PMI PROCESS GROUPS AND KNOWLEDGE AREAS
Karin Groepper Boosman
PMP, Aspyr Media, Inc.
The 5 process Groups are Initiating, Planning, Executing, Controlling/
Monitoring, and Closing. Each project, regardless of length or scope, goes through
each of these Process Groups, usually in cycles during the duration of the project.
The following are definitions of each of the Process Groups:
Initiating: This phase is what occurs at the very start of the project. In this
phase, the work to be performed is discovered and spelled out, and project leader-
ship is assigned and given specific authority for the project and its deliverables. In
the gaming world, this is often called the “greenlight” phase of the project. During
this phase, milestone and end of project acceptance criteria is defined as well.
Planning: This phase is often underestimated and glossed over. During plan-
ning, the objectives for the project (high-level and interim) are defined, and the
plans for the various knowledge areas are developed. For agile/iterative develop-
ment, the project may go back through the planning phase in each sprint as the work
completed is evaluated and the priority for the upcoming work is re-ordered.
Executing: Simply put, this phase integrates all of the resources required to
implement the project management plan for the project.
Monitoring and Controlling: The consistent and frequent progress measure-
ment of project/milestone/sprint objectives. Variances from the beginning or cur-
rent baselines are calculated and corrective measures are taken to keep/bring the
project into control.
Closing: This is all activities that relate to the closing of a project, including
licensor/manufacturer submissions, archiving tasks, and post-mortem processes.
Project Management Knowledge Areas are groups of processes, most of which
apply to most projects and are used to varying degrees, depending on project complex-
ity. The PM Knowledge Areas are Project Integration Management, Project Scope
Management, Project Time Management, Project Cost Management, Project Quality
Management, Project Human Resources Management, Project Communications
Management, Project Quality Management, Project Human Resources Management,
Project Communications Management, Project Risk Management, and Project
Procurement Management. How any team navigates these knowledge areas varies,
but with most game development and publishing these days, each of these Knowledge
Areas are in use, and if they are not in use, they should be.
At my company, we have a variety of projects at any given time whose complexity
varies greatly. Some things we do are so similar to what we have done in the past that
and are already so streamlined that we do not need to do a large, in-depth master
PROJECT MANAGEMENT METHODS 55
project management plan with deep documentation for every Knowledge Area, and
other projects are enormously complex and involve dependencies on external part-
ners over whom we may have limited control. Though the project types vary and the
degree to which we use the PMBoK processes and tools adjusts with the complexity
and development style of the project, we do have a PM approach to each project.
We use all of the following PMBoK knowledge areas:
1. Scope Management (planning, definition, verification, control). For
our projects that are not using an agile methodology (non-iterative),
this is defined at the beginning of the project. Production and Project
Office gather as much data about the scope from all of the participating
departments (programming, art, design, QA, marketing, and so forth).
Production then integrates all of this information and informs the team at
large about the scope at a kick-off meeting attending by the project team.
For our agile-developed (iterative) projects, the scope is loosely defined
at the beginning of the project by the project sponsor(s). The product
backlog is then ordered by production and is defined/managed for the
rest of the project sprint by sprint.
2. Time Management (activity definition, sequencing, resource estimating,
duration estimating <velocity>, schedule development/control). For non-
iterative projects, this is defined at the start, in the single planning phase.
Production coordinates when major deliverables are required and com-
municates dependencies throughout the team, then tracks that schedule
to measure the value of the worked performed to date on a given project.
For our iterative projects, we do a high-level version at the start, where
the estimate of work is divided among the planned sprints and initial dates
are set. Thereafter, the time management component is updated continu-
ously as the work progresses from one agile sprint to the next.
3. Cost Management (estimating, budgeting, control). There is very little
we change from the PMBoK approach. If you’re not managing your proj-
ect costs on an ongoing basis, measuring the earned value of the project
in very regular intervals, then you don’t know where you are really. At the
start of any project, regardless of development methodology, we have an
approximate idea of what we are going to spend and in what intervals.
We use this as a baseline as the project goes on and measure in 1-month
intervals how much work has been accomplished compared to how much
work was scheduled to be accomplished and assign a dollar value to this.
In this way, we track cost creep and are able to account for it. We also
find out earlier in the project if the project is in trouble and has an unre-
alistic budget before it becomes a crisis.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.