Two Dozen Ways to Screw Up a Perfectly Good Project

1
Two Dozen Ways to Screw Up a Perfectly Good
Project

• Dave Rohrl
• Senior Producer, EA/Pogo
• drohrl_at_pogo.com
• Presented at GDC 2002

2
Mistakes Producers Make

• Producers establish standards and practices
• They often search for the comfortable and
  intuitive
• Bad idea!
• Many common mistakes are covered in the
  literature
• Project management, software engineering, general
  management

3
Mistakes in Depth

• Why do we do it?
• The Lure.
• What is the likely outcome?
• The Consequence.
• What should be doing?
• The Best Practice

4
Project Timeline

• Planning/Pre-Production
• Production
• QA/Playtest
• Whenever

5
1. Dont Contain Your Ambitions

• Lure
• Life is too short to make B games
• Consequence
• Given infinite time and money, you still couldnt
  finish
• Best Practice
• Understand your team
• Grow your team in measured ways
• Do risky pieces first

6
2. Dont Delineate Clear Roles

• Lure
• Multitalented, energetic teams
• Consequence
• When decisions have to be made, people will get
  bummed
• Problem-solving gets messy
• Best Practice
• Decide who gets to decide what
• Make sure everyone knows/agrees
• Input ? authority

7
3. Dont Worry About Tool Sets

• Lure
• Tools are dull (relative to games)
• Consequence
• Assets need to be re-created
• Best Practice
• No game assets until tool set is agreed on
• Build tools first with scanty harness

8
4. Be Afraid to Close Decisions

• Lure
• Great games require iteration
• Decisions are hard
• Consequence
• No closure no reliable progress
• Later decisions come undone

9
The Virtuous Course of Game Development
Infinite Universe of Possibilities
Individual Product
Start of brainstorming
Product Release
Time
10
The Shameful Course of Game Development
Infinite Universe of Possibilities
?
Time
Possible Products
11
4. Be Afraid to Close Decisions (cont.)

• Best Practice
• Set criteria
• Define exploration/decision paths
• Identify and manage risks

12
5. Dont Budget Time for Rework

• Lure
• Tight schedules, solid design planning
• Consequence
• Change will happen. Period.
• Playtest will reveal key fun factor plays
• Best Practice
• Add rework time to initial schedule
• Less experience more time
• 20 to start

13
6. Surrender Control of Schedule, Budget, AND
Scope

• Lure
• What the suits want
• Consequence
• Hard to keep balanced in best of circumstances
• Doomed to failure in worst
• Best Practice
• Keep one wild card
• Use the Project Managers Triangle

14
Project Managers Triangle
Schedule
Budget
Content
15
Quick Dirty Project
Schedule
Budget
Content
16
A Title, Hopefully in Quarter
Schedule
Budget
Content
17
7. Make the task durations fit the schedule
constraints

• Lure
• The task estimates add up to a late project.
• Consequence
• Tasks take as long as you originally thought, or
• Your staff can kiss their families goodbye
• Best Practice
• Change the project constraints
• Use the Project Managers Triangle to decide how.

18
8. Dont Prototype

• Lure
• Its all throwaway
• Prototypes create unrealistic expectations
• Consequence
• Your production game becomes the throwaway
• Best Practice
• Build it, circulate it, leverage it
• Keep good change notes

19
9. Dont Write It Down

• Lure
• Too much time, especially to document processes
• Its all going to change any way
• Consequence
• What was that game you were building again?
• Mass confusion, wasted effort
• Best Practice
• Create design, tech, and process documentation
• Budget time to maintain it
• Make the level of detail fit your team and game

20
10. Roll Into Production as Quickly as Possible

• Lure
• It feels great everyones doing what they love
• Consequence
• Inaccurate/incomplete design
• Throwaway code and assets
• Best Practice
• Close out design issues
• Review design in detail

21
11. Tackle the Easy/Fun Stuff First

• Lure
• Its fun!
• Duh!
• Consequence
• Spend 65 of your time on 80 of your tasks
• Then 70 of your time on the rest
• Best Practice
• Put risky stuff first
• Makes schedule issues evident up front

22
12. Dont Practice Change Control

• Lure
• Cant have a great game without iteration
• Some change is inevitable
• Consequence
• Project is completely out of control
• You get called out on Fatbabies
• Best Practices
• Create a change control db (or similar)
• Enforce the practice

23
Change Control DB Screen
Proposed Change
Requestor
Modules/Systems Impacted
Benefit/ Justification
Department Assessments
Dept People Effort Risk Rec? Notes Engine Jack
3d High No Not enough benefit Level Des. Jill,
Lois 4w Low Yes We have enough slack is
very cool
Approved?
Yes
No
Pending
24
13. Move Alpha Back, Hold Ship Date

• Lure
• So much QA time on schedule
• Maybe less QA time will reduce the bug count?
• Consequence
• Your QA cycle isnt shrinking
• Your ship date isnt holding
• Best Practice
• Try to keep the total test schedule constant
• Submit risky modules to QA first

25
14. Assume You Can Make Up the Time Later

• Lure
• Comforting fiction
• Consequence
• Slippage is steady or continually increases
• Exemption for one-timers
• Goodbye nights and weekends
• Best Practices
• Increase schedule monitoring, create scaling
  factor
• Reset expectations if necessary
• Create a detailed make-up plan

26
15. Give 80 Credit For Tasks That Are 80 Done

• Lure
• Seems logical
• Consequence
• The other 20 takes the other 80 of the time
• Best Practice
• Use fine-grained subtasks and binary evaluation
• Put risky subtasks first
• Cross-check task estimates

27
16. Deliver to QA All At Once

• Lure
• Complete game needed for system testing
• Consequence
• Ballooning QA schedule/poor predictability
• Best Practice
• Deliver modules as early as possible
• Use early results to model later schedule
• Build test harnesses as necessary

28
17. Be Too Busy To Playtest

• Lure
• All the other tasks need a piece of you
• Cant stand to look at the game one more time
• Will find bad stuff
• Consequence
• No one is parsing the overall experience
• Bad stuff that hurts the global view ships
• Best Practice
• Budget gt 15 of time for playtesting
• Take the game home if necessary

29
18. Dont Get Fresh Eyes on the Game

• Lure
• Feedback is redundant or untimely
• QAs all over it
• Takes too long to get people up to speed
• Consequence
• Takes too long to get new players up to speed
• Potentially useful feedback lost
• Best Practice
• Internal and external fresh eyes throughout

30
19. Dont Use Project Management Software

• Lure
• MS Project is overkill
• Team members dont read Gantt/PERT charts
• Consequence
• Hard to track dependencies
• Cant understand schedule impact of slippages
• Best Practice
• Become a power user of Project (or similar)
• Learn to use resource/budget features
• Keep a stripped format for team

31
20. Do It All Yourself

• Lure
• Damn, youre good!
• Getting people up to speed takes too long
• Consequence
• Chief bottleneck
• No time/energy to make good decisions
• Best Practice
• Learn effective delegation
• Bring in contractors as needed

32
21. Dont Conduct Risk Analysis

• Lure
• Not enough time, not well understood
• Consequence
• Sudden, surprising, and huge disruptions
• Best Practice
• Maintain a top 10 risks list

33
Top 10 Risks Chart
34
22. Close Lines of Communication

• Lure
• Thats what leads are for
• Consequence
• Low morale, high turnover, flat game
• Best Practice
• Decisions go down through leads and team meetings
• Ideas come up and around from everywhere
• Dont let people confuse input and authority

35
23. Dont Schedule Regular Team Meetings

• Lure
• Meetings dont get tasks done
• Lots of developers hate meetings
• Consequence
• Team gets out of synch
• Cross discipline problems fester
• No clear vision of how overall game is
  progressing
• Best Practice
• Meet regularly throughout
• Get more (not less) frequent as GM gets closer

36
24. Dont Use a Review Process

• Lure
• Reviews take time
• Good people are putting out quality work
• They get touchy when people critique them.
• Consequence
• Lots and lots of rework
• Far more expensive to fix later
• Best Practice
• Use a consistent review process throughout
• Budget 5-10 of staff time for reviews

37
Parting Thoughts

• The lures of these mistakes make them common and
  recurring.
• Learn from every project
• Be honest with yourself and your team
• Study software engineering, project management,
  and risk management
• Make new mistakes every time out
• Send them to mistakes_at_universeman.com
• Thanks!

38
Bibliography

• Peopleware Productive Projects and Teams
• Quality Software Management Series (Volumes 1-2)
• Handbook of Walkthroughs, Inspections, and
  Technical Reviews
• The Mythical Man-Month
• Software Project Survival Guide
• Rapid Software Development

39
Planning/Pre-Production

• Don't contain your ambitions
• Don't delineate clear roles.
• Don't worry about tool sets.
• Be afraid to close out decisions.
• Don't budget time for rework.
• Surrender control of schedule, budget, AND scope.
• Make the task durations fit the schedule
  constraints.
• Don't prototype.
• Don't write it down.
• Roll into production as quickly as possible.

40
Production

• Tackle the easy/fun stuff first.
• Don't practice change control.
• Move your Alpha date back, but hold your ship
  date.
• Assume you can make up the time later
• Give 80 credit for tasks that are 80 done.

QA/Playtest

• Deliver to QA all at once.
• Be too busy to play the game.
• Dont get fresh eyes on the game.

41
Whenever

• Don't use project management software.
• Do it all yourself.
• Don't conduct risk analysis
• Close lines of communication.
• Don't schedule regular meetings.
• 24. Don't bother with a review process.