It's free to join Gamasutra!|Have a question? Want to know who runs this site? Here you go.|Targeting the game development market with your product or service? Get info on advertising here.||For altering your contact information or changing email subscription preferences.
Registered members can log in here.Back to the home page.

Search articles, jobs, buyers guide, and more.

By Timothy Ryan
Gamasutra
[Author's Bio]
February 6, 2003

Risk Assessment

Slack - Another Way to Manage Risk

Printer Friendly Version
   

 


 


Latest Letters to the Editor:
Perpetual Layoffs by Alexander Brandon [09.21.2007]

Casual friendliness in MMO's by Colby Poulson [09.20.2007]

Scrum deals and 'What is Scrum?' by Tom Plunket [08.29.2007]


[Submit Letter]

[View All...]
  



Upcoming Events:
Video Game Expo (VGXPO)
Philadelphia, United States
11.21.08

DIG London Game Conference
London, Canada
11.27.08

5th Australasian Conference on Interactive Entertainment
Brisbane, Australia
12.03.08

IEEE Symposium on Computational Intelligence and Games
Perth, Australia
12.15.08

2K Bot Prize
Perth, Australia
12.15.08

[Submit Event]
[View All...]

 


[Enter Forums...]

Note: Discussion forums for Gamasutra are hosted by the IGDA, which is free to join.
 

 

 


Features

Risk Management with
Development Schedules

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":

Number 6: "Where am I?"
Number 2: "In the Village."
Number 6: "What do you want?"
Number 2: "Information."
Number 6: "Whose side are you on?"
Number 2: "That would be telling. We want information."
Number 6: "You won't get it!"
Number 2: "By hook or by crook, we will."
Number 6: "Who are you?"
Number 2: "The new Number Two."
Number 6: "Who is Number One?"
Number 2: "You are Number Six."
Number 6: "I am not a number. I'm a free man!"

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.

______________________________________________________

[Back to] When Worlds Collide


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