The problem is quite simple. There is a game concept that you are making into a fully fledged game, but you don't believe you have all the necessary skills to do the job. For a lot of BYOND projects this problem will crop up at times. Perhaps it's for little tasks you will outsource to people, or it's a longer term set of work that you will partner with someone for. Stephen001 discusses the role of project manager, from industrial experience, and some basics everyone can benefit from.
What is a project manager? Well, isn't that a question! Any basic definition I could offer would probably be misleading, so I'll change the question a little. What is a good project manager?
A good project manager has a bunch of qualities. They are someone who knows and can tell you what you need to do, without telling you how to do it. In my experience, I've suffered from two failings with project managers, that have made my life as a programmer difficult. Either the project manager wants to tell me how to do my job without telling me what I'm doing, or the project manager makes a vague statement and expects me to fill in all the rest, which happens to include what he wants in detail.
What you essentially have is a working relationship. You build up trust that they can do the job you need them doing through seeing previous work, small (paid) tasks and progressing onto the meat of the work you need doing. They also of course build up trust that you will pay them, that you have reasonable requests, that you are not overbearing or too vague and so on.
It is important to understand that both sides can just as easily "fire" the other if something in this relationship is not going correctly. In fact we see this quite regularly on BYOND when an artist, or a programmer, decides to leave a project or just stop working for a project properly and cites they "can't be bothered". That is a sign that something is wrong, and it's probably wrong with the project management. A good project manager understands this relationship.
A good project manager in my experience also has some knowledge of the area they are looking to employ people in. This doesn't mean particularly that you need to be able to do every job you'd consider hiring someone for. Obviously if that were the case, you wouldn't be hiring. But you do require some experience and knowledge in that area. This helps you be clear about your needs, and answer the other person's questions.
Lastly, and this I think is very underestimated on BYOND: A good project manager is just like you. F0lak probably doesn't get the pleasant communuity contributions he does on Hazordhu II because he's the big boss man, arrogant master of all he surveys. I know him to be a pretty down to earth guy, happy to have a laugh, happy to admit he doesn't know everything and a lot of the time he probably isn't right, and I know he works hard on what he does.
When someone is solid like that, and is very straight-forward and decent to you, you naturally pay the same in kind. I expect that if he hired me for something, we'd have a great working relationship and make some really cool stuff. You don't make cool stuff for "big tough hard boss" types, or people who appear to put in no considered, planned effort on their end. Your attitude is vital to the success of your project.
A good project manager is just that, a good attitude, good planning, and good reasoning. They are no more "the boss" than their team allows. Take that with you when you need to outsource some art/music/programming, or maybe even build a partnership for your game.
Aug 31 2011, 12:19 pm
|
|
D4RK3 54B3R
 |
I feel like this article couldn't have come at a better time. There are a number of large undertakings that could benefit from this.
|
Thus summing up in one post one of the key reasons why most BYOND projects fail, go wrong or are ignored.
A lot of them are good ideas, really badly executed by people who perhaps have a lot of passion, but not the first idea what to do. | |
I think it can be tough for a number of reasons.
- Internet relations can be challenging. No face to face time to help establish trust. - No compensation can lead to no motivation pretty quickly even if your dealing with a decent PM on a complex project. - PMs tend to multi-role which means they are a dev trying to PM. This is pretty much an instant failure unless you have tight connections with those your working with. - Projects can get complex fast. Having to hold peoples hands through technical tasks is actually something interesting now that I think of it. Do you spend PM time helping them learn the task. Do you take over as dev and hash out the design for them? Will you spend task after task with this person or should you realize the gap early on and cut them loose (nicely). I used to think of PM's as a bunch car salesman with college degrees. In my past, I knew many to just wave their hands around and refer to the dev for all else. In recent years, I've come across a few top notch PM's and these are their attributes. The first two are key and drive other good behavior. - Top notch domain knowledge and/or an impressive ability to gain that knowledge in a short amount of time. - Extreme passion for the domain. PMing "this" project is a stepping stone in my career to make big advances in this domain. - Chatter boxes and smooth talkers. Some of the duds can be smooth talkers but the duds tend to have more quirks which make them stand out more. - Likes to be hands on with the developers every step of the way. The ones that let the devs design it in full and then step in to review, are usually the half-assers that let products go out the door half baked. Agile practices are "fixing" this for PMs whether they want to or not. - All the good PMs I've known, tend to contribute in other areas after their spec work is done. They find those "extra" neat tasks which enhance the product from some perspective such as the customers, sales, test, and etc. Often times, the good ones create kick ass demos of their feature area that blows away audiences. The duds just try to pretend like their investigating some edge case or future direction when in reality, their doing nothing. They leave the demo's up to the devs and testers. Anyway, that's about all I can contribute. I've been dabbling towards project management and management in general both in my career and in my hobby projects and it's certainly a challenge for me. The one weakness I have is socialism. I'm not a quick and/or smooth talker and I don't laugh at peoples lame jokes. This sort of small-talk behavior seems to be a requirement of being an effective leader. I've been reading a book on Branding yourself and its recommending to call out your weaknesses and your strengths and then decide if the weaknesses are blocking or delaying you from being what you want to be. Do you need to address those weaknesses or can you utilize and focus on your strengths to compensate for those weaknesses. Over compensation tends to result other areas being totally neglected which can quickly become a problem. I thought that was an interesting exercise and I plan to do it over the next couple of days. Nice read. ts | |
I've tried to manage a team before. never works for me since I end up doing all the work. So I gave up on that, I'm no good at being a manager, I try to do more work instead of coordinate.
Alternately, if the manager doesn't tell people what to do, nothing ever gets done. I'm glad my current team lead is capable of managing well. | |
Another thing we learned about leaders and managers is that there are certain types of people that need to be treated a certain way.
I can't remember all of them, but there was a type of people that could give you spur of the moment ideas and usually just "jump in" to whatever task they have. Then you had the type that were thinkers - after they got the idea or task, they would take their time to balance and get everything to work the way it should. There were also some people that worked better after recognition for their work - things like "Good job" may not mean much to someone like me, but for some it's important that they hear that. I tried to Google search it but couldn't find it, but the point is you shouldn't go to the guy on your team who just whips up ideas for new characters for input on how to balance everything in the game out as opposed to the person you've identified as the thinker. And you should pay attention to those that need a lot of verbal motivation and those who don't need to hear "Keep up the awesome work" every time they complete a task. This is probably only relevant though in large teams. If it's only you and maybe 1 or 2 other people, you don't have to worry about dealing with a lot of different personalities. | |
It is relevant, interestingly, in one or two people teams. It comes back to the manager-engineer relationship that has been discussed in both the post and comments. Knowing the other person's preferred way of working is fairly key to managing them well.
| |
Stephen001 wrote:
It is relevant, interestingly, in one or two people teams. It comes back to the manager-engineer relationship that has been discussed in both the post and comments. Knowing the other person's preferred way of working is fairly key to managing them well. I meant relevant as in having to deal with a lot of personalities. If its only one or two people, thats only 1 or 2 personalities unless of course you've employed two bipolar people. Then the number may vary. =/ | |
Heheh, I wonder. That must be a remarkably tricky situation to manage at times. Thanks for your input on personalities in management, it adds another important dynamic to this.
| |
You make a lot of interesting points, ts. The best manager I've had used to be a software developer himself in a variety of companies over a 10 year period, so it's fair to say that he could definitely "do my job" if he needed, although obviously not to the standard I could.
That understanding was very important though, it gave us a good focus on quality and a good understanding if things slipped. Importantly, when they did slip behind schedule, he made a plan for either correcting it, or making sure it wasn't a problem. | |