|
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.
|