Truth, Lies and Project Management

Project Management and you...

I'll talk about coding another day, but for now I'd like to look at being the project manager of a 3 person team.

At one point we were asked to describe our style of management. Somewhat confused, I replied "Tyranny?". Apparently they were asking about Agile versus Waterfall. Pfft. Whatever. The point is, the world's in a mess and I just need to rule it... I mean manage the project. Yes.

Given that there are three of us and we have a metric crap ton of work to get done, it's obviously not feasible for me to be a full time PM. I look at it more as a project coordinator. A facilitator of projects, as it were. So what is the key to managing a small team with a lot of work and very little time? Well, it helps if the team is receptive to being managed. Luckily, this team is. And done! Okay. I'll try and break it down further.

Sprints
We start every Monday with a short meeting. I go over the task list (excerpted in really tiny script above for your viewing pleasure) and we assign a sprint for the week.

It's an unholy blend of agile and waterfall where the 'due dates' we came up with in pre-pro function more as a guideline and not a rule. They gave us a rough idea of the priority of the tasks to be done, but are not set in stone.

Each person has their own colour of stickies so they can easily see if there are any dependencies (I stack related stickies, so that the yellow at the bottom is waiting for all the top stickies to get done). I first ask if anyone has a preferred task set they want to complete, and assign that. After that, or if there are no preferences, I start writing sticky notes until my target starts to whimper.

The key here is knowing how your team works. That's rough at first, but it's important to get a sense of the pace of work, and how well your team members estimate time. I've been tracking this just to make the numbers official, but I feel pretty confident that 80 - 90% of what I assign in the week is doable (the remaining is there to allow some flexibility in how we work or for priorities to be rearranged).

The sticky notes are up for the week, and I mark the task as assigned in the spreadsheet. When a task is complete, the team member leaves the sticky note on my desk, I tick it off the task list and toss the finished sticky onto the pile.

The Spreadsheet
The fastest way to get someone to leave you alone is to open some giant, multi-coloured spreadsheet. Most people have an innate fear of Excel and will immediately back away. We have such a spreadsheet. It was based on a template I found in the Necronomicon and we've been pretty happy with it (except for the faint sobbing noises you hear late at night when it's really quiet).

Really, the only point of setting up a spreadsheet is to catch all the minutiae of game design. Not every group will want or need this. It depends on your style and organization. I have no style and terrible organization, so spreadsheet it is!

The task list is really broken down into small detail. For example: the Brain's model, UV, texture, move animation, idle animation, script, voice recording, voice processing and adding each component into code are all individual tasks. I could have simply put "Brain - 20 hours" but that really doesn't tell us dependencies and it's a lot harder to estimate time on a monolithic piece of work like a major game character. Currently, the game's main character Eyegore has 33 sub-tasks to be completed just to get him in game and working.

I made a quick set of graphs up for the team. You can see them above. The blue line is projected work done, the red is actual work done. I got rid of all the stuff we purged from the project and it's actually kind of cool how well they're matching actual and expected. Woot?

Originally the graphs were set up to check for outliers, like the time I had to say "Hey guys? We have 36 days of work planned for this week's sprint?". That's the time to go back and rebalance the workload. That's easier with an agile system, but you always have to keep a tight rein on the backlog or else it's going to be week 12 and people will be sobbing under their desks (more than usual).

One really important thing to note is that nobody cares about your spreadsheet but you. Seriously. Mine's covered with graphs and arcane formulae, but they only matter to me and only insomuch as it helps keep the team on track. Numbers can be absurdly fun to crunch (oh god I'm a nerd), but keep them relevant and understand their meaning and why you track them. Also understand that if you ever hand in your spreadsheet, you will be expected to explain it. So, that's where the lies come in.

I've said too much.

(The average reaction to seeing a project manager's spreadsheet)