If you have a long-ish Gantt chart, it is common practice to report on the major milestones form the Gantt chart in a project presentation and leave the actual Gantt chart out all together. You might want to consider something like that, but since this is for a class, you might want to keep the milestones on a page and integral to the report and leave the full Gantt chart as an appendix to prove you've done the work. Also - One thing I always wrestle with is "what should I show on the Gantt chart" Dependencies are nice, critical path is good to highlight, and you might also want to show effort in addition to calendar time. You only have to start using these in anger a short time to realize that you can run out of room on 11x17 paper quickly (which is why I loath printing them out - they change too frequently once actuals are incorporated and each audience wants to see different data or the data differently presented. Have fun in class!

I've used (and like) a section at the top of the schedule for milestones. This keeps the key milestones visible and easily reportable. If you really want to use milestones to show links between teams, I would suggest first that the teams -really- be separate teams and not just different roles. For teams that each manage their own schedule, I have found milestone linking like you are describing moderately helpful. Here is how I have done it Warning - this requires a -ton- of overhead to maintain, I strongly suggest you really understand why this level of tracking is needed... Give each team their own project file. Each project file has three major "sections" Published Milestones - List of milestones from the local schedule file that are reported up and to other projects External Milestones -List of milestones from other teams or external sources. Schedule - where the actual tasks are for the team You then control a master schedule that takes each team's schedule and "creates the links" between their milestones. That is, you need to use the "Published Milestones" to drive the "External Milestones" across all of the teams' project files. This is time consuming and for five teams takes a good few days to set up, plus the communication needed to ensure everyone understands the structure. Each week (or whatever your timeframe is for managing the schedule) you need to pull in the teams' projects into the master, observe the links changing, and resolve the issues. Again, I can't stress enough that this requires a -huge- commitment to the project schedule. I wouldn't attempt this without some of the teams each having their own PM who understands this and can help you work with it. If you can live without a Gantt chart, you might just keep a list of Excel milestones that can be used to communicate across the teams and trust each team to update the milestone list. This gives you 90% of the benefit with 2% of the effort.

My two cents: It is clearest if you use "Offset".

If by "tentative" task you mean one that is not approved or unclear whether it will be in the scope, it generally shouldn't be in the project plan. It should rather be relegated to another document. Anyway, if you have to do it: In MS Project, you'd be able to color-code the task name or the duration bar in the Gantt chart. This would make tentative tasks very easily distinguishable. Projectlibre doesn't allow color coding unfortunately, so the only other way I can think of, is to add an extra column to your Gantt. You do this by right-clicking one of the existing column names and selecting "Insert column". As "Field" you can just specify "Flag 1". This will give you a column with a checkbox for each row / task. You can then rename the column (just right click the newly created column) to "Tentative" and set a checkmark for every tentative task. This will then be shown in the Gantt chart.

Use SS with the number of days lag you need. Then load the duration of the succeeding package so it will end the same as the preceding task. When you baseline, the finish dates will end like you want. That is the only time when you need the ending dates to match. After that, your finish dates need to move based on how you load actuals, which is how you know things are going south. Therefore, only constrain the start based on the preceding package and let the schedule move finish as it should. The preferred way would be to only use FS constraints. Meaning, you would have testing finish with something that triggers testing. Some product is delivered to the testing team to get them to start working. That is what I would exhibit. If development continues, simply start a new package.

The other way is to build trust. Your colleagues need to realize that the kind of planning they want to do is simply impossible and an outdated method of working in most cases. Gantt charts only work when the work to be done and the burn rate are very predictable. Neither of them is in software development. There is a better way of navigating these uncharted waters than simply getting an empty map and drawing a straight line. That way is planning much shorter routes so you can, for example, easily avoid that island that just appeared on your horizon... Agile development (and Scrum) are ways to deal with limited information, by making your yearly plan flexible enough to accommodate changes. You won't have the warm, fuzzy feeling of a precise Gantt chart, but that is not due to agile. That's due to the reality of incomplete information. How do you plan a year using agile? Write epics corresponding to the large chunks of work you want to be done. Prioritize, estimate in points and distribute across the appropriate people. Fit to a year. From that point, remember that you should be time boxed and not scope boxed. You know when you are going to deliver (how many iterations you will dedicate to each chunk) but not exactly how much of the scope (because you will deliver the most valuable stories in order for as long as you have time).

The reliability in pregnancy is much higher than any type of work task. It is 266 days from conception, with only a very small variability except when you have something that is abnormal. Task duration is not like that, where "normal" can have a much larger range. Therefore, creating a tool like this for work would have an extremely low reliability and, therefore, validity.

You need to set the task type to Fixed Duration, which is on the Advanced tab of the Task Information dialog. Having done that set the duration to 2d. Then add the Work column to your display and set the Work=4h for that task. It will show 4 hours of work spread out over two days.

There is no way to do it automatically. Assigning 250% to a resource would seem like you have 2,5 of that resource all the time. So you have to manually assign resources to tasks and then modify the resource availability from resource usage sheet or resource calendar. At this point if you level the resources it should make some of the things you want.

Have you considered exporting the relevant data to Excel? If you display the Task Sheet (use the View ribbon) you can certainly save that view as PDF as well. Saving as PDF just prints the current view to a PDF printer. I would filter and show only the tasks of interest - instead of saving the entire list.

It sounds as though the project is quite small, so I would personally not be assigning resources to tasks - it's not mandatory and, as you say, you are looking to schedule tasks. Also, to say "what are the semantics of a resource in GANTT" isn't quite hitting the nail on the head...a GANTT chart is a project planning tool, and MS project is one software package (I've assumed you're using MS Project) that allows you to assign resources to the tasks that you are planning in a GANTT chart. Having said all this, if you still want to assign resources, they are generally broken down into: Costs, Materials, Work. Regards, G

This is an absolutely classic example of misuse of constraints- The problem is that you have scheduled tasks to appear in a fixed order, nose to tail, by chaining them together since that, presumably is the broad-brush way things are scheduled for this delivery. But in the real world downstream tasks are often started before previous tasks are completed. This fundamentally breaks the scheduling rules you have applied, i.e. only start a later task when the previous one is 100% complete. Trying to then force MS-P to somehow deliver a sensible schedule results in more and more bludgeoning of the plan to try and make it fit. The short answer is: Don't constrain tasks unless there is a real technical dependency, let them float freely until the point a task actually starts and then fix its start date and start logging "Work Completed" against it. Let MS-P resolve resource allocations using levelling, which will keep the end date realistic based on the work remaining in the project, and instead of using Percentage Complete, use Work, Work Completed and Work Remaining to manage effort on the tasks as the situation changes. This is a long subject that I have previously documented for the benefit of my colleagues and others in this document: http://www.projectsmart.co.uk/practical-project-management-and-tracking-using-microsoft-project.html - Please feel free to use it at your leisure if it works for you. It is a bit out of date on some aspects of MS-P since they changed the working time screens in 2010 and I haven't got around to updating it, but the sections on predecessors and constraints, plus tracking and monitoring against a plan are very relevant to your question. Good luck!

Resource leveling will not move remaining work forward. The resource leveling command's sole function to the resolve resource overallations. If you want to move all remaining work out of the past, use the Tools > Tracking, Update Project, Reschedule uncompleted work to start after command. Do not keep changing the Project start date. Set your status date (Project > Project Information) and use the Reschedule command after updating your tasks.

Whilst David's answer is the right one in an ideal world, it is possible to achieve what you want by: Removing all the columns depicting start and end times (or moving the Gantt chart margin over them so they don't show), and Modifying the timescale appropriately- For example if you double-click on the timescale headings and remove all but one tier, then set that tier to show, say, Weeks and further set the Label for that Tier to be "Week 1, Week 2... (from Start)" then you will get the Gantt with just Week 1, Week 2, Week 3 etc. at the top. You can then use the snapshot tool (Copy -> Copy Picture) to cut an image into the cut and paste buffer for subsequent pasting into your slide, document or whatever. It's a bit of a misuse of the tool, but it does work quite effectively.

Fantastic question; significant overlap with my situation. I've got a couple of disorganized observations in response. First, planning without the team violates the assumptions in the PMBOK. I don't mean to treat the PMBOK as gospel, but I've found that pointing out that a given practice is at odds with the PMBOK is enough to get the audience to listen to my next two sentences; it is vital that the next two sentences be worth listening to. The PMBOK planning process is based on planning with the best possible information and based on planning involving the whole team. Once you eliminate the team from the planning effort, the quality of your plan will suffer. If there are operational constraints that prevent involving the team in planning, management (and the PMO specifically) are responsible and accountable for compensating for that weakness. I would suggest: Emphasis on lessons learned, and retroactive quality assessment. After you finish the plan (or any observable sub-unit of the plan), take an hour or two to measure how close the plan came to reality and ask what can I do better next time? Frequent, Short, Modular plans. If you know that the quality of your plan is going to be constrained, then the best way to limit the damage is to shorten the plan. Transform the one large plan into 3, 5, or more shorter plans. We currently have a master plan that is long, and then we build a set of rolling six month plans based on the master plan. A catastrophic planning failure can only set us back only 6 months or so. That also gives us more lessons learned sessions, and more opportunities to adapt our planning process to reality. Second, you can still manage to this program plan, but the importance of Risk Management rises dramatically. The program plan is set without consultation from the team, but that doesn't mean that the PM can't have a discussion with key internal stakeholders (e.g. developer team lead, or SME) and ask, The schedule says we'll deliver X on date Y; is that realistic? If we fail to deliver by that date, what is the most likely cause of failure? I'll bet you $100 that we'll miss this milestone; how much will you bet me that we'll make the milestone? (One of my favorites; when I talk risk, people stop listening, but when I phrase the question this way, people listen). If our lives depend on making milestone X by date Y, what impact will that have on quality and cost? What can we do to make it more likely that we'll make the milestone (and you'll win our bet)? Just as a sidenote, I prefer not to have the discussion about likelihood and impact until we've discussed the problem and both have a reasonable understanding. If Program Dates are edicts, then schedule risk is a major component of your risk mangement. Discuss all the schedule risks, assess the likelihood, and assess the impact in terms of the number of weeks delayed. This is an ideal situation for a monte carlo analysis. This supports a strong brief to external/senior stakeholders. The program plan shows the next milestone as Date X; we are Y% likely to meet that date. The overall program plan shows program completion on Date W; we are Z% likely to meet that date. If we are willing to spend $N, we can improve our chances by P%.

Have you tried using the Date Selection provided in the Print Dialog? Date selection options are highlighted in blue color in the following screenshot: I tried it in MS Project 2007 and it worked fine. Full chart was taking 3 pages, when I used the date range then the chart got printed in 2 pages.

There is a popular plugin for this purpose called Gantt-Chart for Jira. It give you a Gantt view of your issues.

I think this question may be answered elsewhere on PMSE but as a quick response my preference for this situation would be JIRA + Greenhopper + Team Calendars (all Atlassian software and will cost less than $50 at the scale you need). As always, though, it pays to define your process first and then pick your tools. My recommendation works for me but might not fit your specific needs.

Ignore it. It doesn't matter. Chasing a perfectly leveled resource allocation will cost you a ton of effort to get it just right and will be perfect for one day--the day of baseline. The very second you start to load actuals and progress, your resource allocation will go up and down to some degree. You would never--hopefully--chase the leveling. Instead, you would use the tool's warning of a over loaded resource to see if you need to intervene. If you know you don't need to because of other known factors, e.g., resource A won't start for a few days, then you would simply ignore the tool's warning. So load the scenario as you described in the tool, allow resource A to be "over utilized" a bit. Baseline and go. It will not materially affect your schedule analysis one bit.

I second Trevor's description. What I would add is Critical Path analysis, but this is already done by most planning software Dependencies (inside or outside of the project), which require some time-buffering to mitigate possible slippage The Gantt is only a representation of the data behind it, based upon start and finish dates (baseline, planned, actual) etc. Data can be used for all kinds of analysis. What I find useful is a "Milestone analysis", being the % that you hit your planned milestones on time (across projects). This is useful for organisations that use some 'standard' methodology for similar projects, with a defined set of milestones.