Project Management in Construction

• What Is a Project?
• The fundamental nature of a project is that it
is a “temporary endeavour undertaken to
create a unique product, service, or result.
Projects are distinguished from operations and
from programs.
 Project Management
• “Project management is the process of the
application of knowledge, skills, tools, and
techniques to project activities to meet project
requirements.” That is, project management is an
interrelated group of processes that enables the
project team to achieve a successful project . These
processes manage inputs to and produce outputs
from specific activities; the progression from input
to output is the nucleus of project management and
requires integration and iteration.
 Project Management Processes
• Project management knowledge and practices are
best described in terms of their component
processes. These processes can be placed into five
process groups:
• Initiating a project
• Planning a project
• Executing the project/plan
• Controlling execution of the project/plan
• Closing the project
 Nine Management areas
• Integration management,
• Scope management,
• Time management,
• Cost management,
• Quality management,
• Human resource management,
• Communications management,
• Risk management,
• Procurement management.
 Initiating
• Projects will be initiated for any number of reasons. These could
be:
• To solves a current problem;
• As a request of management or stakeholders;
• To meet economic and market demands;
• For compliance with changes in legislation and Codes of
Practice;
• For process improvement;
• To control costs;
• In order to gain technical advantage over competitors;
• To pursue a business strategy or future opportunity.
• It is important that a Project Vision is set to
begin with. This involves defining the expected
value that the project will bring to your
organisation and the reason why the project
will make the difference.
 Planning
A project is a one-time set of activities with a defined
beginning and a defined end. It may be the completion
of a Government Tender, or the building of a new
commercial facility, Implementation of a new computer
system into your organisation or development of new
products and services.
For projects to succeed, it is important that the
planning stage be competed with accuracy to ensure
effective execution and control. There are a number of
models that can be used in the planning stage.
 PERT

Standing for Program Evaluation and Review Technique, PERT is a

network planning method for managing projects. It involves six main
steps:
• All project activities must be clearly defined,
• Sequencing requirements among activities must be identified,
• A diagram reflecting sequence relation ships must be developed,
• Time estimates for each activity must be determined,
• The network must be evaluated by calculating the critical path.
Various activities can be scheduled,
• As the project progresses, actual activity times must be recorded so
any
• schedule revisions and adjustments needed, can be made.
 Execution
• Project tracking and control processes commence
with project baseline setting. Once deliverable
specifications are frozen and you have a baseline
plan, you have a foundation for proper tracking and
control. Review the process for scope change control
with the project team and begin using it to resist
unnecessary changes. Refine your communication
processes to meet the needs of your team,
stakeholders, and sponsor. Document your project
infrastructure execution decisions and your
communication plan. Establish and deliver on
expectations for communicating, meetings, and
reporting.
Controlling
 Project Integration Management

• Integration management is a collection of

processes required to ensure that the various
elements of the projects are properly
coordinated. It involves making trade-offs
among competing objectives and alternatives
to meet or exceed stakeholder needs and
expectations. Comprised of: Project plan
development, Project plan execution, overall
change control.
 Project Plan Development
• Step 1: Explain the project plan to key
stakeholders and discuss its key components.
 Step 2: Define roles and responsibilities. Not all key stakeholders will review all
documents, so it is necessary to determine who on the project needs to approve which
parts of the plan. Some of the key players are:

• Project sponsor, who owns and funds the entire project. Sponsors need to review and
approve all aspects of the plan.
• Designated business experts, who will define their requirements for the end product.
They need to help develop the scope baseline and approve the documents relating to
scope. They will be quite interested in the timeline as well.
• Project manager, who creates, executes, and controls the project plan. Since project
managers build the plan, they do not need to approve it.
• Project team, who build the end product. The team needs to participate in the
development of many aspects of the plan, such as identifying risks, quality, and design
issues, but the team does not usually approve it.
• End users, who use the end product. They too, need to participate in the development
of the plan, and review the plan, but rarely do they actually need to sign off.
• Others, such as auditors, quality and risk analysts, procurement specialists, and so on
may also participate on the project. They may need to approve the parts that pertain
to them, such as the Quality or Procurement plan.
• Step 3: Hold a kickoff meeting. The kickoff meeting is an effective way
to bring stakeholders together to discuss the project. It is an effective
way to initiate the planning process. It can be used to start building
trust among the team members and ensure that everyone's idea are
taken into account. Kickoff meetings also demonstrate commitment
from the sponsor for the project. Here are some of the topics that
might be included in a kickoff meeting:
• Business vision and strategy (from sponsor)
• Project vision (from sponsor)
• Roles and responsibilities
• Team building
• Team commitments
• How team makes decisions
• Ground rules
• How large the group should be and whether sub-groups are necessary
• Step 4: Develop a Scope Statement. The Scope
Statement is arguably the most important
document in the project plan. It's the
foundation for the rest of the project. It
describes the project and is used to get
common agreement among the stakeholders
about the scope. The Scope Statement clearly
describes what the outcome of the project will
be. It is the basis for getting the buy-in and
agreement from the sponsor and other
stakeholders and decreases the chances of
miscommunication.
• This document will most likely grow and change with the life of
the project. The Scope Statement should include:
• Business need and business problem
• Project objectives, stating what will occur within the project to
solve the business problem
• Benefits of completing the project, as well as the project
justification
• Project scope, stated as which deliverables will be included
and excluded from the project.
• Key milestones, the approach, and other components as
dictated by the size and nature of the project.
• It can be treated like a contract between the project manager
and sponsor, one that can only be changed with sponsor
approval.
• Step 5: Develop scope baseline. Once the deliverables are
confirmed in the Scope Statement, they need to be developed into
a work breakdown structure (WBS), which is a decomposition of all
the deliverables in the project. This deliverable WBS forms the
scope baseline and has these elements:
• Identifies all the deliverables produced on the project, and
therefore, identifies all the work to be done.
• Takes large deliverables and breaks them into a hierarchy of smaller
deliverables. That is, each deliverable starts at a high level and is
broken into subsequently lower and lower levels of detail.
• The lowest level is called a "work package" and can be numbered
to correspond to activities and tasks.
• The WBS is often thought of as a task breakdown, but activities and
tasks are a separate breakdown, identified in the next step.
• Step 6: Develop the schedule and cost baselines. Here are the steps involved in
developing the schedule and cost baselines.
• Identify activities and tasks needed to produce each of the work packages,
creating a WBS of tasks.
• Identify resources for each task, if known.
• Estimate how long it will take to complete each task.
• Estimate cost of each task, using an average hourly rate for each resource.
• Consider resource constraints, or how much time each resource can realistically
devoted to this project.
• Determine which tasks are dependent on other tasks, and develop critical path.
• Develop schedule, which is a calendarization of all the tasks and estimates. It
shows by chosen time period (week, month, quarter, or year) which resource is
doing which tasks, how much time they are expected to spend on each task, and
when each task is scheduled to begin and end.
• Develop the cost baseline, which is a time-phased budget, or cost by time period.
• This process is not a one-time effort. Throughout the project you will most likely
be adding to repeating some or all of these steps.
• Step 7: Create baseline management plans.
Once the scope, schedule, and cost baselines
have been established, you can create the steps
the team will take to manage variances to these
plans. All these management plans usually
include a review and approval process for
modifying the baselines. Different approval levels
are usually needed for different types of changes.
In addition, not all new requests will result in
changes to the scope, schedule, or budget, but a
process is needed to study all new requests to
determine their impact to the project.
• Step 8: Develop the staffing plan. The staffing
plan is a chart that shows the time periods,
usually month, quarter, year, that each
resource will come onto and leave the project.
It is similar to other project management
charts, like a Gantt chart, but does not show
tasks, estimates, begin and end dates, or the
critical path. It shows only the time period and
resource and the length of time that resource
is expected to remain on the project.
• Step 9: Analyze project quality and risks.
Project Quality: Project quality consists of ensuring that the
end product not only meets the customer specifications, but
is one that the sponsor and key business experts actually
want to use. The emphasis on project quality is on preventing
errors, rather than inspecting the product at the end of the
project and then eliminating errors. Project quality also
recognizes that quality is a management responsibility and
needs to be performed throughout the project.
• Creating the Quality Plan involves setting the standards,
acceptance criteria, and metrics that will be used throughout
the project. The plan, then, becomes the foundation for all
the quality reviews and inspections performed during the
project and is used throughout project execution.
• Project Risks: A risk is an event that may or may not
happen, but could have a significant effect on the
outcome of a project, if it were to occur. For example,
there may be a 50% chance of a significant change in
sponsorship in the next few months. Analyzing risks
includes making a determination of both the probability
that a specific event may occur and if it does, assessing
its impact. The quantification of both the probability
and impact will lead to determining which are the
highest risks that need attention. Risk management
includes not just assessing the risk, but developing risk
management plans to understand and communicate
how the team will respond to the high-risk events.
• Step 10: Communicate! One important aspect of the project
plan is the Communications Plan. This document states such
things as:
• Who on the project wants which reports, how often, in what
format, and using what media.
• How issues will be escalated and when.
• Where project information will be stored and who can
access it.
• For complex projects, a formal communications matrix is a
tool that can help determine some of the above criteria. It
helps document the project team's agreed-on method for
communicating various aspects of the project, such as
routine status, problem resolution, decisions, etc.
• Once the project plan is complete, it is important not
just to communicate the importance of the project
plan to the sponsor, but also to communicate its
contents once it's created. This communication should
include such things as:
• Review and approval of the project plan.
• Process for changing the contents of the plan.
• Next steps—executing and controlling the project plan
and key stakeholder roles/responsibilities in the
upcoming phases.
• Project plan execution and overall change
control
• The purpose of Project Execution and Control
is to develop the product or service that the
project was commissioned to deliver. Typically,
this is the longest phase of the project
management lifecycle, where most resources
are applied.
• Project Execution and Control utilizes all the plans,
schedules, procedures and templates that were prepared
and anticipated during prior phases. Unanticipated events
and situations will inevitably be encountered, and the
Project Manager and Project Team will be taxed to
capacity to deal with them while minimizing impact on the
project’s CSSQ.
• The conclusion of the phase arrives when the product of
the project is fully developed, tested, accepted,
implemented and transitioned to the Performing
Organization.
• Accurate records need to be kept throughout this phase.
They serve as input to the final phase, Project Closeout.
Recall Figure 2-5. Level of Process Group Activity
Over Time
The most time and money are usually
spent on executing processes

Copyright Course Technology 2001 54

 This phase consist of following processes

• 1 .Conduct Project Execution and Control

Kick-off, where the Project Manager conducts
a meeting to formally begin the Project
Execution and Control phase, orient new
Project Team members, and review the
documentation and current status of the
project.
At this point in the project, the Project Plan comprises all
deliverables produced during Project Initiation and
Project Planning:
1. Project Charter
2. CSSQ (Scope, Schedule, Quality Plan, Budget)
3. Risk Management Worksheet
4. Description of Stakeholder Involvement
5. Communications Plan
6. Time and Cost Baseline
7. Change Control Process
8. Acceptance Management Process
9. Issue Management and Escalation Process
10. Project OrganizationalManagementPlan
11. Project Team Training Plan
12. Project Implementation and Transition Plan
Project Execution and Control Kick-off Meeting Agenda.)
Other items to cover during the meeting include:
■ Introduction of new team members
■ Roles and responsibilities of each team member
■ Restating the objective(s) of the project and goals for
Execution and Control
■ Latest Project Schedule and timeline
■ Communications Plan
■ Project risks and mitigation plans
■ Current project status, including open issues and action
items
• 2. Manage CSSQ, where the Project Manager
must manage changes to the Project Scope
and Project Schedule, implement Quality
Assurance and Quality Control processes
according to the Quality Standards, and
control and manage costs as established in the
Project Budget.
The purpose of Manage CSSQ is to:
■ Manage Changes to Project Scope
■ Control the Project Schedule and Manage
Schedule Changes
■ Implement Quality Assurance and Quality
Control Processes according to the Quality
Standards Revised During Project Planning
■ Control and Manage Costs Established in the
Project Budget
Some questions that the Project Manager should be able to
answer by examining the Project Schedule include:
■ Is the project on track?
■ Are there any issues that are becoming evident that need
to be addressed now?
■ Which tasks are taking more time than estimated? Less
time?
■ If a task is late, what is the effect on subsequent tasks?
■ What is the next deliverable to be produced and when is
it scheduled to be complete?
■ What is the amount of effort expended so far and how
much is remaining?
■ Are any Project Team members over-allocated or under-
allocated?
■ How much of the time allocated has been expended to
 Manage Project Budget

• Some budget-related characteristics the Project Manager

should examine each time the schedule is updated include:
• Original Contract Value: the original estimated budget
(cost) that was approved by the Project Sponsor.
• Total Approved Changes: the total cost of approved changes
as a result of change control.
• Total Current Budget: the sum of the Original Contract Value
and the Total Approved Changes. This is the most current
approved Project Budget.
• Cost to Date: the actual dollars (cost) expended to date on all
tasks and materials in the Project. The labor costs can be
calculated by the scheduling tool based upon the time the
Project Manager tracks against the tasks in the Project
Schedule.
■ Estimate to Complete: the dollars (cost) estimated to be
expended to complete remaining project tasks. The Project
Manager must verify and assess the impact of team
members’ revised effort estimates to complete tasks. The
Project Manager must also validate that the remaining
material costs are in line with the budget. These have a direct
effect on the Project Budget.
■ Forecast Total: the sum of the Cost to Date and the
Estimate to Complete.
■ Project Variance: the difference between all estimated and
all actual dollars. It is calculated by subtracting the Forecast
Total from the Total Current Budget. A positive variance
means that the actual cost of the product is less than the
budgeted cost. A negative variance means that
the actual cost of the product is greater than the budgeted
cost.
• 3 Monitor and Control Risks, where the
Project Manager and Project Team utilize the
Risk Management Plan prepared in previous
phases, and develop and apply
• new response and resolution strategies to
unexpected eventualities.
• 4 Manage Project Execution, where the
Project Manager must manage every aspect of
the Project Plan to ensure that all the work of
the project is being performed correctly and
on time.
The change control process describes:
• The definition of change and how to
identify it
• How requests for change will be initiated
• How requests for change will be analyzed
to determine if they are beneficial to the
project
• The process to approve or reject change
requests
• How funding will be secured to implement
approved changes
The acceptance management process is part of the Project
Plan, and documents:
■ The definition of “acceptance”
■ The criteria that must be met for each deliverable to be
considered “acceptable”
■ The number and identity of Customers designated to be
reviewers of each deliverable – typically reviewers are experts
in the subject matter the deliverable covers
■ The number and identity of Customers designated to be
approvers – approvers have the authority to sign the approval
form, indicating acceptance
■ The number of business days in which deliverables must be
either approved or rejected by the reviewers and approvers
■ The number of times a deliverable can be resubmitted
■ The escalation process that will be followed if a timely
decision on approval or rejection of a deliverable is not met
The issue escalation and management
process addresses the following:
■ How issues will be captured and tracked
■ How issues will be prioritized
■ How and when issues will be escalated
for resolution
These were defined during Project
Planning and may include:
■ Status Meetings
■ Status Reports
■ Memos
■ Newsletters
■ Executive Correspondence
■ Meeting Notes
■ Executive Meetings
■ Steering Committee Meetings
It is the primary communication vehicle between the Project Manager
and the Project Sponsor, and should contain the following information:
■ Summary of Progress to Project Schedule – a high-level glance at the
major project deliverables, with their intended and actual start and end
dates.
■ Issues and action items – a running list of open and closed issues,
including the name of the person responsible for taking action to resolve
them. (See Manage Issues, 4.4.3.)
■ Significant accomplishments – a list of the most important completed
tasks, or a description of work done toward their completion.
■ Significant planned accomplishments for the following weeks – a
description of the most important tasks scheduled for completion during
the following weeks.
■ Deliverable acceptance log – a running diary of actions taken toward
acceptance of deliverables. (See Manage Acceptance of Deliverables,
4.4.2.)
■ Change control log – a running diary of actions taken toward
acceptance of change control. (See Manage Change Control Process,
4.4.1.)
■ Lost time – a description of any situation that occurred that resulted in
the Project Team being unable to perform work.
At a minimum, the Project Manager should make sure the following repository items
are always current:
■ Project Schedule, including any project financials
■ Status Report, including:
▲ Change control log
▲ Issues log (open and closed)
▲ Deliverable acceptance log
■ Team member Progress Reports
■ Team member timesheets, if used
■ Risk Management Worksheet
■ All correspondence, including any pivotal or decision- making memos, letters,
email, etc.
■ Meeting notes, results and/or actions
• 5 Gain Project Acceptance, where the Project
Manager, Customer Decision-Makers and
Project Sponsor acknowledge that all
deliverables produced during Project
Execution and Control have been completed,
tested, accepted and approved, and that the
product or service of the project has been
successfully transitioned to the Performing
Organization.
 What is a baseline?
• It makes the plan difficult to change
• It is rather like writing the plan (schedule and
cost) on the backside of Moses’ tablets
• Its an anchor point for measuring
performance against plan
– Planned cost
– Planned schedule
– Planned scope
 Baseline and Tracking Gantt Charts

FIGURE 13.1
13–78
 Project Schedule Control Chart

FIGURE 13.2
13–79
 Scope
• Scope refers to the detailed set of deliverables or features of a
project. These deliverables are derived from a project’s requirements.
The Scope Statement
• The scope of a project is the clear identification of the work that is
required to successfully complete or deliver a project.  One of the
project manager’s responsibilities is to ensure that only the required
work (the scope) will be performed and that each of the deliverables
can be completed in the allotted time and within budget.

The documentation of the scope of the project will explain the

boundaries of the project, establish the responsibilities of each
member of the team and set up procedures for how work that is
completed will be verified and approved.  This documentation may be
referred to as the scope statement, or the statement of work, or the
terms of reference.
 Project Scope Management
• Project Scope Management refers to the set of
processes that ensure a project's scope is
defined and mapped accurately. Scope
management techniques  allow project
managers and supervisors to allocate just the
right amount of work necessary to complete a
project successfully. It is primarily
concerned with controlling what is and what is
not part of the project's scope.
 Project Scope Management Processes

Project scope management in the PMBOK® Guide

includes 6 processes. The project scope management
processes are:
1) Plan scope management
2) Collect requirements
3) Define scope
4) Create Work Breakdown Structure
5) Validate scope
6) Control scope.
 Plan Scope Management Process

• The point of doing this is to give you a scope management plan at the end of it.
That sets out how you will define, manage, validate and control your project’s
scope. Putting the work in up front to define this gives you something to refer to
later. You may find that you can use another project’s scope management plan as
a starting point, as scope management processes don’t vary wildly between
projects once your company has settled on a way of working that is successful for
them.
• The result of this process is the scope management plan. This is part of your
project management plan and includes:
• How you will prepare a detailed scope statement
• How you will create your Work Breakdown Structure (WBS) from the scope
statement
• How you are going to maintain and approve that WBS
• How you will get formal acceptance for the project’s deliverables
• How you will manage changes to scope.
• The document doesn’t have to be incredibly detailed or very formal: it simply has
to be fit for purpose.
 Collect Requirements Process

• In this process, you’ll   work out what your stakeholders want from the
project. Once you have outlined your big idea, you need to document
the requirements and manage your stakeholders’ expectations. This is
important because often what they ask for isn’t realistic or achievable
given other project constraints, like cost.
• The output of your requirements collection work is a documented set
of requirements. This should be as comprehensive as possible and will
normally include several categories of requirements such as:
• Functional and non-functional requirements
• Stakeholder requirements such as reporting requirements
• Support and training requirements
• Business requirements
• Project requirements such as levels of service or quality
• You’ll also document the dependencies, assumptions, and constraints
that specifically relate to requirements.
 Define Scope Process

• Here’s where you take your requirements and turn

them into a detailed description of the product or
service that your project is going to create. You’ll
end up with a project scope statement which you
can refer to during the project. It will include a list
of what’s in scope and what’s out of scope. That’s
important because often people won’t remember
what is specifically excluded and come back and
ask you to do work on those areas.
• Any inclusions will have to go through change
control.
 Create Work Breakdown Structure Process

• This process enables you to turn your list of

requirements into a structured vision of what
you need to do. The main work here is breaking
down big tasks into smaller, manageable chunks.
• The result of this process is a WBS. Personally, I
don’t use a WBS on my projects, but it can be a
very helpful tool. If you don’t think visually, then
you can achieve the same result by creating a
list.
 Validate Scope Process

• The Validate Scope process isn’t, as you may think,

getting business stakeholders to sign off your WBS. It’s
about making sure that you have a process in place for
getting sign off for your deliverables when the time
comes.
• It’s worth putting this structure in place so that you
don’t have any questions about who is going to
approve a deliverable or what criteria they are going to
use to say it is complete.
• Once the process is complete, you’ll have accepted
deliverables, approved by whoever needs to approve
them.
 Control Scope Process

• The Control Scope process is the last one in

the project scope management knowledge
area. It relates to making sure that there is
effective change control if the scope needs to
change. It also covers tracking your project
with a ‘scope’ hat on to check that it is going
to deliver what you think it will.