Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 21, 2014
arrowPress Releases
October 21, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Managing a (Virtual) Game Project
by Randell Trulson on 02/19/13 06:05:00 am   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

Project Management
Having spent years as a developer on an array of software genres from device drivers, applications, weapons software to game engines, I have seen my share of success and failures.  One of the most important lessons I have taken away from all of this is that a projects success or failure is directly dependant on its preparation and management.  I have witnessed many great software ideas get canceled and I have seen really super stupid projects make it all the way out the door all as a direct result of project management.


Virtual Project Management
If you were a developer in the late 90’s and early 00’s working from home wasn’t really practical because of internet speeds at the time.  Even now, there really aren’t any set rules for managing virtual projects that I am aware of.


My Tips on Managing a Virtual Project

Trustworthy People – There are two types of people; those that can work on their own and those that need direct supervision.  It has been my experience that some people simply won’t work unless someone is physically present.  (I call this the, “Out of sight out of mind syndrome.”)

They don’t have the discipline.  These types will spend the majority of their day playing games and watching TV.

You can tell these types when you get them because they will be very vague about what they have completed.  You can ask to see their progress and they will get defensive or tell you they don’t want you to see it until they are further along.  This happens a lot when people start game companies with friends.  Everyone thinks it is easy and fun to make games, and then find that it is a hell of a lot of work and so they stop performing (or never start).There is only one solution to this problem and I have come across it many times; fire them.  There is no work around, no meeting after meeting to get them to improve in the future….just fire them.  Even if it is a volunteer, if they are holding back the project they jeopardize your success.

I have found that if you are working on a team of volunteers for a project, you can simply exclude the loser from all further development and the problem is fixed and will take care of itself.  They quit and make it look like it was their idea.

You have to find people that want to work because they too want to see the project succeed as much as you do.  These people will work on things without being asked or told.  If you don’t have good people, the rest of these tips are useless.

Good Communication – This kind of goes with having good people.  Make sure everyone can reach everyone at all times.  There are lots of times where someone will need a particular asset from another person on the team in short order.  Make sure everyone has up to date information on how to reach each other.  If someone is going away make sure they tell everyone.  Then have that person get anything done that needs to be before they are unavailable.

Also make sure you use a project tracking system where everyone can see what everyone else is working on, what is already done, and what needs to be done.  I will tell you how to set this up below for next to nothing.

Rule of scheduling – I don’t believe people should have to come in on weekends or work 90 hours a week on anything unless they love it that much.  If people have to work like that to play “catch-up” it is the fault of bad project planning, not the people.  Every developer I have ever met (including myself) thinks they can get things done faster than reality dictates.  So here is my 2X + 20 rule.  Whatever amount of time someone says they can do something in, take that amount of time multiply it by 2 and add 20%.  That will give you the realistic time period it will require. Put that on your Gant chart and that will tell you when the game will be done.

Use Time Boxing – When working from home it is hard to start working some times, and hard to stop working other times.  Working from home also makes it difficult to gage how long something takes because each work day varies.  We use a time boxing technique called Pomodoro.  If you do 12-16 pomodoro timers, you do 6-8 solid none interrupted hours of work.  This ends up being about 2-3 days in an office full of distractions.  There are tons of free pomodoro timers out there.

Virtual Tracking – Virtually tracking a project is hard enough, but to do it on a shoe string budget is even harder.  Here is a super cheap way of doing it.  You need Microsoft Office suite for this.

1. Setup Dropbox for the team to use.  You don’t have to use it for sensitive stuff if you are concerned about that.  Just for tracking stuff.  www.dropbox.com

2. Have everyone install MS OneNote….I know you don’t want to use SharePoint because it costs and you are on a shoe string.  LifeHacker has you all fixed up.  Go here to see how to do it OneNote with Dropbox

3. Then you can use MS Visio if you have it or some other similar package to make task charts (sorta flow charts of what needs to be done).  Big charts with major components of your game that needs to be completed and completed tasks checked off and grayed out.  Only one person should be the keeper of these, like a configuration manager.  This will be the project manager, scrum master or whatever.  Like this!





That way everyone can see at a glance what needs to be completed.  Then at the end of the project there isn’t any, “Oh my god!  I forgot we still have to do XYZ!  So glad I caught that.”

4. If you have a really big project, get source control.  You can get evaluation versions of Perforce for free, an excellent version control package, for up to 20 developers with 20 projects and creatively hook it up to your Dropbox.

That is really about all you need to do to seriously manage a huge virtually developed game successfully.


You can read more and follow me and Neuron Games, Inc. here:


Related Jobs

Crystal Dynamics
Crystal Dynamics — Redwood City, California, United States
[10.21.14]

Audio Lead
Filament Games LLC
Filament Games LLC — Madison, Wisconsin, United States
[10.20.14]

Quality Assurance Associate
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany
[10.20.14]

Team Lead Online Marketing - TV (m/f)
Yoh
Yoh — Vancouver, British Columbia, Canada
[10.17.14]

Build & Test Engineer






Comments


Xavier Moore
profile image
We use a combination of Unfuddled, OpenOffice, and MS SkyDrive.

TC Weidner
profile image
agree with most of what you say especially about the people and communication. As for the hours things, I dont necessarily agree. Production is all that matters and to be honest some weeks some people have it easier than others, others weeks its reversed, as long as everyone is motivated, and is getting quality work done when asked, I dont care how many hours it took them and when. Its all about quality, production, and timeliness.

Randell Trulson
profile image
@Xavier - Interesting...I've never had much luck with OpenOffice though :(

@TC - Everyone has there own style. It is just important to have a system that works for you. The way we do things does two things for us. Gives people a fair schedule load, and because we track the number of pomodoros needed per task it is much easier to calculate time on the next project. There are half a dozen good ways to do it. As long as everyone is happy and in the groove and making super awesome games :D

Abel Bascunana Pons
profile image
Interesting article, many thanks Randell. I'm also working on a somehow complex game project where everybody works from their homes. We've been developing for 10 months + 2 preplanning ones. We use a mix of Assembla, Trello and Google Docs. I also use Onenote but actually only to organize all text areas of the game.
I won't post the link here but if you check a blog entry I wrote titled "A Decalogue + 2 for prospect indie devs", I was also addressing issues with management on a virtual work environment. I hope some of the points can also help someone!

Thibault Jochem
profile image
For the source control, why not using free opensource ones with no limitation ? Git repositories managed by gitolite does the work, and just need a linux box to host it !

Randell Trulson
profile image
@Abel - Thanks I will check out the blog. We mainly use OneNote for mile high views of things, it can get trying when using it through dropbox sometimes, but it beat paying for SharePoint :)

@Thibault - PerForce is one of the best in the biz. I am used to using them from working in the Semi-conductor sector. Not to mention that it is free for 20 people on 20 projects. We have never needed more than 20 people at a time to access version control so it isn't a problem. Not to mention we have never had more than 20 ongoing projects at a time (or even 10 or 5 :P )

Aaron Molenaur
profile image
Agree with your comments about people. Good people is definitely the cornerstone of any project; without them your project will never get anywhere. Sometimes you need to find the right place for that "loser" instead of just firing them. Often times, what a contributor's best fit is, is not necessarily where they might feel it is. A good project manager/leader will take the time to find the best fit for their team. If the person ends up a loser, then yes, get rid of them.

Finding the best fit for contributors is even more important with online volunteer projects. People volunteer because they are passionate about your project (for whatever reason), so you want to keep them around to perform the most good and contribute the most IP they can. I have had success in finding other positions, still within the team, for those people. Their productivity skyrockets, team morale gets a boost, and everyone wins.

Good communication is the key. Skype, Murmer, IRC, chat, email, etc. Team members need to be available as much as they can, whenever they can. My last project i ran had team members spread across 12 different timezones. Bi-weekly meetings (a meeting every 2 weeks) for full staff were required. It kept everyone in the loop, forced people to communicate, kept everyone on track, and let everyone know where things stood.

Additionally, I made sure each sub-team had (at least) weekly team meetings. And as project manager I attended every one, usually just to sit in and listen. That way I was always up to speed on every aspect of the project, and was able to answer questions sub-teams had. It was very rare that I contributed to those meetings, but having the project manager's presence helped instill confidence in sub-teams.

As for schedule, keeping that is the hardest part. Whatever method you use, expect your first few iterations to be very unproductive until each person finds their stride and meshes with the other members of the team. I used monthly iterations and a (mostly) Agile style for my programming teams, but my content teams used more of a waterfall method per story/idea implementation. Team leaders were free to tweak as needed. Once everyone learned how to interact with their teams, iteration estimates became better. The "2x + 20%" estimating rule is a standard one for any programmer. Use it. I also utilized monthly "status reports" broken down by each sub-team. It helped cross-team knowledge and let everyone know roughly where each team was at. I made these publicly available to the community which let everyone know what was going on internally to the project. I found it helped deter a lot of repeat "are we there yet" type questions.


none
 
Comment: