Project Management noob
I have a project I am working on "for fun".
It is a game.
I have about 3 or 4 people who are collaborating with me, who are demonstrating real interest and passion for the project.
Currently we are in the "design" phase.
Now, there is a lot of discussion going on, but no concensus and no decisions being reached.
In several of these areas, the experience of those involved far outstrips my own experience. So I cannot tell those involved in the discussion which course of action to take. I'm just not qualified to do it. This is good because you want smart people working on the different aspects....smarter than you if you can find them. Or so I have heard. :)
So my question is...how do I focus the discussion a bit more than I have been?
How do I focus the discussion so that we start heading towards an eventual FIRM decision -- vs endless (albeit interesting and fun) debate?
Thanks,
Tom
No need to come to a firm decision. Have everyone break off and spend the next 1-3 weeks prototyping their ideas (in flash, C++, board game, whatever is their personal forte). Re-convene at the end of the pre-determined timeframe and evaluate the prototypes as a group. Did they each work? what are the flaws, etc.
-me
-me
Honestly just go for it! Obviously you do need to have some direction. But it really motivates you once you start actually working on the game and seeing your ideas come to life. There is no need for an extremely complexed design, especially when you are an independent developer. Because chances are you aren't going to get rich off it anyway. But who knows. Just get a general idea and start doing it!
Two things:
1) Are these questions of the "Lets make a FPS? ... No i want an RTS?" style? Or more a "Health packs should give you 100health! Nah thats too much, try 90hp!" type? The first type need to be solved now, the 2nd type need to be solved later! So if you know your making a FPS, and you know generally what the final game will play like then by all means start coding. If you still in the "FPS vs RTS" stage, then solve that now :P
2) Even if you do actually start making things now at some point you will need to end up agree'ing on the aspects of the game. When that happens the best way todo it is to get a list of questions, and then ask your team to get them answered by the end of the meeting, day, week! If your face to face its easier as you can just go down the list and write your answers on the spot. If you think up any new questions along the way just add them to the list. This is the best way I've ever found for directing discussion and finalising things - even if you yourself don't activly participate in the discussion. Ask the questions and get a definite answer. The answer might change in 2 weeks, but thats fine at least you've got something to aim at, even if your target moves every so often!
1) Are these questions of the "Lets make a FPS? ... No i want an RTS?" style? Or more a "Health packs should give you 100health! Nah thats too much, try 90hp!" type? The first type need to be solved now, the 2nd type need to be solved later! So if you know your making a FPS, and you know generally what the final game will play like then by all means start coding. If you still in the "FPS vs RTS" stage, then solve that now :P
2) Even if you do actually start making things now at some point you will need to end up agree'ing on the aspects of the game. When that happens the best way todo it is to get a list of questions, and then ask your team to get them answered by the end of the meeting, day, week! If your face to face its easier as you can just go down the list and write your answers on the spot. If you think up any new questions along the way just add them to the list. This is the best way I've ever found for directing discussion and finalising things - even if you yourself don't activly participate in the discussion. Ask the questions and get a definite answer. The answer might change in 2 weeks, but thats fine at least you've got something to aim at, even if your target moves every so often!
Quote:Original post by kaysik
Two things:
1) Are these questions of the "Lets make a FPS? ... No i want an RTS?" style? Or more a "Health packs should give you 100health! Nah thats too much, try 90hp!" type? The first type need to be solved now, the 2nd type need to be solved later! So if you know your making a FPS, and you know generally what the final game will play like then by all means start coding. If you still in the "FPS vs RTS" stage, then solve that now :P
2) Even if you do actually start making things now at some point you will need to end up agree'ing on the aspects of the game. When that happens the best way todo it is to get a list of questions, and then ask your team to get them answered by the end of the meeting, day, week! If your face to face its easier as you can just go down the list and write your answers on the spot. If you think up any new questions along the way just add them to the list. This is the best way I've ever found for directing discussion and finalising things - even if you yourself don't activly participate in the discussion. Ask the questions and get a definite answer. The answer might change in 2 weeks, but thats fine at least you've got something to aim at, even if your target moves every so often!
The questions are concerning design of the game. The game is a 2D board game. The game pieces have been decided. The rules are decided.
The problem is with, for example, TCP/IP vs UDP (just as an example). Team members will discuss the virtues of both, but fail to come to a decision. Each says their peace...but then ?????
Tom wrote:
>The questions are concerning design of the game.
No, they're not.
>The game is a 2D board game. The game pieces have been decided. The rules are decided.
Then the game design is not the issue. The game design is decided.
>The problem is with, for example, TCP/IP vs UDP (just as an example).
Then the problem is which technology solutions to use. (Not game design.)
>Team members will discuss the virtues of both, but fail to come to a decision. Each says their peace...but then ?????
Either the leader of the group will be you or it will be someone else. If it will be you, go to the business section of the bookstore and see what they have on group decision-making. Your project could well end here, if nobody steps up to the plate and facilitates the decision-making.
>The questions are concerning design of the game.
No, they're not.
>The game is a 2D board game. The game pieces have been decided. The rules are decided.
Then the game design is not the issue. The game design is decided.
>The problem is with, for example, TCP/IP vs UDP (just as an example).
Then the problem is which technology solutions to use. (Not game design.)
>Team members will discuss the virtues of both, but fail to come to a decision. Each says their peace...but then ?????
Either the leader of the group will be you or it will be someone else. If it will be you, go to the business section of the bookstore and see what they have on group decision-making. Your project could well end here, if nobody steps up to the plate and facilitates the decision-making.
Original post by tsloperQuote:Tom Knowlton
>The problem is with, for example, TCP/IP vs UDP (just as an example).
Then the problem is which technology solutions to use. (Not game design.)
For once I will disagree with Tom. The problem isn't a technology one it is a management one. You know what the options are for technology (so that isn't a problem) - you just don't have a management process in place to make a decision.
You need to talk with the team about the aims of the project. I would assume that the primary aim is to make something (rather than just talk). If that is the case then development must be done and for that to happen decisions need to be made as to what will be developed. The two key elements of decision making that you need to agree on are:
1. Who makes the decision
2. What the time frame is for making a decision
1. The options are that everyone votes, that one person is charged with making all final decisions or that you appoint a lead for each "dept" (a lead artist and lead programmer) who make the final decisions. You can in fact use all of these methods, with decisions being discussed/voted on by the team as stage one. Then, if there is a tied vote the leads have a casting vote and then if the leads are unable to agree (because for example the issue is an art vs code issue) then a team lead has the final casting vote.
2. Once you have decided on 1. you then need to decide on how long you will allow for each stage. For example, if the team as whole can't decide then continuing to endlessly discuss won't get you anywhere. So you set a deadline for making decisions and if the team haven't reached an agreement by the time the deadline expires you move to the next stage of the decision making process.
Points to note regarding decision making:
i. You will seldom have all the information you require to make the perfect decision so you just have to make the best decision you can and get on with the project.
ii. Making the right decision is great but even making the wrong decision is better than no decision. No decision means you do nothing and you learn nothing (so making the decision doesn't get easier). Making the wrong decision will result in your project moving in the wrong direction - you will learn something from that and can change direction to correct.
Quote:Original post by Obscure
For once I will disagree with Tom. The problem isn't a technology one it is a management one.
I agree, it clearly is a management problem. Does that mean I disagree with me, too? (^_^) It's a management problem about how to deal with choice of technology (certainly not game design as the OP originally said).
Dan explained a way of dealing with the problem very well. I especially liked the point he made about wrong decisions being reversible. All too often, some member of a group adamantly resists making a decision out of fear of it being the wrong one. Explaining this to all should help.
And perhaps a decision grid would help too. Across the top, list criteria like "cheap, easy to learn, supports feature X, supports feature Y, supports future expansion," etc. Down the side, list the different possible technologies.
This is all great advice for you. Just step up to the plate and make a decision. The important thing is to get started! When you talk, talk, talk all that happens is the idea fizzles out. Especially if you are an indie working for nothing. I know from experience. If you aren't comfortable being the leader then tell whoever is to make the decision and go with it. Ok thats my two cents on it.
First of all, nice to "meet" you, tsloper. :)
I've been to sloperama.com, and it is a fantastic site. Perhaps if I had read it and digested it a *tad* more carefully, I may have avoided the pickle I am in.
There are 2 things I have done, since I first posted, in an effort to reverse the damage I have done.
1) I have gone back and have insisted upon our defining Design Scope for the entire project. What main areas are we going to discuss?
2) Once this list has been approved, we are going to take that self-same list and break it down into "Tasks to be completed" for the DESIGN ... such that we could reasonably begin writing source code from the design documents we have generated.
In number 2 above, it is my plan to have the following information tracked for each task:
Sub Project Name
Manager Task
Priority
Assigned To
Date Due
I think this will help a lot in getting a better handle on this project.
Tom
I've been to sloperama.com, and it is a fantastic site. Perhaps if I had read it and digested it a *tad* more carefully, I may have avoided the pickle I am in.
There are 2 things I have done, since I first posted, in an effort to reverse the damage I have done.
1) I have gone back and have insisted upon our defining Design Scope for the entire project. What main areas are we going to discuss?
2) Once this list has been approved, we are going to take that self-same list and break it down into "Tasks to be completed" for the DESIGN ... such that we could reasonably begin writing source code from the design documents we have generated.
In number 2 above, it is my plan to have the following information tracked for each task:
Sub Project Name
Manager Task
Priority
Assigned To
Date Due
I think this will help a lot in getting a better handle on this project.
Tom
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement