“When I started writing software on the side for fun, it never really crossed my mind that I would be able to to support myself and do it full time. Of course, the dream was there in the back of my head, but I didn’t think it was actually attainable. I figured my best bet was to become a good enough programmer to work for a decent mac company some day…”
Indie project management shares many features with traditional project management:
Communication with team members is paramount. They need to know what you expect them to be working on, when to get it done, and so on. And you need to know how far along they are, what resources they need, et cetera.
You need a plan, or what the Bush administration likes to call a “roadmap”. As the old saying goes, “If you don’t know where you’re going, how will you know when you get there?” More practically, with a plan/”roadmap” you can make sure everyone on the team is working towards the same goal.
And so on.
But indie project management contains a few wrinkles of its own. Here are some tips from my own experience (both previous and painfully recent).
1. Don’t get lost in the trees.
When you’re the project manager (PM) for an indie project you’re almost always wearing the PM hat on top of some other chapeau, like “lead programmer” or “art director”. And, if you’re like me, this is the hat you actually like to wear. You enjoy programming in all its tedious bit-shifty-ness (including the parts that drive the rest of humanity insane). Given your “druthers”, you’d be doing this all the time.
As you wander about the trees of detail, though, having fun polishing the leaves and rearranging the twigs, its easy to forget that you were supposed to keeping an eye on the whole forest. Your little section of the forest might be looking pretty spiffy, but if you’ve been ignoring the rest of it, you could find yourself stranded in Mirkwood or Garroting Deep.
Team members are expected to maintain razor sharp focus on their particular task. Team leaders, however, have to maintain a much greater depth of field, seeing the entire project, each team member and their tasks, and the overall level of progress.
Lead by example, of course, but never forget that you are leading.
2. Don’t assume perfect communication.
When you’re the only team member, as well as the PM, you can assume that you understood exactly what it is you wanted you to be doing. When you’re communicating with another human being (or elf or gray alien), though, you need to solicit feedback so you can confirm that what you said is what they heard and understood.
This is particularly important with virtual teams. Email and IM are incredible communication tools, but they miss out on the inflection of voice and lack the benefits of hand-waving. You need to be clear, and you need to test the echoes you get back, looking for resonance and agreement.
The trick is doing this in a way that doesn’t annoy the other person.
3. Don’t be afraid to manage.
I don’t care if you’d rather not be a manager. If you have a team, you have to manage that team. There are very few “fire and forget” teams, and it’s highly unlikely that you have assembled one of them.
Even the most “on board”, “signed up”, “personally invested” team member is looking to you to provide direction. If you don’t tell them what to do, they are reduced to guessing what it is you want. Or, more likely, just waiting on you. Eventually, though, they’ll get tired of waiting and they’ll hand back their boarding pass and move on to something more interesting.
In other words: Your team wants you to manage them. If you don’t, you’re letting them down, and almost certainly dooming the project as a whole.
Indie project management is a challenge. You’re underfunded, understaffed, and trying to get the best possible result from the least possible resources. By creating teams of like-minded individuals, we can achieve more than any of us could by ourselves. But every team needs a leader.
Thomas Warfield over at A Shareware Life posts his answers to questions about his business:
“I received an email with a ton of questions in it and rather than spending a lot of time answering the email, I thought I would post the answers here so that everyone can receive the wisdom of my sage advice.”
I particularly liked this one (email question in italics):
Q. How much money do you put into a game on average and how much do you get out of it on average?
A. Averages are for wusses. If you do it yourself, a game can be very cheap. If you pay someone to program it, any reasonable game is going to cost thousands or tens of thousands of dollars to develop. If you sell it long enough, any game is going to eventually make that back. Good ones will make it back faster.
And this one:
Q. Do you try to implement or fix things that players point out to you or once the game is done, it’s done?
A game is never done. I’m still finding and fixing bugs from 1996.
Arthur Goikhman of Cellufun told me this recently:
“We started getting lots of downloads from China and Singapore, and weren’t sure why — and then someone realized next year is the year of the dog — and they are downloading MobilePet. ”
With this Amazing Casual Game Design Tip, you can plot out your business plan for the next 12 years, and be assured of repeat business in the next 12 years. At least in Asia.
Sorta.
A Bonus Tip: Stepping “Off Deck” to Sell Your Games to Cellphone Users
I talked to Arthur Goikhman, a Managing Director of Cellufun, last week, and he also described how Cellufun is adopting a shareware-like approach to selling games for cellphones.
The market for games on cellphones has become a multi-layered, profit-sucking behemoth, with more layers of separation between the developers and the players than even the retail game market. With multiple publishers and distributors controlling access to the aggregators who, in turn, control access to the carriers who ultimately provide the games to the players, and with each layer working to peel off as much the profit as it can, the retail space looks almost simple–and wide open–and profitable–in comparison.
Cellufun hopes to carve out a niche for themselves in the cellphone market by leveraging new cellphone features and indie-style marketing techniques to bust the market wide open.
The two keys to Cellfun’s approach are:
Marketing directly to cellphone users (going “off deck”).
Utilizing a free-to-play option to draw in new players.
The first key comes as cellphones become ever more powerful and offer access to the Web, including downloads from the Web. This new feature loosens the stranglehold the carriers have had on access to cellphone users. Before cellphone users had Web access, they were limited to only those games the carriers made available. Now, though, they can go around the carriers and access just about any Web-based content they want. And that includes games.
The second key is the tried-and-true indie/shareware approach of allowing the players to try the game before they buy it. Cellufun’s games can be downloaded and played free for as long as the player wants. In the near future Cellufun will begin charging for multiplayer features (for community and competition), continuing content (in the form of new puzzles and levels), and so on. They will continue to offer the basic games for free, though, with no time limits.
The Big Question, of course,is: Will it work? Will enough players opt to pay for the additional features and content to generate a profit? That remains to be seen. The company won’t start charging until early in 2006. So far, though, they have achieved over 1000 downloads per day of their games, including the mentioned Chinese downloads, with no direct advertising, attracting new players through word of mouth and Web presence.
If you’ve wanted to make games for cellphones, but been stymied by the many barriers to entry, now might be a good time to reconsider.
“…from Seoul to San Francisco, affluent online gamers who lack the time and patience to work their way up to the higher levels of gamedom are willing to pay the young Chinese here to play the early rounds for them.”
1. Put the software controls/commands where you think they belong. (You gotta start somewhere.)
2. When a user/player tells you they were looking for a command/control somewhere else, put it there too.
3. Repeat #2 as necessary.
This simple, three-step process means that you, alone, cannot create intuitive software. You have to involve your users/players.
On the other hand, after a few iterations, you’ll start hearing from users/players who are thrilled that you built exactly the right software, precisely the right way. And I can assure you: Those are cool emails to get.
I don’t want to hear any arguments about how hierarchically organized everything is in your software, how logically structured. If the users/players couldn’t find it, whatever “it” is, it might as well have not been there at all.
Intuitive software isn’t about educating the user/player to your software’s representation of the One True Way of thinking. Instead, intuitive software is about anticipating what the user/player is going to look for, and have it sitting there, waiting for them.
Fortunately, you don’t need a crystal ball to anticipate your users/players. All you have to do is pay attention to them. They’ll love you for it. And so will the new users/players, who find that your software “just fits”.
”
