Download Powerpoint

Two Dozen Ways to Screw Up a Two Dozen Ways to Screw Up a Perfectly Good ProjectPerfectly Good Project

Dave RohrlDave Rohrl

Senior Producer, EA/PogoSenior Producer, EA/Pogo

[email protected]@pogo.com

Presented at GDC 2002Presented at GDC 2002

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

Mistakes in Depth

• Why do we do it? – The Lure.

• What is the likely outcome? – The Consequence.

• What should be doing?– The Best Practice

Project Timeline

• Planning/Pre-Production

• Production

• QA/Playtest

• Whenever

1. Don’t Contain Your Ambitions

• Lure: – Life is too short to make B games

• Consequence: – Given infinite time and money, you still

couldn’t finish

• Best Practice:– Understand your team– Grow your team in measured ways– Do risky pieces first

2. Don’t 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

3. Don’t 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

4. Be Afraid to Close Decisions• Lure:

– Great games require iteration– Decisions are hard

• Consequence:– No closure = no reliable progress– Later decisions come undone

The Virtuous Course of Game Development

Time

InfiniteUniverse ofPossibilities Individual

Product

Start of brainstorming

ProductRelease

The Shameful Course of Game Development

Time

InfiniteUniverse ofPossibilities

PossibleProducts

?

4. Be Afraid to Close Decisions (cont.)

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

5. Don’t 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

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 Manager’s Triangle

Project Manager’s Triangle

Schedule

Budget Content

Quick & Dirty Project

Schedule

Budget Content

‘A’ Title, Hopefully in Quarter

Schedule

Budget Content

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 Manager’s Triangle to decide how.

8. Don’t Prototype

• Lure:– It’s 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

9. Don’t Write It Down• Lure:

– Too much time, especially to document processes

– It’s 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

10. Roll Into Production as Quickly as Possible

• Lure:– It feels great; everyone’s doing what they love

• Consequence:– Inaccurate/incomplete design– Throwaway code and assets

• Best Practice:– Close out design issues– Review design in detail

11. Tackle the Easy/Fun Stuff First

• Lure:– It’s 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

12. Don’t Practice Change Control

• Lure:– Can’t 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

Change Control DB ScreenProposed Change

Modules/Systems Impacted

Department AssessmentsDept People Effort Risk Rec? NotesEngine Jack 3d High No Not enough benefitLevel Des. Jill, Lois 4w Low Yes We have enough

slack & is very cool

Benefit/Justification

Approved? Yes No Pending

Requestor

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 isn’t shrinking– Your ship date isn’t holding

• Best Practice:– Try to keep the total test schedule constant– Submit risky modules to QA first

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

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

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

17. Be Too Busy To Playtest• Lure:

– All the other tasks need a piece of you– Can’t 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 >= 15% of time for playtesting– Take the game home if necessary

18. Don’t Get Fresh Eyes on the Game

• Lure:– Feedback is redundant or untimely– QA’s 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

19. Don’t Use Project Management Software

• Lure:– MS Project is overkill– Team members don’t read Gantt/PERT charts

• Consequence:– Hard to track dependencies– Can’t 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

20. Do It All Yourself• Lure:

– Damn, you’re 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

21. Don’t Conduct Risk Analysis

• Lure:– Not enough time, not well understood

• Consequence:– Sudden, surprising, and huge disruptions

• Best Practice:– Maintain a top 10 risks list

Top 10 Risks Chart

# Risk Last Week

Weeks on Chart

Abatement Plan

Done Notes

1 OTM dev $ not greenlit

3 6 Muscle on to Mar exec review

No Can’t make Q3 without approval

2 OTG design spotty

N/A 1 Dave rewrites sketchy sections

Yes Still 4 sections for dev to redo

22. Close Lines of Communication

• Lure:– That’s 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– Don’t let people confuse input and authority

23. Don’t Schedule Regular Team Meetings

• Lure:– Meetings don’t 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

24. Don’t 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

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 [email protected]

• Thanks!

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

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

Planning/Pre-Production

•Deliver to QA all at once.•Be too busy to play the game.

•Don’t get fresh eyes on the game.

QA/Playtest

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

Production

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

Whenever