Module 4 - Project Schedule

4/28/2019 Laureate International Universities
MODULE 5 - PROJECT MONITORING
Learning Resources
Quality Management Roles and Responsibilities
What responsibilities do you, the project manager, have in establishing and maintaining quality throughout
a project? Obviously motivating sta and ensuring adequate resources are available is an important role.
You also have to be involved in designing the quality control system at the project proposal and
development stages. During the production stage you must ensure that monitoring and auditing is done
properly. At the termination stage you need to work with project team members to complete a nal project
review and identify any improvement opportunities for future projects. However you can't just focus on the
processes. E ective quality management is as much about managing people as resources.
In an ideal situation the project manager is involved from the outset of the project. So in the proposal stage
he establishes the speci c requirements of the client and is involved in the development of project scope
and speci cations and identifying the resources required; but the reality is often di erent.
On some projects you may nd yourself working for a contractor. Consultants who interpreted the client's
needs may have designed the project. Specialists on the contractor's sta may have conducted the
tendering process. There may be two project managers. One may work for the client and manage the
project development to the award of tender. The other may work for the contractor and only start at the
project production phase. The rst project manager may still have some authority or in uence on behalf of
the client.
You could be handed a de ned situation with the client relationship established and the project scope,
including speci c quality requirements, de ned. If this has been well done, you have a sound basis to work
on. If it has been badly done, you may nd yourself managing a poorly thought out project which cannot be
completed to the required quality standard within budget and on time.
Continuous improvement may be achieved during a project, but you have to balance this against the need
to deliver on time and within budget. Working with the client early on is an advantage, but ongoing
consultation during the project life cycle may give you information about the client on which to base
decisions about compromises that have to be made and constraints that must be taken into account.
Certain stakeholders have de ned authority and in uence, notably senior management and the statutory
bodies or a higher authority that issue approvals, e.g. the EPA. Senior management has a responsibility to
set the quality management system for the organisation and to ensure that the systems for individual
projects are compatible with the organisation system. They must ensure that the appropriate speci c
https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_68678_1&content_id=_7184740_1&mode=reset 1/14
standards are adopted in projects completed by their sta . A building surveyor may need to approve plans
for a building. Other government inspectors have authority to enforce safe working practices. Some will
have greater in uence than others. Financiers may impose conditions before making a loan. Others, such
as designers, lawyers and contractors have speci c expertise. They can signi cantly in uence the structure
of the project, the nal requirements and the way it is carried out.
Quality Management Plan
If you have forgotten any of the basic principles of quality management we have discussed earlier, refer
back to Module 3 – Project Quality to refresh your memory before we look at what a quality management
plan looks like.
The Quality Management Plan is an integral part of any project management plan. The purpose of the
Quality Management Plan is to describe how quality will be managed throughout the lifecycle of the project.
All stakeholders should be familiar with how quality will be planned, assured, and controlled.
A Quality Management Plan includes the processes and procedures for ensuring quality planning,
assurance, and control are all conducted including:
Introduction states the purpose of the quality management plan
Quality This section describes the approach the organisation will use for managing
Management quality throughout the project’s life cycle from both a product and process
Approach perspective.
Quality This section should describe how the project team and/or quality group will
Requirements identify and document the quality requirements and standards. Additionally,
/ Standards there should also be an explanation of how the project will demonstrate
compliance with those identi ed quality standards. The quality standards and
requirements should include both the product and processes.
Quality This section should explain how you will de ne and document the process for
Assurance auditing the quality requirements and results from quality control
measurements in order to ensure that quality standards and operational
de nitions are used. This section should also document the actual quality
assurance metrics used for this project.
Quality Control
This section describes how you will de ne and document the process for
monitoring and recording the results of executing the quality activities to assess
performance and recommend necessary changes. Quality control applies to the
project’s product as opposed to its processes. It should include what the

acceptable standards and/or performance are for the product and how these
measurements will be conducted.
Quality Control This section should contain a sample or useable table/log to be used in taking
Measurements quality measurements and comparing them against standards/requirements.
These forms may be found in many di erent styles or formats. The most
important aspect of this log is to provide documentation of the ndings. If actual
measurements do not meet the standards or requirements then some action
must be taken. This may be done in regularly scheduled project status meetings
or as necessary throughout the project lifecycle.
Sponsor This section is for authorisation to implement the quality management plan.
Acceptance
Quality Management Manuals
On a small project a quality management plan may simply be a small number of procedures, checklists and
inspection and test plans. On a large project, however, a quality management manual may be required in
hard copy or electronic format. This manual may include individual quality plans for design, procurement,
installation and testing, as well as inspection and test plans, procedures for all project activities (e.g. human
resource management, procurement, document control). In some projects clients require manuals to be
prepared in accordance with speci c standards or according to their own organisational requirements. You
need to establish this early on in the proposal stage, before you start to develop the quality management
manual for that project.
If you have responsibility for developing a quality management manual, make sure its format and content
are consistent with organisational policies and any certi cation conditions that the organisation must
comply with. This manual should be regularly updated and there should be restrictions placed on who is
authorised to make changes to it. However, project team members must have access to those sections of
the plan that they need to carry out their work.
Audit of Quality Management Systems
Every aspect of the quality management plan and the output of the production process should be reviewed
during and at the end of the project life cycle. Auditing the project processes allows you to thoroughly
review what happens in a project. Audits should be scheduled in any project management plan you
prepare.
A quality audit is an independent and systematic assessment of project activities and outputs to determine
if they comply with the requirements documented in the project management plan. An audit involves a
thorough examination of how the project was managed and conducted. They can be conducted by internal
or external auditors who review the project’s:
speci cations
procedures
project information systems
documentation
budgets
expenditures
schedules.
The timing of an audit depends on what is being audited. Early on in the project life cycle it is useful to
review the technical processes being used in a project. Later in the project life cycle, budget and schedule
audits are useful for senior management to track project progress.
Role of the Project Manager in the Audit Process
The project audit usually has a number of stages. Typically these are:
Audit team is briefed on project requirements
On-site audit is carried out
Audit report is written
Audit report is distributed.
Project managers are usually involved in the brie ng of the audit team. Before and during the audit, you
need to provide auditors with the information and data they need to carry out the audit. This usually
involves giving them access to sta familiar with the project, including project team members. You also
need to inform the project team that an audit is taking place and that the purpose of the audit is to identify
opportunities for improvement.
When the audit report is completed, it is up to the project manager to:
analyse the report
identify areas that need attention
implement any necessary improvements
where relevant notify project stakeholders, including senior management of the information included
in the audit report
ensure that the audit report is made available on the project information system.
Some examples of what an audit report might identify include:
weaknesses in the procedures for dealing with the client in the early stages to clearly de ne the
project outcome
design and documentation processes need amending
procedures for supervision of contractors may need review to ensure that contractors clearly
understand requirements and deliver an outcome that conforms to the project speci cations.
Due to the xed duration of projects only limited improvements may be possible. Usually a formal, nal
audit is needed at the end of the project to ensure that the project processes produce the desired quality.
Question: What happens if there is a need to make changes to scope, either as a result of a quality
management audit realising risks to product or processes, or due to other impacts such as changes to
business, stakeholder, resources, funding or schedule needs?
Answer: A corrective action needs to occur.
Change requests
Change is inevitable. Change is variable. Change means di erent things to di erent people.
Some of the more common terminologies are:
Scope changes the agreed scope and objectives of a project to accommodate a need not
change originally de ned in scope of project
Change management process used to review, approve and implement controlled changes
control to project deliverable
Version administrative control of multiple versions of a deliverable which track changes

control after initial completion
Change applies to changes in human resources (behaviours) and how those changes are
management handled
Question: Are all changes to be feared?

Answer: No.
Project managers should be focussed on delivering projects on time and in budget and so should be
rigourously monitoring scope creep to ensure this. But project managers also have a duty to optimise the
bene ts generated by the project which may mean making changes that will be bene cial in the long term
rather than detrimental in the short term. This is particularly relevant in quality management.
In instances where you decide to accept changes to a project's scope, these must be properly documented
along with any ow-on changes to other aspects of the project. They also must be backed up with evidence
as to why the changes should be authorised.
Question: How is evidence provided?

Answer: By analysis of a properly developed and baselined schedule.
Remember that projects have de ned life-cycles. A project does not go on forever. It’s start and end dates
are there to give substance to the allocation of resources and achievement targets. Any variances from that
baseline have ow on e ects throughout the project life-cycle. Variance is the di erence between what is
expected and what is actually accomplished.
The project scope, schedule and budget are all part of the project baseline.
A change represents a permanent deviation from that baseline. The word “permanent” is important
because it is possible that a deviation can occur intermittently that is self correcting and is only classed as a
deviation because of the timing of the event.
An example of a timing deviation could be that a deliverable is completed a week late because the sequence
had been switched with another deliverable, as opposed to an example of a permanent deviation, being a
deliverable completed a week late because it took a week longer to complete than anticipated, thereby
losing a weeks time that cannot be recovered.
The change is identi ed and measured upon the impact on the baseline (that is the scope, schedule and
budget). It should be quite obvious that the further the project is along in its lifecycle, the more dangerous
(in terms of cost and impact) a change is to a project.
It is therefore imperative to be able to identify and monitor the early warning signs of potential change.
Some of these include:
Schedule slippage - tasks that aren’t started or completed on time or don’t progress as quickly as
estimated.
Variance Trends – variations to cost, schedule, risk, scope or quality can be caused by actual work
e ort di erences, new deliverables added to the project, which in reality is probably due to gaps in
the planning process, or many other inconsistencies in the overall project.
All of these should ring alarm bells alerting to potential changes from the baseline.
Change control should be equivalent in a project manager’s mind to prevention of changes taking a project
o track. The goal of change control is not to prevent all change, but to steer inevitable changes in line with
the project’s successful completion.
There are 5 steps in that change management process.
Identify the change
Assess the impact of the change
Review and approve the change
Implement and verify the actions required to implement the change. This establishes a new baseline
for the project if the change is implemented e ectively.
Follow up veri cation with a review to con rm the change had the anticipated impact on the project
Good project managers should be able to describe the di erence between the original baseline and the
actual results. They do this by being proactive in monitoring trends and identifying potential changes before
they happen.
Match the level of control around analysis and change approvals appropriate to the organisation and
project. Don’t create overly complex solutions to simple problems, but on the other hand, if the change is
going to have di erent impacts on di erent stages of development, do make rigorous analyses to ensure
control is over the broad spectrum of variances.
Be transparent in what you do. Be visible. Ensure everyone in the project can see the status of changes at
any time. Be focused on proper implementation after the analysis and approval is done.
Follow up to con rm the implementation steps have been completed and compare the actual impact on the
cost and schedule to the estimated project impact.
Analysing information
Analysis is the process of turning detailed information into an understanding of patterns, trends,
interpretations. To analyse meaningful variances there must be two things: a properly developed project
schedule and a project team who give accurate status updates.
The starting point for analysis is quite often very unscienti c. It is your intuitive understanding of the key
themes that come out of the information gathering process. Once you have the key themes, it becomes
possible to work through the veri able information; structuring and organising it. The next step is to write
up your analysis of the ndings as a basis for reaching conclusions, and making recommendations.
There are 2 main variances that can be destructive in managing a project: schedule variance and cost
variance.
Schedule Variance shows how far ahead or behind a project baseline the project is running.
To calculate schedule variance use the following formula:
Schedule Variance (SV) = Earned Value (EV) − Planned Value (PV)

or
Schedule Variance (SV) = BCWP – BCWS
where EV (Earned Value) is the budget associated with the work that has been completed to the point in
time of variance analysis
and
PV (Planned Value) is the budget for the work planned to be completed to the point in time of variance
analysis.
If the calculation results in a positive number the project is ahead of schedule, a negative number means
the project is behind schedule, and 0 means the project is on schedule.
Cost variance shows how well the project is being managed to the approved budget.
To calculate cost variance use the following formula:
Cost Variance (CV) = Earned Value (EV) – Actual Cost (AC)

where AC is the actual cost of work performed to the date of variance analysis.
If the result of the calculation is a positive number the project is under planed costs. If the result is a
negative number the project is over planned costs and 0 means the project is on target.
PERT charts
The word PERT is an acronym, standing for program evaluation and review technique and was developed in
the 1950s in North America to assist in the management of large (defence) projects. Today it is still used
extensively in these environments. PERT charts are useful for analysing the variances in a project’s schedule.
Instead of taking just one time for each activity, PERT enables three estimates of time to be made for each
activity (Refer to Module 4 for background information on time estimations):
optimistic time (O)—the best time we believe will be possible, should everything go well
most likely time (M)—the time we think the activity will take under normal conditions
pessimistic time (P)—the time we believe the activity could take should things not go as we expect.
We will look at an example to understand the value of PERT charts in analysing baseline variances.
The following table shows time estimates for project activities (tasks)
Optimistic Time Most Likely Time Pessimistic Time Expected Time

Activity
O M P
A 1 3 5 3
B 1 2 4 2
C 3 5 7 5
D 2 3 6 3
E 6 8 14 9
F 1 2 3 2
G 2 4 7 4
H 3 4 9 5
I 1 3 6 3
J 4 6 11 8
Expected Time was calculated by:
O + 4M + P
6
Using these gures we can now represent our data as a PERT diagram:
Notice that we have shown three time estimates for each activity in a PERT diagram:
the optimistic time, followed by
the most likely time, followed by
the pessimistic time.
Estimating Time Variance for PERT Diagrams

A useful extension of this diagram is to calculate the likelihood of a set of activities being completed in a
nominated time. Let’s work through our example to estimate the likelihood of the project path between the
end of activity B and the start of activity G being completed in 13 days.
Step 1
Calculate the variance for each activity in our PERT diagram.
Firstly calculate the standard deviation by subtracting optimistic time from pessimistic time and dividing the
result by 6:
SD = P – O
6
Next caculate the variance by multiplying Standard Deviation by itself :
SD2
The results for our example are:
Activity Optimistic Time Most Likely Time Pessimistic Time Expected Time
O M P
A 1 3 5 0.44
B 1 2 4 0.25
C 3 5 7 0.44
D 2 3 6 0.44
E 6 8 14 1.78
F 1 2 3 0.11
G 2 4 7 0.69
H 3 4 9 1.00
I 1 3 6 0.69
J 4 6 11 1.36
Step 2
Add the variances of the activities comprising each of the paths being investigated, i.e. C-J, D-E-F, D-H-I
CJ = 0.44 + 1.36 = 1.80
DEF = 0.44 + 1.78 + 0.11 = 2.33
DHI = 0.44 + 1.00 + 0.69 = 2.13
Step 3
Calculate the standard deviation for each path—that is the square root of the variance.
CJ =1.80 =1.34
DEF =2.33 =1.53
DHI =2.13 =1.46
Step 4
Calculate the Z values for each path, where Z = [path objective – expected time] divided by the standard
deviation.
Z = PO – ET
SD
The path objective in this case is 13 days.
Z (for CJ) = [13 – 13] / 1.34 = 0.00
Z (for DEF) = [13 – 14] / 1.53 = -0.65
Z (for DHI) = [13 – 11] / 1.46 = 1.37
Step 5
Refer to a Z-values table (try http://www.statsoft.com/Textbook/Distribution-Tables#z to begin but there are
many others available) and determine the probability of each path being completed within the path
objective (in this case 13 days).
From the table it can be established that:
When Z = 0.00 the probability is 0.5000
When Z = -0.65 the probability is 0.2578
When Z = 1.37 the probability is 0.9147.
That is:
Path CJ has a 50% chance of completion in 13 days
Path DEF has a 26% chance of completion in 13 days
Path DHI has a 91% chance of completion if 13 days.
Step 6
Calculate the probability that all three paths will be completed in 13 days by multiplying the probabilities of
the individual paths together.
That is 0.5000 x 0.2578 x 0.9147 = 0.1179
In other words, the chance or likelihood of C-J, D-E-F and D-H-I being completed in 13 days is rated at
11.79% or just under 12%.
Calculation Summary for baseline variance
Path Path variances Standard Z Probability of completion in 13

Deviation days
C–J 0.44 + 1.36 = 1.80 1.34 (13 – 13) / 1.34 = 0.5000

0.00
D–E– 0.44 + 1.78 + 0.11 = 1.53 (13 - 14) / 1.53 = 0.2578

F 2.33 -0.65
D–H 0.44 + 1.00 + 0.69 = 1.46 (13 - 11) / 1.46 = 0.9147

–I 2.13 1.37
All of this analysis will give you the tools to make the decision on whether the current processes are
a ecting the baseline and need to be changed or left well alone. If the decision arises to make a change
then a formal structure should be taken to ensure the decision is approved by those with authority.
A change management process should never be taken too lightly or made too simple. Changes must be
applied with su cient thought and analysis to warrant their implementation. On the other hand, the
process should not be too onerous or change may never happen.
The balance is to de ne various responsibilities and authority levels so that routine changes can be dealt
with e ciently but signi cant changes receive due management attention.
For example:
a change to scope may have to be sanctioned by business owners as it a ects the deliverables,
resources, costs, schedule
changes to technical speci cations may have to be sanctioned by technology experts
changes to sta ng may require authorisation by human resource managers
changes to legislations may e ect and need approvals from local government bodies
Change request processes should be outlined in the project initiation documentation and should provide
guidance for decisions made regarding change.
Sometimes changes do not follow the approval process and this can lead to risks to the project. The
changes without approval are usually minor matters where it seems to be a waste of time to go through the
formalities, but, if the change request and control processes are not followed, even in practical simple
situations, ensuing more costly changes may follow the same path, thus jeopardising project outcomes.
Change Request forms are relatively simple in layout and address the speci c changes to be reviewed,
authorised and made. The project manager would need to identify the exact nature of the changes, if they
a ect the project scope, what stage of the project life-cycle they are in, what documentation needs
attention, what deliverables are a ected, etc.
Section Summary
For a project plan to be e ective it must equally address the parameters of ‘activity time’ and ‘activity logic’.
This logical relationship is required to model the e ect schedule variance will have down stream in the
project. -– Rory Burke, Author of Project Management Series of Books- Levels of Project Management.
Rory has an MSc in Project Management (Henley) and degrees in Naval Architecture (Solent University) and
Computer Aided Engineering (Coventry). He has worked internationally on capital projects.
Rory’s words ring true as you have seen from your studies to this point. It is the juggling of time, cost, quality
and resources that ultimately determines your skill at project management and identi es your project’s
outcome as a success or failure.
In this module you have seen that your initial preparation work at establishing quality management metrics
and a schedule baseline give you the opportunity to measure your project and product development’s
progress and to give creditable advice for change when necessary.
Rory also mentioned another home truth in one of his books:
The project manager must be able to develop a fully integrated information and control system to plan,
instruct, monitor and control large amounts of data, quickly and accurately to facilitate the problem-solving
and decision- making process. – Rory Burke
Topic Resources
The Critical Link between Requirements and Project Quality:

http://www.amanet.org/training/articles/The-critical-link-between-Requirements-and-Project-
Quality.aspx
Integrate variance tracking into your project change management process:

https://support.o ce.com/en-ie/article/Integrate-variance-tracking-into-your-project-change-
management-process-58908699-6304-4fde-ae72-0c26b4e4d927
Further Reading and Useful Websites
View How to Manage Project Scope Change. This is a 4:59 minute video and is available at
https://www.youtube.com/watch?v=tMR7jVefRIQ(Accessed 14 November 2015)
Some quality management plan examples are available from:
http://www.quality.co.uk/example/manual.htm (Accessed 19 November 2015)
http://www.management-zone.com/performance_management_library/Quality-Management-
Plan-Example/index.php (Accessed 19 November 2015)
http://www.mass.gov/eea/agencies/agr/pesticides/quality-management-plan.html (Accessed 19
November 2015)
Examples of change control processes in the design and construction industry at:
http://www.designingbuildings.co.uk/wiki/Change_control_procedure_for_building_design_and_construction
(Accessed 19th November 2015)

Module 4 - Project Schedule

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Module 4 - Project Schedule

Hochgeladen von

Copyright:

Verfügbare Formate

4/28/2019 Laureate International Universities

MODULE 5 - PROJECT MONITORING

Quality Management Roles and Responsibilities

Quality Management Plan

Introduction states the purpose of the quality management plan

project’s product as opposed to its processes. It should include what the

Quality Management Manuals

Audit of Quality Management Systems

project information systems

Role of the Project Manager in the Audit Process

Audit team is briefed on project requirements

On-site audit is carried out

Audit report is written

Audit report is distributed.

analyse the report

identify areas that need attention

implement any necessary improvements

Some examples of what an audit report might identify include:

design and documentation processes need amending

Some of the more common terminologies are:

Version administrative control of multiple versions of a deliverable which track changes

Question: Are all changes to be feared?

Question: How is evidence provided?

Some of these include:

There are 5 steps in that change management process.

Identify the change

Assess the impact of the change

Review and approve the change

To calculate schedule variance use the following formula:

Schedule Variance (SV) = Earned Value (EV) − Planned Value (PV)

To calculate cost variance use the following formula:

Cost Variance (CV) = Earned Value (EV) – Actual Cost (AC)

Optimistic Time Most Likely Time Pessimistic Time Expected Time

Expected Time was calculated by:

the optimistic time, followed by

the most likely time, followed by

the pessimistic time.

Estimating Time Variance for PERT Diagrams

Next caculate the variance by multiplying Standard Deviation by itself :

The results for our example are:

CJ = 0.44 + 1.36 = 1.80

DEF = 0.44 + 1.78 + 0.11 = 2.33

DHI = 0.44 + 1.00 + 0.69 = 2.13

CJ =1.80 =1.34

DEF =2.33 =1.53

DHI =2.13 =1.46

The path objective in this case is 13 days.

Z (for CJ) = [13 – 13] / 1.34 = 0.00

Z (for DEF) = [13 – 14] / 1.53 = -0.65

Z (for DHI) = [13 – 11] / 1.46 = 1.37

When Z = 0.00 the probability is 0.5000

When Z = -0.65 the probability is 0.2578

When Z = 1.37 the probability is 0.9147.

Path CJ has a 50% chance of completion in 13 days

Path DEF has a 26% chance of completion in 13 days

Path DHI has a 91% chance of completion if 13 days.

That is 0.5000 x 0.2578 x 0.9147 = 0.1179

Calculation Summary for baseline variance

Path Path variances Standard Z Probability of completion in 13

C–J 0.44 + 1.36 = 1.80 1.34 (13 – 13) / 1.34 = 0.5000

D–E– 0.44 + 1.78 + 0.11 = 1.53 (13 - 14) / 1.53 = 0.2578

D–H 0.44 + 1.00 + 0.69 = 1.46 (13 - 11) / 1.46 = 0.9147

changes to technical speci cations may have to be sanctioned by technology experts