Need tips for CS project management on game/application development

I hate to admit it, but this is the best we can do.

Your grades should be based on the best you can do, not the best we can do.

Others that might help will be more interested in how you developed the plans as opposed to what they are.

I would suggest agreeing on some sort of shared workspace and free CM tool like Subversion, Mercurial, or Git an one of the appropriate free hosting sites like GitHub, Codeplex, or Google Code. Most of these offer ways to manage the project within them with issue trackers, wikis, etc. Makes working together without stepping on each others feet great.

I haven't been able to grasp some aspects of project management,

Then read. Here are two books:
Introduction to Game Development (Rabin) - I wrote the chapter on Production.
The Game Production Handbook (Chandler) - I wrote the foreword (the author was my associate producer at Activision).

What about the project management itself?

Like, how do you provide a scheme that takes control of how much time we need to use up? What can I do to extend my original 6-weeks scheme into a 50-weeks scheme?

If a group of people wanted to do a project, and keeping the software part out (programming, version controlling, etc.), and wanted to plan how the work force, what work should be done, how the work is like, and how long the total amount of work should be done by the time that group is about to reach a deadline, shouldn't they start off with a plan/scheme/something that the group members can rely and work without worrying about what should be done next?

I am grasping that little concept of project management. I hoped that I can get more from this.

EDIT:

@Tom Sloper, do you mean (after reading your post for the third time), you want me to read both of the books' chapters (Production chapter and Foreword)?

EDIT 2:

@Telastyn: Do you mean on how I should develop my plans instead of what they are? When it comes to developing a plan, what are the key aspects if you're starting out from scratch? Do you start from the beginning of the project or from the end? What did I miss out? Thanks.

@Tom Sloper, do you mean (after reading your post for the third time), you want me to read both of the books' chapters (Production chapter and Foreword)?[/quote]



No. Read Chandler's whole book. Do not read my foreword.
And, either before or after you read her whole book, you can read my chapter in the other book.

Do you start from the beginning of the project or from the end? [/quote]

Both at the same time. You have to work it from the back end to determine what the unchangeable events at the end of the project are, so you know when you have to hit Beta. Then plan from the beginning and make sure you don't have too much work to accomplish by Beta.

Do you mean on how I should develop my plans instead of what they are?

I mean that it's important for you learn how to do something, and it'll aid people here to guide you in learning that if we understand how you developed these plans.

If you can get a hold of MIL Handbook 881 (Work Breakdown Structures) it helps alot with breaking down the tasks of projects of any size (software to ships). Once you get past the military jargon, its a real asset. Another good one is MIL Handbook 61a (Configuration Management). What makes these nice is they are free (unlike IEEE, ISO, and EIA). Additionally, ISO, IEEE, and EIA were based off of them ;)

No. Read Chandler's whole book. Do not read my foreword. And, either before or after you read her whole book, you can read my chapter in the other book.

@Tom Sloper, could you recommend another book? Seems to me the Game Production Handbook is not available in my country. I'm outside of USA, so my book resources are limited at my disposal.

I mean that it's important for you learn how to do something, and it'll aid people here to guide you in learning that if we understand how you developed these plans.

I started developing these plans based on 2 things:

1. Visual graphs made by my professor on his computer, in which it displays the project's lifetime and its deadlines. I've only briefly seen a project scheme that shows a large project split into 20 subgroups, each with an arrow pointing from the main group labeled "Project Name". Each subgroup contains a duration deadline of 2 weeks. This is where I develop the 2-week length for my plan.
   
2. Little, but vague facts from my professor, who told me that software projects have to start off with a plan. And without any plans, it would be hard to progress. I don't think that I told him clearly that I do not have the expertise to construct a plan, and at that time, I didn't think much about this until now.
   

From there, I hypothesize that for a project to be fleshed out, it needs to have at least 3 stages, splitting the entire timeframe of the project (lifetime, the duration of the project, etc.). Thus, I planned out the Initial Phase, Preproduction and Programming, the first 3 subgroups which are part of my small "Project Unnamed" project (the 6-week project).

I have not had any experiences in project planning, so the only sources I get from is from my professor, who only taught me that much, when I finally thought of it just 2 weeks before winter vacation (and 1 week before the finals). I had tried emailing my professor, and I'm still haven't received any replies. So, I couldn't get more information from him.

Is that, all of this, known as the answer to the question, "How I develop my plan?" Or I'm still unable to get the picture?

"Plans are nothing, Planning is Everything" - Eisenhower

Don't worry so much about putting stuff on paper, worry more about the proplem at hand and how you're going to go about dealing with it. That is what planning is: Your approach towards solving a problem. It doesnt need to be complete to the n-th degree, its just a guide you put together to remind yourself what you need to do next on your path to solve a problem. Human memory is faulty, and as programmers/engineers, we tend to get lost in the weeds more than we should and loose sight of where we're heading. Plans help to remind us why we were chasing problem x down the rathole or why group x was chasing that problem. They also tell us where we've been so we dont end up duplicating work as well or tell us where we may have made a wrong turn, so we dont have to start over entirely.

So to sum it up, don't worry too much about "having the ultimate plan", just make sure that you think about how you're going to solve the problem(s) before you, and write that approach down, so you can make use of it and formulate a strategy to resolve it (planning). Do that and you'll have a useful plan.

P.S.:
Remember, NO plan is complete nor correct at the start, not a single one. So don't expect yours to be. They can change and modify as you learn more about the problem you're solving. Additionally, remember this: be able to accept that you may have to start over from scratch if you learn your original assumptions were wrong. Sometimes your initial approach will be the exact opposite of what you need to do to solve the problem, so be comfortable with this idea. Anyway, good luck.

Thanks, Net Gnome. Looks to me, I have to get gritty with all of this.