Where should one put a large Gantt chart in a project report?

Working on a project, how to make a schedule/gantt chart?

• Hello, hopefuly someone can advice me on this. I am working on a project (I am making a game-level with the Unity game-engine) and I would like to manage my time in the best way so things would go smother. basically I understand that I am going to have to cut the whole project in parts: idea/sketches, 3D modelling, texturing, Unity engine and Coding/programming and report (I think those are it). but how can I put all of this into a schedule/Gantt chart? advice please

• Answer:

  You have the individual tasks: Idea/sketches 3D modelling Texturing Unity stuff and coding/programming What you need to do is spliyt the up further if you can: Idea/sketches 3D modelling: basic modeling of X Rigging animation Unity engine: basic setup importing models and placing them programming: For this I suggest you make a basic UML chart, giving you an idea of the class layout, inheritance etc. The chart is subject to change as you move along, adding functions etc. so: creating basic class structure writhting this function writing that function code testing etc. Depending on how long you have for the project, I suggest you divide the project down into "sprints" (as known from scrum), intervals of a week or two, where you set some basic goals (game element xyz is finished for example) and have a daily short meeting on what has been done and what needs to be done. A larger, weekly or bi-weekly meeting is also good, where you make the chart and discuss the goals for next "sprint". The gantt chart indicates an estimated number of hours a given task takes, so making a burndown chart (google it) can reflect the actual number of hours used on a given task or a set of tasks. The burndown chart is a running tally on the time used compared to the time alotted, and indicates if there were any problems during the sprint. Also make sure that no group members are stuck doing two things at once or nothing at all. A list of tasks can be made and crossed off as the tasks are completed, thus if someone has some extra time on his hands, he can choose a new task and keep going, even if it's reserved for the next sprint. At the end of each sprint, you may also include some time for testing existing code and gameplay elements, noting down any bugs and gameplay changes you wish to implement. This turns your waterfall model into more of a spiral model, making you able to compile running prototype versions and incrementing them. Thus, if a project version gets messed up for some reason, you have a working backup to fall back on, or, later on in life, you have a set of game versions that can be forked into new projects.