Contents
Who hasn’t had a project delayed because of an unforeseen dependency or delay?
This then ripples out to the delivery of all of the related parts of the project causing chaos, if you’re not on top of things.
As the old saying goes, “Hope for the best, plan for the worst, prepare to be surprised.”.
Microsoft Project is the most widely used project management software in the world.
It’s very quick and simple to use and lets you plan and control all aspects of your project: time, budget or resources.
If your project is delayed it will show their impact on project delivery, and finally, it makes it very easy to communicate your project plan to others.
As you can probably tell we’re big fans!
This guide will take a complete beginner and get them up and running in 8 easy steps.
Looking for a more personal guided experience? Check out our training courses here.
Step 1 – Project Data & File Properties
File properties are is a standard MS Office feature, and is simply descriptive text (sometimes called meta-data) about the project.
Select File>Info>Project Information>Advanced Properties
This displays the following dialog box, into which appropriate text may be entered:
You can also figure out the properties of a Project file by its file extension!
Step 2 – Project start and finish dates
There are two main aspects to project-level timings; the expected start or finish date of the project and the working times.
Select Project>Project Information to display the following dialog box:
You can choose either to work forwards from a specified start date (and Project will calculate the expected finish date) or, by choosing the option Schedule From: Project Finish Date, to specify the required project end date.
Microsoft Project will then work backwards from this and calculate the expected start date.
NB. If the project has a deadline, then this may seem a useful option.
However, if, say, a finish date of 23rd December is entered and a start date of September 5th calculated, then this means in practice that if the project starts on this date and everything goes exactly according to plan, then it will finish just in time!
This is unlikely to be the case, and it would make sense to treat the calculated start date as the latest possible date when the project should commence.
In any case, even if you use this feature throughout the whole of the planning stage, when the project starts you should change to scheduling from the start date.
This is because during the tracking stage the project start date is an actual date that has already happened and should be known exactly, whereas the expected finish date is unknown, and hence should be calculated by Project.
Learn more about Microsoft Project schedules here.
Step 3 – Project Calendars
The other aspect of project timing is the project calendar, which specifies the working and non-working days.
For each working day, the working times, and hence total working hours, are specified.
Project comes with three built-in calendars; Standard, 24 hours and Night Shift.
The Standard calendar is used by default.
The Standard calendar covers dates from 1st January 1984 to 31st December 2149 for version 2013, 31st December 2049 for earlier versions.
All weekdays are assumed to be working, and all weekends non-working.
There is no facility for entering public holidays for a particular country, as in Outlook; these must be entered by the user.
A custom calendar may easily be made, typically by copying one of the built-in calendars and editing the copy.
Such a calendar is an integral part of the Project file within which it is created, thus allowing the flexibility of having different calendars for different projects; a quite feasible scenario.
It is possible to customise the built-in calendars, but this is not recommended; better to keep the built-in calendars unchanged to facilitate making further copies of them.
To make a copy of the Standard calendar (the one most commonly used) select Project>Change Working Time to display the following box:
Click Create New Calendar, and enter a suitable name:
On clicking OK the calendar is created and you will be able to edit it:
You may enter one or more exceptions. An exception may be one day in length or many.
If more than one day in length, it may extend over a number of consecutive dates or over non-adjacent dates that are separated by equal periods of time (e.g. every Saturday during the last quarter of the year).
An exception may either be non-working (which is assumed by default) or working (in which case the working times may be set).
In the example above, 29th August 2016 (a public holiday) is selected. On clicking Details the exception type (working/non-working) may be set:
To enter an exception covering a number of consecutive days (e.g. the Christmas break), click and drag to select the days and enter a suitable name.
If the exception extends over more than one month, then you can edit the start or finish dates (in the example below, the end date of 2nd January 2017 has been directly entered:
Suppose it has been decided to work a half-day for each Saturday in September. Select the first Saturday (September 3rd) enter a suitable name and click Details:
Select “Working times” to make these exceptions working and enter suitable times (default is 8am to 12pm and 1pm to 5pm, giving 8 working hours). In the example above, the afternoon slot has been deleted.
The recurrence pattern and range of recurrence may then be set (this dialog is identical to Outlook’s calendar feature for entering recurring meetings or appointments).
Note: If your standard working times are different to the default, then it is possible to change the default times used for non-exception working days. To do this, select the Work Weeks tab from the Change Working Time dialog:
Click Details. To select all weekdays, click on Monday, keeping Shift pressed and select Friday.
Choose the option Set day(s) to these specific working times and enter the required start and finish times:
In the example above a 7-hour day has been specified for any non-exception working day.
NB. If you do this, then you must update the timing options to match the new default times.
Select File>Options>Schedule and edit the Calendar options for the project:
If you do not do this then it is likely that you will get inaccurate start and finish dates for your tasks.
This is because when the duration is entered for a task, unless the duration units are in hours or minutes, Project will convert the duration to an hours figure using the options above.
So, for example, if a 10-day task is entered in the above project, the duration would be converted to 70 working hours.
Project will then take this hours duration and match it up, on a day-by-day basis to the calendar.
It will check the working times for each day and calculate the number of working hours.
The working hours figure for each day is then subtracted from the hours duration for the task until no hours are left. This then gives the finish date.
Suppose that a 7-hour calendar has been set up, but, mistakenly, the options are still set to an 8-hour day and 40-hour week. A task of 10 days duration is entered.
The user means 10 7-hour days, but Project calculates the duration to be 80, rather than 70, hours. It then matches it to each of the 7-hour days in turn, but needs about 11.5, rather than 10, of these days.
The Gantt bar is too long and the finish date about 1.5 days later than it should be:
It is suggested that, for the sake of simplicity, it would be best to keep the options and default working times unchanged and simply concentrate on adding suitable exceptions.
Calendars can also be used to create your own planner in Microsoft Project.
Step 4 – Task Data
Managing your task data is one of the most important steps in getting your project up and running, but also one of the more complicated! Let’s break it down a little bit.
Step 5 – Task Mode
A task’s mode may be either manually or auto-scheduled. The default is manually-scheduled, but may be changed (possibly before any tasks are actually entered) via File>Options>Schedule>Scheduling options for this project:
For any task, there are three pieces of interconnected data; the start and finish dates and the duration.
If a task is manually scheduled then the user needs to enter any two of these; Project will calculate the third.
A manually–scheduled task is particularly useful if both the start and end dates of the task need to be specified.
A manually-scheduled task cannot have any date constraints set, nor does resource-driven scheduling apply to it.
These topics are described later (see below Task Date Constraints and Resource-Driven Scheduling in the next chapter).
If a task’s mode is auto-scheduled, then Project will carry out a lot more of the scheduling, but any data value so calculated can be changed by the user.
Step 6 – Task Duration
The duration (in minutes, hours, days, weeks or months) may either be entered directly by the user or (for auto-scheduled tasks) calculated by Project.
It may be influenced by the working calendar (see Project Calendars in previous chapter) or by changes in resource assignment or work times (see Resources chapter).
It may be working (i.e. during working time, this is the default) or elapsed.
This essentially ignores the non-working times in the calendar.
For example, if the project calendar has non-working weekends, then a task of eight working days, starting first thing on a Monday, would finish at close of business on Wednesday of the following week.
If the duration is eight elapsed days then it would finish at close of business the following Monday.
One use for elapsed duration is for tasks not requiring any human involvement, for example allowing paint to dry or concrete to set.
The duration (in minutes, hours, days, weeks or months) may either be entered directly by the user or (for auto-scheduled tasks) calculated by Project.
It may be influenced by the working calendar (see 2.3 Project Calendars) or by changes in resource assignment or work times (see 5 Resources). It may be working (i.e. during working time, this is the default) or elapsed.
This essentially ignores the non-working times in the calendar.
For example, if the project calendar has non-working weekends, then a task of eight working days, starting first thing on a Monday, would finish at close of business on Wednesday of the following week.
If the duration is eight elapsed days then it would finish at close of business the following Monday. One use for elapsed duration is for tasks not requiring any human involvement, for example allowing paint to dry or concrete to set.
Step 7 – Task Dependencies
A task may be linked to another task with any of the following four dependency types. In each example, A is the predecessor and B is the successor.
Finish-to-start
The most common type. This may be used either because the nature of the two tasks requires it (e.g. finish laying the foundations before building the walls) or for two otherwise unrelated tasks that require the same resource.
To avoid the resource becoming overallocated due to the tasks overlapping, a finish-to-start dependency may be used (see 5.5 Resource Overallocation).
Start-to-start
The two tasks start at the same time, run in parallel, but finish at different times unless of the same duration.
This used to be used to maximise the amount of concurrent work, and hence minimise the overall project duration.
It is not really needed now as Project by default schedules all tasks to start as soon as possible, unless they are manually scheduled.
This dependency may be useful for two tasks that feed in to one another whilst underway.
For example, during the development of a computer program, coding and testing may be run in this manner, with a short delay on the commencement of testing.
First do some coding, then test what has been coded, then carry out further coding to remedy any bugs found in the testing and extend the scope of the program, then test further… etc.
Finish-to-finish
The two tasks start at different times unless of the same duration, run in parallel and finish at the same time.
This may be applicable to tasks in the final stage of the project, when a number of things may need to get “wrapped up”.
For example, a new computer system would need to be installed on the computers on which it is to run, and the end-users would need to be trained in its use.
It would make sense for these two tasks to finish at the same time so that as soon as the system is installed it can be used.
Conversely as soon as the users have finished their training they can start using it; if they have to wait before using the system, they may forget some of what they learned.
Start-to-finish
If set between Tasks A and B, this has the effect of pushing B backwards so that its finish date is the same as the start date of A.
This dependency is rarely used, but one possible application is for pre-project tasks. If the planner wishes to include one or more tasks to be completed before the official project start date, then these tasks may be linked using this dependency to the first task in the project.
Lag and lead times
All four dependency types may be further qualified by lag or lead times.
Lag is an extra delay to the start of the successor task.
Suppose that Task A must be completed before Task B can be started. This suggests a finish-to-start relationship.
However, it does not necessarily mean that B can be started as soon as A has been completed; there may be a further delay.
This may have many causes; perhaps allowing time for the client to read and approve the specification produced in A before moving on to the next stage in B.
Lead is the opposite of lag; the successor task is brought forward.
With a finish-to-start dependency that would mean the two tasks would overlap by a period equal to the lead time.
Both leads and lags may be expressed as durations (same units as tasks, either working or elapsed) or percentages.
The latter applies if (say) B can be started when A is 75% completed; the lead time would then be 25%. Examples of lag and lead are shown below.
You can also find more information on Microsoft Project lead times here.
Lag
Lead
The way the project is displayed on the right hand side is starting to look a lot like the waterfall methodology!
There are a variety of ways to set and edit task dependencies.
A full listing is beyond the scope of this document, but a convenient method is via the Task Information dialog box.
Select the successor task, and choose Task>Properties>Information (alternatively double-click the task name).
Select the Predecessors tab and enter the required data. Both task name and dependency type may be selected from drop-down lists.
Step 8 – Task Date Constraints
A further piece of task data is the date constraint. This is only applicable to auto-scheduled tasks. Unless specified otherwise, Project will schedule each such task to start as soon as possible. Date constraints can also be set via the Task Information box (Advanced tab):
Other date constraints include:
As Late As Possible
The task is delayed by the longest time possible without delaying the project end date. This time period is the Total Slack (see 4 Critical Path).
Start No Earlier Than <specified date>
This is useful where, for example, some materials have been ordered for a task, and a delivery date specified. The task should clearly not start earlier than the delivery date.
Finish No Later Than <specified date>
This effectively puts a deadline on the task. Applied to the last task in the project (or to a milestone marking this) it is one way of encoding a deadline into the project plan.
NB. If a task has this constraint set and also is linked to another task then a scheduling conflict may occur.
For example, suppose that Task B has Finish No Later than 31st August applied, but is also linked in a Finish To Start dependency with Task A.
If A’s end date is (say) September 9, then a scheduling conflict would occur with two incompatible requirements. The Planning Wizard would give warning of this:
If the scheduling conflict is allowed, then, by default, the demands of the date constraint (a so-called “hard” constraint) would override those of the dependency, giving a rather odd look to the Gantt chart:
This can be changed so that the dependency overrides the date constraint by selecting File>Options>Schedule and switching off “Tasks will always honor their constraint dates”:
This changes any such constraint from “hard” to “soft”:
An alternative to a soft constraint is to apply a deadline date. This is also set in the Advanced tab of the Task Information dialog box:
If the task end date goes beyond the deadline, a distinctive red marker is displayed in the Indicators column.
NB. For autoscheduled tasks, a date constraint will be set by Project if either the start or finish date for the task is edited by the user. If, for example, the user enters a start date of 3rd August for Task B, then Project will assign a date constraint of Start No Earlier Than 3rd August to the task.:
This would also apply if the user moves the Gantt bar for the task by clicking and dragging it; this is just another method of setting a task’s start date.
If a finish date is entered, then a Finish No Earlier Than constraint would be set. This is a major difference between autoscheduled and manually scheduled tasks.
Because of this, it is advisable to add a note to a constrained task explain why the constraint is being set. This may be done via the Notes tab on the Task Information box:
This helps distinguish between genuine constraints and those that may have been set accidentally.
To view tasks with date constraints use the Tasks With Fixed Dates filter. Select View>Data>Filter drop-down>More Filters>Tasks With Fixed dates>Apply.
To clear a filter and display all tasks, press F3.
Now your project is up and running! Looking for the next step? Read this article on mastering Microsoft Project views to get a better understanding on how they can serve you.
