Features

Risk Management With
Development Schedules

Risk is a silent partner in any undertaking that pushes the technical envelope, goes in a direction never tread before, or draws heavily upon the imagination and subjective instincts of what's fun - in other words, game development. Unless your game project is a no-brainer and you have a seasoned team with ample resources, experience and technology to accomplish it, you have to account for some risk in your schedule.

The traditional way to deal with risk is to ignore it and make up for it with overtime, or to pad your task durations and milestone dates -- if you can get away with it. However, more and more publishers (like Electronic Arts, Microsoft and Sony) expect a certain amount of technical due diligence during the planning phase of their projects. They want to see a risk assessment in the pre-production phase, and they want to see those risks accounted for in the schedule. In other words, publishers want to see a schedule that makes them feel comfortable that you have everything under control, despite the risks. Certainly that assessment makes your job as a producer, development director, or other form of taskmaster less stressful, too. Within this article I describe how to assess, manage and account for risk in your schedule.

Risk Assessment

I know what some of you are thinking. Why should you point out your project's weaknesses to your publisher? So many of you work so hard to convince the publisher that you have the right stuff to do a project, that it seems foreign to show your Achilles Heal, so to speak.

First, not all the risks you identify will end up in your schedule but they may influence the order in which you do things, who does the work, or what solutions you choose for your implementation. Second, you need to be honest with yourself and your publisher, because it builds a positive publisher-developer relationship. In addition, most publishers are pretty savvy and will spot these risks even if you don't. Most of the risks here are to be expected with any company, be it a start-up or an established company. Not accounting for risk doesn't mean the project will fail -- it just means the project probably won't proceed as smoothly or likely ship on time.

Risk assessment is a process that produces a list of potential problems and the impact on the schedule should they manifest (see Figure 1). The impact is measured in person-days of work for particular (or all) resources. There should be some risks identified in the technical specification, or even in the game proposal. Do not assume that all risks are technical, however: Design and art have risks as well, especially if the project is at all experimental with its art direction or gameplay. Use your discretion to identify these risks and throw them in a master risk assessment document, like a spreadsheet.

Figure 1. Sample Risk Assessment

Here are some things to think about when putting together a risk assessment:

• It's better to have identified too many risks than to miss something. Not all of the risks in your assessment will end up being reflected in your schedule, however - think of this list as a discussion document.

• Do not confuse risks with tasks. If you suspect some work will need to be completed (for instance, the renderer might need updating), that should be a task on the engineering schedule, not a risk. An example of a risk would be, "Off-the-shelf renderer has toon-shading, but it's untried and might require custom code."

• External dependencies usually imply some sort of risk, especially if there is no way of immediately determining if the risk is valid. For example, you might have eyes on an SDK you've never used before. If the SDK is complete, a simple bit of research during pre-production will mitigate the risk. On the other hand, if the SDK is still in development or if it's not code-based (for instance, it's some sort of externally developed content like music or a cinematic), then you definitely have an unmitigated risk.

• Risk should be assessed for anything that occurs after pre-production; however, a risk assessment is a good way to identify, as in the example above, some research that should be done during pre-production.

• Do not include risks concerning loss of employees, such as a house falling on your AI programmer or your entire art staff quitting to work on an animated film. Such risks would make the schedule unmanageable and make you look like too much of an alarmist. (Unless, of course, you happen to know the AI programmer is living underneath a cliff-house and the art staff is a bunch of disgruntled ex-Disney animators.) Besides, there are ways of dealing with those problems when they occur.

• Risks are often associated with particular features or tasks that are complex or experimental in nature.

• Account for the team's inexperience with a particular platform or genre, as this usually translates to delays in the first playable.

• An item or license yet to be purchased or borrowed is a risk until it has been purchased and delivered. This includes development kits, software licenses or anything that could suddenly halt progress if it's not taken care of. Anyone who's dealt with the red tape of purchasing knows what I'm talking about.
  

Reducing Risk

A good assessment also describes back-up plans and explores other solutions that would reduce or eliminate the risk. That's the next step after identifying them. The producer and team leads and directors should meet to go over the risk assessment. While some risks cannot be mitigated with anything but accounting for them in the master schedule (see Risk Tasks below), other risks can be reduced by a variety of ways:

• Redesign - eliminate the feature or change the design.

• Keep it simple (the so-called KISS principal).
  

• Put your best people on the task.
  

• Pre-purchase your equipment or leases.
  

• Front load the task in the schedule to give you time to adjust should the risk materialize.
  

• Review other options or solutions that might be a better trade-off and less of a gamble.
  

• Consider using proven off-the-shelf solutions for any undertaking with which the team lacks experience.
  

• Formulate a back-up plan for anything experimental or unproven.
  

• Create an early review and proof-of-concept stage in the risk area to minimize the amount of wasted work should it come down to changing course.
  

• Lots of risk stems from the unknown. Reduce the unknowns by researching them during pre-production.
  

• Ensure you have a complete functional and technical design specification (i.e. a plan), before you start production.

Risk Tasks

A risk task is an entry in your scheduling program that reflects the impact of a risk on the master schedule. You should put these risk tasks together with the area in which they are associated (Figure 2, item (A)). Assuming you have a group of tasks associated with a feature, any risk to that feature being completed should be appended to that task group. This allows you to associate dependencies (i.e., predecessors) with the summary task of the group (Figure 2, item (B)), such as a feature with a milestone, that reflect the associated risk.

	Figure 2. Associating risks with the tasks they apply to.

You may want all subsequent tasks on the schedule (or perhaps just particular tasks) to reflect that risk. Personally, I like to have only the milestone deliverables for the publisher reflect the risk assessment, and have all other dependencies associated with the actual work. People on your team can adjust their schedule to accommodate some slipped dependencies of other team members, but the publisher should not have to. I also don't like the confusion of having a bunch of unscheduled days in the middle of someone's schedule just because of a potential risk unless there really is nothing else he or she can do to skip ahead.

To avoid confusion, risk tasks should not have any real resource assigned to them. Since the resulting work from a realized risk is only hypothetical, it would throw off the schedule and create some apparent assignment problems. If you are using your scheduling program to do your project budget, you may want to assign a "Risk" resource to the risk task. That allows you to budget for the risk.

The duration of risk tasks is based on the assessment and the number of people that would be working to resolve it (if it's effort driven). Personally, I like to use zero-duration tasks with the risk days added as lag to the predecessor formulae (i.e. "9FS + 5 days", or 5 days from Finish to Start of Task 9). I call this the "Simple Method", and it is shown in Figure 3. The risk tasks are marked as milestone tasks in Microsoft Project, which helps indicate their hypothetical nature and their association only with publisher milestone dates. This is fast and simple.

	Figure 3. The "Simple Method" of creating risk tasks.

Note that if you are budgeting for risk using Microsoft Project then you cannot use the simple method; in Microsoft Project zero-duration tasks do not have any associated work to bill against. Instead, enter the risk days as the duration and the predecessor like a normal task. You will want to modify the bar styles to help clarify the difference with regular tasks. This makes the method of adding risk tasks to the schedule a little more complex. Follow these steps if you don't know how:

Step 1: Right click on the Resource column on the Gantt chart and choose "Insert Column" from the pop-up menu. Select the field "Flag1" with the title "Risk". Click "OK" to insert the Risk column.

 

Step 2: Apply the Risk flag to all risk tasks and set your durations and predecessors appropriately.

 

Step 3: On the Gantt chart view, select Bar Styles off the Format menu.

 

Step 4: Scroll to the first blank row and replicate the settings shown. Set "Show For … Tasks" to Flag1, and make the bar pattern hollow and the color red. Choose OK to see the results.

 

Finished: See the risk tasks marked in red.

______________________________________________________

 

Slack - Another Way to Manage Risk

join | contact us | advertise | write | my profile
news | features | companies | jobs | resumes | education | product guide | projects | store



Copyright © 2003 CMP Media LLC

privacy policy | terms of service