Module 4 - Project Schedule PDF

4/28/2019 Laureate International Universities
MODULE 4 - PROJECT SCHEDULE
Learning Resources
Work Breakdown Structure
A large project is the sum total of many smaller tasks. By breaking down the work tasks
into smaller and smaller tasks a project manager eventually is left with a collection of
‘work parcels” which inter-relate.
The reason for breaking down work into the smallest possible tasks is to provide the
level of detail you need to identify duration, quality, cost and resourcing needs. Of
course, the question could be asked as to how far down does the breakdown go? That
would depend entirely on the complexity of the project and the amount of management
required. It would also depend on the accuracy of the project scope and the extent of
the standards and speci cations required.
Breaking down and identifying tasks enables the project manager to prepare an
accurate budget and to accurately schedule the work. It shows an indication of the
actual e ort required by each person performing a task.
Let’s use an example here of a wedding plan.
There are two main areas of planning needed, that is, the wedding and the reception.
We will ignore the reception for this part of the example. It’s quite often full of distant
relatives you don’t really want to talk to anyway. (Just joking) In the wedding we need to
plan to do a number of things such as organise the venue, organise the celebrant, write
the vows and buy the rings. So at this point we have broken the wedding down into 4
smaller tasks or ‘chunks’.
But within each task there are even more smaller tasks to be done.
https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_68678_1&content_id=_7184743_1&mode=reset 1/34
To organise the venue we have to visit the venue and then book the venue.
To organise the celebrant we have to source celebrants, interview them and then
select one.
Writing the vows could be broken down into writing the vows and then having
them proofread and approved
Buying the rings could mean actually going shopping, comparing possible
purchases and then purchasing the rings.
Each of those smaller tasks may have more detailed tasks within but for this example,
you should be able to see the basic process. These tasks can then be represented
pictorially in what is known as a work break down structure or WBS.
'Chunking' Project Work
The WBS is the representation of a project into 'chunks' of work. These chunks are
devised to facilitate the management of the project. A rough, but appropriate analogy is
to use a cake to represent our project. Let’s call our image a wedding cake to continue
our example. In order to consume the cake (undertake the project), we need to cut the
cake into smaller pieces (break the project down into doable chunks of work).
Let's say the idea is to cut our cake (chunk our project) into four roughly equal pieces.
How might we do this?
Our rst option is a rather simple option—we have made two vertical cuts, roughly at
right angles to each other to provide four roughly equal portions of cake in the shape of
quadrants of a circle.
Our second option, while still quite simple, takes a di erent approach. Instead of ending
up withquadrants, we will end up with four at discs as a result of the three horizontal
cuts we make of our cake. Still the same cake, but a very di erent piece to consume
from our rst option!
For our third option, we have made three concentric cuts to form three hollow cylinders
and one solid cylinder, all roughly equal portions—as was the original requirement. Our
third option, however, may be more challenging to eat than the rst two options!
Although our analogy is somewhat crude, it serves to illustrate that there are options
available in the breakdown process. It is true in the case of our cake and it is true in the
case of any project. The key to e ective project planning and management is the
selection of the appropriate WBS that will facilitate the ongoing monitoring and
management of the project.
A Work Breakdown Structure document helps to answer some fundamental project

questions.
What work must be performed?
How long will each task take?
What resources can perform the work?
How much investment is required?
So before we launch into creating a WBS, identifying the tasks and task parcels is critical.
You need to look at a number of things such as:
The name of the task being performed – try to group related tasks together and
give them a descriptive task name that clearly identi es what work is to be
performed
An identi er code number for each task – this enables accurate identi cation
particularly when issuing cost assignments
Expected duration of the task – think about how you are going to measure your
time units. Are you going to record time as actual hours, weeks or days. The
accuracy of this, at this stage in the project may not be too high but this is where
you have the chance to show a time tolerance level. You could indicate for
example, 8 hours plus or minus 25%
Identi cation of the relationships that exist between each task –some tasks will
occur independent of each other and therefore have no relationship. Some will
start when others nish and so have a nish-start relationship and some will nish
when others start which is a start nish relationship.
Determination of start and end dates of each task – depends on the relationship
identi ed
Resource assignment to the task – if you are lucky, the resource pool will be
available to you to assign resources to particular tasks. If you are even luckier,
none of those resources will need extra training or modi cation to get the job
done. Have you won lotto lately? No. Hmm. Don’t think you are going to be one
of the lucky project managers. Factor in training or modi cation time if necessary.
Estimates of the costs involved in each task – you will have xed costs (for
example xed pricing regardless of hours worked) and you will have variable costs
(for example per litre rates or per hour rates). This process of preparing for a
Work Breakdown structure will give you a more accurate estimate of budget
needs than the project scope did.
Remember that the WBS is an expansion of the project scope document into greater
detail.
If a task isn’t identi ed in this document, it’s not going to be completed in the project.
ID Task Duration Relationship Dates Resources Costs
1. Buy wedding rings
1.1 Choose 4 days N/A 4pm Margaret, $0

rings 1/9- Stephen
5pm 4/9
1.2 Pay deposit 1 day 1.1 8am 5/9- Stephen $1000

on ring 5pm 5/9
1.3 Get ring 1 day 1.1 8am Margaret $80

sizing done 5/9–
5pm 5/9
1.4 Pay o ring 3 months 1.1, 1.2, 1.3 8am Stephen $2000
6/9–
5pm
6/12
Identifying Levels and Elements
At the most macro level, the 'project' is referred to as level 1. We have called this the
'project outcome'. Our rst chunking of the project into smaller parts is referred to as
level 2 and we have called these chunks 'activities'. Further chunking down of our
project is referred to as level 3, which we have called 'tasks'.
We give a generic label to each of the components of a WBS. Either:
a 'summary' element, or
a 'detail' element.
A summary element is a unit of work that is decomposed further. Another way of saying
this is that it is a 'parent' to a lower level element.
A detail element is a unit of work that is not broken down any further. It is located at the
lowest level of each branch of the WBS and it is at this level that you determine detailed
time and cost estimates, resources and dependencies.
Gathering Data for the WBS
Frequently asked questions are: 'How many levels should my WBS contain?' or 'How
detailed should my WBS be when I am at the lowest level?’ While the issues may seem
complex, the answer is, in fact, quite straightforward. It relates to getting the data you
need. You will know that your project has been broken into su cient detail when you
are able to answer the following key questions:
How long will the element take to perform (often referred to as elapsed time)?
How much will the element cost to perform (if labour is involved, often referred to
as e ort)?
What resources will be required to perform the element (often referred to as

resource allocation)?
What must be completed or partially completed prior to starting this element

(often referred to as the dependency)?
The answers to these questions could well be available at level 2 in a small project. On
the other hand, it is not uncommon for very large projects to run to level 15 or even level
20 before it is possible to make these detailed estimates.
When this data is established, we can manage our project with a higher level of certainty,
particularly in regard to on time and within budget completion.
Project managers can use two methods to establish the level of detail we need in our
WBS:
bottom-up planning
top-down planning.
Bottom-Up Planning and the WBS
This process involves team members or a group of project stakeholders working

together through four key steps. This ensures those involved in the project have input
into and are committed to the project schedule right from the project beginning.
Step 1
Arrange a number of large blank sheets of paper, e.g. butcher's paper or charts, along a
wall. Each chart represents a potential project activity (or WBS level 2 label). You might
ask how many charts or sheets of paper should be used. The answer has to be
somewhat quali ed—but as a rough guide, four or ve charts would be used for a
smaller project and six or seven for a larger project. Blank 'post-it' notes are attached to
the top left hand corner of each chart to be used later in the process. These post-it
notes are a di erent colour to the ones used in Step 2.
Step 2
Ask participants to brainstorm the micro level actions that will be required to deliver the
project from start to nish. Direct them to:
Do this in silence, without consulting anyone.
Focus on actions that are within the scope of the project and leave out what are
outside the project scope.
Write only one action on each post-it note.
Record only speci c actions (not generic actions).
The time you will need varies from project to project, but ten minutes is usually enough.
Step 3
Ask participants to place post-it notes with a similar theme on the same chart. The
a nity or similarity that a person sees between their post-it notes and others on the
chart is what the process is seeking to achieve.
To reduce the risk of one person 'directing' where everybody places their post-it notes,
instruct them to:
Do this in silence, without consulting anyone.
Take turns to place post-it notes on the di erent charts one at a time, i.e. don't
put all your post-it notes on the charts before other team members.
The outcome of this process is called di erent names, but its generic label is the
'a nity diagram', which is one of the seven new quality tools.
Step 3 usually takes between ve and ten minutes
Step 4
Tell participants that our aim is to reach a consensus about the description of the piece
of work that is represented by each chart. Ask them as a group to:
Look at each separate chart and agree on a label for it.
Write the label on a post-it note and place it in the top left hand corner of the
chart.
The rules for these labels are that:
they may be single word labels, or
they may be 'verb' initiated short action statements.
Whichever form is chosen, it must be used consistently. Single word labels tend to be
used for larger projects and short action statements for those projects that are not so
large or complex.
The purpose of bottom-up planning is not to provide a detailed plan for the whole
project. Rather, it is to identify the labels for the 'chunks' of work that it has been
decided to break the project down into. Bottom-up planning is often used for projects
that are somewhat di erent from those usually undertaken by an organisation. It is a
useful method, as it reduces the risk of omitting necessary project activities.
Top-Down Planning and the WBS
Top-down planning takes up where bottom-up planning leaves o . As we've discussed,

bottom-up planning is used to develop the level 2 labels in the WBS. Once these level 2
labels have been determined, the bottom-up planning process has ful lled its function
and the balance of the WBS is determined using the top-down planning method.
Whereas the bottom-up planning process used micro level actions to determine high
level labels (level 2), the top-down planning process uses the high level labels (level 2) to
determine the next level down labels (level 3).
Top-down planning is usually used on projects that an organisation is used to

managing. In other words, project managers have a good idea of what the labels will be.
As for bottom-up planning, a proven process can be used to improve the robustness of
the outcome. This process involves the team members or a group of project
stakeholders working together through two key steps.
Step 1
In what is often referred to as the transition process, we start where we left o in the
bottom-up planning process. That is, we begin with pages of post-it notes on charts with
the level 2 labels represented on the post-it note in the top left hand corner of each
chart.
Starting with any chart, but usually the end one, we strip o all the post-it notes except
the level 2 notes. We place the rest of the post-it notes from this chart in a group out of
sight.
Step 2
Ask the team to:
Brainstorm the labels that will represent the level 3 chunks of work for the level 2
label we have chosen.
Write these level 3 labels on new post-it notes.
Place them underneath and to the right of the top post-it note, as they would
appear if we were performing this process using a software planning package.
As a general rule in planning projects, the number of lower level 'chunks' compared to
higher level chunks should be a minimum of two (otherwise there is no point in driving
the plan to a lower level) and a maximum of around ten, but preferably eight.
The reason for limiting these breakdowns is that if our project is quite complex, this
complexity is better dealt with by adding levels, rather than by increasing the number of
'chunks' for a given higher level 'chunk'. This is often described as dealing with
complexity by using a hierarchical structure—often referred to as the 'tree, branches
and twigs' model.
There are obvious advantages to the creation of a WBS but there are also disadvantages.
Projects work to deadlines and if that deadline is too tight because of bad time
estimations, chances are there will be a lot of unhappy stakeholders. People often
underestimate the amount of time needed to implement projects, particularly when

they're not familiar with the work that needs to be done.
For instance, they may not take into account unexpected events or urgent high priority
work; and they may fail to allow for the full complexity of the job. This is a trigger for
scope creep to set in. So it is crucial to estimate time correctly.
Time estimations
What is an estimate? According to the Oxford Dictionary it is: an approximate

calculation or judgement of the value, number, quantity, or extent of something.
Estimating is predicting the time to be allocated to, and cost of, completing project
deliverables and should be done by the person most familiar with the task.
So why is it important to estimate time? When you undertake estimations you are trying
to balance the needs and expectations of the stakeholders during the project
implementation.
Good estimates support good project decisions.
Your estimations help to schedule work; to determine how long the project should
take. You are developing time-phased budgets and you are establishing the
project baseline.
This helps to determine whether the project is worth doing or not and if it is worth
doing, you can keep an eye on how well it is progressing through the
implementation.
A project sponsor often judges whether a project has succeeded or failed depending on
whether it has been delivered on time or under budget. To have a chance of being
successful as a project manager, you need to be able to negotiate achievable deadlines.
The project manager will need to follow 4 steps to estimate the time a project will take.
1. Firstly you have to understand what is required. By completing a Work Breakdown

Structure and ensuring that time is allowed for meetings, reports,
communications, testing and every other activity required to complete the project
you are on the way to full understanding of the project requirements
2. List these activities in the order they need to happen. At this point you don’t need
to think about how long they will take but you will need to work out the
relationships depending on start and end dates as we discussed in the last lesson.
3. Decide who to involve because a project manager cannot do all of this alone.
Regardless of how self important a project manager may feel, in reality he doesn’t
know everything about everything and so he should brainstorm this section with
all the subject matter experts, that is, the people who actually will be doing the
work. That also helps to cement relationships with a team because if they work
out how long it will take, they will work harder to make sure they meet the
deadlines set. But remember that people are often overly optimistic, and may
signi cantly underestimate the amount of time that it will take for them to
complete tasks.
4. Make your estimations. To begin, estimate the time needed for each task rather
than for the project as a whole. List all of the assumptions, exclusions and
constraints that are relevant; and note any data sources that you rely on. This will
help you when your estimates are questioned, and will also help you identify any
risk areas if circumstances change.
It is a general project management rule to assume that resources will be productive for
only 80% of the time. Using this presumption allows the schedule to build in time for
unexpected events such as sickness, equipment or supply failures, accidents, meetings,
etc.
In the early stages of project planning, you often won't know who will do each task – this
can in uence how long the task will take. For example, an experienced chef should be
able to cater for a 3 course meal for 100 people much more quickly than someone less
experienced. Until that chef is hired, the schedule should be planned to be for the less
experienced chef.
You can build this into your estimates by giving best, worst, and most likely estimates,
stating the basis for each view.
When estimating an activity’s duration, consider past experience, expert opinion, and
other available sources of information to clarify the following components of the activity:
Knowing the types of resources an activity requires can help you improve your estimate
of the activity’s duration. For example, not all printers print at the same rate. For
example, a printer that produces 100 copies per minute can complete a job in half the
time a printer that produces 50 copies per minute requires. Likewise, a large printing job
can take half as long if you have access to a printer for eight hours a day rather than
four hours a day. Specifying the characteristics of the particular machine you’ll use to
make copies can improve the activity’s duration estimate.
Estimation Techniques
There are 5 main estimation techniques
1. Top-Down Estimating or Macro Estimation
In top-down estimation, you develop an overview of the expected timeline rst. You use
the actual durations, e ort or costs from previous projects as a basis for estimating the
e ort or costs for the current project. For accuracy it's often helpful to compare top-
down estimates against the next method which is bottom-up estimates.
2. Bottom-Up Estimating or Micro Estimation
This is considered to be the most accurate method for generating project estimates.
Bottom-up estimating allows you to create an estimate for the project as a whole. To
analyse from the "bottom up," break larger tasks down into detailed tasks, and then
estimate the time needed to complete each one. Because you're considering each task
incrementally, your estimate of the time required for each task is likely to be more
accurate. You can then add up the total amount of time needed to complete the plan.
The method uses the Work Breakdown Structure (WBS) developed during the planning
stage of the project. Estimates are created for all tasks at the lowest level of the WBS and
then these are accumulated to determine the estimates for the whole project. One
disadvantage of the bottom-up method is that it is much more time-consuming than
other methods.
3. Comparative Estimating
With comparative estimating, you look at the time it took to do similar tasks, on other
projects.
4. Parametric Estimating
With this method, you estimate the time required for one deliverable; and then multiply
it by the number of deliverables required. For example, if you need to create pages for a
website, you'd estimate how much time it would take to do one page, and you'd then
multiply this time by the total number of pages to be produced.
5. Three-Point Estimating
To build in a cushion for uncertainty, you can do three estimates – one for the best case,
another for the worst case, and a nal one for the most likely case. Although this
approach requires additional e ort to create three separate estimates, it allows you to
set more reasonable expectations, based on a more realistic estimate of outcomes.
Formula
Before we look at formulas to calculate your project schedule we need to de ne some

basic terms related to project time.
Duration is important for scheduling and for determining how long project
activities will take to complete.
E ort is used to determine how much it will cost to complete the activity in terms
of human resources. These are usually measured in labour units, e.g. hours or
days.
Project calendar time is the days from project start to project nish based on a
normal calendar. It includes all days of the week regardless of whether project
work is carried out on these days.
A factor that may be taken into consideration when estimating time is the amount of
e ort required to do a task. This is usually calculated when allocating resources to tasks,
but in some projects, there may be a nite number of resources pre-allocated and so
duration will rely on e ort.
E ort = duration x resource units

For example: you have allocated 10 days duration to a task and you know that it will
take 10 men to complete the task in ten days (that is the e ort of 10 men). Therefore
your e ort calculation is 100 man days. If the project sponsor said that the duration was
too long and needed to be halved, your calculation would then have to show a doubling
of your resource units to reach the same result. That is the duration of 5 days multiplied
by 20 men (double the original 10 men)
Duration = E ort / resource unit

Taking that same example, if we wanted to calculate the duration but knew the e ort
and resource units we could say that 100 man days (the e ort) divided by 10 men (the
resources) would give us duration of 10 days
Resource units = E ort / duration

And also, if we know the e ort is 100 man days and divide that by the 10 days duration
we can allocate 10 men as resources.
A cautious way to generate your time estimates is to use a simple formula. The formula
works like this:
Most Optimistic (TO) – best case scenario
Most Likely (TL) “normal” scenario
Most Pessimistic (TP) Worst case scenario
((TO x 1) + (TL x 4) + (TP x 1)) / 6 = TE
i.e. sum of (optimistic x 1) + (likely x 4) + (pessimistic x 1) / by 6 = expected task duration
TE is earliest possible completion time
Go on; try it for another simple example:
You have to go to the shop to buy the cat food. You need to estimate how much time
that might take. In the best case, with no tra c holdups or chance meetings that require
you to converse with anyone it usually takes about 15 minutes. But what usually
happens, that is, the most likely scenario, is that you go around the time school is getting
out and the speed zones drop to 40kph and children press the button on the pedestrian
crossings. So, usually, it takes you about 20 minutes to get the cat food. The worst case
scenario is that you avoid the school time zone but just as you get into the car to begin
the journey, Great Aunty Mary comes up the street on her walking frame and you feel
obligated to give her a lift to the shops and by the time she gets into the car and
measures you up for your next knitted Xmas jumper the school zones have been
activated and, guess what?, it’s fete day and there are 3 times the number of people
pressing the pedestrian button as usual. Worst case scenario… 35 minutes.
Let’s use the formula now. ((15 * 1) + (20 * 4) + (35*1))/6 = 22. Based on that formula you
would leave yourself 22 minutes to get the cat food.
Taking another example with a more thorough approach, let's assume that we have a
part-time painter and decorator to prepare and paint a room. For this particular room,
we have decided to include a feature dado border around the room and to nish all
timberwork in a mirror nish. We know this painter is meticulous in his work and we are
happy to wait until he is available for our job.

The painter gave us the following availability and plan for work.
We now take that information and use it to calculate e ort, duration and project
calendar time. Notice that we have assumed that our painter does not work weekends
or public holidays and, therefore, we do not take them into account when we calculate
duration.
Estimating Time with Bottom-Up and Top-Down Planning

Let's look at how bottom-up and top-down planning can be applied to the way in which
time is estimated for a project.
In our painter example, the project was broken down into daily blocks of time and work
was allocated to these days. This enabled a micro level view of the project and a detailed
estimate of the e ort and duration. When estimating at this level of detail, we need to
complete a bottom-up estimate, which will produce the micro level view of the project
that we need.
If we were to take the same example and perform a top-down estimate, we would not
be exposed to the same level of detail, but rather a more macro view of the project. For
example, in a brief discussion with our painter we would learn that there was between
say 6–8 person days of e ort required to complete the project and that this would be
done over approximately a fortnight starting around the middle of the month.
If we said that sounded ne, the painter might then suggest that we engage him on a
time and materials basis. That is, we would incur whatever cost (in labour and materials)
that it takes to complete the project. For example, if the painter had di culty painting
one of the walls because of rising damp and this added two days of e ort to the project,
we would be obligated to pay this extra.
If on the other hand, we had a xed price contract with the painter, this may well have
been struck at the six, seven or eight days' e ort price. We could then expect our painter
to complete the project for this price, regardless of the e ort involved. The upside for
the painter is that if things went well and the job did not take as long as expected, he
would bene t from the xed price agreement.
Identifying Dependencies
As with our painter example, very few projects consist of activities that start and nish
on the same day. On most projects, activities are interdependent and relate to other
activities in some way. While projects will include a number of independent activities
that have no relationship to other activities, most project activities are constrained by or
dependent on other activities.
Four types of logical dependency can exist between two project activities.
1. Finish-to-start
Finish-to-start dependency means that the start of the next activity must wait for the
nish of the previous activity. For example:
2. Start-to-start
Start-to-start dependency means that the start of the next activity must wait until after
the start of the previous activity, however activities may overlap. For example:
3. Finish-to- nish
Finish-to- nish dependency means that the next activity cannot nish until the nish of
the previous activity, however activities may overlap. For example:
4. Start-to- nish
Start-to- nish dependency means that the start of the next activity must occur before
the nish of the previous activity. Both activities must overlap. For example:
Identifying Lag and Lead Times
When talking about the four types of dependency, the terms lag time or lead time are
used. Let's see how they might apply to our previous examples.
1. Finish-to-start dependency

It might be desirable to allow sanding dust from the preparation to settle before we
paint the room. The lag time between the two activities might be four hours, especially
for a good quality paint nish.
2. Start-to-start dependency

We might wish to have more than half the furniture available before we attempt to
arrange it. Depending on the distance over which the furniture has to travel and how
much furniture there is, the lag could be anywhere from hours to days.
3. Finish-to- nish dependency

We might know that the data analysis will be complicated, requiring quality time
between the end of populating the spreadsheet and completing the data analysis. So,
we might nominate a lag time of say ve days. The data analysis will not be completed
until ve days after the spreadsheet is populated.
4. Start-to- nish dependency

We may wish to run the replacement system for one full accounting period before the
legacy systems are turned o . The start up of the replacement system would have a
lead time of 31 days over the decommissioning of the legacy systems.
Developing a Gantt chart
One of the most widely used scheduling tools is the Gantt chart—a timeline that shows
activities, their duration, their sequence and their dependency. It is a useful graphical
(and therefore easy to understand) representation of a project.
The Gantt chart was named after Henry Gantt and rst appeared in the early 1900s. It is
one of a number of bar charting techniques that plots the activities of projects as bars of
time on a chart showing duration or calendar time. The activities are listed to the left
hand side of the chart in a vertical column with the earliest at the top and the latest at
the bottom. On rows beside each activity are bars representing the amount of time that
the activity is expected to take (duration or calendar time). Vertical lines with arrows are
drawn between the bars to indicate dependency.
The illustration shows a project consisting of activities A–J, starting on day 1 and
concluding on day 22.
If we were to write the plan in text form, it might be something like:
Activity A commenced on day 1 and concluded on day 3.
Upon conclusion of Activity A, but not before, Activity B will commence, and will
conclude on day 5.
Following completion of Activity B, both Activity C and D can start simultaneously.
Following completion of Activity D, Activity E and H can start simultaneously.
Following completion of Activity E, Activity F may commence.
Activity J can start following completion of Activity C, but not before.
Activity I can start any time after Activity H is complete.
Activity G can start upon completion of all of Activities F, I and J.
Activity G is scheduled to conclude on day 22, provided the project is running to

schedule.
Embedding Milestones
Milestones are signi cant events or points in time in a project. They are a useful way of
signalling the start or nish of some part of the project and where approvals, reporting
requirements and inspections have been completed. They provide us with a useful
measure of project progress.
Let’s now add milestones to our illustration. These appear as numbered diamond
shapes in the graphical part of the diagram and are listed as text in the left hand
column. The diamonds are as they would be in a live project. Notice they are placed at a
point in time (e.g. Milestone 4 is at the end of day 10). A milestone does not have the
concept of a duration or e ort associated with it. Rather, it is always the culmination (or
start) of duration or e ort.
A key, but perhaps obvious, di erentiator between activities and milestones is in the
language used to represent them. From level 3 in the work breakdown structure and
beyond, the generally accepted description of an activity starts with a verb, e.g. 'Build
prototype product'. In contrast, milestones start with a noun, e.g. Prototype built and
signed o .
Milestones:
must be concise
should start with a noun
must be clear and unambiguous.
Critical Path Analysis
Now you have your task durations, scheduling and milestones all clearly illustrated in a
Gantt chart and you are thinking you have covered all the bases and that your project is
going to be a marvellous success. Hopefully it will be!
There is just one more tool you should investigate prior to handing your hard work over
for nal approval and that is determining your critical path. A critical path analysis
identi es the tasks which must be completed on time for the whole project to be
completed on time, i.e. the CRITICAL TASKS.
It also determines which tasks can be delayed in the event of catastrophes in scheduling
and which tasks you could accelerate to complete a project within remaining available
time. Whilst a critical path analysis is very useful, it can be a disadvantage if you use it to
only manage your project because it does not show the full gamut of tasks necessary for
project completion.
As with Gantt Charts, the essential concept behind Critical Path Analysis is that you
cannot start some activities until others are nished. These activities need to be
completed in a sequence, with each stage being more-or-less completed before the next
stage can begin. These are 'sequential' activities. Critical path identi es the sequence of
activities that will allow the earliest nish of the project.
The critical path is the longest sequence of activities from project start to end that
should be started and completed EXACTLY as scheduled. Imagine you have a project
that will take 100 days to complete according to your Gantt chart. If the rst task on the
critical path is 1 day late in completion, your project will now take 101 days to complete
UNLESS another task can be reduced in time by 1 days.
The critical path is simply all the tasks that determine the end date of your project
schedule.
Creating a Critical Path Network Diagram
There are 6 steps to creating a critical path network diagram.
1. Speci cation of activities – The WBS is used to identify the activities at all levels but
in the critical path method, only the higher-level activities are selected.
2. Establish activity sequence – In this step 3 questions are asked:
Which tasks should take place before this task happens?
Which tasks should be completed at the same time as this task?
Which tasks should happen immediately after this task?
3. Gantt chart – When the activity sequence has been correctly determined, the
diagram can be drawn.
4. Activity estimates – duration of critical tasks is estimated.
5. Critical path is identi ed – For this step a project manager must determine 4
parameters of each activity of the network diagram:
Earliest start time (ES) – the earliest date an activity can start once the
previous dependent activities are over.
Earliest nish time (EF) – ES + activity duration
Latest nish time (LF) – the latest time an activity can nish without delaying
the project
Latest start time (LS) – LF - activity duration
The time between ES and LS or between EF and LF is known as oat time. During oat
time and activity can be delayed without delaying the project nish date. The critical
path is the longest path of the network diagram. If a project needed to be accelerated,
the critical path activities would have to be reduced.
6. Draw critical path diagram – the diagram becomes a live artefact and will be
updated with actual values once the activities are completed to give a more
realistic date for meeting the deadline.
Critical path diagrams o er a visual representation of the project activities, determine

project duration and allow for tracking and monitoring during project implementation.
Project Schedule vs Project Baseline
According to A Guide to the Project Management Body Of Knowledge (PMBOK GUIDE,

5th Edition), a schedule baseline is the approved version of a schedule model that can
be changed only through formal change control procedures and is used as a basis for
comparison to actual results. It is accepted and approved by the appropriate
stakeholders as the schedule baseline with baseline start dates and baseline nish
dates. During monitoring and controlling, the approved baseline dates are compared to
the actual start and nish dates to determine whether variances have occurred. The
schedule baseline is a component of the project management plan.
Having looked at the di erent scheduling tools, you will realise that project schedules
can take di erent formats. For example, sometimes schedules are displayed in hard
copies on boards in the project management o ce, other times they are developed
using software packages and are only available as electronic copies. On some projects
Gantt charts will be used, other projects may use a combination of project scheduling
formats.
Whichever format is chosen for a project, for a schedule to be e ective it must:
be easily understood by all project stakeholders
clearly identify critical work activities and tasks
be in su cient detail to enable the timing and monitoring of project resources
be in a similar format to and be aligned to other organisational plans that share

common resources
be included as part of the project information system
be easily updated and modi ed.
The last point is important because although a great deal of work may have gone into
the project schedule, once the project is underway changes may need to be made.
Despite laying out a tentative project timeline and a scope of work document for the
endeavour, due to changing market trends and shifting stakeholder interests sometimes
project objectives and the ow of activities tying the beginning to the end have to be
altered.
From these contingencies rise the concepts of baseline schedule (also referred to as
schedule baseline) and project schedule.
A baseline schedule and a project schedule are two di erent documents entirely.
Baseline schedule – original (frozen) project schedule that was decided upon prior to
implementation.
Project schedule – the working (live) schedule that is updated to accommodate all
changes, delays and problems encountered throughout the project life-cycle. Milestone
dates, completion dates, start dates are shu ed and juggled as the project schedule
works towards trying to keep to the baseline schedule.
As the project hurtles towards completion a project manager compares the variances
between the baseline schedule and the actual project schedule, determining courses of
remedial action when necessary and documenting causes of variance for future projects.
Scope Management Plan
In Module 1 we discussed project initiation documentation including the project scope

statement. During this initial concept or initiation phase of the project, a lot of raw data
had been collected. You looked at stakeholders, timelines, speci cations, organisational
briefs and mission statements and made a solid and realistic document that would
consolidate all of that data and produce the nal project scope. (realistic is the optimum
word here)
The project scope can be called by a few other names so please don’t be confused by the
other terms when you are doing your own research. It can be called a project charter, a
project brief, a project overview statement and sometimes a Scope of Work statement.
There is no hard and fast rule about which terminology to use. There is also no hard
and fast rule about which template to use to document it.
Now, with the additional work you have done in determining quality and scheduling
requirements, you can now start thinking about how you are going to manage the
project scope and avoid scope creep and schedule variances if possible.
This involves creating a scope management plan in collaboration with the project
sponsor, selected team members, stakeholders or other project managers. The plan
must de ne how to develop, monitor, control and verify formal changes to project
scope.
The key elements of a project scope management plan are:
I can hear a sigh of relief as you see that you have already done most of the work
required for the scope management plan; the scope statement and the WBS. By
previously analysing your stakeholders and determining in uence, impact, roles and
responsibilities of each you also know who has authority over various tasks. So rest easy,
from here on it isn’t too di cult to have the relevant ‘authorities’ verify your work and
validate your quality control processes.
Changes or alterations that occur during implementation must adhere to the project’s
change control procedure. We will look at these in more detail in Module 5, but for now
we need to allocate who are the stakeholders delegated to authorise those changes.
It is vital to have strict controls over such changes to halt risks that may incur scope
creep. All interested parties must be informed and kept up-to-date on the projects
progression and your scope management plan outlines this in writing.
A scope management plan ensures that everyone has a common and thorough
understanding of the projects overall objective and how this need will be met. It de nes
the role and responsibility of every individual linked to the project and the
communication that must occur between di erent parties to ensure it success.
Let’s have a look at what makes up a scope management plan in a little more detail:
PROJECT SCOPE MANAGEMENT PLAN
DESCRIPTION Displays a top-level summary of essential information relating

to the Scope Management Plan such as:

Author: Project Manager (include contact details)

Project Name.
Version # of Scope Management Plan
Approval: Lists the names and job titles of each

person who as given approval and sign-o of this
plan.
Circulation list of who (name, location &

organisation) has received the plan
Describes how scope of project will be de ned, developed

INTRODUCTION
and validated
Describes process used to control and manage scope

during its lifespan, so that project creep can be avoided.
SCOPE Summarises scope management approach for project.

MANAGEMENT De nes who has overall responsibility and authority for
APPROACH this area as well as what documents and measures will
rstly de ne and then validate the scope.

Describes entire change request process.
ROLES & Lists names, contact details and responsibilities of anyone

RESPONSIBILITIES involved in scope management.
States who is responsible for and has authority to accept

the scope’s project deliverables
States who has overall authority to accept the nal project

deliverable.
SCOPE Describes how project deliverables will be de ned so that

DEFINITION each one has a detailed description.
Refers to any other documents that it uses as part of this

process i.e. Project charter, scope statement etc.
Describes tools and techniques that will be used in scope

de nition process.
PROJECT SCOPE Describes work required for each of the project

STATEMENT deliverables in detail.
WORK WBS outlines how the scope has been divided up or

BREAKDOWN decomposed into manageable chunks.
STRUCTURE
(WBS)
Describes how each project deliverable will be validated

SCOPE
or veri ed against initial scope baseline.
VALIDATION
Describes how each deliverable will be formally signed o
and accepted by the ‘customer’ during project lifecycle
Describes single end deliverable that de nes the end of

the project.
SCOPE CONTROL Describes how project creep will be prevented and

changes to the scope baseline assessed, evaluated,
approved and integrated into a new version of project
scope.
Outlines how progress will be monitored and status

reported
Outlines how any approved changes will be

communicated within project team, third-parties and to
relevant stakeholders.
Section Summary
A quality project is one that satis es the needs of the client after external constraints
have been considered. The role of the project manager in a challenging one and is as
much about people management as the management of processes.
Throughout the project life cycle the project manager must interact with a range of
stakeholders to ensure the project meets their requirements and is completed using
processes and working methods that will achieve a quality outcome. E ective quality
management involves focusing on the total management of a process and all of the
people involved.
Project managers must take responsibility for project quality assurance and for ensuring
that the required standards of quality are attained. They can achieve this by
implementing a quality management plan that provides a framework with appropriate
management processes, quality control procedures and documentation for achieving a
quality outcome.
Each project needs to be audited and the quality management system must also be
audited to ensure that continuous improvement takes place. It is the project manager's
role to ensure that audits are scheduled throughout and at the end of the project life
cycle to promote continuous improvement on that project and on future projects. We

will discuss this in more detail in Module 5.
Topic Resources
Using WBS for E ective Project Estimation:

http://www.projecttimes.com/articles/usinu-work-breakdown-structure-wbs-for-
e ective-project-estimation.html
Managing Project Baselines:

http://thepmcoach.blogspot.com.au/2010/08/managing-project-baseline-
changes.html
Poor scope-management practices could precipitate project failure:

http://www.techrepublic.com/article/poor-scope-management-practices-could-
precipitate-project-failure/
Bene ts of a Scope Management Plan:

http://www.projecttimes.com/articles/bene ts-of-a-scope-management-plan.html
Further Reading and Useful Websites
Look at what can happen when you get the scheduling wrong by reading this
article from the LA. Times: http://mynewsla.com/government/2015/11/12/over-
budget-scheduling-delays-plaguing-mta-rail-project/ (Accessed 14th November
2015)
Some scope management plan component templates are available in various

formats from here: http://project-management.magt.biz/templates/02-scope-
mgmt/ (Accessed 14 November 2015)
The Ultimate Guide to Critical Path Method is a website full of expert articles on
creation and use of critical path analysis. https://www.smartsheet.com/critical-
path-method (Accessed 14th November 2015)
Examples of Work Breakdown Structures are available from:

http://www.stakeholdermap.com/plan-project/example-work-breakdown-
structures.html (Accessed 14th November 2015)
A set of short animated videos outline project scheduling in simple to understand

language. I suggest you watch them in order:
Project Time Planning – Process: https://www.youtube.com/watch?

v=BBZVxz2HS00 (Accessed 14th November 2015)
Project Time Planning – Resources: https://www.youtube.com/watch?

v=vhk2EwtoVw0 (Accessed 14th November 2015)
Project Time Planning – Break Down: https://www.youtube.com/watch?

v=l4tlexWOaNI (Accessed 14th November 2015)
Project Time Planning – Critical Path: https://www.youtube.com/watch?

v=lJ0TlbcbL-A (Accessed 14th November 2015)

Module 4 - Project Schedule PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Module 4 - Project Schedule PDF

Enviado por

Direitos autorais:

Formatos disponíveis

4/28/2019 Laureate International Universities

MODULE 4 - PROJECT SCHEDULE

Work Breakdown Structure

Let’s use an example here of a wedding plan.

'Chunking' Project Work

A Work Breakdown Structure document helps to answer some fundamental project

What work must be performed?

How long will each task take?

What resources can perform the work?

How much investment is required?

ID Task Duration Relationship Dates Resources Costs

1. Buy wedding rings

1.1 Choose 4 days N/A 4pm Margaret, $0

1.2 Pay deposit 1 day 1.1 8am 5/9- Stephen $1000

1.3 Get ring 1 day 1.1 8am Margaret $80

Identifying Levels and Elements

Gathering Data for the WBS

What resources will be required to perform the element (often referred to as

What must be completed or partially completed prior to starting this element

Bottom-Up Planning and the WBS

This process involves team members or a group of project stakeholders working

Do this in silence, without consulting anyone.

Write only one action on each post-it note.

Record only speci c actions (not generic actions).

Do this in silence, without consulting anyone.

Step 3 usually takes between ve and ten minutes

Look at each separate chart and agree on a label for it.

The rules for these labels are that:

they may be single word labels, or

they may be 'verb' initiated short action statements.

Top-Down Planning and the WBS

Top-down planning takes up where bottom-up planning leaves o . As we've discussed,

Top-down planning is usually used on projects that an organisation is used to

Write these level 3 labels on new post-it notes.

underestimate the amount of time needed to implement projects, particularly when

What is an estimate? According to the Oxford Dictionary it is: an approximate

Good estimates support good project decisions.

1. Firstly you have to understand what is required. By completing a Work Breakdown

There are 5 main estimation techniques

1. Top-Down Estimating or Macro Estimation

2. Bottom-Up Estimating or Micro Estimation

Before we look at formulas to calculate your project schedule we need to de ne some

E ort = duration x resource units

Duration = E ort / resource unit

Resource units = E ort / duration

Most Optimistic (TO) – best case scenario

Most Likely (TL) “normal” scenario

Most Pessimistic (TP) Worst case scenario

((TO x 1) + (TL x 4) + (TP x 1)) / 6 = TE

i.e. sum of (optimistic x 1) + (likely x 4) + (pessimistic x 1) / by 6 = expected task duration

TE is earliest possible completion time

Go on; try it for another simple example:

happy to wait until he is available for our job.

Estimating Time with Bottom-Up and Top-Down Planning

Identifying Lag and Lead Times

1. Finish-to-start dependency

2. Start-to-start dependency

3. Finish-to- nish dependency

4. Start-to- nish dependency

Developing a Gantt chart

Activity A commenced on day 1 and concluded on day 3.

Following completion of Activity B, both Activity C and D can start simultaneously.

Following completion of Activity D, Activity E and H can start simultaneously.