For my winter vacation assignment, I plan on creating a project scheme for me and two colleagues. Our job is to create a 1-year project in which we can plan, develop, and produce a product for everyone to see at a small convention held next year in Spring. It's something that we have to do in order to graduate in CS.

Our main problem is that our project planning scheme is very poorly designed, and we're not good at project planning. My professor asks for a solid project scheme that lasts for 1 full year to 1.3 years, then we can edit it off based on everyone's opinions. Currently, we're wasting time due to both of my colleagues have full-time jobs and I'm left to do most of the planning. I hate to admit it, but this is the best we can do.

Right now, I have planned out a small 6-week schedule, separated into 3 2-week groups, as we also have classes in-between these schedules.

• Initial Planning
  
  
  
  • 2/13 ~ 2/24:
    
    
    
    • Design game genre, game type, story plots.
      
    • Graphical layout, on what language, and on what platform.
      

Preproduction

• 2/27 ~ 3/9:
  
  
  
  • Plan out the basis on the game
    
  • Decide upon game controls
    

Program

• 3/12 ~ 3/23:
  
  
  
  • Program the basis.
    
  • Add the game controls
    

This is all I can think of. I know that this is very short, when compared to a full year, but since I haven't been able to grasp some aspects of project management, I decide on planning things from the small scale, learn a few things, and then slowly jump towards the full scale.

I would like to ask for tips/advices on how to create a project scheme that lasts for a year, based on game development; Or, in a general sense, based on an application development.

One unusual task my colleague gave me before he goes abroad, is that I need to create at least 3 project schemes, so that we can have at least 2 projects to fall back upon, in case our first project fails to meet expectations. I liked to think of this as a practice, and not a burden, unlike what my colleague thought when he told me.

Thanks in advance. If you need more info, please let me know.

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.

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.

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.