Project Managing on a Micro Scale

Not micro-projects, necessarily, but micro-team: Greg and I.

I thoroughly enjoy project management, enough so that I’m willing to do it at least a little in my free time every day. That’s checking on tasks’ statuses, project timelines, testing projects in progress, offering feedback and suggestions, and gently kicking in the ass.

Well, as gently as I do anything.

FogBugz is my friend right now, although there are reports I want that it doesn’t have, like a per-user timeline across all projects. Surprisingly, it’s not overkill–I guess that’s why they have startup accounts.

Managing a team of two at home is rather different than managing a team of three in the workplace. The challenges are rather different. The projects take much longer relative to their number of person-hours. When you only have 3-5 hours on a weekday to work on projects (as I do), then include project management, volunteer projects, and personal projects in those numbers, timelines are surprisingly long. It makes me all the more possessive of my weekends, where I’d now usually rather be working than gaming.

In some regards, I’m working in an environment when my developer must learn how to estimate, how to break tasks down, and how to manage and understand a timeline. Likewise, I have to adapt myself to a video game developer’s perspective rather than a web developer’s. For instance, we had an interesting exchange the other night (paraphrased):

Me: So, I grouped the tasks into two rough milestones, “Fully Testable Beta” and “Salable Product”. Just to work on prioritizing a bit.
Greg: Yeah, I really don’t… I don’t get that. You put “sounds” and “music” in “Salable Product”.
Me: Right, because the music isn’t crucial to the act of playing the game. “Beta” is the fully-playable version, but not the finished product.
Greg: Well, I’d call that an “alpha”. But the sounds and music are crucial to the mood and gameplay. The sound may have cues that help the game!
Me: …Fine, then put “sounds” in “Beta” if that’s the case. But music is a finishing touch. So are loading screens.
Greg: What?! No. Look at “The Day”–the loading screen was crucial to the feel of the game.
Me: But that’s what most designers, most clients think–that that special font or whatever is going to make or break the whole site’s testability.
Greg (surly): Then what’s “Salable Product”?
Me: When that milestone’s complete–and it’ll get more tasks as the game develops and we want to chat about the mood, feel, and polish–when that’s complete, you’re ready to talk to sponsors.
Greg (still surly, now being contrary): Okay, so this “Fully Testable Beta” is really… I guess I should think about it as a “Gameplay Fully Testable” thing, then.
Me (trying not to wince at the awkward-to-me wording): Yep. I’ll change the name.
Greg (grumpily magnanimous): Oh, you don’t have to. I’ve got it now.

I changed the name.

Pardon the blanket statement about designers’ priorities–I was trying to make a point. Greg’s not just a developer; he’s a designer and an artist, and I have to remember that.

It was presumptuous of me to create and arrange the milestones without explaining it all to him first, maybe, but niggling over everything before I do it is not only a time-killer, but defeats some of the purpose of Greg having a separate PM–if I put the burden of all that initial PM decision-making back on him, it’s more crap he has to think about. If he knew what structure he wanted, he’d have imposed it himself. We have to try new things, see what works.

Working with a solely at-home person is tricky, too, from a tool standpoint. FogBugz considers work schedule in terms of what hours during the day the person is working (without the option for complex intervals), whereas what I really need is simply how many hours a day the person works.

Same for me, too. I get some work done on the bus, maybe during lunch, and then another hour or three at home in the evening. But if I enter 07:00 – 22:00 as my work hours, then every single timeline projection is wrong. So I pick a random evening interval that’s about three hours and suffer the “working outside normal hours” alerts I get when I toggle on the time tracker.

With a team of two, also, there’s no easy redistribution of labor. I can’t reliably take on development tasks on his games to accelerate the timeline, and he can’t write for me. Outsourcing pieces of games is complicated–more complicated than, say, outsourcing web QA using offshore talent. I’m not experienced enough yet to look at the music task for a game, and say, “Hmm, that’s going to take 8 hours. Let’s outsource that to the awesome guy who did the music for ‘Mold Fairy‘.” The answer’s “No, I’ll do it, it’s not worth it.” I’m hoping that’s not possessiveness or a fear that it won’t be done right, despite a great track record.

All of that said, it’s really interesting to see the changes wrought even in a short time of imposing structure on Greg’s projects. We both like numbers (useful ones, at least), and to see a breakdown of how he’s spending his time, where he needs to tighten up, what kind of feedback he needs from me, and how the timelines are looking is providing a new-found focus on projects.