It seems so obvious: at the beginning of a project set up a project schedule; monitor project progress against the schedule; and adjust the schedule, the project team, or the scope of works if things go wrong. Yet surprisingly this is often not done. Reason for not doing this include: inability to set up a schedule; too confident to need a schedule; a desire not to know; or simply inexperience. I know of one senior engineering leader who cannot read a schedule—seems he is dyslexic in that regard.
I have helped young engineers set up schedules. The process should be almost mechanical. But for many of them it was not. The worst error they made was to list activities and then try to insert fixed dates. That is a nigh on impossible task. So here follows something I wrote a while ago on the simple rules of setting up a schedule. Hope it helps.
As in any project, it is prudent to establish a project schedule at the outset. We presume you are familiar with MicroSoft Project or similar. It is good practice to use such a code to plan, manage, and track the progress of a project. The two aspects of scheduling that are valuable is that it allows you to initially establish a sound plan to complete your work and secondly allows you to track performance and determine what actions to take to maintain a schedule or determine when it becomes necessary to modify the schedule and dates.
Here are a few tips about setting up a schedule that we have found useful and more often ignored than implemented:
- If possible use the same categories for the schedule as you do for your cost estimates. This will make your reviews of the projects schedule and budget performance much easier.
- Establish the project start and end dates. In many codes this involves assigning the end task as a milestone. There may also be intermediate milestones such as “all permits in place” or “contract to construct awarded.”
- List the tasks and subtasks into which you decide to break the project. There is no end of sub-levels into which a project may be divided. Generally, however, three to four levels of subtasks are sufficient for all but the longest, most complex projects.
- Assign durations to each task and subtask. A good guideline is that tasks should be so assigned that no one task has a duration of more than a week to eight weeks. Less than that and you are constantly scurrying to keep the project up-to-date. Longer than that and you may miss a key task or subtask that may not be properly tracked and result in unexpected schedule overruns.
- Establish the links between tasks. This is the key activity. Too often we see junior engineers trying to insert start and finish dates before establishing task linkages. They get frustrated and never seem to get a fully-fledged schedule in place. Key linkages include:
- Finish to Start: The designated task starts only once another designated task is finished.
- Start to Start: Two tasks start at the same time.
- Finish to Finish: Two tasks, usually of different durations, finish at the same time.
- Start.to Finish. The designated task must start so that it is finished by the time a second designated task begins.
- You can also establish lags between two tasks. For example in a Finish to Start relationship, you may specify that the second task starts 19 day after the first task is finished.
- Now check the schedule and see if it logical and achievable. Most often on the first run-through, it is not achievable. You will probably have to adjust task and subtask durations, links, or lags. This tells you that you may need more resources to achieve a milestone completion date. Adjust the schedule until it is all correct and then proceed to manage.
As the project proceeds you may have to come back and adjust task durations and relationships. You may have to add or delete tasks. No matter, for that is why you have a project schedule.
The best part of using the project scheduling software is going into the task information block and inserting the percentage of the task that has been completed—at least this is true if work has gone according to schedule. If it has not, this may be an awkward thing to deal with, but nevertheless important.

Great advice jack. I think this has applications beyond engineering. It seems a sensible way to project research for example.
One of my first jobs was to set up a schedule for an alimak raise. I have still not mastered scheduling software, other than Excel. In the old days gant charts were cone on graph paper, so moving to Excel was a natural evolution.
I particularly like the first suggestion, to set up a schedule according to how the accounting will work.