CHAPTER FOUR

4. PROJECT EXECUTION AND MANAGEMENT

4.1. Project Deliverables
This phase requires the physical construction of each deliverables for acceptance by the
customer. The actual activities undertaken to construct each deliverable will vary, depending on
the type of project (e.g. engineering, building development, computer infrastructure or business
process re- engineering project). Deliverables may be constructed in a ‘waterfall’ fashion (where
each activity is undertaken in sequence until the deliverable is finished) or an ‘iterative’ fashion
(where iterations of each deliverable are constructed until the deliverable meets the requirements
of the customer). Regardless of the method used to construct each deliverable, careful
monitoring and control processes should be employed to ensure that the quality of the final
deliverable meets the acceptance criteria set by the customer.
4.2. Establishment and staffing of project management Structures
A project organization is a structure that facilitates the coordination and implementation of
project activities. Its main reason is to create an environment that fosters interactions among the
team members with a minimum amount of disruptions, overlaps and conflict. One of the
important decisions of project management is the form of organizational structure that will be
used for the project.
Each project has its unique characteristics and the design of an organizational structure should
consider the organizational environment, the project characteristics in which it will operate, and
the level of authority the project manager is given. A project structure can take on various forms
with each form having its own advantages and disadvantages.
One of the main objectives of the structure is to reduce uncertainty and confusion that typically
occurs at the project initiation phase. The structure defines the relationships among members of
the project management and the relationships with the external environment. The structure
defines the authority by means of a graphical illustration called an organization chart.
A properly designed project organization chart is essential to project success. An organization
chart shows where each person is placed in the project structure. An organization chart is drawn
in pyramid form where individuals located closer to the top of the pyramid have more authority
and responsibility than members located toward the bottom. It is the relative locations of the
individuals on the organization chart that specifies the working relationships, and the lines
connecting the boxes designate formal supervision and lines of communication between the
individuals.
Creating the project structure is only a part of organizing the project; it is the actual
implementation and application that takes the most effort. The project organization chart
establishes the formal relationships among project manager, the project team members, the
development organization, the project, beneficiaries and other project stakeholders. This
organization must facilitate an effective interaction and integration among all the major project
participants and achieve open and effective communication among them.
The project manager must create a project structure that will meet the various project needs at
different phases of the project. The structure cannot be designed too rigid or too lose, since the
project organization's purpose is to facilitate the interaction of people to achieve the project
ultimate goals within the specified constraints of scope, schedule, budget and quality. The
objective in designing a project structure is to provide a formal environment that the project
manager can use to influence team members to do their best in completing their assignment and
duties. The structure needs to be designed to help develop collaboration among individual team
members; all in a cost effective way with a minimum of duplication of effort and overlaps.
The organization chart has a limited functionality; it only shows the hierarchical relationship
among the team members but does not shows how the project organization will work, it is for
that reason that the design should consider factors that will facilitate the operation of the
structure; these include communications, information flows, coordination and collaboration
among its members.
4.2.1. Factors in designing a project structure
There are two design factors that significantly influence the process of developing a project
management structure. These are the level of specialization, and the need for coordination. The
project manager should consider these factors at the moment of designing the project
organization in order to maximize the effectiveness of the structure.
Specialization affects the project structure by the degree of specialty in technical areas or
development focus; projects can be highly specialized and focus on a specific area of
development, or have different broad specializations in many areas of development. For large
projects that have multiple specializations or technical areas, each area may have a different
need; from differences in goals, approaches and methodologies, all of which influence the way
the project will implement its activities. A project that has two components, a reconstruction and
education, will need to manage different approaches based on the specialization of each one. In
the education component, the needs is for a structure more open and informal, where the time
horizon is longer, with more emphasis on sharing and generation of new ideas in order to achieve
innovation and creativity. In a reconstruction component, there are specific goals, a need for a
rigid, hierarchical structure, and there is a defined time horizon with little sharing of ideas. While
specialization allows each project component to maximize their productivity to attain their
departmental goals, the dissimilarities may lead to conflict among the members or leads of each
component. In general, the greater the differences, the more problems project managers have in
getting them to work together.
Coordination is required to bring unity to the various elements that make up a project. The
project work is organized around a work breakdown structure (WBS) that divides the overall
project goals into specific activities or tasks for each project area or component; the project
manager must design an organizational structure that ensure that the various components are
integrated so that their efforts contribute to the overall project goal. Integration is the degree of
collaboration and mutual understanding required among the various project components to
achieve project goals. Most projects are characterized by the division of labor and task
interdependencies, creating the need for integration to meet project objectives. This need is
greatest when there are many project components that have different specializations. The goal of
the project management structure is the achievement of harmony of individual efforts toward the
accomplishment of the group goals. The project manager's principal responsibility is to develop
integrating strategies to ensure that a particular component or activity is organized in a way that
all of the components, parts, subsystems, and organizational units fit together as a functioning,
integrated whole according to the project master plan.
4.3. Time, Cost, Resources and Risk Management
Construction planning includes at least the following:
 Time planning
 Resource planning
 Cost planning
 Risk planning
TIME PLANNING
 Time plan depicts the sequence of accomplishment of the planning components plotted
against time scale.
 helps to avoid delay and subsequent additional costs
 is a base for resource allocation and material procurement plan
 Involves the following three stages
 Activity definition
 Activity sequencing
 Activity duration estimating
 Schedule development
1. Activity definition
What? The processes of determining the specific activities that needs to be executed to achieve
objectives.
How?

 WBS
2. Activity sequencing
What? Processes of determining the job logic
How?

 Mandatory requirements (hard logic)

 Discretionary requirements (preferred (soft)) logic

 External requirements

 Relationship types (in PDM)

o S-S o F-S
 o F-F o S-F

Lead/lag time and their determinations

Project Risk Management

The goals of risk management are to decrease the probability and impact of adverse events and to
increase the probability and impact of events beneficial to a project. Project Risk Management
includes:
o Risk Management Planning;
o Risk Identification;
o Risk Analysis;
o Response Planning; and
o Risk Monitoring and Control.
These processes interact with one another and each can require input from one or more people or
groups, depending upon the needs of the projecte or more project objectives. Project objectives
include: Project risk is an uncertain event or condition that may have a positive or negative effect
on
 Completion within the time scheduled for completion;
 Completion within the agreed budget or contract price;
 Completion of the specified scope; and
 Completion to the specified standards.
Risk Management Planning
Proper planning is essential to the success of the overall risk management process. It is the
determination of how to conduct the management of risk for a project. Part of the planning
process is to ensure that all those involved with the project are aware of the risks that might
affect it and of the planning process so that they may contribute to it. The process also should
ensure that the risk management is appropriate for the importance of the project and the impact
that adverse outcomes might have upon the organization.
The risk management planning exercise should be carried out early as analysis of the risks
associated with various project options is likely to influence the way in which the project is
executed. In the worst case, such an analysis may demonstrate that the project should not be
pursued in the format currently under consideration.

A risk assessment should be carried out at the beginning of each stage of the project and be
repeated at regular intervals to determine any changes in the exposure to threats or opportunities,
whether from risks already recognized or from newly developed ones.
a. Planning Inputs
Organizational factors will influence the development of the management plan. Chief among
these will be the organization’s attitude towards risk; an entrepreneurial company may be more
prepared to accept risks than a more conservative, traditional organization. Individuals involved
in a project will also have different views of risks and what is acceptable. These are often
constrained by an organization’s policy statements and procedural manuals. These allocate
authorities at different levels of responsibility and also specify through what approval processes
a risk management plan must pass before it can be adopted.
The scope of work defines the deliverables of the project and the work that is required to
generate them. A properly defined scope of work provides all stakeholders with a common
understanding of a project’s objectives. It should define not only what is included in the project,
but also what is excluded. This can be of great importance in preventing incorrect assumptions
becoming articles of faith. For example, a contract may include the manufacture and delivery to
site of an item of equipment but exclude its installation and commissioning.
A risk management plan is usually a subsidiary component of the project management plan, not a
standalone document. Its development requires reference to the project management plan to
assist in the identification of risks and the resources that might be available to help in their
mitigation.
b. Planning Outputs
A risk management plan will include the resources that will be used to manage the risk on a
project and the methodology to be followed. It may include a flowchart to illustrate the logic of
the risk management process.
The plan will specify the composition of the risk management team and allocate roles and
responsibilities to its members and ensure that all activities required by the plan have an owner.
The reporting of risks and the implementation of the plan will also be defined. Risk management
may be structured in a way similar to quality assurance (QA) where the person with
responsibility for implementing QA is a member of the project management team and works
with the project manager but is independent and reports to a QA director or senior manager away
from the site of the project. The intention is to ensure that risk management, or QA, is recognize
as an important part of the day to day management of the project but that the person with
immediate responsibility for the function is independent of the manager of the project. In this
way the risk manager should not be unduly influenced by the project manager who is likely to
have different priorities with an emphasis on financial and programmed requirements.
Included in the development of a management plan will be an estimate of the resources and
budget necessary to develop and implement the plan so that these costs can be incorporated into
the overall project budget. This will contain a programmed that shows when the risk
management process will be repeated and the associated activities, which should be written into
the project programmed.
The risk management plan will provide categories of risks and definitions of the probability and
impact of the risks that have been identified.
In the same way a Work Breakdown Structure (WBS) can be used when developing the detail of
the scope of a project, to provide the building blocks of the basic elements making up each
activity, so can a Risk Breakdown Structure (RBS) be created. An RBS is a hierarchical
structure which divides a project into broad categories from which risks might arise and then
subdivides these categories further to facilitate the identification of risks. An example is shown
in fig. 1.
 Project

Technical External Organisational Project Management

Requirements Subcontractors &SuppliersProject Dependencies Estimating

Technology Regulatory Resources Planning

Complexity &interfaces
Market Funding Controlling

Performance & reliability

Customer Priorities Communication

Quality Weather

Fig.1 Risk breakdown structure

Evaluating the probability of a risk occurring and its potential impact are an essential part of risk
analysis. The probability of a risk event happening can be described as not at all likely through
to extremely likely. Various steps between these two extremes can be assigned numerical
values. The potential impact of a risk event can be classified in the same way. These values can
be used to create a matrix that presents risks in an order of priority.
Often material from a previous, similar project can be used as a basis for plan outputs. These
references should have been updated during the currency of the project from which they are
derived, in order to ensure that they are more relevant and to make good any shortcomings.
6.1 Risk Identification and Assessment
Risk Identification
This is the process of identifying what risks might affect a project and then determining their
characteristics. Data from previous projects can be used to assist the process. Individual
members of the risk management team can be tasked with considering aspects of the project with
which they are familiar. Brainstorming is a useful technique for expanding upon these.
Depending upon the complexity and value of the project, a risk management specialist team may
be appointed from inside or outside the organization to coordinate the risk management process.
Other personnel would contribute at different stages of risk management.
Risk identification is an area, which benefits from input from a wide range of viewpoints.
People involved should include the project manager and senior discipline managers and client
representatives. Other contributors could include industry representatives and other stakeholders
such as end users. All project and organization staff should be encouraged to consider risks and
to submit any they identify.
Risk identification leads to qualitative analysis and subsequently to quantitative analysis.
External inputs that may assist with risk identification include technical references, databases,
and studies, analyses of previous projects carried out by others and material from risk
consultants. Internal inputs can be derived from records of previous projects, which can offer
actual data and the benefit of hindsight.
The scope of work can be a rich source of risks. The scope makes a number of assumptions,
which can be tested for uncertainty, itself a harbinger of risk.
The allocation of roles and responsibilities within the project team, the provision for risk
management in the budget and resource schedule and other outputs of the planning process all
provide material for review in risk identification. Other components of the project management
plan should also be reviewed to reveal risks. The programmed, budget and QA plan should all
be assessed for potential risks.
This illustrates why it is important that the people having input to risk identification should have
a wide range of interests and expertise; it ensures a range of different viewpoints and discourages
consideration from only a purely technical aspect, or that of any other single interest group.
a. Risk Identification Inputs
As a means of risk identification reviews of project documentation should be undertaken. Its
quality, consistency and compliance with the scope of work can indicate risks in the project.
Records from previous projects will also provide indicators of risk.
Brainstorming has already been mentioned as a means of identifying risks. This is usually
managed by a facilitator. Participants can include the project team, discipline managers,
stakeholders and external experts. An RBS can be used as a framework for consideration.
The effort and expense put into risk identification should be proportional to the potential impact
upon the organization. If the impact is potentially significant, the employment of more resources
and greater expense is justified.
Interviewing is recognized as a significant means of identifying risks. Experienced project team
members, experts in constituent parts of the project and stakeholders can be interviewed for this
purpose.
A SWOT analysis is also a popular tool for this purpose. It evaluates the Strengths, Weaknesses,
Opportunities and Threats for a project.
Checklists can be based upon available historical data, including records from earlier projects. A
checklist can be a useful tool, but it is important to recognize that it is not comprehensive and
efforts must be made to identify unlisted risks. Checklists should be updated during a project to
increase their value for future works.
Projects are inevitably based upon a number of assumptions. Some of these assumptions may be
grounded in investigations and surveys, but the interpretation of the data is affected by
generalizations. The more detailed a survey or investigation is, the more weight it provides to
assumptions based upon it. However, an investigation or survey prior to project design cannot
be exhaustive for reasons of cost and time. This means that the design work has to be based on
assumptions used when analyzing the data. Assumptions are also used when evaluating the
returns from a project, its economic benefit.
Analysis of the assumptions used when developing, designing and documenting a project is of
great value in assessing risks to a project from inconsistent or unfounded assumptions. A number
of diagram techniques can be used to assist in risk identification. These include flow charts,
influence diagrams, fishbone diagrams, histograms, Pareto charts and others.
b. Risk Identification Outputs
As the risk identification outputs the results of a risk identification exercise are typically
recorded in a Risk Logical Framework or Log frame. Such a document is also referred to as a
risk register.
The first column in the log frame contains the identified risks. Each row shows the probability,
impact, priority, mitigation activities or responses and the responsible party. The risks are
usually grouped into categories, and sub categories if appropriate.
The log frame is updated at specified intervals, possibly quarterly, when a new or changed risk is
recognized, when a significant event occurs or when a project enters a new phase. The log frame
is added to in later stages of risk assessment.
4.4. What is 'Quality Management?'

Quality management is the act of overseeing all activities and tasks needed to maintain a desired
level of excellence. This includes the determination of a quality policy, creating and
implementing quality planning and assurance, and quality control and quality improvement. It is
also referred to as total quality management (TQM).

BREAKING DOWN 'Quality Management'

At its core, quality management (TQM) is a business philosophy that champions the idea that the
long-term success of a company comes from customer satisfaction. TQM requires that all
stakeholders in a business work together to improve processes, products, services and the culture
of the company itself.

The Origins of Quality Management

While TQM seems like an intuitive process, it came about as a revolutionary idea. The 1920s
saw the rise in a reliance on statistics and statistical theory in business, and the first-ever known
control chart was made in 1924. People began to build on theories of statistics and ended up
collectively creating the theory of statistical process control (SPC). However, it wasn't
successfully implemented in a business setting until the 1950s.

It was during this time that Japan was faced with a harsh industrial economic environment. Its
citizens were thought to be largely illiterate, and its products were known to be of low quality.
Key businesses in Japan saw these deficiencies and looked to make a change. Relying on
pioneers in statistical thinking, companies such as Toyota integrated the idea of quality
management and quality control into their production processes.

By the end of the 1960s, Japan completely flipped its narrative and became known as one of the
most efficient export countries, with some of the most admired products. The effective quality
management resulted in better products that could be produced at a cheaper price.

Quality Management ensures that an organization, product or service is consistent. It has four
main components: quality planning, quality assurance, quality control and quality improvement.
Quality management is focused not only on product and service quality, but also on the means to
achieve it. Quality management, therefore, uses quality assurance and control of processes as
well as products to achieve more consistent quality.

Objectives and skills for the quality management portion of Project+ certification include:
Identify components of a quality management plan

 Quality metrics, control limits, and frequency of measurement

 Quality assurance processes

 Quality control processes

 Quality baseline

Explain the appropriate steps to ensure quality of project deliverables

 Monitor work performance

 Analyze performance information

 Identify variances

 Generate change requests

 Implement change requests

Identify potential tools to use when a project deliverable is out of specification as defined in
the quality baseline

 Pareto charts

 Histograms

 Run charts

 Ishikawa diagram