310 THE GAME PRODUCTION HANDBOOK, 2/E
The follow-up is critical, especially if solutions were discussed for potential
problems. If the solutions are not followed-up on and implemented at the team
level, a small problem will quickly grow into a large one.
Conducting a Project Review
Conducting a project review is not difficult. Several project management
books discuss the review process more in-depth. Please consult Appendix C,
“Resources.” First, define the review’s goals and objectives. If these are not de-
fined beforehand, the proper information may not be presented, and the review
will not be beneficial to the team or anyone else involved. It is important that the
correct people attend the review—studio management, project leads, and per-
haps someone from the publisher will need to attend. These are the people with
the most responsibility on the project and the ones who can authorize changes.
Second, establish a format. The review format is important in establish-
ing the goals of the review. The format must include the following types of
information:
Comparisons: Compare the project plan with the current status of the proj-
ect. This includes such information as the original milestone dates and when
they were actually achieved, what content was scheduled to be created ver-
sus what content has actually been created, and how much was originally in
the budget and how much has actually been spent.
Accomplishments: List any accomplishments since the last review. This
shows the concrete progress of the game’s development. If there are no ac-
complishments to list, the project is in trouble. Accomplishments include
things like recording all of the voiceover, sending all the assets to be trans-
lated, and completing all the character models for the game.
Risks: Identify any potential risks and propose solutions. The risks can be
prioritized as high, medium, or low to give a better assessment of the impact
they might have on the project.
Roadblocks: Roadblocks are anything that prevents the team from mak-
ing progress. For example, if the team is still waiting for console develop-
ment kits, that directly prevents them from running a version of the game on
the correct platform. Roadblocks are something that can be identified and
quickly removed so that progress does not come to a standstill.
Supporting Documentation: This includes the updated project schedule,
deliverable lists, status reports for each area of the game, and anything else
that concretely illustrates the progress made on the game.
Resources: Identify any additional resources needed. For example, you
might need another engineer for two months to help code a new feature that
PRODUCTION TECHNIQUES 311
was approved. An additional artist might be needed for two weeks to create
objects for the levels.
Including this information in the format will keep the reviewed focused.
Third, plan sufficient time for the review. The initial review might take
several hours, depending on the size of the project. After the initial review is
completed, the follow-up reviews might not take as long. But don’t cut the
time short. If you find that you are running short on time and the review is not
completed, schedule some time in the next few days to complete it.
Fourth, take notes at the review and publish them everywhere—email them
to the team, post them on the website, and discuss them during the team meet-
ings. Any decisions made or solutions proposed should be noted in the meeting
minutes. Also, be sure to follow up on action items. Please refer to the section
later in this chapter that discusses how to run meetings for more information on
meeting minutes and action items.
Benefits
Project reviews are beneficial because they keep everyone focused on the big
picture of what needs to be completed during each phase of the project. So
instead of getting mired down in the little details of how many weapons are going
to be in the game, the focus is on when all the weapons have to be finished and
who is working on them.
Reviews also keep people honest about the reality of the project. If the
project is thoroughly examined on a monthly basis, the problem areas will be
exposed and discussed. If you are participating in a monthly project review and
are tempted to gloss over the problems, you are not doing the game or your team
any favors. Problems can’t be fixed unless they are known about and discussed.
A monthly project review keeps the producer in regular contact with the
project leads and project’s status. Many producers will claim they know what is
going on with their projects, but when asked to provide a comprehensive status
report, they find they don’t know everything and must consult with their leads
on the exact status of many items. This does not mean the producer is doing a
bad job, it just demonstrates how many people are necessary to keep track of all
the tasks on the project.
Although regular project reviews are not a norm in game development, they
are becoming more popular as development teams get larger and more risk is
attached to a project. If you are working at a studio that does not currently do
these reviews on a studio management and publisher level, you can start by
working with your team leads on a monthly review. Eventually, you can ease
management into the process as well, especially when they see these reviews are
providing them with pertinent project information.
312 THE GAME PRODUCTION HANDBOOK, 2/E
18.4 CRITICAL STAGE ANALYSIS
Critical Stage Analysis (CSA) is a technique developed by Wolfgang Hamann
to provide ongoing improvements in the production process by examining the
game’s progress at critical stages in the development cycle. This process is de-
scribed in detail in his article, “Goodbye Post Mortems, Hello Critical Stage
Analysis,” which is cited in Appendix C, “Resources.”
CSA is a simple process that happens on a regular basis (usually monthly)
and involves the entire team answering these three questions:
■
What are five things that went right during this past development period?
■
What are five things that went wrong during this past development period?
■
What are five things that can be improved for future development periods?
Each team member writes up his own answers and ranks them according
to importance. It does not matter if the producer or leads agree with the items
listed or the rankings, because it really is a measure of what each individual thinks
about the project at this point in time. Additionally, these questions should be
answered within two to three days of completing a critical milestone. What’s nice
about this technique is that provides a snapshot of what each person thinks about
the current standing of the project.
These answers are then turned in to the producer who compiles the infor-
mation in a master document. The document is emailed to leads and a meeting is
scheduled within two days to discuss the findings. Solutions are discussed for the
most important findings, and the leads are tasked with implementing solutions
for these issues within the next development period.
When this plan is finalized, a team meeting is scheduled, and the findings
and solutions are presented to the entire team. During the meeting, all the feed-
back and proposed solutions are discussed and any questions answered. At sub-
sequent team meetings, status updates are given on where things stand with
solving the issues. Hopefully, the top five issues are solved, and the development
process has improved as a result. The main goal is to emphasize the positive and
to show the team that their feedback is taken seriously.
18.5 WEEKLY STATUS REPORTS
Weekly status reports are also a good way to track development process, but they
should not be used in lieu of the comprehensive project review. If you are work-
ing on a small project that takes less than two months to complete, you might
be able to accurately gauge the development progress with a weekly report, but
projects that run longer than a couple months need project reviews as well.
PRODUCTION TECHNIQUES 313
Weekly status reports communicate the game’s current status to the
development team and management. Oftentimes, a producer might forget that
the members of the development team are hard at work on their assigned tasks
and don’t have a chance to keep up with everything being done during production.
For example, the engineer coding the animation system might not realize when
the cinematics are finished or when the first few missions are ready for play test-
ing. The weekly status report is a chance to tell the team where the project is.
For the Development Team
Weekly reports for the development team are a positive way to show the prog-
ress they are making as a team. It’s also a good forum to inform the team of
critical deadlines, discuss the latest marketing updates, and introduce new team
members. The following types of information can be included:
Departmental updates: This is a good way to keep everyone informed on
just exactly what the artists, designers, and engineers are doing on the proj-
ect. If a new game type has been added, include that in the design update.
If new characters are working in the build, make sure to add that to the art
update. Include anything that gets the team excited about the work they and
their teammates are doing.
Marketing and PR information: Include information on tradeshows where
the game will be showcased, the latest articles and interviews about the game,
upcoming press tours, the current status of the packaging, and anything else
that marketing is doing for the game. This section will show the team how
hard other parts of the company are working to promote the game.
New employees: As teams get larger, new employees are bound to start
mid-production. Introduce these people and give some brief background
information to make it easier for other team members to get to know them.
Upcoming deadlines: It is always a good idea to note upcoming deadlines
and what main items need to be accomplished in order to meet them. If the
team is consistently reminded of any upcoming deadlines, they will plan to
be have their work ready on time.
These reports can be emailed, posted on the team website, presented ver-
bally during the regular team meeting, or all three. It is good to present the
information in as many forms as possible, to ensure that everyone gets it.
For Management
Management usually requires some type of weekly summary of the projects
status. They are interested in the progress the game is making, any risks that
314 THE GAME PRODUCTION HANDBOOK, 2/E
will impede the progress, and any areas that are not progressing smoothly. The
weekly report also serves as a good reminder to the producer of what is going on
with the project. The types of information to include in a weekly status report to
management should include the following:
Departmental updates: Include information on the progress art, design,
and engineering have made in the past week.
Risks: Call out which areas are at risk and don’t be shy about it. If manage-
ment is not aware that something is even slightly at risk, they cannot propose
any solutions. Also, if the risk grows into something bigger, management will
want to know why they weren’t informed of the problem before it got to be
serious.
Key deadlines and approvals: Note upcoming milestones and whether
there is any risk the milestone will be late. If you are waiting on approvals for
any content or features, include this as a line item in the report as well.
Resources: If you need additional resources on the project—hardware,
software, or personnel—noting this on the report is a good way to bring this
to management’s attention.
18.6 RUNNING MEETINGS
If you are a lead or a producer, you will spend a great deal of time in meetings
when working on a game—team meetings, management meetings, lead meet-
ings, QA meetings, and so on. You may feel that you spend a majority of your
time in meetings, so it is important to keep these meetings as productive and
effective as possible. There are some simple ways to do to make meetings more
useful. They include the following:
■
Define the purpose of the meeting. Before scheduling a meeting, spe-
cifically define the goals and desired outcome of the meeting. For ex-
ample, the goal could be to provide feedback on the game scripting for
one of the missions. If you can’t decide on what these goals are, cancel the
meeting.
■
Publish an agenda. Once you’ve determined what the meeting is about,
publish an agenda to all the attendees. This will help them better prepare for
the meeting and keep them on track during the meeting discussion. If the
attendees have to review anything before the meeting, indicate that in the
agenda. During the meeting, stick to the agenda and table any topics that are
not listed in the agenda.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.