My advice to serious plug-in developers

Keeping your team together

Hi everyone,

I was recently discussing some issues with a correspondent of mine, and we were hashing out some problems with game development for small, scattered team of people. I ran through some problems that ATMOS encountered when developing Nova, and I thought that the points I came up with might be of some use to you guys out there.

Please note that these points are as general as I can make them, but they may not apply to your situation. As always, your mileage may vary.

---

There are two main things that groups of friends and acquaintances who are in business with each other should have, in order to reduce the likelihood of projects and friendships going sour. They are:

• Contracts -- a document that lists what a person will do, when they will do it by, and what remuneration they will receive for doing so. It should also include mechanisms for item two, namely

• Dispute Resolution -- a series of procedures for resolving disputes, which might include creative disagreements, remuneration changes, time changes, etc.

I'm not going to try and tell you how to draw up contracts or set up the mechanisms for dispute resolution. What I will try to do is tell you that disputes happen. Even the best of us have disagreements, and business can foster some of the nastiest hatreds in even the firmest friends. I've seen it happen. Moreover, it's happened to me.

My definition of a contract: a defined and signed set of specifications of what a person does for the team, how long it will take them, and what percentage of the final cut they'll get. Make it a good, solid contract. Make sure everyone agrees, and whatever you do, make sure people understand that what they agree to do is what they are bound by.

I want to give you some advice so I can hopefully stop it happening to any of you. I very nearly lost my three best friends to business, and that's no good at all. Not all the things I preach here are what I actually did. On the contrary, I made many of the mistakes here listed -- that's how I know they're mistakes.

So, without further ado, a stream-of-consciousness list of whatever good advice came to mind while I was talking with my acquaintance.

---

• Decide what the project will involve. Have precise measures in place as to exactly what needs to be done. Don't get too detailed, but do try and think of as much as you can in general terms.

• Focus on the time taken to do the job. That is the only thing that matters! Do not accept any arguments like "I'm more important, and my job is harder", or "I'm more talented -- no one can do what I do." Time is the only measure you can use. You're not trying to decide whether a graphics person is worth more than a story person -- EVERYONE IS WORKING!!! Leave award rates and pay scales to companies that have HR departments. You're a small team, and without any one of you the project will not be completed. Think about that. (I really mean that last -- time is the only important measure)

• Once you've sorted that, get everyone to say how long they think the job will take them. Don't just ask them, and expect an accurate answer; let them take the problem away with them and get them to think about it really hard. Get two estimates from them -- how long it will take them to do the work (in hours), and how many hours they can devote to it each week. That tells you how long the project will take. (Remember, it's only hours they work that count).

• Calculate out how much each person will be working (in hours), and double those figures. That's how long it will take. Remember to take into account how much they can work per week.

• Take these figures back to them. If there are massive overloads on a particular person, take responsibility off them. That includes you. I don't care how good they are -- even up the load. (In the end, though, some people will work more than others. That's just the way of it).

• Provide some leeway for people who have made bad estimates on time, but not too much. If it becomes apparent very early on that one person's time estimate was really bad, the earlier you fix their time estimate (and readjust everyone if necessary), the better. This must be done early -- readjusting after 2 years is bad.

• Watch out for people over-padding their estimates so they can slack off but still earn good returns. If you think they can do better, say so. Get the team's input.

• If someone really isn't pulling their weight, they may have to go. Make sure this is written into their contract -- reasonable performance by a reasonable time, or they're off the team. DO NOT ever, ever, ever go soft on this. Be strong, and fire them. Pay them out (in shares of returns) whatever hours they've worked under contract as per their contract schedule (ie. if they said they'd do 3 ships in 3 weeks but you fired them after 7 weeks for only completing one, you pay them for one ship -- in other words, 1 week).

• You WILL include time taken to manage the project as a work task!!! (and you'll provide time estimates on this like you would anything else -- a manager is no different to any other team member.)

• Once all that is done, add 6 to 8 months for beta testing. Beta testing will mainly find problems in the missions and other resourced/coded areas. Allow for this -- mission coders will need more time (and thus final split) in this area.

• Allow time for bug-fixes after release. Whoever does the maintenance (and it'll usually fall to one or two people) will need to be compensated. Figure about 1 hour per bug. Use ATMOS' release logs and progress logs on Nova as a good guess as to how many bugs we had.

• If anyone starts taking massively longer than they said they would, then THAT IS THEIR FAULT, NOT OTHER PEOPLE'S FAULT! (Unless you can verify that they are waiting on someone else). On that note, time taken while waiting for someone else is not time that can be added to their total. While they're waiting, they're not doing any work. Just remember this important rule: by taking more time, they are not worthy of more money -- all they've done is BROKEN CONTRACT by NOT PROPERLY ESTIMATING THEIR TIME to begin with! You see, a good team member will find other tasks to do while waiting for other people, but they'll be hours that they've already budgeted for. Playing Solitaire doesn't count. Expect some team members to be cooling their heels while waiting for others -- it just happens.

• You must, above all things, make sure that the team understands exactly what they must do to produce their initial time estimates. They must try as hard as they can to give you as good and as realistic a time estimate as they can. That includes the manager. Include time taken to transport people, if required, to run a website and forums, to correspond, to organise, etc. Just remember, you team leaders, that this time estimate that you put in for your management duties is not flexible , just like everyone else. Make it a good estimate.

• Keep your people having fun, if you can. Most of you are hobbyists, and the moment this becomes un-fun, kill the project. It's not worth your time or pain. If, however, you're gong to be published, grind on through. Having a real game published is a real thrill, if nothing else. I'm very proud of Nova; my bits, and the wicked-sick stuff my mates did.

---

Well, that's it. Oh, one last thing: feel free to ignore anything and everything I have just said. It may not work for you. It may not apply to you. All I ask is that you bear this stuff in mind. It will help in the long run, particularly for those of you who go all the way with their projects.

The very best of luck to you all!

Dafydd "pipeline" Williams
Project lead for EV Nova
ATMOS Software Productions Pty Ltd

Wow. Thanks for the advice, Dafydd! I don't know exactly when, but I'm sure this economical business advice is going to be useful.

But come to think of it, the great thing about this advice is that it doesn't only apply to game developing. Music bands, university group projects, , every kind of team work (yes, even those that don't include money) are concerned by this.

I can relate to many points in there, and I'm sure everyone else can recall at the very least one time where a group project didn't work well enough because someone was too laxist. Heck, I'm in that situation right now, where I've done almost all the work for a seminar project, and we only have one more week, though this time, it's no more Mr Nice Guy, and Dave is just helping me confirm that change of attitude.

I therefore urge you all to read Dave's post fully, and recommend even bookmarking it or copying its contents to a place you'll remember.

This is advice for the rest of your life, how long it may be.

Cool, thanks for sharing your insight pipeline

I can certainly see how this is valuable. I've also had some trouble with a team member...

But if the contract isnt for money, they dont have any reason not to violate it, and you dont have any recourse if they do. Most of this, while sensible for most projects, isnt quite applicable to hobbyists making plugins for the glory.

I can see a contract being useful for accountabilities' sake. So everyone is totally aware, in writing, of what they are supposed to do and by when. I could of used one in a few cases.

I think this should be in the wiki..

Good advice Pipeline.

Pipeline, Thank you for all you've done for us.

Just remember this -- contracts sound terrifying. You can call them something else, if you like.

All they are is an agreement between you and the team that says "I think this work will take me 40 hours, and I can only give you 1 hour a week of my life."

If I'd have had one while working on Nova, I'd be a happier man today.

Thank you.

rmx256, on Apr 5 2005, 11:19 AM, said:

I can certainly see how this is valuable. I've also had some trouble with a team member...
View Post

The same for me. This is very useful to me.

Wiki'd.

Best advice I've heard all week.

Some of the best advice I've heard in my whole life, seriously. It can save you alot of trouble and heartache.