This article originally appeared on PocketGamer.biz on 10th October May 2014.
Who isn’t excited at the thought of project management? All those budgets, project plans, tasks and milestones – it’s clearly the most glamorous part of the whole game development process.
When you’re on a small team it’s easy to let things slide a bit, even if you know intellectually what you’re “supposed” to do. No-one wants to have lots of process for process’ sake, and the project management needed for a team of 100 full time staff is clearly overly engineered and impractical for a couple of staff and a few freelancers.
But too little project management can be just as damaging, leading to overspending or having to cut back on features because of poor planning.
This year I’ve been project managing a couple of games back-to-back with around 10-20 people involved (mostly freelancers) and have been thinking a lot about the tips and tools that have made life easier, as well as some of what I’d do differently next time. This list is what’s stuck near the front of my brain, and I’m really interested to know what’s stuck at the front of yours.
#1 Time, money, stuff
Tremble before the awesome usefulness of The Triangle of Truth. It’s a fact that the amount of stuff you can have in your game is tied to how much money and time you have. While obvious to point out, it’s also the first casualty when new requirements come swooping in.
As the project manager, these three constraints are your lenses – the things you look through to help you make the decision on what can move. They’re also your levers – they’re the things you can move to try and solve problems and make the game great.
Keep them in mind all of the time.
#2 At the start of your project, identify your givens…
Have you got a hard launch date, a fixed budget, technologies that must be used, particular platforms that must be targeted, a brand that must be included?
List everything that is certain, so you know enough to have the next conversation…
#3 Define success
How will this project be judged? Who is judging it?
You need to know the most important project aims, so that later when there’s a fog of TONS OF STUFF TO DO ARGH you can use your time-money-stuff lenses to figure out the best decisions to still meet the success criteria.
#4 Be optimistic, but budget pessimistically
Humans are hardwired to be dreadful at planning ahead. So figure out the maximum amount you can spend on external costs, and then plan to make a game that will cost half of your budget.
Then, then when it all goes wrong (and it will, to a greater or lesser extent), you haven’t spent all your money.
“But what if it doesn’t go wrong? Then I’ll have loads of money left over!” I hear you cry.
It will go wrong. It will definitely, definitely, definitely go wrong. Even if nothing major goes wrong, you will absolutely encounter the insidious it’s-taken-longer-than-I-thought-it-would and the irritating ah-I-didn’t-realise-we’d-need-to-do-these-ten-other-things-to-make-this-one-thing-work.
Proper testing and proper polish always takes more time and money than you think at the start.
Be brutal. You’ll thank you for it later.
I still like Gantt charts, even for fairly iterative Agile-y projects. No need to go day-to-day, usually they cover a week as the smallest unit of time, done in a Google Spreadsheet and are mostly used a high level way to map out the framework for the game build and capture major deliveries (Alpha, Beta, Release Candidates).
Even if the phases are only defined up to a point (e.g. prototyping before figuring out the ‘main’ game), it’s still good to give yourself an overall structure with clear deadlines. Tasks tend to expand to fill the time available, so even the most creative, free-wheeling innovation projects need a deadline and review points to keep them focussed and to get something useful out of them.
As a starter for ten, I try to have lines in the schedule for game design, user experience, sound design, music, testing, art, user interface, scripting, animation, programming, particle effects, testing, lighting, writing content, level design, more testing, integration with other technology, deploying to platforms, approval times, contingency, marketing materials (promo images/videos), accessibility options, and not to forget testing.
I find filling them out in this way very helpful for flagging any gaps in the existing team’s skillsets before it becomes a problem, giving enough time to find freelancers, or re-think the approach.
If you only realise this in the last couple of weeks, by the time you’ve found someone to bring on, and brought them up to speed, it’s too late for them to have a meaningful impact on the game – i.e. Brook’s Law.
#6 Everyone likes sausage games, but no-one wants to see how sausage games are made
As project manager, pretty much your only real job is communication. Making sure that the right people have the right information at the right time, presented in the clearest possible way.
You may need a place:
- to communicate progress to client/funder/senior stakeholders
- for the project repo to live
- for ticketing tasks and bugs, and private communication around the team
- to share and transfer files and documents around the team
- to deploy test builds (possibly automated)
Depending on how many people you have working on the project and how much oversight you have, your mileage will vary. For me I’m a fan of BaseCamp for discussions with senior stakeholders, CodeBase for tickets, DropBox for file transfer, and we’re using the Unity Cloud Beta to automate daily builds to a secure AWS instance and notifying relevant team members via email.
Setting all of this up at the beginning of the project means that when you’re bringing on new team members you have a clear and documented process for getting new people on board and can quickly figure out what they need to have access to. It should also reduce the ‘ramp up’ time if everything’s well organised across these systems from the start.
#7 Briefs for everyone, even you! But keep them brief…
Speaking of bringing on new team members, when you do hire a freelancer make sure they have a clear brief. This is vital and necessary if the contract is based on deliverables, but even if it’s based on days it’s still important so that you can have an informed conversation with them at the start.
There will almost certainly be issues you hadn’t considered, and the brief may need to be revised. It doesn’t have to be over-written, but for everything on the project you should try to be clear about:
- what the task is
- who is responsible
- when it’s due
- what the dependencies are (e.g. implementing the user interface needs signed off art)
- who decides when it’s done
Whatever you budget for freelancers, keep some aside for contingency. You will need it. You will definitely, definitely need it.
#8 Take a long, hard look at yourself
You’re the project manager, but I bet that’s not your only job on the project. For me, I’m usually the producer as well, which may mean Iâ€™m writing content, editing images, level designing – doing actual work that isn’t just project management and all of which takes real time.
Don’t forget to allow yourself enough time to project manage AND perform your other tasks on the project. Finding this balance, and properly estimating the size of my own tasks, is what I personally find hardest.
There’s nothing worse than realising that the bottleneck on the game that’s blocking others from progressing is you.
#9 Spanners ahoy!
On every project I’ve ever managed something has always come up that no-one was expecting that had a major impact. Every situation is different, but the overall approach is always the same:
- keep your cool. You can’t control whether other people freak out, but you can control your own reaction
- investigate the issue. Make sure you understand exactly what the problem is
- discuss the issue with your team. What are all of the suggestions for resolving it? What are your suggestions?
- for each suggestion, work through the impact in terms of time-money-stuff for the rest of the project. This may involve further consultation with the team
- present the top three or four proposed solutions in a succinct, clear way to the stakeholders involved in making the decision, so they clearly understand that impact. Make sure everyone understands that they can’t have it all and that one or more of the levers (time, money, stuff) needs to move, it’s just a question of to what degree
- communicate the ultimate decision back to the team clearly and then make it happen
#10 Getting it over the line
There’s always a gap between what you know you should do, and what you ultimately end up doing – no battle plan survives first contact. There are also times when a lot of this goes out the window and you end up just hustling away to Get It Done.
Speaking of, I’ll wrap up here as I’ve written more on this than I expected, and it’s taken a fair bit longer than planned. I really should’ve removed some stuff…