Everyone wants to make a mod. Everyone tries to get 4269 different team members for each and every little detail of their extra amazing idea. Everyone thinks their idea will become the next Counter-Strike. Everyone thinks they're going to magically create something incredible because everyone will listen to their idea.
But what about the guy who actually has some skill? Whose age that isn't a single digit? What if he has the time, the means, and the minions available to really make something epic? Perhaps he isn't really a leader. Perhaps he needs their help simply to help him move along. Perhaps he's here, at the heart of the Hive, because no one else is willing.
He is the Project Manager, and his job is a doosey.
This article is wrote based on my views as an individual. They do not represent the views of CC as a whole and should not be treated as such. This article may not be recited anywhere else, in part or in whole, without my written permission.
Your team, Your project, Your fate
Yes, Your team. They're yours. It's your project. Your responsibility. You are the project leader. You can't just flip a switch and watch the ants in your anthill mope around and suddenly get gold. No, you have to work, and you have to define what your minions are going to do.
But first thing's first. You need to assemble your team, don't you? This is of course assuming you have a bunch of people who are willing to join your project.
I am writing this article from the perspective of the way I handle things. I have found my methodology to be extremely effective and it has helped other people get their own projects off the ground and successful in the past. My methodology works in the assumption that I'll be doing a lot of the work; just as you should be for your project. If you're the kind of guy who expects everyone on your team to do your work for you, expect your project to end very quickly.
By nature, humans are lazy, unmotivated sheep. Most of the people who up at a chance to help you won't actually help you and will be totally useless, only tagging along for the vain hopes of having their name on your credits should you magically end up with something epic. Therefore, it is up to you to make a judgment of character before you choose to affiliate yourself and your hard work with someone.
Under traditional circumstances, I only allow people I know well to even help me. I don't really call these people team members; I call it ourtsourcing. Likewise, it's unnecessary for you to devote time and resources to every time and dick who shows up on your doorstep saying OMG I CAN PROGRAM AND MODEL.
To help you sort out these pleboids, I'll tell you my personal guidelines for assessing people.
- First off, their grammatical skills. Do they type like the average hamburger-eating American or are they well-composed Brits covered in tea and crumpets? Sure, the guy could be foreign and just doesn't know English; that's typically a red flag right there. If you can't understand each other very well, one barrier is in the way already.
- How active is he? How involved is he? I always talk to people on vent. I would ask someone looking to devote serious time into my project to hop onto vent and have a chat. Is he on daily, or only weekly? Does he respond often? Someone who isn't on often, or responds that much, is generally not someone you can depend on. Even if they are motivated, they cannot simply treat their position as a mere hobby they can turn to at any point or time - nothing gets done under that mindset, period. Likewise, you know you cannot approach the task of getting someone to help you out and put considerable work in your effort as a simple off-hand glance. This is quite indeed serious business.
- Have him/her present work. In the likely case you're asking someone you don't know, you should have a time where you are "interviewing" or "considering" them. Rating their activity, their skills, and overall their dedication to spending time on your project.
- Devotion. Do they enjoy the concept of your mod, or are they simply here for the pie? Someone who actually likes your concepts and ideas is far, far more likely to put time into it than someone who is just lending their talents out of boredom. Commitment over time will be tested by even the sturdiest and most devout of followers; they must be strong-willed and they must take on the challenge of time.
Pay close attention to the words they use, how they use them. As Project Leader, it is your job to decide who will benefit your project and who will simply add dead weight or complicate management. Speechcraft is an important skill, even in the fangled world of typing. Someone who doesn't put any effort into making their words sensible, ideas coherent, and suggestions logical is not likely to be of any use to you. You must think about the long-run when creating your team. You must consider who will stand with you all the way, and who could potentially kill your project by jumping ship mid-production.
Your project, Your fate
There is no kidding yourself - you will be doing most of the work. Unless you have family members or close friends who are willing to do your dirty work for you, you will be leading the project. A leader doesn't just tell people what to do, he acts as an example and a focus. He is managing, and he is moving the project forward.
When you start a project, you should have very strong skills in the game you're modding. Big teams are cumbersome and generally impossible to form much less get moving. You want to eliminate the number of people you have to depend on as much as possible, to streamline your activity and leave you with less to worry about.
Before you start assembling your team, you should have a large chunk of work already finished to prove to them that you are yourself reliable and willing to see the project to its bitter end. You cannot treat your project as a hobby that you do on week-ends; it's either a commitment or it's dust. Period.
There must be driving forces behind your project. If you're going out of your way to find people to help you, chances are it's a big undertaking - at least for you. You must ask yourself, "Is it worth it to have these guys spend their time on it? Is it worth it for me to go to the trouble of finding them in the first place?" A mod made under the premise of simply making a mod for the hell of it won't really go places. Me? I mod to bring my dreams and visions to life. Most of them have never been finished, but still managed to establish key and memorable points that I don't think my contributors have ever regretted.
Your team isn't just working for you, you're working for them.
The concept of Outsourcing, and Bearing the Burden
The truth is, I don't form teams. I outsource work. I keep the majority of my production secret and to myself, because I work under the concept that if I can't finish the project by myself then it isn't worth it to do it, because I know I'll never find someone who I can lean on through the course of the project's life. You must realize that chances are you will be faced with the prospect of going it alone.
I prefer to work alone, but I know people who I can sometimes call upon for random odd jobs. Take poiuy_qwert for example. Is he technically a team member? Not really. But he's a reliable individual I outsource renaming files to. He has a skill I lack; he can make a script to batch rename an asston of frames out of graphics I've pulled from PK in the form of gifs, making nearly SC-ready BMPS I can then process. Recently, I then forwarded these BMPS to HKS to have him resize them and give them black backgrounds. It's a relatively simple task for both of these guys, but it's more efficient for them than me and opens up my time to focus on getting those units ready to receive the graphics.
Outsourcing. These jobs I give these guys I give to them because they share my vision, they're willing to help. If someone randomly comes to me and asks me for something, I usually say, "Tough luck".
But then there's ASofT. He rigged the space terrain in ITAS for me. He needed graphics; in return, I gave him a bunch of my unused stuff for Temptation.
I feel this relationship is better than making a big team out of things. Sometimes, though, you need something a little more permanent than a few guys you can come to once every so often and throw generic, simple jobs to.
Let's say you're making a fairly big project, and you have several guys working on it. You've trimmed the fat; you've got just the guys you actually need. You're ready to start.
"Wait. How do I start!?"
Humble beginnings, setting the foundation for the future
As project leader, it is automatically resolved to you to manage the flow and flux of data. You need to keep your little workers busy and working efficiently, but you also need to manage their data. They may be fairly organized themselves, but ultimately this is a tree, and you're the center of it all - it's you who needs to eventually compile everything into working order.
Back when HKS was more seriously modding, like in MFTGATRL, I kept the main data files and I added things he created myself. We communicated literally minutely on what we were doing and we usually worked daily. Quick, efficient, and impossible to screw up. We simply used aim and, later on, Ventrilo as our means of communications. In a larger team, it is necessary to communicate often and in real-time - it is necessary to regularly contact each other via AIM, but vent is preferable because it lets your voice physically be heard.
LoL, my AoS, was a more challenging project to manage because I had several guys working on it.
WarGiant remade the terrain.
I had two triggerers; Xenon, Tipereth
Sometimes Mucky or even Bill would jump in and do stuff.
HKS would sometimes make graphic conversions and icons and stuff.
I acted as the focus. When I transferred the map to someone for them to do major changes, I halted everything else until I got it back. This was a bit cumbersome and kind of gay because both the guys who triggered stuff were slow. It was often my responsibility to work what they created on alternate maps into LoL itself, and then work with them in fixing the retarded amount of issues that would arise. As a relatively inexperienced triggerer, this was challenging, but I forced myself into doing it and learning intermediate and advanced triggering methods so I could keep the project going.
Every project will change you, no matter how small or how big. You'll always learn something new, usually because you have to.
You must always keep tabs on what everyone is doing. I had a forum thread for this, and I communicated regularly with the members. Under ideal situations I'd organize a neat, tidy forum for people to post major contributions on.
This is where your skills in leadership will be truly forged.
You, the Arbiter
As Project Leader, you are as much a book keeper, example, and piloting force as you are simply a leader. Therefore, you ultimately must pronounce yourself the absolute force and make decisions. I've been in teams that have done this and teams that have done the whole "let's poll the most minor decision". Sometimes it's beneficial to get everyone's opinion on major works, but often you need to man up and say "No, I don't like this" or "Yes, this is what we'll do".
You have to make arbitrary decisions in such matters, and relatively quickly, for the project to succeed. Decision-making processes are slow and timeconsuming and ultimately cost you production time and even motivation. This comes in many walks of life, including website management, moderation, actual game development, ect.
You're the boss; act like it.
Me? Since I outsource most of my work, I keep my major decisions to myself. Sometimes I ask for opinions, but it's ultimately my decisions and I do what I desire. In times I've worked with more people, I take their suggestions into account, but I largely act as the impounding force and what I say happens, period.
It is necessary to be the force that weaves the team and their work through rough waters, because that is quite simply what a leader does. If your project's leadership is weak, team members begin to fray, they can even conflict with each other (Been down that road a few times... always entertaining), and it is hard to get back on track.
Remember these words when faced with large decisions: It is your project.
Dealing with drama
In big projects and teams you end up with people from all walks of life. Some know each other, some don't. In the odd case your team members may come at odds with each other or even you.
I treat drama and conflicts with complete and total strictness, and I advise everyone else to do the same.
Drama can be associated with decision making, work ethics, or anything like that. It's most likely to happen in a project with very weak leadership or a project that lacks a true driving force to it. If you are the Zen, the focus of your hive, and your goal strong, you should never encounter any kind of problems.
But let's say you do. Let's say a certain circumstance appears.
I treat problems in which team members act immaturely or behave inappropriately very harshly. In my world, if someone wants to cause trouble, they're out. Period. They can pack up and leave if they want to start shit - or I'll kick them out myself. Do not allow problems to fester in the vain hope they'll solve themselves; they won't, and even if they do, the feelings will remain and brood over time. Stop it when you see it and solve it immediately.
I do not allow personal feelings or conflicts between people to emerge into work ethics, although I can't say I've dealt with it in a project I've personally lead (except for Tipereth making horribly imbalanced heroes in LoL; that was solved rather easily by telling him to simply fix them, which he did so over time), I have been dragged into the crossfire of other projects. I won't name them out, but some of these problems included members who previously acted stupidly/were kicked out wanting back in, members having inappropriate attitudes, people who otherwise are capable of great deeds but are very lazy/unresponsive, ect.
My answer to these subjects is usually to kick them out and don't look back. You can't afford to waste time on little children who act like morons or are too lazy/unmotivated to do anything. Thank them for their time, ask them to shape up or ship out.
This doesn't necessarily mean you should act like a douchebag. It's one of the things my methodology of "Outsourcing" allows me to completely and totally avoid, but I find myself perfectly capable of acting as diplomacy in times of need. If you keep a cool head then you can use logic and common sense to flow through your words and actions. Allowing personal feelings or judgemental impulses to cloud your judgment will hurt your entire team and serve to destroy the project in the end.
Your project is serious business, it's not a fucking playground. Yes, these people are trying to help you, but if they're serving only to hurt you, it's time to make the cut and move on.
I don't set deadlines, personally. When I outsource oddjobs to people, I generally say, "Do it when you have time." Because I know the guys I'm asking this of, I know they're busy, and that they'll get to it when they can, and they generally do. For other people, I say, "As soon as possible."
Previous to LoL, literally every single wc3 project I started I sought outside help for. Yes, the Blizzard community. Full of retards and little kids, this cesspool of brain damage was my only hope.
Many people said they'd help me. Not just anyone, but big shots, including Alfred, one of the more notable modelers. They were all fucking useless. They'd claim to be of help, then they vanished without a trace when given something to do. I learned important lessons from them, though. I learned I could not entrust key work to just anyone, and that in general people are unreliable.
It's a harsh reality.
When working with people you can trust, it's generally a bad idea to make hard-set deadlines because it puts psychological pressure on them and creates stress. Psychological pressure can hurt your project and its team members because stress is a meaty killer of production. I set personal deadlines for myself all the time and consistently fail to reach them.
It's nice to meet your deadline, but you often find yourself cutting corners to reach it. Cutting corners is bad. You're not a company; there isn't some cock-hungry publisher down your throat forcing you to do make a deadline.
I can summarize this part up quite well - Don't release an incomplete project ever. No demos. Nothing. Just the final product.
Demos kill your project.
No doubt that during the stretch of your project you've developed some degree of hype and interest. Demos act as a kind of opening a floodgate and dissipate this interest. Suddenly they have your project and it's not all they expected it to be; it's just a demo, after all. Some will want more, most will kind of mill around like lost puppies and eventually dissipate.
It's in the best interests of you and your team to release something they feel is finished, polished, and ready. This may entail a long production life, but consider that every bit of work is more then what would have been in your demo. A demo doesn't do much for you; people tell you about bugs you already know about, maybe you get some random suggestions, but ultimately at the cost of the final release.
I could go into more reasons why it's unnecessary to release demos, but in short, if you want your final release to really carry weight and really deliver a sense of accomplishment.
There is a difference between a demo and a proof of concept, however. But I'll leave that in your hands to decide whether or not to make such decisions; you're the leader, after all.
Sometimes when big projects reach a certain point, the Leader decides he doesn't want to release a demo. He does, however, want to make sure everything works and wants to stress test his work.
Beta testing is a double-edged sword and could potentially spell disaster in the form of a leak. You need to be just as devout and careful in selecting your testers as you do your team members. Furthermore, you might be inclined to harvest an army of testers, but it's unlikely you need a hundred random fools from some other forum you visit to be testers. In most cases, you can deal with just a handful of fellas.
There's another part, too.
What's the point in having a tester if he doesn't give good feedback?
You need a process of screening the useless guys who just want a peek inside your mod from the guys who will pour their heart into writing an essay for you on why the Wraith MK II is an overpowered piece of shit. Something I would do is have the testers write a significantly large PM on why they feel they should be testers and what they have to contribute to the testing process. Then you will judge their words and their motives on a personal level.
It's a time-consuming and arduous process, but if you can get some really useful testers out of it, then your needs are met and everyone is happy.
Me? Personally I play my mods so much that I generally don't have test-phases. I create custom AI to help me balance stuff and it has yet to fail me. In the off times I needed a more larger-scale romp, I assembled the fellows who helped me actually create the mod. For LoL, it was being built for SS by the majority of its members; I released it to them every week in the form of updates. It was a private project for SS, after all.
Hope this helps some of you fledgling forgers out there who asked how I do things.
The source for all things IskatuMesk and then some. From projects, to articles, and even Let's Plays- it's all here for the taking.
1 post • Page 1 of 1
- Xel'naga World Shaper
- Posts: 8962
- Joined: Sat Feb 07, 2009 1:40 pm
- Location: M͈̙̞͍͞ͅE̹H̨͇̰͈͕͇̫Ì̩̳CO̼̩̤͖͘ జ్ఞా
- Status: Offline
Who is online
Users browsing this forum: No registered users and 2 guests