|
By
Heather Chirtea
Gamasutra
CGDC Roundtable Report, April
1997
|
|
CGDC '97
Roundtable Reports
How to
Screw Up a Perfectly Good Production
Three days of debate produced a great list of potential hazards in the
production process. Most of the advanced attendees were producers, so
each item listed below is actually based on true "screw ups" in the production
process. I would invite others to add to the list.
*Improper planning-The
design is larger than the production budget. This often reflects the inexperience
of the producer as well as a breakdown in scheduling.
*Should I write it or license it?-Writing code can often be more costly
than licensing an off the shelf program. BEWARE THOUGH! Do a lot of research
before you license. Sometimes the off the shelf part doesn't work correctly,
or doesn't meet the claims of the publisher.
*Subcontractors live in different time zones-Before you hire that European
developer, be sure you understand that when you are awake, they are sleeping.
Communication breaks down very quickly across time zones.
*Marketing gets involved too late-Half way through a project, marketing
intervenes and changes the direction of the product. Get them involved
early whenever possible. Despite arguments to the contrary, early marketing
involvement can be much healthier for your product. The marketing people
are often the ones who have to sell the products, and if they like them
from the start, the marketers will do a better job for the team.
*My publisher went out of business-Many projects get canceled when publishers
downsize or close their doors completely. Research your publisher before
you sign the contract. Find out if they are stable. Never do a concurrent
multiple product deal unless you are 100% sure the publisher will be in
business next year. Cancellations have ruined entire companies.
*Unclear lines of authority-Make sure one person has the final say. Creative
arguments can spawn new ideas, but stop them before they swing wildly
out of control.
*Schedule estimations were completely wrong-The smaller the time chunks
in your schedule, the more likely it is to be accurate. Shoot for estimations
in 'days' and 'hours'. Stay away from estimations in 'weeks' and 'months'.
After the design is frozen, art is predictable, coding isn't. Put your
slush time in the programming schedule.
*Budget estimations were completely wrong-This typically happens due to
scheduling mistakes so the 'trickle down' theory applies here. The more
line items you have in a budget, the closer it will be to correct.
*The publisher didn't market the product correctly-Go into the software
stores and see who is getting shelf space, who owns the end caps, and
who is advertising. Sign with these publishers! When you relinquish control
of the marketing function, you have to live with the results. You can
negotiate minimum marketing budgets in the initial contract.
*The President interfered in the product and changed the design-This relates
back to lines of authority. If they are unclear, you will have inevitable
problems.
*My team is burned out-This is typically caused by unrealistic expectations
in the schedule. Revise the schedule after each major milestone is met.
Be realistic. Weekends are not work days! Give your staff a break, they
will perform better.
These are the major subjects
we debated and laughed about in the roundtable. Please add more.
|
