For smaller projects I use excel spreadsheets or even lists of tasks with dates clearly marked next to them for quick reference, on a Word document. The aim here is to think about who uses these - if a small team of developers they should have something that is easy to read and on a program they are likely to have on their PCs.

But the most important task involved in timelines is the management of expectations - especially the client’s. If the client understands from the outset that some tasks cannot be started until completion/signoff of another task and a delay may cause delays to the end date then any argument about which program to use for a project plan seems piffling in comparison.

I’ve seen quite often that people start with Project (e.g. to get some nice drawings of a project plan) but tend to abondon it quite soon afterwards.
Why?
Well, for really large projects (I was working on some with >200 developers), Project is just too lightweight. Here, you need much more controlling capabilities and a solid multi-user database to keep track of everything. The tight integration of planning, controlling and drag/drop modification of project plans together with automated recalculation of a schedule causes very easy a schedule where you do not know anymore whether you looking at the current version, a version of last week or a “new version” reflecting the latest controlling data.

On the other side, I guess most projects are just small scale, with less than 10 or even 5 people involved. Here, the issue is a missing (or very poor) integration with the daily calendars of the project team, and -most important- the fact that in small projects chances are high that people have parallel projects. So, you usually have on one side a tool which gives the impression that everything is under control while at the other side the data within the tool tend to not reflect reality any more.

Is there a solution to it? Not yet (we are currentyl developing a P2P based tool to adress this issue), but I’ve seen a lot of people just going back to Excel: Here you can track what’s really important for you and have full control of all KPI (as you have to calculate them on your own). Drawback: requires some advance Excel skills, no drawings and does not scale beyond a certain size of your project team.

Klaus

In the mean time, it makes real nice GANTT calendars for sales packages, and it isn’t half bad for initial planning. But tracking? Maybe someday I’ll get it.

Anyway, Project is a great tool to express to customers that you have a vague idea that you know what the hell you are doing. Gantt charts show cool bars and milestone diamonds that make customers comfortable that you’ve thought about what you are doing.

For managers, it does give you the chance to analyze and understand the impact of changes to the project when one task changes (slipping deliveries, adjustments to labor).

MS Project, along with other project management tools, have bad habits, especially with labor allocation. But it is also useful for performing estimates.

I agree that project plans and costing should be discussed with everyone involved to verify that the number of hours the system is proposing is right or off.

One tip that I’ve found is that the more detailed a project plan is, the more likely a customer will micro-manage you. What I’ve found is that I create two project plans. One, at a higher level, is the one I give my customer so that no task is shorter than a week. The other, more detailed version is the one I use with my team.

Regards,

Paul

Having run a software company for 12 years before I got into the writing business, I know whereof I speak!

More definitions: http://www.badlanguage.net/the-devils-marketing-dictionary-part-3

To use it well -
* Schedule realistically - adjust estimates according to risk/complexity of certain tasks. Ask team members to provide input on the level of complexity of tasks when planning.
* Don’t micro-manage - create tasks and milestones at an appropriate level of detail.
* Manage well - seek regular feedback on project progress and adjust the schedule accordingly.

To use it poorly -
* Assume anything you don’t understand is easy to do (credit to Dilbert for this one ).
* Create the project plan in isolation to the people who will actually be doing the work.
* Assume all people on the team provide 40 hours a week of productive project time.
* Assume the team all have the same experience and ability.
* Assume nobody takes sick leave, annual leave, attend training sessions or staff meetings, or have any other work commitments.
* Schedule every possible task and activity of the project (including toilet breaks).
* Create a very aggressive and optimistic schedule - assume everything will work right the first time.
* Print the plan once, attach it to the meeting room wall, and leave untouched for the duration of the project.

Rajesh Shakya
http://www.rajeshshakya.com

If the entire team (devs, designers, database-ers, PMs etc) are all in the one building, then MS Project is total overkill. In that instance, a free open source project like GanttProject does the job nicely.

But if i’m working on multiple projects, with multiple timelines, with shared resources, across more than one location; then MS Project really come into it’s own.

And if you HAVE to stick to a management methodology (e.g. Prince 2) for goverment departmental oversight, then MS Project is really handy.

I think the thing to realise is that when seeing a job advertised, it’s rarely written by the people who actually want to hire you. It’s either written by HR (who copy the previous ad or from their competitor) or it’s by a recruiter who’s looking to cover the bases as he doesn’t know the technology.

I mean, who’s gone for a web design job where the recruit has told you that 5 years JAVA experience is an absolute must, when really any small javaScript knowledge will do?

It’s not the tools fault, it’s the incompetent / inexperienced PM’s fault.

@Rob: Experienced PM’s know that only about 75% (or less) of a working day is productive.