Risk Management With Development Schedules
By Timothy Ryan
Gamasutra
February 6, 2003

URL: http://www.gamasutra.com/features/20030206/ryan_01.shtml

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

As managers we are expected to keep people productive and remove undesirable slack from our schedules. Having people on payroll without work to do just doesn't make fiscal sense. Plus the pressure of deadlines and a limited headcount forces us to uncover and utilize any slack in the schedule we can to maximize efficiency. To us, an unassigned day on the schedule is a wasted day. When I was at a consulting firm, we called this unassigned time "on the beach" because it was like a free vacation day where you weren't making the company any money.

One thing we recognized at the consulting firm, though, was while having a lot of people on the beach was bad, having none was worse and added risk of its own. The reason stems from the inflexibility of your work force if it's completely booked. A tight, maximally efficient schedule is a house of cards that will never stand up to unexpected risks. If you can't grow or reassign your team as necessary to take on new assignments, put out fires or deal with unexpected absences, then you risk the big picture - getting the work done well and on time.

What does this mean for a game developer? It means having a robust, flexible and sizeable workforce and not scheduling everyone 100%. If you can manage it, have some contractors on stand-by or on a flexible, part-time basis. Make your leads the project's firefighters. Schedule them at most 50% on regular tasks, leaving the rest of the time to mentor, manage and put out the occasional fire. Lastly, don't sweat it if some dependencies cause minor gaps in peoples' schedules. Trust them to skip ahead and find work they can do to occupy their time. This gives them some slack in the master schedule in case they get seriously sick or are needed to fill in someplace else.

Accounting for Free-Form Resources - "I'm not a NUMBER!"

If you haven't already starting doing it, you may find yourself calling people on your team what Microsoft Project calls them - "resources". You look at everyone contributing to the project as a resource, but there are always going to be some resources that will throw off the yoke and declare, "I'm not a resource! I'm a free man!" This is analogous to the interplay in the 1960s' BBC television production of "The Prisoner":

Like the dubious hero Number 6, who refused to provide information or be a number, you may have some people on the team who cannot or will not be able to give you the information you need to schedule them as a resource. For example, some people may split their time among multiple projects. Some may be involved with the chaotic demands of business development. Others just can't work according to any normal schedule and prefer to schedule their own time. This certainly adds an unstable element and a certain amount of risk to the schedule. Call them "free spirits", "free radicals" or just plain "free-form resources", and recognize that these people are unpredictable by nature of their work and thus need a different style of scheduling to minimize the risk.

Instead of normal tasks, you should define some deliverable tasks and mark them as zero-duration milestones in the schedule. The people doing the work might not give you estimates, but you should be able to get them to sign-off on the delivery dates. The dates should be based on any dependencies with other tasks or project milestones. Of course you should push the dates up a few days early to account for the unpredictable nature of the person. Common deliverable tasks include documentation, such as level designs and sound effects lists, as well as any engineering or art task assigned to a free-form resource. This way, you don't need their information or even need to add them to your resource sheet, just as long as they can commit to the deliverable dates.

Overtime: Your Last Weapon in the Arsenal of Risk Management

Finally, let's address the issue of overtime. Overtime is the traditional way development teams have dealt with risk while still staying in the same timeframe and budget. We all know that overtime is an unavoidable aspect of working in our industry. Often it's because of bad scheduling, over-ambitious leaders, poor planning, feature creep and a meandering vision that we end up working the sanity burning hours of crunch mode. All that aside, even with the best schedules, documentation, planning and unerring vision, there's going to be something you overlook, underestimate or just plain aspire to do that makes the team work overtime. Appallingly, some companies go so far as to schedule overtime even during non-crunch periods. That's a serious mistake, because overtime is both the easiest and most cost-efficient method of managing risk and feature creep, and if you are already scheduling overtime for regular task assignments, there's not a lot left to give. Overtime also takes a toll on people's health and lives. It should be used wisely as it is your last weapon in the arsenal of risk management.

Copyright © 2003 CMP Media Inc. All rights reserved.