Risk Management With Development Schedules

Author: by Tim Ryan

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 Heel, 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:

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:

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.

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.

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:

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 just as bad 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.