Hey everyone,

I've been managing a udk game project for a few months and it seems that my team has lost momentum. (Its a single map UDK demo)

I did a survey and in short the trend from the team members seemed to be 'I don't see anyone else doing anything, so I don't feel like doing anything'.

The GDD has taken a while to flush out which I can understand can take some wind out of the sails during the prepro. (I try to live by its a living document and update it daily based upon questions that need to be answered.)

I've recruited some replacements for those that seem to be uncommunicative for the past month, however I don't want to repeat the issue.

Any suggestions?
Any questions I need to be asking myself or the team?

Ok, can you make a suggestion for me to test? I'm open to anything.

I've emailed the team, keep updating our project management system with back end, recruitment updates, and tasks that have been completed/assigned. I've written out more backstory, updated the website with game dev bios, and even allowed time for a dedicated team meeting time for our international devs who seem to miss out on the domestic team meetings.

Getting the momentum up is the hardest part. One thing I had some success with was deciding on a time amount each team member was supposed to work each week (in our case 30h/week, for a hobby project it would likely be closer to maybe 5-10). We then setup a time reporting system in which members would login, enter a start and end time as well as what they worked on during that time. That way we could easily see who worked and on what, even when there were stuff that didn't give any visual indication of progress (stuff like testing or designing).

Another thing is communication. We used an internal wiki (MediaWiki) and an IRC channel with a history-keeping bot. The IRC channel/bot can help alot, if one person posts "I'm currently working on X, what do you think of this? <link>" then it often triggers responses causing other people to work as well. A Wiki on the other hand is great for storing documents and decisions. It's easy to collaborate and you get stuff like history for free which also means you can follow activity.

I assume that you have not gotten everyone in the team to sign a collaboration agreement. I hope I'm wrong there.

You are not wrong on your assumption. I inherited this project as the originator landed a job at Bethesda. It was either step up from dept lead to project lead, or let te project die. I didnt want to let a lot of man hours go for naught, so I stepped up and organized the project better and have been trying push things forward to get our demo done.

Have you talked with each member of the team to determine what his or her motivations are? Why he or she joined the team in the first place? You need to know what each member of the team hopes to get out of the project, so you can apply motivational techniques.
[/quote]
Yes and no. Yes I've asked each new member I've recruited, but no to the old members. The reason of each person varies, but in general it's to add to a portfolio or help others.

Do you have a website, a central repository of team information? Do you do regular team communications?
[/quote]
Yes and Yes.
We have weekly team meetings via TeamSpeak on Sundays and another team
Meeting on tuesdays for the international devs.
We do have a website, however each person int listed yet as they have not provided a bio. www.frakturedgames.com
It's something I'll need to followup on.

Could be difficult at this stage, especially since I guess this would be considered a 'hobby' project since no one is getting paid for the demo. Even more so difficult since we have collaborators from around the globe... (USA, Canada, England, Sweden, Bulgaria, Australia), some of which are 17, which would make the agreement unenforceable for those younger individuals in the USA..

I can setup an online form which I have everyone fill out and agree to and have them write out their initials as a signature. (or other simple identifier).

The question I have now, are you recommending it as a 'motivational' tool or a legally binding agreement to protect myself?

The question I have now, are you recommending it as a 'motivational' tool or a legally binding agreement to protect myself?

I recommend it for both reasons.


Imagine a common scenario: One person on the project leaves.

On the legal side, without a collaboration agreement in place the entire project becomes legally tainted. The person who left is still a copyright holder with full rights to everything they did; their work and everything derived from their work is still owned by them. Except now they are gone. That is a legal poison-pill for the project. One person leaves and the entire project becomes a legal black hole. You must get the rights from that person if you intend to do anything with the project.


To prevent the project from becoming legally tainted you need to go back to every person who has ever contributed to the project and get them to sign a collaboration agreement, or if they won't, at least a rights assignment. Without that in place the project is legally dead; without that I agree with Tom that you should run for the nearest exit.

That needs to be done quickly, the sooner the better.

Failing that the project becomes a legal nightmare that you can never sell, license, or even give away. The only legal option for such projects is to abandon them to the wreckage heap of failed projects.

I hate to sound negative about it, but a project without an agreement is fatally flawed from a legal standpoint.




On the management side any cohesive structure will help the team any time there is a morale hit. One person leaving can be a major morale blow and often will results in a negative ripple effect. Having an agreement will help rebound the damage faster. You can re-assure everyone that even though the person is gone the project is able to continue.

As for motivation, people change. That is a basic simple part of human nature.

When a person is no longer motivated to work on the project your best option is to make a clean and swift break. Taking to long hurts everybody, both the person who lost motivation and those who remain. Chances are good that if ties were severed with a few key people earlier-on, the project's morale would be better overall. Now you still have to sever ties with those people but additional damage has been done. Left for too long a few unmotivated people can cripple any project.

Even at big studios where people are generally happy there is still employee turnover. People lose interest and decide they would rather become teachers or botanists or screenwriters rather than make games. Presenting the fact that the person is following their passion in a positive manner is very helpful.

There should always be a private side of the break and a public side of the break. The private side is often very difficult and personal. It is unique to every individual.

The public side that the team sees, if you can do the break on positive terms it helps mitigate the ripple effect.

Examples:

"We love what Bob has done for the team, but now his life is taking a different direction. Bob, if you ever decide to come back we'd love to have you. We're sad to see you go but glad to see you following your dreams. We all want to thank you for being a part of the project."

"We're sad to see Bob go, but we're glad he gets to follow his new passion of stunt car racing! Let's give him a cheer; pass around the drinks!"


Without the collaboration agreement in place, when anybody leaves the project the entire project is instantly and automatically doomed. No amount of positive spin can change the plain and obvious fact that the project is doomed.

So get that collaboration agreement in place post-haste.