• Table of contents
• Reviewing your Gantt Chart
• Project Management

See also: Gantt Charts / Project Management

Reviewing your Gantt Chart¶

This should be done EVERY week at least once. Each member of the team is responsible for updating their own tasks. Generally, successful teams will also appoint one person to monitor the Gantt chart to remind team members to make updates.

FYI - issues will not show up on the Gantt chart unless they have a due date!

A typical project management / Gantt chart review process (not in any particular order):

• is there a link to the forum where the issue is being discussed / developed / addressed? Always use the forum for the discussion, use the issue to track progress.
• is there a link to the file(s) in the repository where the work is being placed? You must provide evidence of the output/results of the issue before it can be closed. The author of the issue should be providing these links. A second person (the 'closer') should validate that the link(s) are present and working/correct and that the work found there actually relates to the issue. The the 'closer' can actually close the issue.
• is EVERY task assigned to someone?
• there should NOT be a category named "To-Do"! There is already a tracker for that!
• Do the categories represent the major subsystems for your project? Additionally there may be a category for "Documentation" or "Project Management".
• once a person has been assigned, the status must be manually changed to "assigned"
• are the tasks 'meaningful'? Are they important enough to bother adding to the Issues list? Short tasks that might be completed in an hour or two are often not meaningful in terms of the overall project plan. Adding them just increases the 'noise' in the project plan making it harder to determine the actual tasks that need to be performed. Group these small items into a checklist for a single larger task.
• all tasks that have not yet been started need to have a more appropriate start date entered!
• all tasks must have an end date so that they appear on the Gantt chart
• are the relationships between tasks entered? You can "link" tasks to show that one task precedes another. this can be done when you view an issue - there is a "related issues" section.
• does EVERY person on the team own at least one remaining issue? why not?
• everyone should have issues that they own for the rest of the semester.
• all of the tasks should be about one week or less in length
• all of the tasks should have a useful description, not just a one line title
• do not use academic titles, for example do not use names like 'Detailed Design', 'Define Requirements' - these don't communicate enough specifics to be useful.
• avoid generic names for versions or issues. For example, do NOT include things like "Milestone 1", "Milestone 2", etc. in a version name even though the syllabus may name them like that!
• avoid generic names like 'Release 1', 'Release 2', etc. Instead use a name that actually describes WHAT will be delivered in each release.
• Be sure you use terms that are unique / specific to your project for issues and versions. They will provide a much stronger communication of what your team is doing on your specific project! That will help your client as well as the Chief / Project Engineers know what you are doing.
• when updating the percent complete, you should be posting a link to the artifact(s) that show that progress. This might be a repository version, forum posting, attachment to the issue, or a wiki page that has been created/updated
• does each issue have a target Version?
• does each issue have a category assigned?
• are you properly using the trackers: feature vs. bug vs. to-do
• is there an important document attached to an issue? If so - post it somewhere more appropriate! Anything attached to an issue will become hard to find once that issue is closed and no longer appears on your open issues list! Avoid putting important documents in an issue. Put them in a forum where you can and should discuss and review them. Use the issue to mention where it was posted AND to manage it's schedule and to track the progress toward completion.
• are there tasks left over from a previous semester that have not yet been closed? Why? Are they completed but not marked as closed? You need to verify that status before closing them.
• Tasks from a previous semester may need to be reassigned to a current team member and rescheduled with dates and a version that is relevant to the current semester.
• Look for the term "SMART" or "S.M.A.R.T.". Your issues should follow those guidelines.
• Do not add never-ending tasks like "Project Management" or Wiki Webmaster". These are really roles that perform ongoing activities, not measurable tasks. If a specific task is eventually identified that can be measured and completed in a week, then add that item instead.
• Do not create parent tasks that have only one sub-task (child task). Only create parent tasks to show how a large effort is broken down into smaller, shorter pieces or to show how the multiple elements of a complex task are divided among the team members.

Project Management¶

If you are unclear on project management itself, on the differences between tasks and milestones, on what Gantt charts are or the why and how they are used, we recommend you visit YouTube as there are many excellent videos available on these topics.