UNIT 1 UNDERSTANDING THE PROJECT

Objectives:

After reading this Unit, you would be able to:

• Discuss the concept of projects;

• Define the scope of projects;
• Classify different projects;
• Explain the characteristics of projects.
Structure:

1.1 Introduction to Project

1.2 Projects in Different Fields
1.3 Classification of Projects
1.4 Project Classification Based on Nature of Project
1.5 Characteristics of Project
1.6 Summary
1.7 Key Words

1.1 Introduction to Project

A project in business and science is typically defined as a collaborative enterprise, frequently involving
research or design that is carefully planned to achieve a particular aim. Projects can be further defined
as temporary rather than permanent social systems that are constituted by teams within or across
organizations to accomplish tasks under time constraints.

The word project comes from the Latin word projectum from the Latin verb proicere, "before an
action" which in turn comes from pro-, which denotes precedence, something that comes before
something else in time (paralleling the Greek πρό) and iacere, "to do". The word "project" thus actually
originally meant "before an action".

When the English language initially adopted the word, it referred to a plan of something, not to the
act of carrying this plan out. Something performed in accordance with a project became known as an
"object".
 1.2 PROJECTS IN DIFFERENT FIELDS

The project concept is applied in different ways in different fields. It has different application in
following fields:

School and University

At school, educational institute and independent work, the project requires more efforts than is
involved in a normal essay assignment. It requires students to undertake their own fact-finding and
analysis, either from library/internet research or from gathering data empirically. The written report
that comes from the project is usually in the form of a dissertation, which will contain sections on the
project's inception, analysis, findings and conclusions.

Engineering Project
Engineering projects are, in many countries, specifically defined by legislation, which requires that
such projects should be carried out by registered engineers and/or registered engineering companies.
That is, companies with license to carry out such works as design and construction of buildings, power
plants, industrial facilities, installation and erection of electrical grid networks, transportation
infrastructure and similar works.

The scope of the project is specified in a contract between the owner and the engineering and
construction parties. As a rule, an engineering project is broken down into design and construction
phases. The outputs of the design process are drawings, calculations, and all other design
documentation necessary to carry out the next phase. The next phase would normally be sending the
project plans to a developer who will then help construct the plans (building).

Business Management
In Business management a project consists of a temporary endeavor undertaken to create a unique
product, service or result. Another definition is a management environment that is created for the
purpose of delivering one or more business products according to a specified business case.

Project objectives define target status at the end of the project, reaching of which is considered
necessary for the achievement of planned benefits. They can be formulated as SMART criteria:
Specific, Measurable (or at least evaluable) achievement, Achievable (recently Agreed-to or
Acceptable are used regularly as well), Realistic (given the current state of organizational resources)
and Time terminated (bounded).

The evaluation (measurement) occurs at the project closure. However, a continuous guard on the
project progress should be kept by monitoring and evaluating. It is also worth noting that SMART is
best applied for incremental type innovation projects. For radical type projects it does not apply as
well. Goals for such projects tend to be broad, qualitative, stretch/unrealistic and success driven.
Experimental/Research/Measurement Projects
These projects are based on designing an experiment to study the effects of one or more variables on
an object. Students should model scientific procedures by presenting their results in a group report
that should include: The Problem studied Purpose, Method, Data, Results and Conclusion.

Search and Find Projects

This type of project includes selecting a topic (global warming, mission to planet Mars, the FLU) or a
scientist, and use primary and secondary resources to build a presentation board summarizing their
findings. This can be done by making use of a variety of resources, including the Internet.

1.3 CLASSIFICATION OF PROJECTS

How should we categorize different types of projects? The dictionary defines typology as the study of
types as in systematic classification. It defines taxonomy as the science, laws, or principles of
classification. It defines classification as the systematic grouping into categories by shared
characteristics or traits. The project management profession needs a classification system for different
types of projects so that we may communicate effectively across the entire spectrum of projects and
across the entire world.

There are many different potential purposes for a system of classification. One useful objective for a
list of different types of projects is to segment the market for marketing purposes. Another is to define
the different management approaches needed for different projects. The system of classification
might change based on the purpose. Another purpose would be to select the right project manager
based on the requirements of a specific project.

Shenhar and Wideman in several papers have proposed a system of classification based on three
variables of (1) Degree of uncertainty at initiation; (2) Complexity based on degree of
interconnectedness and (3) Pace based on the need for speed in the available time frame for the
project. In a paper they added the dimension of an intellectual product (white collar) versus a craft
product (blue collar).

Parameters for Categorizing Projects

There are four basic ways in which we can set up a classification system of projects as follows:
(1) geographical location, (2) industrial sector (Standard Industrial Classification System), (3) stage of
the project life cycle and (4) product of the project (construction of a building or development of a
new product). The most important and the most useful breakdown is by type of product or deliverable
that the project is producing such as building a building, developing a new product, developing new
computer software program or performing a maintenance turnaround or outage on a chemical plant
or electric generating station.

Each of these types of projects has more in common with other similar projects producing the same
type of product than with other types of projects. Conversely there is much less commonality between
different types of projects in the same industrial sector or company.
For example there is much more commonality between projects for developing a new software system
in a construction company and a bank than there is between three projects in the same bank for
constructing a new building, developing a new product and developing a new computer software
system. The broad classification includes following projects:
• Administrative
• Construction
• Computer Software Development
• Equipment or System Installation
• Event or Relocation
• Maintenance of Process Industries
• New Product Development
• Research

As explained in the article on the site www.users.globalnet.co.uk/~rxv/projmgt/projtypes.htm,

projects can be classified as per following:

Construction Projects
The project produces an artifact. The value generated by the project is embedded in the artifact. The
artifact may be a complex system with human and mechanical components.

Examples:

• Warship
• National Highway construction
• Port Development
• Dam construction

Research Projects
The project produces knowledge. The knowledge may be formally represented as models, patterns
or patents. Or the knowledge may be embedded in a working process or artifact.

Examples:

• Business modeling
• Developing a model of the country’s economy
• Developing a new species of wheat
• Developing novel approaches to project management
• Military intelligence / code breaking
• The analysis, testing, QA or evaluation portions of a larger project

Reengineering Projects
The project produces a desired change in some system or process.

Examples:

• converting sterling into the Euro

 • Renumbering the telephone system
• Designing and installing an Intranet

Procurement Projects
The project produces a business relationship contractually based with a selected supplier for a
defined product or service based on a fixed specification and/or a defined specification process.

Examples:

• Outsourcing a specific construction or research project.

• Outsourcing a complete business function (such as IT).
• Imposing new rules and measures on a regulated industry.

Business Implementation Projects

The project produces an operationally effective process. The value generated by the project is
embedded in the process.

Examples:

• Developing a new business process to repackage and exploit existing assets

• Installing e-commerce

Some projects are difficult to classify under this scheme.

National symbolic programmes:

• Putting a man on the moon by the end of the decade

• New Labor Laws

Large medical programmes:

• Creating an artificial heart

• Mass inoculation programmes

Other hybrid or interdisciplinary projects

• Pilot projects
• Moving offices

In most cases, this difficulty arises from an ambiguity about the primary purpose of the project. Are
we doing this pilot for its own sake, or merely as an experiment? Are we doing this drug trial to benefit
current patients, or to create knowledge that will benefit future patients? What’s the real political
agenda? Of course, we must be able to handle hybrid projects - but we may need to surface the
underlying ambiguity.
Each type of project yields different answers to these questions - and this implies that each type of
project needs a somewhat different process and management style.

start stop evaluate

Construction With a set of When the artifact is “complete”. On delivery of the artifact.
requirements.
When the requirements are Over the lifetime of the
With a defined satisfied. artifact.
solution.

Research With a When the time runs out. When the knowledge is
hypothesis. confirmed or disconfirmed
When we detect diminishing by later work.
With a problem. returns.
When the knowledge is
used by later work.

Reengineering With a problem. When we seem to be ahead of the At any time.

game.
With an
opportunity. When some higher process
changes the game we’re playing.
With an
(imported)
solution.

Procurement With a set of We construct a tender document Over the lifetime of the
requirements. that is “complete”. contract.

With a defined We sign a contract with the On completion of the

solution. supplier who seems to be ahead contract.
at the end of the tender period.

Business With an When the process is operational. When the process has
Implementation opportunity. been running smoothly for
When the process has been a defined period.
With a business running smoothly for a defined
concept. period. When the business
benefits are starting to
When the business benefits are become visible.
starting to become visible.
Over the lifetime of the
process.
 1.4 PROJECT CLASSIFICATION BASED ON NATURE OF PROJECT

This classification of project is as per following:

Greenfield Projects
A Greenfield project is the investment in a manufacturing, office, or other physical company-related
structure or group of structures in an area where no previous facilities exist. Greenfield project is
usually offered as an alternative to another form of investment, such as mergers and acquisitions,
joint ventures, or licensing agreements. Greenfield Investing is often mentioned in the context of
Foreign Direct Investment.

A related term to Greenfield Investment which is becoming popular is Brownfield Investment, where
a site previously used for business purposes, such as a steel mill or an oil refinery, is
expanded/upgraded to achieve superior return.

A form of foreign direct investment where a parent company starts a new venture in a foreign country
by constructing new operational facilities from the ground up. In addition to building new facilities,
most parent companies also create new long-term jobs in the foreign country by hiring new
employees.

Developing countries often offer prospective companies tax-breaks, subsidies and other types of
incentives to set up green field investments. Governments often see that losing corporate tax revenue
is a small price to pay if jobs are created and knowledge and technology is gained to boost the
country's human capital.

Other uses
Examples of Greenfield projects are new factories, power plants, airports which are built from scratch
on Greenfield land. Those facilities which are modified/upgraded are called Brownfield land projects
(often the pre-existing site/facilities are contaminated/polluted.)
In transportation industries (e.g. automotive, aircraft, engines) the equivalent concept is called "clean
sheet design".

Greenfield also has meaning in sales. A Greenfield opportunity refers to a marketplace that is
completely untapped and free for the taking.

Brownfield Project
The term Brownfield was originally used in construction and development to reference land that at
some point was occupied by a permanent structure. In a Brownfield project the structure would need
to be demolished or renovated. Today, the term Brownfield project is used in many industries,
including software development, to mean to start a project based on prior work or to rebuild
(engineer) a product from an existing one.

Reengineering Projects

Reengineering projects design and implement solutions that:

 • are customer focused
• capitalize on best practices and learning from others
• are designed for the future
• produce significant bottom-line improvements for the business

The methodology selected for your project impacts the size of the improvement and how fast the
improvement will be realized.

These guidelines present an approach shown to be effective in other companies. Research results
from 248 projects are included. Ultimately, the best framework is one you select based on this
information, knowledge of your project, and any internal practices at your company.

If you are trying to decide whether to use a continuous- improvement methodology or a business
process reengineering approach for your project, review the decision matrix at the end of this
tutorial.

The recommended approach for a business process reengineering project includes the following
phases:
• Project Planning and Launch (team selection, objective setting, scope definition, methodology
selection, schedule development, consultant selection, sponsor negotiations, change
management planning, team preparation).

• Current State Assessment and Learning from Others (high-level process definition,
benchmarking, customer focus groups, employee focus groups, technology assessment).

• Solution Design (process design, enabling technology architecture, organizational design, job
design).

• Business Case Development (cost and benefit analysis, business case preparation,
presentation to key business leaders).

• Solution Development (detailed process definition, system requirements writing and system
development, training development, implementation planning, operational transition plan,
pilots and trials).

• Implementation (larger-scale pilots and phased implementation, measurement systems, full

implementation).

• Continuous Improvement (on-going improvement and measurement of new processes and

systems).

Restructuring Projects
As technologies, clients and market change, so do the companies that wish to stay successful and
competitive. Optimal organizational structure offers flexibility, profitability and competitive edge of a
certain player in market. On the other hand, every change, especially at the scale of restructuring,
represents considerable stress for the employees and the work to be done.

Effective planning and managing of the restructuring process significantly reduces stress and
productivity downfall.

The project involves restructuring by:

• Defining organizational structure
• Planning the phases and milestones of restructuring
• Designing and implementing communication plan
• Employee outplacement

Backward Integration Projects

Backward Integration is an approach of a company to increase its level of control on its inputs. It is a
part of the Corporate Strategy which is defined as “the match an organization makes between its
internal resources and skills….and the opportunities and risks created by its external environment.”

In the business world of today, it is not very uncommon for a corporation to acquire a supplier or a
vendor or to create facilities of its supplier that are important to the welfare of the company. This
process of acquiring existing supplier or creating a supply chain of its own is referred as Backward
Integration.

Definition: “Backward Integration is a type of Vertical Integration in which a consumer of raw material
acquires its suppliers, or sets up its own facilities to ensure a more reliable or cost – effective supply
of inputs.”

The process of Backward Integration involves in integrating of the supply chain within the corporate
family. It usually begins when a company becomes aware that the product or service line offered by
one of the company’s suppliers is especially more appealing. This appeal may be built on the fact that
the products that are currently purchased have worked out very well, and are helping to improve the
quality and bottom line.

Backward Integration is one part of the Vertical Integration which is best understood by applying
Michael Porters Value Chain Model, Vertical Integration refers to the degree of integration between
a firm’s value chain and the value chain of its suppliers and distributors. Full Backward Integration
happens when a company incorporates the Value chain of a supplier into its own value chain. This
generally happens when the company acquires a supplier or expands its operation to carry out the
activities of its supplier. A lower degree of Backward Integration is commonly known as Supply Chain
optimization or also as Supply Chain planning.

Forward integration Projects

Forward integration is a strategy in which companies expand their activities to control the direct
distribution of their products. This might be required, if companies would potentially benefit from
handling e.g. the shipping of own products directly to customers, or the retail selling of own brands in
brand stores.
There might be various good reasons for companies to perform either backward or forward
integration, but such strategic initiatives should always add specific value to the company, and should
always be aligned with the overall strategy of the company and with customer needs and wants.

Modernization Projects
Modernization refers to a model of an evolutionary transition from a 'pre-modern' or 'traditional' to
a 'modern' society. The teleology of modernization is described in social evolutionism theories,
existing as a template that has been generally followed by societies that have achieved modernity.
While it may theoretically be possible for some societies to make the transition in entirely different
ways, there have been no counterexamples provided by reliable sources.

Historians link modernization to the processes of urbanization and industrialization, as well as to the
spread of education. As Kendall (2007) notes, "Urbanization accompanied modernization and the
rapid process of industrialization." In sociological critical theory, modernization is linked to an
overarching process of rationalization. When modernization increases within a society, the individual
becomes that much more important, eventually replacing the family or community as the
fundamental unit of society.
Modernization theory and history have been explicitly used as guides for countries eager to develop
rapidly, such as China. Indeed, modernization has been proposed as the most useful framework for
World history in China, because as one of the developing countries that started late, "China's
modernization has to be based on the experiences and lessons of other countries."

Instead of being dominated by tradition, societies undergoing the process of modernization typically
arrive at governance dictated by abstract principles. Traditional religious beliefs and cultural traits
usually becomes less important as modernization takes hold.

1.5 CHARACTERISTICS OF PROJECT

A project has several characteristics:

• Projects are unique

• Projects are temporary in nature and have a definite beginning and ending date
• Projects are completed when the project goals are achieved or it’s determined the project is
no longer viable
• A successful project is one that meets or exceeds the expectations of your stakeholders

Consider the following scenario: The VP of marketing approaches you with a fabulous idea. (Obviously
it must be “fabulous” because he thought of it.) He wants to set up kiosks in local grocery stores as
mini offices. These offices will offer customers the ability to sign up for car and home insurance
services as well as make their bill payments. He believes that the exposure in grocery stores will
increase awareness of the company’s offerings. He told you that senior management has already
cleared the project and he’ll dedicate as many resources to this as he can. He wants the new kiosks in
 place in 12 selected stores in a major city by the end of the year. Finally, he has assigned you to head
up this project.

Your first question should be “Is it a project?” This may seem elementary, but confusing projects with
ongoing operations happens often. Projects are temporary in nature, have definite start and end
dates, result in the creation of a unique product or service, and are completed when their goals and
objectives have been met and signed off by the stakeholders.

Using these criteria, let’s examine the assignment from the VP of marketing to determine if it is a
project:

Is it unique? Yes, because the kiosks don’t exist in the local grocery stores. This is a new way of offering
the company’s services to its customer base. While the service the company is offering isn’t new, the
way it is presenting its services is.

Does the product have a limited timeframe? Yes, the start date of this project is today, and the end
date is the end of next year. It is a temporary endeavor.

Is there a way to determine when the project is completed? Yes, the kiosks will be installed and the
services will be offered from them. Once all the kiosks are intact and operating, the project will come
to a close.

Is there a way to determine stakeholder satisfaction? Yes, the expectations of the stakeholders will
be documented in the form of requirements during the planning processes. These requirements will
be compared to the finished product to determine if it meets the expectations of the stakeholder.

If the answer is yes to all these questions, then “it is a project”.

The project characteristics can be mainly given in the following form:

• Projects have a purpose: Projects have clearly-defined aims and set out to produce clearly-defined
results. Their purpose is to solve a "problem”, and this involves analysing needs beforehand.
Suggesting one or more solutions, a project aims at lasting social change.

• Projects are realistic: Their aims must be achievable, and this means taking account both of
requirements and of the financial and human resources available.

• Projects are limited in time and space: They have a beginning and an end and are implemented in (a)
specific place(s) and context.

• Projects are complex: Projects call on various planning and implementation skills and involve various
partners and players.

• Projects are collective: Projects are the product of collective endeavours. They involve teamwork and
various partners and cater for the needs of others.
• Projects are unique: Projects stem from new ideas. They provide a specific response to a need
(problem) in a specific context. They are innovative.

• Projects are an adventure: Every project is different and ground-breaking; they always involve some
uncertainty and risk.

• Projects can be assessed: Projects are planned and broken down into measurable aims, which must
be open to evaluation.

• Projects are made up of stages: Projects have distinct, identifiable stages.

1.6 SUMMARY

A project in business and science is typically defined as a collaborative enterprise, frequently

involving research or design that is carefully planned to achieve a particular aim. Projects can be
further defined as temporary rather than permanent social systems that are constituted by teams
within or across organizations to accomplish particular tasks under time constraints.

The project concept is applied in different ways in different fields. It has different application in
following fields: School and university, Engineering project, Business management, Experimental /
Research / Measurement Projects, Search and Find Projects, Construction Projects, Reengineering
Projects, Procurement Projects, Business Implementation Projects

Some projects are difficult to classify. In most cases, this difficulty arises from an ambiguity about the
primary purpose of the project. Are we doing this pilot for its own sake, or merely as an experiment?
Are we doing this drug trial to benefit current patients, or to create knowledge that will benefit future
patients? What’s the real political agenda? Of course, we must be able to handle hybrid projects.

Project can also be Classified based on nature of Project as per following: Greenfield Projects,
Brownfield Project, reengineering projects, Restructuring projects, Backward Integration Projects,
Forward integration Projects, Modernization Projects.

A project has several characteristics:

• Projects are unique

• Projects are temporary in nature and have a definite beginning and ending date
• Projects are completed when the project goals are achieved, or it’s determined the project is
no longer viable
• A successful project is one that meets or exceeds the expectations of your stakeholders
 1.7 KEY WORDS

Project - A project in business and science is typically defined as a collaborative enterprise, frequently
involving research or design that is carefully planned to achieve a particular aim. Projects can be
further defined as temporary rather than permanent social systems that are constituted by teams
within or across organizations to accomplish particular tasks under time constraints.
Greenfield project - A Greenfield project is the investment in a manufacturing, office, or other
physical company-related structure or group of structures in an area where no previous facilities
exist.

Brownfield Project - The term Brownfield was originally used in construction and development to
reference land that at some point was occupied by a permanent structure. In a Brownfield project the
structure would need to be demolished or renovated.

Backward Integration - Backward Integration is a type of Vertical Integration in which a consumer of

raw material acquires its suppliers or sets up its own facilities to ensure a more reliable or cost –
effective supply of inputs.”

Forward integration Projects - Forward integration is a strategy in which companies expand their
activities to control the direct distribution of their products.

Modernization Projects - Modernization refers to a model of an evolutionary transition from a 'pre-

modern' or 'traditional' to a 'modern' society.
 UNIT 2 PROJECT MANAGEMENT
Objectives

After reading this unit, you will be able to:

• Explain the concept of project management;

• Describe the importance of project management;
• Explain the phases in project management;
• Explain the characteristics project management;
• Describe the steps in project management;
• Explain the project process.

Structure

2.1 Project Management Introduction

2.2 Need for Project Management
2.3 Project Management Objectives
2.4 The Value of Project Management
2.5 Characteristics of Project Management
2.6 Phases in Project Management
2.7 Approaches to Project Management
2.8 Project Processes
2.9 Summary
2.10 Keywords

2.1 PROJECT MANAGEMENT INTRODUCTION

In this unit we will define the concept of project management. The unit is focused on helping the
student understand what is project management and why do we need project management. It will
help the students to equip themselves with the concept of project management objectives and value
in today’s scenario of globalization. It will help the students to approach project management in
different ways considering the characteristics and phases of project management.

2.2 NEED FOR PROJECT MANAGEMENT

Many things can go wrong in project management. These things are often called barriers. Here are
some possible barriers:
• Poor communication
• Disagreement
• Misunderstandings
• Bad weather
• Union strikes
• Personality conflicts
• Poor management
 • Poorly defined goals and objectives

A good project management discipline will not eliminate all risks, issues and surprises, but will provide
standard processes and procedures to deal with them and help prevent the following:

• Projects finishing late, exceeding budget or not meeting customer expectations.

• Inconsistency between the processes and procedures used by project managers, leading to
some being favored more than others.
• Successful projects, despite a lack of planning, achieved through high stress levels, goodwill
and significant amounts of overtime.
• Project management seen as not adding value and as a waste of time and money.
• Unforeseen internal and/or external events impacting the project.

The Top Ten Reasons Why You Need Project Management

• Control scope creep and manage change;
• Deliver project results on time and on budget;
• Focus the project team on the solution;
• Obtain project buy-in from disparate groups;
• Define the critical path to optimally complete your project;
• Provide a process for estimating project resources, time, and costs;
• Communicate project progress, risks, and changes;
• Surface and explore project assumptions;
• Prepare for unexpected project issues; and
• Document, transfer, and apply lessons learned from your projects

Project management is about creating an environment and conditions in which a defined goal or
objective can be achieved in a controlled manner by a team of people.
Project management is often summarized in a triangle. The three most important factors are time,
cost and scope, commonly called the triple constraint. These form the vertices with quality as a central
theme.

• Projects must be delivered on time

• Projects must be within cost
• Projects must meet customer quality requirements
A disciplined project management process is important to any project. Project managers are expected
to deliver results, on time (if not sooner) and within budget. Solid project planning reduces the risks
associated with any project you take on. Here are ten reasons why you need project management:

Control Scope Creep and Manage Change

Small changes in demands occur on every project. They come from management, the customer, your
project team, suppliers, or other stakeholders. Individually, they may appear acceptable, but
collectively these project demands can add up to a significant project expansion (referred to as “scope
creep”) that can overrun your budget. As a project manager, if you effectively manage the scope of
your project, you have a better than even chance of effectively managing project resources — time,
money, etc. — and managing change.

Deliver Project Results on Time and On Budget

Project planning starts with a well thought out business case justification that usually includes some
type of cost calculation associated with Return on Investment (ROI). Once these measures are
established, it is up to the project manager to ensure that on-time, on-budget performance is
maintained; otherwise, the project will never produce the expected results. That’s what good project
management is all about.

Focus the Project Team on the Solution

The project team can easily drift off topic and spend too much time on the wrong tasks. A good project
manager keeps the project team focused by using a clear and concise project charter, resolving
barriers, or shielding the team from unnecessary interference.

Obtain Project Buy-In from Disparate Groups

As President Lincoln once said, “Public sentiment is everything. With it, nothing can fail; without it,
nothing can succeed.” A good project manager uses the tools in the initiation phase of project
management to collect user requirements, project constraints, and a feasibility study to build a strong
business case justification. Using input from various sources, the project manager overcomes dissent
and obtains buy-in by communicating the project benefits as the different stakeholder groups see
them.

Define the Critical Path to Optimally Complete your Project

Every project is made up of a series of connected activities, each of which has its own constraints. The
project manager identifies the critical path of activities — the optimal sequence of actions that best
ensure the project’s successful completion.

Provide a Process for Estimating Project Resources, Time, and Costs

Using project management software, previous project experiences, and a solid project initiation phase
can provide the discipline needed to reduce project estimating errors, increasing the likelihood that
the project will finish on time and on budget.

Communicate Project Progress, Risks, and Changes

As a project progresses, stakeholders must be kept informed of the outcomes, changes, stumbling
blocks, or successes that the project experiences. Project management creates a project
communication plan to address these communication issues, provide a format, and lay out a process
for execution.

Surface and Explore Project Assumptions

All projects are based on assumptions to some extent. A good project manager delves into user
requirements, project constraints, and management expectations to understand what is said and what
is not said. Relying on too many unconfirmed assumptions can invalidate a project schedule or, worse,
sink the project.

Prepare for Unexpected Project Issues

Every project runs into unforeseen issues, such as changes in market conditions, and is hit with random
cause variability. Experienced project managers plan for the unexpected by lining up alternative
courses of action.

Document, Transfer, and Apply Lessons Learned from Your Projects

The last phase of project management focuses on “closing out” the project. The project manager
reviews how well each prior phase — project initiation, project planning, project execution, and
project monitoring and control — was performed. As part of good knowledge management, all project
review notes should be dissected and analyzed for patterns, trends, and opportunities for
improvement. These “lessons learned” should be documented and communicated to other project
managers before starting the next project.

2.3 PROJECT MANAGEMENT OBJECTIVES

Effective objectives in project management are specific. A specific objective increases the chances of
leading to a specific outcome. Therefore objectives shouldn't be vague, such as "to improve customer
relations," because they are not measurable. Objectives should show how successful a project has
been, for example "to reduce customer complaints by 50%" would be a good objective. The measure
can be, in some cases, a simple yes or no answer, for example, "did we reduce the number of customer
complaints by 50%?"

While there may be one major project objective, in pursuing it there may be interim project objectives.
In lots of instances, project teams are tasked with achieving a series of objectives in pursuit of the final
objective. In many cases, teams can only proceed in a stair step fashion to achieve the desired
outcome. If they were to proceed in any other manner, they may not be able to develop the skills or
insights along the way that will enable them to progress in a productive manner.

Objectives can often be set under three headings:

Performance and Quality

The end result of a project must fit the purpose for which it was intended. At one time, quality was
seen as the responsibility of the quality control department. In more recent years the concept of total
quality management has come to the fore, with the responsibility for quality shared by all staff from
top management downwards.

Budget
The project must be completed without exceeding the authorised expenditure. Financial sources are
not always inexhaustible and a project might be abandoned altogether if funds run out before
completion. If that was to happen, the money and effort invested in the project would be forfeited
and written off. In extreme cases the project contractor could face ruin. There are many projects
where there is no direct profit motive, however it is still important to pay proper attention to the cost
budgets, and financial management remains essential.

Time to Completion
Actual progress has to match or beat planned progress. All significant stages of the project must take
place no later than their specified dates, to result in total completion on or before the planned finish
date. The timescale objective is extremely important because late completion of a project is not very
likely to please the project purchaser or the sponsor.

2.4 THE VALUE OF PROJECT MANAGEMENT

Looking for a way to stay ahead of the pack in today’s competitive and chaotic global economy,
companies are turning to project management to consistently deliver business results.

Disciplined project management starts at the portfolio level, where the strategic vision drives initial
investments and where value measures are established. A fully aligned project, program and portfolio
management strategy encompasses the entire organization, dictating project execution at every level
and aiming to deliver value at each step along the way.

Project management is, in fact, shorthand for project, program and portfolio management. And more
companies are clearly seeing the payoff from investing time, money and resources to build
organizational project management expertise: lower costs, greater efficiencies, improved customer
and stakeholder satisfaction, and greater competitive advantage.

The economic downturn only heightened that value. An Economist Intelligence report showed that 80
percent of global executives believed having project management as a core competency helped them
remain competitive during the recession. And even as some executives see the glimmers of a fragile
recovery, there is little doubt that a strong organization-wide commitment to project management
leads to better results and long-term business value.

Leading organizations across sectors and geographic borders have been steadily embracing project
management as a way to control spending and improve project results.
When the recession began, this practice became even more important. Executives discovered that
adhering to project management methods and strategies reduced risks, cut costs and improved
success rates—all vital to surviving the economic crisis.

Companies are also discovering that as their project management strategy matures, the business value
derived from it also increases. To increase that value and ensure strategic alignment across the project
portfolio, executives at many global organizations are creating formal project management offices
(PMOs).

Implementing project management across the organization helps create a strategic value chain that
gives companies an edge on their competitors, particularly in high-risk sectors and markets. Being able
to deliver projects on time and within budget often determines whether a company will get the next
job or whether its new product hits the market.

Keeping the project on track requires a strict management of metrics and project goals that extends
across the project team and out to suppliers, contractors, the client and the stakeholders.
To keep that competitive edge, companies need to align their project management strategies directly
with their strategic business goals.

2.5 CHARACTERISTICS OF PROJECT MANAGEMENT

Project management is a complex process which can be successfully accomplished if we understand

the characteristics of project management which are as follows:

Resource requirement: During the course of executing the project, it is seen that the resource
requirement increase from start to an intermediate stage of the project. It further increases at rapid
rate and becomes constant while the project is during it’s so to 95% progress stage. Thereafter the
resources requirement decreases to zero i.e. when the project comes to finish. Refer the characteristic
chart.

Funds: The requirement of funds to complete execution of the project also follows the same trends as
that of the resources. The two are more or less proportional. Refer the characteristic chart.

Probability of completion: The probability of completing the project can be estimated based upon the
normal distribution curve. In the initial stage of the project the probability of completing the project
is low though not zero. It gradually increases and as the project approaches finish the probability of
completing the project tends to become 100% Refer the characteristic chart.

Risk: The risks involved in the project effecting its completion time are high at the initial stages and
low at the later stages of the project. Refer the characteristic chart.

Design changes: The project during the course of its progress may be subjected to changes because of
some external factors. The influence of such external factors on the project may result in changes in
the design of the project though not very often. It is observed that such changes.
• Importance of project Management projects may be completed with one or more of the following:
⎯ Stretched deadlines
⎯ Over stressed team
⎯ Wasted resources
⎯ Unmet customers’ functional requirements
⎯ Overshot budget

• A good project management methodology provides a framework for the process.

It provides guidelines for the execution of the project that greatly increases the chances of the
project being successful, and therefore provides value to the project.

2.6 PHASES IN PROJECT MANAGEMENT

A project goes through six phases during its life:

• Project Definition: Defining the goals, objectives and critical success factors for the project.
• Project Initiation: Everything that is needed to set-up the project before work can start.
• Project Planning: Detailed plans of how the work will be carried out including time, cost and
resource estimates.
• Project Execution: Doing the work to deliver the product, service or desired outcome.
• Project Monitoring & Control: Ensuring that a project stays on track and taking corrective
action to ensure it does.
• Project Closure: Formal acceptance of the deliverables and disbanding of all the elements that
were required to run the project.

Steps in Project Management

For every project to be successful, there should be complete agreement about what the clients/end
users/stakeholders want and what you are trying to achieve through the project. It is best if this is
achieved in the analysis stage itself, so the project can set off in the right direction without any doubt
about matching the deed to the need. The following are the steps for an optimal business requirement
analysis for any project to be successful.

Know Your Stakeholders

Learn all about the sponsors/clients/stakeholders/end users of the project. It is essential to identify
the sponsors who may have authority to change any decision. What their views and needs are will
have a strong influence on the process. Also you should know about the intended end-users. Their
input is essential. Stakeholders and end-users may be from within the company or outsiders.

Know Stakeholders’ Requirements

• You should compile an exhaustive list of the requirements of each of stakeholder and end-user;
you should compile all their requirements to get an overall picture.
• Give an exact picture of the limits and extent of the project to keep the requirements within the
range and pertaining to the project alone.

• You can hold individual interviews as well as group discussions (requirements workshops) to
discuss the requirements.

• There are other techniques for eliciting the requirements like use cases, prototyping, data flow
diagrams, and competitor analysis. It is essential that the exact requirements of the stakeholders
are established.
• Build a prototype of the project to give an exact idea of the final results of the product or project
to stakeholders.

Classify the Requirements

With so many requirements on the agenda, it will make better sense to group the requirements under
various categories. There can be 3-4 types, such as:

• What requirements identify with functions and components the end-users are expecting?
• What requirements identify with the operational activities that need to be done?
• What requirements identify with the technical details needed for smooth functioning?
• What may be needed for the successful completion of the project?

Analyze the Requirements

Now it is necessary to go in depth about the nature of the requirements. You should determine
whether the compiled list of requirements are clear in their purpose and are pertaining to the project
or the process. Is there any ambiguity inherent? Are there any contradictory interests to other issues?
Is implementation of each requirement feasible?

• List all the requirements with regard to priority and relevancy to the project.
• Also try to predict the impact of any changes proposed.
• Solve the ambiguous and conflicting details that have come up.
• The final list of requirements must be clear, unambiguous, concise, feasible, and relevant to
the project.

Document the Requirements

Once the requirements are completely known and the stakeholders/end-users are clear about what
they want from the project, what they are going to achieve, and they have seen the prototype and are
satisfied, it is time to create a document that will combine all the details and get it signed by all
stakeholders/end users and the project manager. This will be the rule-book for the project. All
stakeholders, end-users, project personnel, and developers should be given a copy to apprise them of
the project goals. An efficiently-done business requirements analysis will enable you to pinpoint
exactly what is wanted from the project and how you can achieve it. Once this is done, there will be
no ambiguity about the diverse requirements/specifications connected with the project and there will
be a focused and well-planned execution of the project with no chance for a scope or function creep.
 2.7 APPROACHES TO PROJECT MANAGEMENT

There are a number of approaches to managing project activities including lean, iterative,
incremental, and phased approaches.

Regardless of the methodology employed, careful consideration must be given to the overall project
objectives, timeline, and cost, as well as the roles and responsibilities of all participants and
stakeholders. The traditional approach

A traditional phased approach identifies a sequence of steps to be completed. In the "traditional

approach", five developmental components of a project can be distinguished (four stages plus
control):

Typical development phases of an engineering project

• initiation
• planning and design
• execution and construction
• monitoring and controlling systems
• completion

Not all projects will have every stage, as projects can be terminated before they reach completion.
Some projects do not follow a structured planning and/or monitoring process. And some projects will
go through steps 2, 3 and 4 multiple times.

Many industries use variations of these project stages. For example, when working on a brick-and-
mortar design and construction, projects will typically progress through stages like pre-planning,
conceptual design, schematic design, design development, construction drawings (or contract
documents), and construction administration. In software development, this approach is often known
as the waterfall model, i.e., one series of tasks after another in linear sequence. In software
development many organizations have adapted the Rational Unified Process (RUP) to fit this
methodology, although RUP does not require or explicitly recommend this practice. Waterfall
development works well for small, well defined projects, but often fails in larger projects of undefined
and ambiguous nature. The Cone of Uncertainty explains some of this as the planning made on the
initial phase of the project suffers from a high degree of uncertainty. This becomes especially true as
software development is often the realization of a new or novel product. In projects where
requirements have not been finalized and can change, requirements management is used to develop
an accurate and complete definition of the behavior of software that can serve as the basis for
software development. While the terms may differ from industry to industry, the actual stages
typically follow common steps to problem solving—"defining the problem, weighing options, choosing
a path, implementation and evaluation."

PRINCE2

The PRINCE2 process model

PRINCE2 is a structured approach to project management, released in 1996 as a generic project

management method. It combined the original PROMPT methodology (which evolved into the PRINCE
methodology) with IBM's MITP (managing the implementation of the total project) methodology.
PRINCE2 provides a method for managing projects within a clearly defined framework. PRINCE2
describes procedures to coordinate people and activities in a project, how to design and supervise the
project, and what to do if the project has to be adjusted if it does not develop as planned. In the
method, each process is specified with its key inputs and outputs and with specific goals and activities
to be carried out. This allows for automatic control of any deviations from the plan. Divided into
manageable stages, the method enables an efficient control of resources. On the basis of close
monitoring, the project can be carried out in a controlled and organized way.

PRINCE2 provides a common language for all participants in the project. The various management
roles and responsibilities involved in a project are fully described and are adaptable to suit the
complexity of the project and skills of the organization.

PRiSM (Projects integrating Sustainable Methods)

PRiSM is a process-based, structured project management methodology that highlights areas of
sustainability and integrate them into four core project phases in order to maximize opportunities to
improve sustainability and the use of finite resources.

The PRiSM Flowchart

The methodology encompasses the management, control and organization of a project with
consideration and emphasis beyond the project life-cycle and on the five aspects of sustainability.
PRiSM is also used to refer to the training and accreditation of authorized practitioners of the
methodology who must undertake accredited qualifications based on competency to obtain the GPM
certification.

Critical Chain Project Management

Critical Chain Project Management (CCPM) is a method of planning and managing project execution
designed to deal with uncertainties inherent in managing projects, while taking into consideration
limited availability of resources (physical, human skills, as well as management & support capacity)
needed to execute projects. CCPM is an application of the Theory of Constraints (TOC) to projects. The
goal is to increase the flow of projects in an organization (throughput). Applying the first three of the
five focusing steps of TOC, the system constraint for all projects is identified as are the resources. To
exploit the constraint, tasks on the critical chain are given priority over all other activities. Finally,
projects are planned and managed to ensure that the resources are ready when the critical chain tasks
must start, subordinating all other resources to the critical chain. The project plan should typically
undergo resource leveling, and the longest sequence of resource-constrained tasks should be
identified as the critical chain. In some cases, such as managing contracted sub-projects, it is advisable
to use a simplified approach without resource leveling. In multi-project environments, resource
leveling should be performed across projects. However, it is often enough to identify (or simply select)
a single "drum". The drum can be a resource that acts as a constraint across projects, which are
staggered based on the availability of that single resource.

One can also use a "virtual drum" by selecting a task or group of tasks (typically integration points)
and limiting the number of projects in execution at that stage.

Event Chain Methodology

Event chain methodology is another method that complements critical path method and critical chain
project management methodologies.

Event chain methodology is an uncertainty modeling and schedule network analysis technique that is
focused on identifying and managing events and event chains that affect project schedules. Event
chain methodology helps to mitigate the negative impact of psychological heuristics and biases, as
well as to allow for easy modeling of uncertainties in the project schedules. Event chain methodology
is based on the following principles.

Probabilistic Moment of Risk

An activity (task) in most real-life processes is not a continuous uniform process. Tasks are affected by
external events, which can occur at some point in the middle of the task.

Event chains: Events can cause other events, which will create event chains. These event chains can
significantly affect the course of the project. Quantitative analysis is used to determine a cumulative
effect of these event chains on the project schedule.
Critical events or event chains: The single events or the event chains that have the most potential to
affect the projects are the “critical events” or “critical chains of events.” They can be determined by
the analysis.

Project tracking with events: Even if a project is partially completed and data about the project
duration, cost, and events occurred is available, it is still possible to refine information about future
potential events and helps to forecast future project performance.

Event chain visualization: Events and event chains can be visualized using event chain diagrams on a
Gantt chart.

Process-Based Management
Also furthering the concept of project control is the incorporation of process-based management. This
area has been driven by the use of Maturity models such as the CMMI (capability maturity model
integration; see this example of a predecessor) and ISO/IEC15504 (SPICE – software process
improvement and capability estimation).

Agile Project Management

The Iteration Cycle in Agile Project Management

Agile project management approaches based on the principles of human interaction management are
founded on a process view of human collaboration. It is "most typically used in software, website,
technology, creative and marketing industries." This contrasts sharply with the traditional approach.
In the agile software development or flexible product development approach, the project is seen as a
series of relatively small tasks conceived and executed as the situation demands in an adaptive
manner, rather than as a completely pre-planned process.

Lean Project Management

Lean project management uses principles from lean manufacturing to focus on delivering value with
less waste.

Extreme Project Management

Planning and feedback loops in Extreme programming (XP) with the time frames of the multiple loops.

In critical studies of project management it has been noted that several PERT based models are not
well suited for the multi-project company environment of today. Most of them are aimed at very large-
scale, one-time, non-routine projects, and currently all kinds of management are expressed in terms
of projects.
Using complex models for "projects" (or rather "tasks") spanning a few weeks has been proven to
cause unnecessary costs and low maneuverability in several cases. Instead, project management
experts try to identify different "lightweight" models, such as Extreme Programming and Scrum.

The generalization of Extreme Programming to other kinds of projects is extreme project

management, which may be used in combination with the process modeling and management
principles of human interaction management.

Benefits Realisation Management

Benefits realization management (BRM) enhances normal project management techniques through a
focus on agreeing what outcomes should change (the benefits) during the project, and then measuring
to see if that is happening to help keep a project on track. This can help to reduce the risk of a
completed project being a failure as instead of attempting to deliver agreed requirements the aim is
to deliver the benefit of those requirements.

An example of delivering a project to requirements could be agreeing on a project to deliver a

computer system to process staff data with the requirement to manage payroll, holiday and staff
personnel records. Under BRM the agreement would be to use the suppliers suggested staff data
system to see an agreed reduction in staff hours processing and maintaining staff data (benefit reduce
HR headcount).

2.8 PROJECT PROCESSES

Traditionally, project management includes a number of elements: four to five process groups, and a
control system. Regardless of the methodology or terminology used, the same basic project
management processes will be used. Major process groups generally include:

• Initiation
• Planning or design
• Production or execution
• Monitoring and controlling
• Closing
The Project Development Stages

In project environments with a significant exploratory element (e.g., research and development),
these stages may be supplemented with decision points (go/no go decisions) at which the project's
continuation is debated and decided. An example is the Phase–gate model.

Initiating

Initiating Process

The initiating processes determine the nature and scope of the project. If this stage is not performed
well, it is unlikely that the project will be successful in meeting the business’ needs. The key project
controls needed here are an understanding of the business environment and making sure that all
necessary controls are incorporated into the project. Any deficiencies should be reported and a
recommendation should be made to fix them.
The initiating stage should include a plan that encompasses the following areas:

• analyzing the business needs/requirements in measurable goals

• reviewing of the current operations
• financial analysis of the costs and benefits including a budget
• stakeholder analysis, including users, and support personnel for the project
• project charter including costs, tasks, deliverables, and schedule

Planning and design

After the initiation stage, the project is planned to an appropriate level of detail. The main purpose is
to plan time, cost and resources adequately to estimate the work needed and to effectively manage
risk during project execution. As with the Initiation process group, a failure to adequately plan greatly
reduces the project's chances of successfully accomplishing its goals.

Project planning generally consists of:

• determining how to plan (e.g. by level of detail or rolling wave);

• developing the scope statement;
• selecting the planning team;
• identifying deliverables and creating the work breakdown structure;
• identifying the activities needed to complete those deliverables and networking the activities
in their logical sequence;
• estimating the resource requirements for the activities;
• estimating time and cost for activities;
• developing the schedule;
• developing the budget;
• risk planning;
• gaining formal approval to begin work.

Additional processes, such as planning for communications and for scope management, identifying
roles and responsibilities, determining what to purchase for the project and holding a kick-off meeting
are also generally advisable.

For new product development projects, conceptual design of the operation of the final product may
be performed concurrent with the project planning activities, and may help to inform the planning
team when identifying deliverables and planning activities.

Executing
Executing Process

Executing consists of the processes used to complete the work defined in the project plan to
accomplish the project's requirements. Execution process involves coordinating people and resources,
as well as integrating and performing the activities of the project in accordance with the project
management plan. The deliverables are produced as outputs from the processes performed as defined
in the project management plan and other frameworks that might be applicable to the type of project
at hand.

Monitoring and controlling

Monitoring and Controlling Process

Monitoring and controlling consists of those processes performed to observe project execution so that
potential problems can be identified in a timely manner and corrective action can be taken, when
necessary, to control the execution of the project. The key benefit is that project performance is
observed and measured regularly to identify variances from the project management plan.

Monitoring and controlling includes:

• Measuring the ongoing project activities ('where we are');

• Monitoring the project variables (cost, effort, scope, etc.) against the project management
plan and the project performance baseline (where we should be);
• Identify corrective actions to address issues and risks properly (How can we get on track
again);
• Influencing the factors that could circumvent integrated change control so only approved
changes are implemented.

In multi-phase projects, the monitoring and control process also provides feedback between project
phases, in order to implement corrective or preventive actions to bring the project into compliance
with the project management plan.

Project maintenance is an ongoing process, and it includes:

• Continuing support of end-users

• Correction of errors
• Updates of the software over time

Monitoring and Controlling Cycle

In this stage, auditors should pay attention to how effectively and quickly user problems are resolved.
Over the course of any construction project, the work scope may change. Change is a normal and
expected part of the construction process. Changes can be the result of necessary design
modifications, differing site conditions, material availability, contractor-requested changes, value
engineering and impacts from third parties, to name a few. Beyond executing the change in the field,
the change normally needs to be documented to show what was actually constructed. This is referred
to as change management. Hence, the owner usually requires a final record to show all changes or,
more specifically, any change that modifies the tangible portions of the finished work. The record is
made on the contract documents – usually, but not necessarily limited to, the design drawings. The
end product of this effort is what the industry terms as-built drawings, or more simply, “as built.” The
requirement for providing them is a norm in construction contracts.

When changes are introduced to the project, the viability of the project has to be re-assessed. It is
important not to lose sight of the initial goals and targets of the projects. When the changes
accumulate, the forecasted result may not justify the original proposed investment in the project.

Closing

Closing process

Closing includes the formal acceptance of the project and the ending thereof. Administrative activities
include the archiving of the files and documenting lessons learned.

This phase consists of:

Project close: Finalize all activities across all of the process groups to formally close the project or a
project phase

Contract closure: Complete and settle each contract (including the resolution of any open items) and
close each contract applicable to the project or project phase.

Project controlling and project control systems

Project controlling should be established as an independent function in project management. It

implements verification and controlling function during the processing of a project in order to
reinforce the defined performance and formal goals. The tasks of project controlling are also:
 • the creation of infrastructure for the supply of the right information and its update
• the establishment of a way to communicate disparities of project parameters
• the development of project information technology based on an intranet or the determination
of a project key performance index system (KPI)
• divergence analyses and generation of proposals for potential project regulations
• the establishment of methods to accomplish an appropriate the project structure, project
workflow organization, project control and governance
• creation of transparency among the project parameters

Fulfillment and implementation of these tasks can be achieved by applying specific methods and
instruments of project controlling. The following methods of project controlling can be applied:

• investment analysis
• cost–benefit analyses
• value benefit Analysis
• expert surveys
• simulation calculations
• risk-profile analyses
• surcharge calculations
• milestone trend analysis
• cost trend analysis
• target/actual-comparison

Project control is that element of a project that keeps it on-track, on-time and within budget. Project
control begins early in the project with planning and ends late in the project with post-implementation
review, having a thorough involvement of each step in the process. Each project should be assessed
for the appropriate level of control needed: too much control is too time consuming, too little control
is very risky. If project control is not implemented correctly, the cost to the business should be clarified
in terms of errors, fixes, and additional audit fees.

Control systems are needed for cost, risk, quality, communication, time, change, procurement, and
human resources. In addition, auditors should consider how important the projects are to the financial
statements, how reliant the stakeholders are on controls, and how many controls exist. Auditors
should review the development process and procedures for how they are implemented. The process
of development and the quality of the final product may also be assessed if needed or requested. A
business may want the auditing firm to be involved throughout the process to catch problems earlier
on so that they can be fixed more easily. An auditor can serve as a controls consultant as part of the
development team or as an independent auditor as part of an audit.

Businesses sometimes use formal systems development processes. These help assure that systems
are developed successfully. A formal process is more effective in creating strong controls, and auditors
should review this process to confirm that it is well designed and is followed in practice. A good formal
systems development plan outlines:

• A strategy to align development with the organization’s broader objectives

 • Standards for new systems
• Project management policies for timing and budgeting
• Procedures describing the process
• Evaluation of quality of change

The figures taken from "Project Management Guide". VA Office of Information and Technology. March
3, 2005.

2.9 SUMMARY

Project management is about creating an environment and conditions in which a defined goal or
objective can be achieved in a controlled manner by a team of people

Project management is often summarized in a triangle. The three most important factors are time,
cost and scope, commonly called the triple constraint.

Many things can go wrong in project management. These things are often called barriers. Here are
some possible barriers: Poor communication, Disagreement, Misunderstandings, Bad weather, Union
strikes, Personality conflicts, Poor management, Poorly defined goals and objectives

A good project management discipline will not eliminate all risks, issues and surprises, but will provide
standard processes and procedures to deal with them

Proper project management results into Better efficiency in delivering services,

Improved/increased/enhanced customer satisfaction, Enhanced effectiveness in delivering services,
Improved growth and development within your team, Greater standing and competitive edge,
Opportunities to expand your services, Better Flexibility, Increased risk assessment, Increase in
Quality, Increase in Quantity.

Project management is a complex process which can be successfully accomplished if we understand

the characteristics of project management which are Resource requirement, Funds, Probability of
completion, Risk, Design changes.

Some of the steps of a good project management are – Define the project, reduce it to a set of
manageable tasks, Obtain appropriate and necessary resources, Build a team to perform the project
work, Plan the work and allocate the resources to the tasks.

A project goes through six phases during its life: Project Definition, Project Initiation, Project Planning,
Project Execution, Project Monitoring & Control, Project Closure.
 2.10 KEYWORDS

Project management: Project management is about creating an environment and conditions in which
a defined goal or objective can be achieved in a controlled manner by a team of people.

Project management methodology: project management methodology covers all the things a project
manager needs to do regardless of whether the project is a software development, package selection,
or relocation of his department.

Project Management steps : Some of the steps of a good project management are – Define the
project, Reduce it to a set of manageable tasks, Obtain appropriate and necessary resources, Build a
team to perform the project work, Plan the work and allocate the resources to the tasks.

Project phases: A project goes through six phases during its life: Project Definition, Project Initiation,
Project Planning, Project Execution, Project Monitoring & Control, Project Closure.
 UNIT 3 PROJECT MANAGEMENT CONTENTS

Objectives

After reading this unit, you will be able to:

• To explain the phases in project life cycle;

• To arrange for resources for projects;
• To control the use of resources for projects;
• To Prepare a business case.

Structure

3.1 Introduction to Project Management contents

3.2 Project life cycle
3.3 Business case
3.4 Project management resources
3.5 Summary
3.6 Keywords

3.1 INTRODUCTION TO PROJECT MANAGEMENT CONTENTS

For a successful project management it is important to look at understanding the contents of

project management. This unit on content of project management is focused around following
topics: Lead a project throughout its cycle; it’s so important that it is the first topic, Prepare a
business case; and arranging resources for project management.

3.2 PROJECT MANAGEMENT LIFE CYCLE

The Project Management Life Cycle has four phases: Initiation, Planning, Execution and
Closure. Each project life cycle phase is described below, along with the tasks needed to
complete it.
Source - http://www.maxwideman.com/papers/projenviron/dimensions.htm

Conception stage: Project idea is conceived to a level where it is possible to take a call on
working on the same.
• Project basics such as type of product /service / output as the end result.

• Financial feasibility including IRR, investments, nature of resources, rough time frame,
nature of legal, procedural & permission oriented requirements & fundamental
acceptance for the project profile from the customer.

Planning/Design stage: Detailed designing of various aspects of project are carried out to the
last nut & bolt.
• Splitting of the project into logical & functional modules (mini projects in themselves).
• Defining clear interfaces between the modules.
• Individual specifics of each module – Objectives, time & cost targets, milestones etc.
• Resource needs (inclusive of HR) for each module & allocation of the same.
• Execution plan of each module & integration of the same with the rest.
• Identifying the risk elements & provision for addressing them.
 • Evaluation of impact of risks & probable solutions to mitigate the same.
• Clear definition of approach & path for execution.
• Identification of most critical factors for the success.
• Control plan for monitoring the progress.
• Clear definition of process for customer interface.
• Define organization structure.

Execution/Implementation stage - Execution as per the design.

• Resource provision, allocation & distribution.
• Role definition & explanation to the team members.
• Launching of startup thro’ complete, transparent communication – Formal & informal.
• Launching of functional activities as per the plan.
• Clear plans to implement & monitor the activities as per the plan.
• Launch effective process to identify & rectify the deviations.
• Impact analysis of every deviation.
• Close interaction with customer to ensure that the project is as per the need &
integration of the desired changes.
• Taking the project towards logical conclusion.

Completion / Transfer / Commissioning stage – It is commissioned & put to use. This

signifies the end of project life cycle.
• Ensure completion of each activity.

• Analysis for deviations & corrections of the same or the integration of the same.

• Trial run of the live process with the help of customer for monitoring the results as
compared to the original expectations.

• Monitoring the efficiency & effectiveness of each sub process wrt to output quality,
resource consumption & required time as also integration of the same with whole
process.

• Customer approval for the whole thing.

• Formal closure of the project.

 3.3 BUSINESS CASE

A business case is: ‘A document that forms the basis of advice for executive decision-making
for an asset investment. It is a documented proposal to meet a clearly established service
requirement. It considers alternative solutions and identifies assumptions, benefits, costs and
risks.’

The purpose of a business case is to persuade those with authority that they should endorse and
fund a particular project or initiative by making a “compelling case for investment”2. The level
of detail required in the business case will depend on the complexity and cost of the project. In
many environments there will be a set format or template that agencies will need to use. It may
be a mandatory requirement when requesting funding over a certain level for the business case
to be written using a specific template.

It is critical to identify the audience for your business case, so that you can work out how best
to “sell” your proposal. For a business case the audience is the person or people who need to
support or approve it for it to be successful and result in the outcomes you want.

Sometimes this means your business case needs to be written for several audiences as there
may be multiple levels required to support or endorse it. This can become difficult when these
audiences have different or even opposing viewpoints.

Once you have established who the audience is, critical questions to ask are:
• Does this person understand the environment and background of the project?
• What information will this person be looking for?
• What impact is the project or initiative going to have on this person?
• How could this person influence the direction of the project or initiative?
• What does this person need to see in order to support or endorse the project or initiative?

Keep in mind that, although there may be a number of people who will be reading your business
case, you will only be writing it once. This means that your business case will need to be written
in a way that will ensure everyone who reads it can understand it. The language and concepts
that you use within the business case will need to be understood clearly by all those who will
need to read it.

To ensure the success of your business case, take the time to gain the support of other business
groups across the agency – especially if the project or initiative will have an impact on them.
Discussing the project with other groups, including its likely implementation and the role that
you would like them to play will strengthen your business case. Possible issues can be
discussed and mutually rewarding solutions can be determined and included in the business
case. Ensuring that the business case is supported and endorsed will then become desirable for
the other group as they will see the project as adding benefit to their work as well as to yours.

It may be necessary to gain support from an influential person who has no knowledge of or
interest in your project. In such instances you should investigate the interests of this person,
and how the project or initiative may benefit them in light of their interest. Focus on the benefits
for them and express your requirements in these terms.

Preparing a business case is an integral part of the planning and fundraising process for any
municipal or community project. It becomes more important as the cost and complexity of the
project increases.

This Factsheet will help municipalities and not-for-profit organizations prepare an effective
business case for raising funds — both within the community and through government
programs.
A business case is similar to a business plan prepared for private business. Its purpose is to
outline the business rationale for undertaking the project and to define the parameters and
management factors involved in the project itself. It provides the project manager with a tool
to guide the design, management and evaluation of the project.
The business case serves four purposes:

• It helps the applicant think through the project in a systematic, step-by-step manner.
• It explains to program administrators, funding partners and other interested parties why
the project should be undertaken.
• It helps potential funding partners understand the economic value of the project.
• It provides a framework for completion of the project on time and on budget.

An effective business case is one that matches the purpose and parameters of the funding
program that it seeks to attract. In short, an effective business case justifies:
• Why a project should be undertaken?
• Why a private or public partner should invest in it?
• Why the project represents a worthy expenditure of public funds?

While the business case may be presented in various formats, there are certain elements to
include in any written document. The description that follows is a logical sequence for the final
business case. This format can be adapted to almost any project, but be sure to present the
business case in a manner that will create a favorable impression on the funding partner or
program administrator.

A typical business case format is as per following:

Part One: Executive Summary

Instruction:
This section of the document should be written last and provides a concise summary of each
part of the Business Case. It should include the following:
• Purpose of the business case
• The problem or opportunity the project seeks to address
• The goal and objectives of the project
• An explanation of how the project goal and objectives align with the organization’s
strategic priorities
• Key methods and assumptions used in writing the Business Case
• The results of financial and non-financial impact analyses
• An assessment of the achievability of the project (capability, affordability, risk etc.)
• Conclusions and recommendations

Part Two: Introduction

Recommended text:
This introduction provides the problem or opportunity the proposed project seeks to address
and an overview of how other organizations have responded to similar situations. It also
provides the project goal and objectives and explains how these align with the organization’s
strategic priorities.

Purpose
Instruction:
This section answers the following questions:
• Who is this Business Case written for?
• How will the results of this Business Case be used?

Problem/Opportunity
Instruction:
This section describes the problem or opportunity the project seeks to address using factual
information.
Examples of the types of factual information relevant to problems or opportunities are as
follows:
• Change in legislation requires action.
• Current technology is outdated and not meeting needs.
• Service levels are low, resulting in frequent customer complaints.
• Demand for products or services are increasing.
Tips:
• Be consistent with the “Problem/Opportunity” section of the Project Definition
Document if one was written, but update the problem/opportunity and provide more
details as required.
• Be concise: try to keep this section to half a page or less.
• Focus on information relevant to the project rather than providing a lot of background
information on the organization undertaking the project.

External Review
Instruction:
This section demonstrates that the team has looked at best practice and lessons learned. It
describes how other organizations (public, private, local, or international) have responded to
similar problems, opportunities, and business needs.

It should describe action taken in other organizations, and the high level results, and lessons
learned from their actions. If no other organization has attempted a similar project, include
possible reasons why not.

Goal and Objectives

Instruction:
This section lists one project goal and the project objectives. The project goal is a clear, concise
statement of the project’s purpose and desired results. Project objectives are concise statements
of what the project must achieve to realize the project goal. Objectives can be thought of as
“sub-goals.”

Tips:
• Be consistent with the “Project Goal” and “Project Objectives” sections of the Project
Definition
• Document if one was written. The project goals and objectives should not change if
they have already been approved.
• Be concise: goal statements and objectives should each be one sentence long.
• Example:
• The goal of this project is to reduce traffic accidents. This goal will be achieved if the
following three objectives are achieved:
• Increase public awareness and knowledge of how to drive safely.
• Pass new stricter laws for speeding and seatbelts.
• Assign more police to enforce new stricter laws.

Strategic Alignment
Instruction:
This section describes how the proposed project supports organizational priorities. It explicitly
references the organization’s 3-5 year Strategic Plan and annual Business Plan (also known as
Operating Plan or Output Plan).

This section can also reference relevant decrees and speeches.

This section answers the following questions:

• How does this project help the organization meet its key objectives?
• Why is the project important now (as opposed to another year)?
• What are the consequences of not doing the project?

Part Three: Methods and Assumptions

Instruction:

This section outlines the methods used to arrive at the conclusions and recommendations in
this document.

Authors use this section to explain and defend their conclusions and recommendations. This
section allows readers to judge how data was gathered and analyzed and, ultimately, the
validity of the Business Case.

Scope
Instruction:
This section summarizes the scope of the Business Case, NOT the scope of the proposed
project. It must include all of the following information:

• What costs are included in the case? (The cost to one section in your organization, your
entire organization, or multiple organizations? Are costs to customers included?)
• What benefits are included in the case? (The benefits to one section in your
organization, your entire organization, or multiple organizations? Are benefits to
customers included?)
• How many years of costs and benefits are included (i.e. two-year analysis period vs.
four-year analysis period)?
• What is the start and end date for the period of analysis for costs and benefits? (i.e. Jan
1, 2006 to Dec 31, 2010)

Assumptions and Constraints

Recommended Text:
An assumption is a circumstance or event outside the control of the project that can affect its
success and that the authors of this Business Case believe will happen. Constraints are
restrictions or boundaries placed that limit the choices of the team producing the Business Case.
Note that the assumptions listed in this section apply to all the options examined below. Any
assumptions specific to one option are provided in that option description.

Example Assumptions:
 • Cost of materials will not change.
• Implementation can be completed in one month.
• Required vendors will be available.

Example Constraints:
• Required adherence to standards
• Required timeline
• Maximum budget

Data Sources and Methods

Instruction:
This section outlines how the data presented in this Business Case was gathered and analyzed.
Data sources may include internal government reports, census and other survey-based data,
data from international organizations, feasibility studies, pilot project results, benchmarks,
proposals, and contracts.

Methods that should be identified include:

• Full value or incremental value (for cost information).
• Resource-based costing or activity-based costing (for cost information).
• How benefits are measured and valued (for benefit information).

Decision Criteria
Instruction:
Because a Business Case supports decision-making by senior executives, it must explicitly
outline the criteria for recommending a certain course of action. The criteria can be listed as
“results” and can be financial (ROI, NPV, IRR, payback period etc) or non-financial
(Qatarization of workforce, employee morale, organizational reputation).

Tips:
• Decision criteria should align with the organization’s overall strategy and objectives.
 • Decision criteria should be confirmed with senior executives prior to the evaluation of
alternatives.

Examples:
• The recommended project will have a payback period of three years or less.
• The recommended project will decrease customer waiting times by 50%.
• The recommended option will improve customer satisfaction by 25%.
• The recommended option will improve worker productivity by 20%.
• The recommended option will improve the agency’s reputation/profile.

Options Considered

Instruction:

This section describes the options evaluated in Part Three: Impact Analysis.
A Business Case analyzes and compares options to defend its recommendation for a specific
course of action.
Some organizations will accept two options: (i) “Base case” or status quo and (ii) one alternate
course of action.

Many organizations require three options.

Project Business Case – Preparation Guidelines Page 4

A key challenge in a Business Case is to identify credible options for evaluation. Typical
options explored are as follows:
• Base case: no changes are made to current situation.
• Minimum scope: the minimum scope the project could undertake to address the
problem / opportunity.
• Full scope: the maximum scope the project could undertake to address the problem /
opportunity.
• Collaboration: ways in which project costs could be shared with other government
agencies or the private sector.
 • Make or Buy: the pros and cons of completing a project in-house versus purchasing the
desired product or service from another party.
• Pace: the pros and cons of completing a project quickly versus completing a project in
smaller increments over a longer period of time.

Part Four: Impact Analysis

Instruction:
This section presents the financial and non-financial impacts of the options described in earlier
section of this document. For each option, provide the following information:

Financial Impacts
The extent of financial analysis captured in this section of the business case depends on the
rigor of the financial model used. Common measures used include the following:
• Cash flow, new cash flow, cash flow stream
• Payback period
• Return on Investment (ROI)
• Discounted Cash Flow (DCF) and net present value (NPV)
• Internal rate of return (IRR)

Non-Financial Impacts
Use this section to list the positive and negative non-financial impacts of the option.
Non-financial impacts contribute to strategic priorities and business objectives but cannot
easily be assigned values for lowering costs or increasing revenues. Examples include
employee morale, customer satisfaction, and improved agency reputation.

Sensitivity and Risk

This section identifies the likelihood of results other than the financial and non-financial
impacts described above. This section should provide information on the following:
• Sensitivity: which assumptions are most important to controlling overall results?
Examples include the number of transactions or the cost of materials.
• Risk: What is the likelihood and impact of things that could go wrong?

Summary Evaluation of Options

Instruction:

This section provides an evaluation of options against the decision-making criteria provided in
earlier Section of this document. The template provides a table to summarize the evaluation.

Part Five: Achievability

Recommended text:

This section provides an assessment of how challenging it will be for the organization to
complete the project successfully. It provides (i) an assessment of organizational capability to
complete the project; (ii) an overview of procurement considerations; (iii) recommendations
on how the project should be governed and managed; (iv) a high level timeline for the project
with phases and milestones; (v) an explanation of how risks will be managed; and (vi) available
funding for the project.

Capability
Instruction:
For internal projects, answer the following questions:
• Does the organization have the needed skills and experience to execute this project
successfully?
• Are enough people resources with the needed skills and experience available to execute
this project successfully?
• Has the organization successfully completed similar projects in the past?
• For outsourced projects, answer the following questions:
• Are there vendors available to complete this project?
• Do the vendors have experience delivering similar projects successfully?
• How will procurement be managed?

Procurement
Instruction:
If procurement is required to complete the project, provide information here regarding how the
procurement process will be managed and how the contract will be negotiated and managed
once a vendor is selected.
Project Governance and Management
Instruction:
This section describes how the project will be governed and managed.
To describe project governance arrangements, explain who will (i) make strategic decisions for
the project; (ii) approve final deliverables; (iii) oversee the work of the team. Note that this is
typically done by a Project Sponsor and sometimes also involves a Steering Committee.
To describe how the project will be managed, provide the project management methodology
and the identity of the Project Manager.

Tips:
• The Sponsor and Steering Committee members should be senior enough to oversee the
project, and no one in a governance group should be completing the work of the project.
Example Text:
The Director of Human Resources will be the Project Sponsor and chair a Project Steering
Committee made up of all other Directors at the organization. The Sponsor will receive weekly
status reports from the Project Manager and direct and support the team as needed to keep the
project focused on its goal, objectives, and desired outcomes. At each milestone, the Sponsor
will chair a Steering Committee that will meet to review progress, make strategic decisions,
and approve major deliverables.

The Project Manager for this project will be the Manager of Human Resources, who will work
closely with an external consultant to manage this project and provide technical direction to
the team. Project management processes and deliverables will be based on the Qatar National
Project Management Framework, which is compliant with Project Management Institute (PMI)
standards.

Timeline
Instruction:
This section explains how long the project is expected to take and provides a description of
project phases and milestones.

Risk Management
Instruction:
Project Business Case – Preparation Guidelines Page 6
This section lists the risks identified to date and the recommended response to each risk. A risk
is something that may or may not occur in the future and that can have an impact on the success
of the project.

Tips:
• Include the risks listed in the Project Definition Document if one was written.

• Do not include things that have a 100% chance of happening or that have already
happened: these are issues, not risks.
A good risk event statement includes what might happen and its effect on a project. For
example,
“weather” is not a risk event statement. “Bad weather may delay project completion” is a risk
event statement.

Affordability
Instruction:
This section assesses available funding for the project, and should answer the following
questions:
• Is budget currently available for this project?

• If budget is not currently available, how can budget be obtained to deliver the whole
project?

• If budget cannot be obtained for the whole project, are there ways to reduce the scope
or extend the timeline to reduce costs this year and still achieve meaningful results?

Part Six: Conclusions And Recommendations

Instruction:
This section should be a concise summary of the major findings of the Business Case and the
recommendations of the authors to the decision-makers reading the case.
 3.4 PROJECT MANAGEMENT RESOURCES

In project management terminology, resources are required to carry out the project tasks. They
can be people, equipment, facilities, funding, or anything else capable of definition (usually
other than labour) required for the completion of a project activity. The lack of a resource will
therefore be a constraint on the completion of the project activity. Resources may be storable
or non storable. Storable resources remain available unless depleted by usage, and may be
replenished by project tasks which produce them. Non-storable resources must be renewed for
each time period, even if not utilised in previous time periods.

As given in the article http://arunkottolli.blogspot.in/2011/07/resource-management-in-

projects.html , the author has explained resource management as one of the key corner stones
of project management. If a project manager excels in resource management, then he has 50%
of project management challenges solved, and the project manager needs to concentrate on the
remaining 50% to get the project completed on time & on budget.

Resources cost money, and not having the right resources at the right time upsets the schedule.
In complex projects - especially non - IT projects, there are several types of resources that
needs to be managed: Equipment, supplies, machinery, people, land, clearances etc. These
resources cost money to procure. If the lead times are too short, it costs more money to get the
resources. So it pays to look ahead in the project planning stage and make proper plans to
procure the required resources in a timely manner for the lowest cost. Changes to the cost of
the resources has a big impact on the viability of the project, therefore resource management
also impacts cost management. Resource management has several components:

• Effort Estimation
• Resource Identification
• Lead time to get required resources
• Resource Utilization
• Resource Tracking

Effort Estimation
Effort Estimation is the first step in project planning. Essentially the project has to be broken
into smallest possible work packages and a project plan is made based to meet the delivery
date.

Project manager needs to know the type of efforts involved & the resources needed for that to
start the estimation process. Next step is to prepare the estimates. The best way to get the
estimate is to talk to the actual persons who will be doing the work. Talk to the people and ask
for three estimates: average, pessimistic & optimistic. An experienced project manager will
have a good feel for how reliable these estimates are, and then modify/enter the estimates to
the actual project plan. It is essential to add some buffers into the initial estimates - for
contingencies such as vacations, unexpected sickness etc.

It is very important to know the accuracy of the estimates in project planning. For example, if
you are working on a fixed price project, or if your project is in a critical path of a bigger
program, then you need to have a high level of accuracy.

From experience, people know how much actual effort is involved, so taking a review of the
estimates from an expert will be useful in determining the accuracy of the estimates.

Using a software tools to capture the initial estimate for the task - i.e, for each work package,
and then comparing with the actual effort / resources consumed for a similar task in the past is
very useful for project management. This comparison will help in determining the accuracy of
the estimates. My suggestion would be to use tools such as Clear Quest or Remedy to create
job orders for each work package - and within each job order, capture the initial estimate,
revised estimate and the actual effort taken. If such a system is implemented organization wide,
then even a new project manager can query the system and get a comparative data for analyzing
the estimates.

Only after finalizing on the accuracy of the estimate, share the upper limit value with customers
or any people external to the project team. For the internal project team the aggressive estimate
should be used as bench mark. This allows for flexibility within the project execution and helps
a great deal in customer satisfaction.
Never reveal the lower end of the estimate to customer or even reveal the ball park figures to
the customer before the completing the estimation exercise. Customers often tend to seize the
lower end of the estimate and treat that as the final figure. A good project manager takes effort
and time to hammer all the caveats and assumptions into customer's mind along with the upper
limit of the project estimate.

Summarizing this, the exercise of resource estimation is as follows:

• Break the project down into smallest possible set of tasks - also called work packages.
• Talk to the persons who will be doing the work to get a range of estimates
• Validate the estimate with experts & historical data
• Determine the way the estimates are recorded and presented to customers & stake holders
• Roll up all the estimates and present the pessimistic estimate to customers
• Hammer all the caveats and assumptions into customer's mind along with the estimates

Following are some of the main Estimating Mistakes to Avoid

• Bowing to pressure and changing the carefully computed estimates with numbers given
by someone senior or from upper management.

• Not having the estimates for all work packages worked out, and relying on the gut feel
for the missing estimates

• Taking the words of experts as final estimate. An expert will be able to do the work in
hours - which for a fresher will take days.

• Taking the estimates from team as final - without factoring in caution or optimism.
Depending on the overall experience of the team, the accuracy of the estimates changes.
The estimates given by the team is driven by several of their internal political factors -
and the estimates may not reflect reality. So as a good practice, all estimates must be
validated.

Resource Identification
Every single work package in the project should have resources identified with. In the initial
stage of the project, if resources for each work package is not identified and assigned for that,
then that's a major gap in project planning, and the project plan is not complete nor it should
be shared outside to customers.

It is the role of the project manager to work with the stake holders to get resources for each
work package. In most cases, not all the resources are identified and allocated at the start of
project, so from planning perspective this denotes a risk & hence a contingency resource
identification must also be done during the planning stage.

Lead Time for Resources

Resources are always scarce and must be carefully used. In most cases, resources will be
committed to the project at the beginning of the project, but it is the duty of the project manager
to know the lead time needed to get the required resources and plan things accordingly.

With agile projects, resources are not made available to the project till the time it is really
needed. In such cases, project managers will have to set timelines and do an early check if the
resources are indeed available for the forthcoming iterations, identify the timelines as to when
the resources will be made available, who is responsible for the resources, what is the escalation
path/plan needed to get the resources, and what is the contingency plan in case the needed
resources are not available.

A good project manger should have forward thinking to ensure resources are available when
needed. This involves making early bookings, and reconfirming the availability on periodic
basis, - particularly reconfirming the availability as the planned state date approaches.

Having a resource schedule as part of the project plan is a good practice. The resource schedule
should list the following:
• Resources needed
• Duration of the need
• Lead time for procuring/booking the resources
• Remainders/reconfirmations schedule for ensuring that resources to be made available.
• Cost of resources & cost variations of resources.
• Ramp-up time for the resources - i.e, time needed for the resource to be fully effective
Resource Utilization
Resource utilization refers to the plan on how the allocated/available resources are utilized in
the project. Often times people succumb to the pressure and get into over utilization of
resources: i.e, make people work overtime to complete the tasks, overload/overuse machinery
etc.
Over utilization of a given resource is not a standard plan. No project manger should plan for
overloading of resources in the initial project plan. The project plan must account for normal
usage of the resource.

A good project manager will not make a plan in with all resources are utilized at full capacity
- especially people. This is because resources cannot operate at their full capacity all the time.
With people resources, one also needs to account for other overheads such as meetings, training
and also plan for holidays, sickness, & vacations. This implies that a 32 man hour task should
be planned as a 1 man week task. Ideally 60% of person resource utilization must be factored
for project planning.

With equipment or machinery resources, overloading must never be considered in the project
plan & in practice it must be followed on ground. If overloading is permitted, then the inevitable
happens: the machine breaks down, causing your project schedule go haywire. To eliminate
the schedule variance due to breakdowns, resource utilization must be planned at 80% of the
machine capacity. This means that on the ground, if a machine breaks down, the other machines
can then be loaded at 100% and the project schedule is still unaffected.

Resource Tracking
Once the resource planning, resource schedule is done and the project is under way, the project
manager must track the actual usage/consumption of the resources and compare against the
plan. The actual usage must be captured into the system and this helps in refinement of future
project plans.

During the project estimation time, people have a tendency to tell things which their managers
like to hear - thus giving an overtly aggressive estimate or a conservative estimate. But when
the actual efforts are tracked against the initial estimate and the variances are discussed openly
in the project meetings, people tend to become more realistic in the future projects.
In my experience, I have used tools such as Rational or Remedy to track the actual utilization
and then build that into the knowledge base for future use. Also having a centralized tool to
track the actual resource utilization will help in project analysis & progress tracking. If the
actual resource utilization is much greater than the initial estimate/plan, then it is an indication
that the project is likely behind schedule and people are over working to cover up.

Also under utilization of resource is not a good thing. This implies that the initial estimates
were over blown or the project is falling behind schedule and things are not starting on time.
From my experience a 10% variation from the planned resource utilization is acceptable,
anything higher is a leading indicator that something is going wrong in the project.

Tracking Resource utilization is not everything for a project manager. One also needs to know
how much of work has been completed on the ground. Often times people report that their work
is 90% complete - and then it remains at 90% for a long time, with 10% pending and consuming
resources. The percentage (%) of resource utilization should be an indicator for the
completeness. Of 100% of the allocated resources are consumed then the work should be 100%
complete, else the project is said to be behind schedule/plan.

Contingency Planning
Resources are always scarce & hence there is always a possibility of required resources not
being available to the project. It is therefore a good practice to add resource contingency into
the resource estimates to guard against resource scarcity.

Resource contingency is something that's added to the initial estimates to guard against things
requiring more work than expected or simply to reflect the fact that the estimate is not reliable.
It is good practice to add contingency to individual work packages. In some cases, contingency
is added en bloc in form of additional work packages.

In large complex projects, it is common to incorporate contingency at both levels.

Understanding how much is already built into individual, detailed estimates is part of deciding
how much additional contingency you should allow for the project as a whole.
 3.5 SUMMARY

For a successful project management it is important to look at understanding the contents of

project management. The content of project management are focused around following
contents: Lead a project throughout its cycle; define a project’s goals and objectives, plan a
project, Organize a project, Control a project and Close a project.

The Project Management Life Cycle has four phases: Initiation, Planning, Execution and
Closure.

Project management in any business activity requires creating a business case. The purpose of
a business case is to persuade those with authority that they should endorse and fund a particular
project or initiative by making a “compelling case for investment”. The level of detail required
in the business case will depend on the complexity and cost of the project. In many
environments there will be a set format or template that agencies will need to use. It may be a
mandatory requirement when requesting funding over a certain level for the business case to
be written using a specific template.

A typical business case format has following contents: Executive Summary, Introduction,
Purpose, Problem / Opportunity, External Review, Goal and Objectives, Strategic Alignment,
Methods And Assumptions, Scope, Assumptions and Constraints, Data Sources and Methods,
Decision Criteria, Options Considered, Impact Analysis, Financial Impacts, Non-Financial
Impacts, Sensitivity and Risk, Summary, Evaluation of Options, Achievability, Capability,
Procurement, Project Governance and Management, Timeline, Risk Management,
Affordability, Conclusions And Recommendations.

In project management terminology, resources are required to carry out the project tasks. They
can be people, equipment, facilities, funding, or anything else capable of definition (usually
other than labour) required for the completion of a project activity. The lack of a resource will
therefore be a constraint on the completion of the project activity. Resources may be storable
or non storable. Resource management has several components: Effort Estimation, Resource
Identification, Lead time to get required resources, Resource Utilization, Resource Tracking.

3.6 KEYWORDS
• Business case - A business case is a document that forms the basis of advice for executive
decision-making for an asset investment. It is a documented proposal to meet a clearly
established service requirement. It considers alternative solutions and identifies
assumptions, benefits, costs and risks.
• Resource Utilization - Resource utilization refers to the plan on how the
allocated/available resources are utilized in the project. Often people succumb to the
pressure and get into over utilization of resources: i.e, make people work overtime to
complete the tasks, overload/overuse machinery etc.
• Resource Tracking – It is a process of comparing the actual usage / consumption of the
resources against the plan.
 UNIT 4 PROJECT FINANCE AND EVALUATION

Objective:

After reading this Unit you would be able to:

• To arrange for project finance;

• To evaluate the project feasibility;
• To do the cost and time estimation for the project;
• To conduct PESTEL analysis;
• To do the cost benefit analysis for the project.

Structure:

4.1 Introduction to Project finance and evaluation

4.2 Projects Finance
4.3 Estimation of time & costs in project
4.4 Project Evaluation using Cost benefit analysis
4.5 Feasibility Study
4.6 PESTEL analysis
4.7 Summary
4.8 Key Words

4.1 INTRODUCTION TO PROJECT FINANCE AND EVALUATION

In this chapter we will discuss the concept of project finance and evaluation. Finance is one of
the most important resources for any project. At every stage of project, we need money and
hence project finance becomes critical for the success of any project. Project Evaluation is a
process which supports a project, by measuring the extent to which the objectives are met,
identifies achievements & areas for improvement, and encourages decisions to be taken
including changes. Project evaluation involves several steps, related to the stages of the project.
It includes discussing and defining the aims, collection of data following the objectives of the
project and the subject of the evaluation, analysis and the interpretation of this data leading to
informed conclusions, Amendments of the project in the light of the evidence acquired.

4.2 PROJECT FINANCE

Project finance is the long term financing of infrastructure and industrial projects based upon
the projected cash flows of the project rather than the balance sheets of the project sponsors.
Usually, a project financing structure involves a number of equity investors, known as
sponsors, as well as a syndicate of banks that provide loans to the operation. The loans are most
commonly non-recourse loans, which are secured by the project assets and paid entirely from
project cash flow, rather than from the general assets or creditworthiness of the project
sponsors, a decision in part supported by financial modeling. The financing is typically secured
by all of the project assets, including the revenue-producing contracts. Project lenders are given
a lien on all of these assets, and are able to assume control of a project if the project company
has difficulties complying with the loan terms.

Generally, a special purpose entity is created for each project, thereby shielding other assets
owned by a project sponsor from the detrimental effects of a project failure. As a special
purpose entity, the project company has no assets other than the project. Capital contribution
commitments by the owners of the project company are sometimes necessary to ensure that the
project is financially sound. Project finance is often more complicated than alternative
financing methods. Traditionally, project financing has been most commonly used in the
mining, transportation, telecommunication and public utility industries. More recently,
particularly in Europe, project financing principles have been applied to public infrastructure
under public–private partnerships (PPP) or, in the UK, Private Finance Initiative (PFI)
transactions.

Parties to a Project Financing

There are several parties in a project financing depending on the type and the scale of a
project. The most usual parties to a project financing are;
• Project company
• Sponsor
• Borrower
• Financial Adviser
• Technical Adviser
• Lawyer
• Debt financiers
• Equity Investors
• Regulatory agencies
• Multilateral Agencies
• Host government / grantor

Contractual Framework
The typical project finance documentation can be reconducted to four main types:
• Shareholder/sponsor documents
• Project documents
• Finance documents
• Other project documents

4.3 ESTIMATION OF TIME & COSTS IN PROJECT

The most daunting & challenging task for success of project. The estimates are the absolutely
necessary inputs for successful implementation of the project within the stipulated resource
constraints.

It can be defined as the process of forecasting the requirement of time & financial resources
for the completion of project. This can be done by either following top down approach or the
bottom up approach.

Top down approach - Here the total time & costs mentioned for the whole project is taken as
reference & the same is not broken down to the individual task level. This is also called as
Macro estimation. Normally this approach is used during the project evaluation stage at the
time of selection & evaluation of the project by the top team. These estimates are normally
reasonably rough & are based on the experience of the team who do it as also the previous
experience of the connected people with similar activities. This process does not break down
the project into individual tasks or activities & therefore operates at gross top level. This is
normally substantiated by bottom up approach for the actual estimation.

Bottom up approach – Here the complete project is divided into individual tasks. The
estimates of these tasks for all variables are prepared. These estimated costs or consumption
parameters are added up (Rolled up) to arrive at the top level estimate. This is also called as
Micro estimation.
This process does give the estimate which is reasonably close to the reality. This process is
necessary for actual implementation of the project, In most cases, this approach cannot be
successfully deployed for estimation at the beginning due to absence of detailed break up of
project & deliverable designs. The individual estimates are prepared by the functions & the
individuals who would eventually execute the tasks & are specialists in the respective fields.

Methods of estimation - This is divided in 2 parts - Macro type B. Micro type

Macro type
Ratio method: Based on past experience – Does not break down the project into tasks – Uses
experience to create a ratio which represents average costs per unit variable of the project which
bundles all variables into one – For example the construction costs of residential buildings are
calculated using a ratio of Cost in Rs. For per square meter of construction - Or cost of transport
in terms of Rs. Per ton kilometer travel – Obviously the ratio figures are created based on many
such past experiences.

Apportion method: This is similar to the ratio method – It is used for executing projects which
are very similar to earlier executed projects - It uses the past experience of the similar projects
to break down the same into various deliverables or milestone activities – The costs are broken
down at the level of every deliverable – This helps generate estimates for each deliverable or
milestones – Addition gives total estimate.

Function point method: The project is identified by a typical activity which is part of the
project - Normally this activity is repeated often in the project & truly represents the project
profile. For the said activity, the historical data is also available in details which help
managers arrive at a fairly accurate estimates. The ratio estimates are made based on this
activity costs – These ratios are used to estimate the total cost of the project – For example
for the cost of setting up a Telephone exchange, the estimates are made based on cost ratio
of the number of lines that the new exchange will have. Cost of construction per unit area
of constructed building becomes the base for estimation of civil projects etc.

Learning curve method: Effective tool for estimation of projects which contain lot of
similar activities from the previous projects – It is a proven fact that when the activities are
carried out again, they consume less time every time it is repeated – This is used to make
estimates in the new projects – The logic is based on empirical formulae. For example,
Time taken to develop a chip of higher capacity is much less than the one that was taken
for the prevalent capacity – Scientists were able to develop a clear structure which
stipulated the memory capacity of the chip of the same size 10 years from now. Off course
this logic does reach a saturation level beyond which further improvements are much
slower.

Micro type
Template method: Used for projects which are similar in nature to the past projects – The
detailed estimates are transferred from the previous projects & adjustments are done for the
known deviations.

Parametric method: The total costs of the project in the historical data are directly related
to one of the typical variable parameter which is most representative – For example, the
estimate for painting one sq. meter is derived from the historical data & used as a basis for
all future calculations after adjusting for inflation & other such variable because of elapsed
time.

Detailed estimates method: Possibly the most elaborate & therefore accurate method of all
– Detailed WBS activity chart is prepared – For each activity the estimates are prepared
from the likely members who actually execute the said activity - Such data for all activities
are generated to arrive at a project estimate – This also helps in getting the support from
the same people when they actually execute the job because of the obviously associated
ownership

Hybrid phase estimation: This uses both the approaches – what is prepared first is a macro
estimate – As the project progresses thro’ the phases, detailed estimates are prepared for
the immediate phase & remaining staying at the macro estimate level – As the project
moves forward, this is repeated for successive phases. This process is more suitable when
the prevalence of uncertainty is of the much higher magnitude & the refinement happens
as we proceed with the work. Development of new software or building of large airplanes
are the classic examples.
Level of detailing will defer in the organizational hierarchy – The senior management would
be more interested in general plan & would not be interested in the nuts & bolts of the project.

However as we go to lower levels in the hierarchy, the detailing required goes up reasonably
high. This is because the actual execution of the project is done at this level & will obviously
need all the minute details.

Time Phasing Of the Project

No project would be executable if the estimates are made only at macro level. There is no point
in telling finance people that the project would require X amount of Rs. What is needed is the
overall progress report card which indicates the various time points at which resource needs
will have be established.

4.4 PROJECT EVALUATION USING COST BENEFIT ANALYSIS

The Cost/ Benefit Analysis (CBA) is an economic assessment tool/ technique for comparing
the anticipated benefits of proposed investments/ projects with the corresponding costs to help
users identify the alternative with the maximum net benefit (benefits minus costs). The more
the benefits exceed the costs, the more the end users (society) will benefit from the project
activity or policy decision.

In this context, the CBA can be used not only during the development of Business Case for the
identification of the most preferable solution option, but also during the Inception &
Prioritising Stage in order to give a higher priority to the investments/ projects which prove to
be more profitable efficient not only in monetary but also in socioeconomic terms.

It should be noted, that wherever possible the CBA should be undertaken from a national
perspective rather than government or departmental perspective. This is often termed
“economic CBA” and is preferred because the actions of one agency or department can impose
costs or benefits on individuals or the nation as a whole (e.g. increasing the size of a programme
operated by a particular department may assist the operation of the department but may
nonetheless require a large increase in income tax on individuals). In other words, economic
CBA seeks to capture all benefits and costs regardless of to whom they accrue. Of course, in
case of investments or projects where costs and benefits are limited to impacts on an individual
agency or department (e.g. purchase of new notebooks for a department, lease or buy decision
for an agency building), a “finacial CBA” should be used. That is to consider only the benefits
and costs to an individual agency or department.

The elaboration of a CBA is usually a complicated and sophisticated task that should be carried
out by specialised professionals or assigned to external advisors, since it involves advanced
calculations and financial analysis, which require a relevant background knowledge and
familiarisation with investment appraisal techniques. Especially in cases of large investments/
projects, where the CBA may be a prerequisite in order to apply for EU funding (e.g.
investments for waste treatment, water supply and depuration, transport, etc.), the CBA should
be conducted very carefully and by specialized experts in order to justify the request for co-
financing and receive the relative approval.

The most important parts of a CBA are the following:

• Determining the lifetime of the investment/ project (period of analysis)

• Identifying all relevant costs and benefits of a given investment/ proposal/ option
• Valuing all relevant costs and benefits of a given investment/ proposal/ option (assigning
monetary values)

• Preparing the cash flows for the analysis period

• Discounting of cash flows to present values
• Calculating the Net Present Value (NPV)
• Evaluation of alternative options and selection of the preferred option

4.5 FEASIBILITY STUDY

A Feasibility Study is the analysis of a business problem to determine if it can be solved
effectively. The operational (will it work?), economical (costs and benefits) and technical (can
it be built?) aspects are part of the study. Results of the study determine whether the solution
is feasible in all the above aspects and thus should be implemented.

It should be noted that the economic feasibility of an option or a project is typically assessed
through a Cost/ Benefit Analysis, which can be performed either in the framework of a
Feasibility Study or as a separate study and then incorporate its results in the overall Feasibility
Study.

Conducting a feasibility study is usually a complicated task that should be undertaken by

specialized professionals or assigned to external consultants with relevant experience in
conducting such studies, as well as with relevant background to the scopes under consideration.
Feasibility studies for large scale projects are usually conducted by a team of experts in order
to cover all aspects of solution’s feasibility. For example, in case of a bridge construction
project, it is necessary to appoint an architect or civil engineer in the feasibility study team in
order to examine the technical feasibility of the proposed solution, an economist or financial
analyst to examine the economical feasibility, an environmental expert to assess the
environmental impacts of each solution and a transport specialist to examine the operational
efficiency (e.g. forecasted vehicle load, impact on traffic) of the constructed bridge.

Especially in cases of large investments/ projects, which are proposed for receiving EU funding
(e.g. investments co-financed by the Cohesion Fund or ISPA) the Feasibility Study is a
prerequisite of the application folder and should be conducted very carefully and by specialised
experts in order to justify the request for co-financing and receive the relative approval.

Feasibility Study is usually undertaken as part of the overall Business Case process to add more
rigour to the solution options presented in the Business Case. For this reason, the topics defined
in both the Business Case and Feasibility Study documents are quite similar. However, the
feasibility study may be conducted prior to the Business Case in order to minimise the
alternative solutions by excluding those which are either infeasible or they proved to be the
least feasible. In this case the results of the Feasibility Study should be included in the Business
Case document either under the relevant heading or as an annex (if they are too analytical and
extended).

Even though the Feasibility Study is usually outsourced to specialised consultants, the project
designers should be accustomed with the basic topics included in a Feasibility Study in order
to be in a position to provide the appropriate input to the external consultants, as well as to
interpret the results in order to use them in the presentation of the Business Case.

The topics that are usually included in a Feasibility Study and some basic guidance on how to
deal with each topic are presented below.
Executive Summary: Outline the problem or opportunity, the project requirements, the
feasibility assessment results and the overall outcome.

Problem Statement: Firstly, describe the business environment which contains the
business problem (or opportunity) by taking into account the external environment (e.g.
products and services available, technology and commercial or operational trends, statutory
or legislative changes), the business vision, strategy or objectives, the business organisation
(e.g. units relevant to this project, internal communication lines), and the Business
processes (e.g. procurement, supply chain management, IT systems, HR management,
strategic planning, finance/accounting, manufacturing/logistics, engineering). Then
provide a full description of the core problem (or opportunity), refer to the reasons why the
problem exists (or provide support evidence that the opportunity exists), describe the
impact it is having on the business (or the positive impact that the realisation of the
opportunity will have), and state the timeframes within which it must be resolved (or for
which the opportunity will likely exists).

Requirements Statement: List the key business drivers for this project (e.g. changes to
legislative framework, a particular citizens’ need that must be covered within a certain
period, limited timeframe for the absorption of EU funds). For each business problem (or
opportunity) describe the detailed business requirements (e.g. training of employees in the
new procedures, establishment of a new business unit, 20% increase in the existing
connections to the water supply network, upgrade of existing IT networks).
Feasibility Assessment: Provide a detailed description of each solution option. Assess the
feasibility (or likelihood) of each solution option to meet the requirements defined above.
To assess the overall feasibility of each option, break the solution down into components
and rate the feasibility of each component. To ensure that the feasibility ratings are
accurate, use all appropriate methods possible to identify the likely feasibility of the
solution. For example, if adopting new technology, develop a small prototype and test it to
see if the resultant benefits match those expected from the exercise, or if considering
changes in business processes perform staff surveys and interviews, or if considering to
purchase, rent or lease a new product/ service undertake market surveys. Then describe the
actual result of the assessment in comparison with the expected result. Finally, describe
also the risks and assumptions associated with the feasibility of each option.

Feasibility Ranking: List the criteria used to rank the alternative options (e.g. technical
feasibility/ implement ability, environmental impacts/ sustainability, economic viability,
social acceptance) and describe the scoring/ weighting mechanism used to produce the
overall result.

Feasibility Result: Based on the feasibility ranking, identify which option has achieved
the highest total score and thus is the most feasible for implementation. Summarise the key
reasons why this option is most likely to meet the business requirements.

4.6 PESTEL analysis

There are many factors in the macro-environment that will effect the decisions of the managers
of any organisation. Tax changes, new laws, trade barriers, demographic change and
government policy changes are all examples of macro change. To help analyse these factors
managers can categorise them using the PESTEL model. This classification distinguishes
between:

Political factors: These refer to government policy such as the degree of intervention in the
economy. What goods and services does a government want to provide? To what extent does
it believe in subsidising firms? What are its priorities in terms of business support? Political
decisions can impact on many vital areas for business such as the education of the workforce,
the health of the nation and the quality of the infrastructure of the economy such as the road
and rail system.

Economic factors: These include interest rates, taxation changes, economic growth, inflation
and exchange rates. As you will see throughout the "Foundations of Economics" book
economic change can have a major impact on a firm's behaviour. For example:

• higher interest rates may deter investment because it costs more to borrow
• a strong currency may make exporting more difficult because it may raise the price in terms
of foreign currency
• inflation may provoke higher wage demands from employees and raise costs
• higher national income growth may boost demand for a firm's products
• Economic feasibility of an option or a project is typically assessed through a Cost/ Benefit
Analysis, which can be performed either in the framework of a Feasibility Study or as a
separate study and then incorporate its results in the overall Feasibility Study. There are
various tools that can be used to measure the economical feasibility of a project. Some of
the tools used for economic analysis are as follows:

Adjusted present value (APV): adjusted present value, is the net present value of a project if
financed solely by ownership equity plus the present value of all the benefits of financing.

Payback period: which measures the time required for the cash inflows to equal the original
outlay. It measures risk, not return.

Cost-benefit analysis: which includes issues other than cash, such as time savings.

Real option method: which attempts to value managerial flexibility that is assumed away in
NPV.

Internal rate of return: which calculates the rate of return of a project while disregarding the
absolute amount of money to be gained.

Modified internal rate of return (MIRR): similar to IRR, but it makes explicit assumptions
about the reinvestment of the cash flows. Sometimes it is called Growth Rate of Return.

Accounting rate of return (ARR): a ratio similar to IRR and MIRR

Rate of return (ROR): also known as return on investment (ROI), rate of profit or
sometimes just return, is the ratio of money gained or lost (whether realized or unrealized) on
an investment relative to the amount of money invested.

Economic Value Added or EVA: is an estimate of economic profit, which can be determined,
among other ways, by making corrective adjustments to GAAP accounting, including
deducting the opportunity cost of equity capital. The concept of EVA is in a sense nothing more
than the traditional, commonsense idea of "profit," however, the utility of having a separate
and more precisely defined term such as EVA or Residual Cash Flow is that it makes a clear
separation from dubious accounting adjustments that have enabled businesses such as Enron
to report profits while in fact being in the final approach to becoming insolvent.

In corporate finance, Economic Value Added or EVA is an estimate of economic profit, which
can be determined, among other ways, by making corrective adjustments to GAAP accounting,
including deducting the opportunity cost of equity capital. The concept of EVA is in a sense
nothing more than the traditional, commonsense idea of "profit," however, the utility of having
a separate and more precisely defined term such as EVA or Residual Cash Flow is that it makes
a clear separation from dubious accounting adjustments that have enabled businesses such as
Enron to report profits while in fact being in the final approach to becoming insolvent. EVA
can be measured as Net Operating Profit After Taxes (or NOPAT) less the money cost of
capital. EVA is similar to Residual Income (RI), although under some definitions there may be
minor technical differences between EVA and RI (for example, adjustments that might be made
to NOPAT before it is suitable for the formula below). Another, much older term for economic
value added is Residual Cash Flow. In all three cases, money cost of capital refers to the amount
of money rather than the proportional cost (% cost of capital). The amortization of goodwill or
capitalization of brand advertising and other similar adjustments are the translations that can
be made to Economic Profit to make it EVA. The EVA is a registered trademark by its
developer, Stern Stewart & Co.

Calculating EVA

In the field of corporate finance, Economic Value Added is a way to determine the value
created, above the required return, for the shareholders of a company. The basic formula is:

where

called the Return on Invested Capital (ROIC).r is the firm's return on capital, NOPAT is the
Net Operating Profit After Tax, c is the Weighted Average Cost of Capital (WACC) and K is
capital employed. To put it simply, EVA is the profit earned by the firm less the cost of
financing the firm's capital.
Shareholders of the company will receive a positive value added when the return from the
capital employed in the business operations is greater than the cost of that capital; see Working
capital management. Any value obtained by employees of the company or by product users is
not included in the calculations.

Relationship to Market Value Added

The firm's market value added, or MVA, is the discounted sum of all future expected economic
value added:

Note that MVA = NPV of company.

Social factors: Changes in social trends can impact on the demand for a firm's products and
the availability and willingness of individuals to work. In the UK, for example, the population
has been ageing. This has increased the costs for firms who are committed to pension payments
for their employees because their staff are living longer. It also means some firms such as Asda
have started to recruit older employees to tap into this growing labour pool. The ageing
population also has impact on demand: for example, demand for sheltered accommodation and
medicines has increased whereas demand for toys is falling.

Technological factors: new technologies create new products and new processes. MP3
players, computer games, online gambling and high definition TVs are all new markets created
by technological advances. Online shopping, bar coding and computer aided design are all
improvements to the way we do business as a result of better technology. Technology can
reduce costs, improve quality and lead to innovation. These developments can benefit
consumers as well as the organisations providing the products.

Environmental factors: environmental factors include the weather and climate change.
Changes in temperature can impact on many industries including farming, tourism and
insurance. With major climate changes occurring due to global warming and with greater
environmental awareness this external factor is becoming a significant issue for firms to
consider. The growing desire to protect the environment is having an impact on many industries
such as the travel and transportation industries (for example, more taxes being placed on air
travel and the success of hybrid cars) and the general move towards more environmentally
friendly products and processes is affecting demand patterns and creating business
opportunities.

Legal factors: these are related to the legal environment in which firms operate. In recent years
in the UK there have been many significant legal changes that have affected firms' behaviour.
The introduction of age discrimination and disability discrimination legislation, an increase in
the minimum wage and greater requirements for firms to recycle are examples of relatively
recent laws that affect an organisation's actions. Legal changes can affect a firm's costs (e.g. if
new systems and procedures have to be developed) and demand (e.g. if the law affects the
likelihood of customers buying the good or using the service).

Different categories of law include:

• consumer laws; these are designed to protect customers against unfair practices such as
misleading descriptions of the product
• competition laws; these are aimed at protecting small firms against bullying by larger
firms and ensuring customers are not exploited by firms with monopoly power
• employment laws; these cover areas such as redundancy, dismissal, working hours and
minimum wages. They aim to protect employees against the abuse of power by
managers
• health and safety legislation; these laws are aimed at ensuring the workplace is as safe
as is reasonably practical. They cover issues such as training, reporting accidents and
the appropriate provision of safety equipment

Typical PESTEL factors to consider include:

Factor Could include:

Political e.g. EU enlargement, the euro, international trade, taxation policy

Economic e.g. interest rates, exchange rates, national income, inflation, unemployment, Stock
Market

Social e.g. ageing population, attitudes to work, income distribution

Technological e.g. innovation, new product development, rate of technological obsolescence

Environmental e.g. global warming, environmental issues

Legal e.g. competition law, health and safety, employment law

By using the PESTEL framework we can analyse the many different factors in a firm's macro
environment. In some cases particular issues may fit in several categories. For example, the
creation of the Monetary Policy Committee by the Labour government in 1997 as a body that
was independent of government but had the ability to set interest rates was a political decision
but has economic consequences; meanwhile government economic policy can influence
investment in technology via taxes and tax credits. If a factor can appear in several categories
managers simply make a decision of where they think it best belongs.

However, it is important not to just list PESTEL factors because this does not in itself tell
managers very much. What managers need to do is to think about which factors are most likely
to change and which ones will have the greatest impact on them i.e. each firm must identify
the key factors in their own environment. For some such as pharmaceutical companies
government regulation may be critical; for others, perhaps firms that have borrowed heavily,
interest rate changes may be a huge issue. Managers must decide on the relative importance of
various factors and one way of doing this is to rank or score the likelihood of a change occurring
and also rate the impact if it did. The higher the likelihood of a change occurring and the greater
the impact of any change the more significant this factor will be to the firm's planning.

It is also important when using PESTEL analysis to consider the level at which it is applied.
When analysing companies such as Sony, Chrysler, Coca Cola, BP and Disney it is important
to remember that they have many different parts to their overall business - they include many
different divisions and, in some cases, many different brands. Whilst it may be useful to
consider the whole business when using PESTEL in that it may highlight some important
factors, managers may want to narrow it down to a particular part of the business (e.g. a specific
division of Sony); this may be more useful because it will focus on the factors relevant to that
part of the business. They may also want to differentiate between factors which are very local,
other which are national and those which are global.

4.7 SUMMARY
Project finance is the long-term financing of infrastructure and industrial projects based upon
the projected cash flows of the project rather than the balance sheets of the project sponsors.
Usually, a project financing structure involves a number of equity investors, known as
sponsors, as well as a syndicate of banks that provide loans to the operation.
The time and cost estimation is the most daunting & challenging task for success of project.
The estimates are the absolutely necessary inputs for successful implementation of the project
within the stipulated resource constraints.

It can be defined as the process of forecasting the requirement of time & financial resources
for the completion of project. This can be done by either following top down approach or the
bottom up approach.

Top down approach - Here the total time & costs mentioned for the whole project is taken as
reference & the same is not broken down to the individual task level. This is also called as
Macro estimation.

Bottom up approach – Here the complete project is divided into individual tasks. The estimates
of these tasks for all variables are prepared. These estimated costs or consumption parameters
are added up (Rolled up) to arrive at the top-level estimate. This is also called as Micro
estimation.
The Cost/ Benefit Analysis (CBA) is an economic assessment tool/ technique for comparing
the anticipated benefits of proposed investments/ projects with the corresponding costs to help
users identify the alternative with the maximum net benefit (benefits minus costs). The more
the benefits exceed the costs, the more the end users (society) will benefit from the project
activity or policy decision.

The way of financing investments of the public infrastructure is a very important issue. In the
past, many project ideas ended up in a drawer or in the bin for the simple reason of lack of
public funds. For carrying out infrastructure investments to meet public needs, there are
basically following options: The traditional public-financed approach & The alternative
private-financed approach.
Feasibility Study is the analysis of a business problem to determine if it can be solved
effectively. The operational (will it work?), economical (costs and benefits) and technical (can
it be built?) aspects are part of the study. Results of the study determine whether the solution
is feasible in all the above aspects and thus should be implemented.

There are many factors in the macro-environment that will affect the decisions of the managers
of any organization. Tax changes, new laws, trade barriers, demographic change and
government policy changes are all examples of macro change. To help analyze these factors
managers can categorize them using the PESTEL model. This classification distinguishes
between: Political factors, Economic factors, Social factors, Technological factors,
Environmental factors, Legal factors.
4.8 KEY WORDS

Project finance - Project finance is the long-term financing of infrastructure and industrial
projects based upon the projected cash flows of the project rather than the balance sheets of the
project sponsors.

Cost / Benefit Analysis - Cost / Benefit Analysis (CBA) is an economic assessment tool/
technique for comparing the anticipated benefits of proposed investments/ projects with the
corresponding costs to help users identify the alternative with the maximum net benefit
(benefits minus costs).

Feasibility Study - A Feasibility Study is the analysis of a business problem to determine if it

can be solved effectively. The operational, economical and technical aspects are part of the
study.

PESTEL Model - PESTEL model is the classification that distinguishes between: Political
factors, Economic factors, Social factors, Technological factors, Environmental factors, Legal
factors for project feasibility study.
 UNIT 5 PROJECT PLANNING

Objective

After reading this Unit you would be able to:

• To plan the projects;

• To do the scheduling of project activities;
• To Create WBS;
• To find critical path;
• To estimate project duration using PERT.
Structure

5.1 Introduction to Project Planning

5.2 Projects Planning Cycle
5.3 Project Planning Tools
5.4 Summary
5.5 Key Words

5.1 INTRODUCTION TO PROJECT PLANNING

The key to a successful project is in the planning. Creating a project plan is the first thing you
should do when undertaking any kind of project. Often project planning is ignored in favour of
getting on with the work. However, many people fail to realise the value of a project plan in
saving time, money and many problems. This unit looks at a simple, practical approach to
project planning. On completion of this guide, you should have a sound project planning
approach that you can use for future projects.

5.2 PROJECT PLANNING CYCLE

In organizations and businesses, project management can be concerned with anything,

particularly introducing or changing things, in any area or function,

Successful project management, for projects large or small, tends to follow the process outlined
below. The same principles, used selectively and appropriately, also apply to smaller tasks. The
Planning Cycle brings together all aspects of planning into a coherent, unified process. By planning
within this structure, you will help to ensure that your plans are fully considered, well focused, resilient,
practical and cost-effective. You will also ensure that you learn from any mistakes you make, and feed
this back into future planning and Decision Making. Planning using this cycle will help you to plan and
manage ongoing projects up to a certain level of complexity – this will depend on the circumstance. For
projects involving many people over a long period of time, more formal methodologies and approaches
are necessary.

How to Use the Tool

It is best to think of planning as a cycle, not a straight-through process. Once you have devised
a plan you should evaluate whether it is likely to succeed. This evaluation may be cost or
number based, or may use other analytical tools. This analysis may show that your plan may
cause unwanted consequences, may cost too much, or may simply not work.

In this case you should cycle back to an earlier stage. Alternatively you may have to abandon
the plan altogether – the outcome of the planning process may be that it is best to do nothing!
Finally, you should feed back what you have learned with one plan into the next.

The Planning Cycle is shown below.

The stages in this planning process are explained below:

Stage 1: Analysis of Opportunities

The first thing to do is to do is to spot what needs to be done. You will crystallize this into a
formal aim at the next stage in the process.

One approach to this is to examine your current position, and decide how you can improve it.
There are a number of techniques that will help you to do this:

• SWOT Analysis: This is a formal analysis of your strengths and weaknesses, and of the
opportunities and threats that you face.
•
• Risk Analysis: This helps you to spot project risks, weaknesses in your organization or
operation, and identify the risks to which you are exposed. From this you can plan to
neutralize some risks.
 •
• Understanding pressures for change: Alternatively, other people (e.g. clients) may be
pressing you to change the way you do things. Alternatively your environment may be
changing, and you may need to anticipate or respond to this. Pressures may arise from
changes in the economy, new legislation, competition, changes in people's attitudes,
new technologies, or changes in government.

Stage 2: Identifying the Aim of Your Plan

Once you have completed a realistic analysis of the opportunities for change, the next step is
to decide precisely what the aim of your plan is. Deciding and defining an aim sharpens the
focus of your plan, and helps you to avoid wasting effort on irrelevant side issues.

The aim is best expressed in a simple single sentence. This ensures that it is clear and sharp in
your mind.

If you are having difficulty in formulating the aim of your plan, ask yourself:

• What do I want the future to be?

• What benefit do I want to give to my customers?
• What returns do I seek?
• What standards am I aiming at?
• What values do I and my organization believe in?

The aim can be presented as a 'Vision Statement' or 'Mission Statement'. Vision Statements
express the benefit that an organization will provide to its customers. For example, the vision
statement for Mind Tools is: 'To enrich the quality of our customers lives by providing the tools
to help them to think in the most productive and effective way possible'. While this is wordy,
it explains what this site aims to do.

Mission statements give concrete expression to the Vision statement, explaining how it is to be
achieved. The mission statement for this site is: 'To provide a well structured, accessible,
concise survey of the best and most appropriate mind tools available'.

Stage 3: Exploring Options

By this stage you should know where you are and what you want to do. The next thing to do is
to work out how to do it. The Creativity Tools section of this site explains a wide range of
powerful creativity tools that will help you to generate options.

At this stage it is best to spend a little time generating as many options as possible, even though
it is tempting just to grasp the first idea that comes to mind. By taking a little time to generate
as many ideas as possible you may come up with less obvious but better solutions. Just as
likely, you may improve your best ideas with parts of other ideas.

Stage 4: Selecting the Best Option

Once you have explored the options available to you, it is time to decide which one to use. If
you have the time and resources available, then you might decide to evaluate all options,
carrying out detailed planning, costing, risk assessment, etc. for each. Normally you will not
have this luxury.

Two useful tools for selecting the best option are Grid Analysis and Decision Trees. Grid
Analysis helps you to decide between different options where you need to consider a number
of different factors. Decision Trees help you to think through the likely outcomes of following
different courses of action.

Stage 5: Detailed Planning

By the time you start detailed planning, you should have a good picture of where you are, what
you want to achieve and the range of options available to you. You may well have selected one
of the options as the most likely to yield the best results.

Detailed planning is the process of working out the most efficient and effective way of
achieving the aim that you have defined. It is the process of determining who will do what,
when, where, how and why, and at what cost.

When drawing up the plan, techniques such as use of Gantt Charts and Critical Path Analysis
can be immensely helpful in working out priorities, deadlines and the allocation of resources.

While you are concentrating on the actions that need to be performed, ensure that you also
think about the control mechanisms that you will need to monitor performance. These will
include the activities such as reporting, quality assurance, cost control, etc. that are needed to
spot and correct any deviations from the plan.

A good plan will:

• State the current situation

• Have a clear aim
• Use the resources available
• Detail the tasks to be carried out, whose responsibility they are, and their priorities and
deadlines
• Detail control mechanisms that will alert you to difficulties in achieving the plan
• Identify risks, and plan for contingencies. This allows you to make a rapid and effective
response to crises, perhaps at a time when you are at low ebb or are confused following
a setback
• Consider transitional arrangements – how will you keep things going while you
implement the plan?

Stage 6: Evaluation of the Plan and its Impact

Once you have worked out the details of your plan, the next stage is to review it to decide
whether it is worth implementing. Here you must be objective – however much work you have
carried out to reach this stage, the plan may still not be worth implementing.

This is frustrating after the hard work of detailed planning. It is, however, much better to find
this out now than when you have invested time, resources and personal standing in the success
of the plan. Evaluating the plan now gives you the opportunity to either investigate other
options that might be more successful, or to accept that no plan is needed or should be carried
out.

Depending on the circumstances, the following techniques can be helpful in evaluating a plan:

• PMI (Plus/Minus/Interesting): This is a good, simple technique for 'weighing the pros
and cons' of a decision. It involves listing the plus points in the plan in one column, the
minus points in a second column, and the implications and points of uncertainty of the
plan in a third column. Each point can be allocated a positive or negative score.
• Cost/Benefit Analysis: This is useful for confirming that the plan makes financial sense.
This involves adding up all the costs involved with the plan, and comparing them with
the expected benefits.
• Force Field Analysis: Similar to PMI, Force Field Analysis helps you to get a good
overall view of all the forces for and against your plan. This allows you to see where
you can make adjustments that will make the plan more likely to succeed.
• Cash Flow Forecasts: Where a decision is has mainly financial implications, such as in
business and marketing planning, preparation of a Cash Flow Forecast can be extremely
useful. It allows you to assess the effect of time on costs and revenue. It also helps in
assessing the size of the greatest negative and positive cash flows associated with a
plan. When it is set up on a spreadsheet package, a good Cash Flow Forecast also
functions as an extremely effective model of the plan. It gives you an easy basis for
investigating the effect of varying your assumptions.
• "6 Thinking Hats": 6 Thinking Hats is a very good technique to use to get a rounded
view of your plan and its implications. It provides a context within which you can
examine a plan rationally, emotionally, optimistically, pessimistically and creatively.

Any analysis of the plan must be tempered by common sense.

If your analysis shows that the plan either will not give sufficient benefit, then either return to
an earlier stage in the planning cycle or abandon the process altogether.

Stage 7: Implementing Change

Once you have completed your plan and decided that it will work satisfactorily, it is time to
implement it. Your plan will explain how! It should also detail the controls that you will use to
monitor the execution of the plan.

Stage 8: Closing the Plan

Once you have achieved a plan, you can close the project. At this point is often worth carrying
out an evaluation of the project to see whether there are any lessons that you can learn. This
should include an evaluation of your project planning to see if this could be improved.

If you are going to be carrying out many similar projects, it may be worth developing and
improving an Aide Memoire. This is a list of headings and points to consider during planning.
Using it helps you to ensure that you do not forget lessons learned in the past.

5.3 PROJECT PLANNING TOOLS

Here are examples and explanations of five commonly used tools in project planning and
project management, namely: Brainstorming, Fishbone Diagrams, Work breakdown structure,
Critical Path Analysis, and Gantt Charts.

Brainstorming

Brainstorming is usually the first crucial creative stage of the project management and project
planning process. See the brainstorming method in detail and explained separately, because it
many other useful applications outside of project management.

Unlike most project management skills and methods, the first stages of the brainstorming
process is ideally a free-thinking and random technique. Consequently it can be overlooked or
under-utilized because it not a natural approach for many people whose mains strengths are in
systems and processes. Consequently this stage of the project planning process can benefit from
being facilitated by a team member able to manage such a session, specifically to help very
organised people to think randomly and creatively.

Fishbone diagrams

Fishbone diagrams are chiefly used in quality management fault-detection, and in business
process improvement, especially in manufacturing and production, but the model is also very
useful in project management planning and task management generally.

Within project management fishbone diagrams are useful for early planning, notably when
gathering and organising factors, for example during brainstorming.

Fishbone diagrams are very good for identifying hidden factors which can be significant in
enabling larger activities, resources areas, or parts of a process.

Fishbone diagrams are not good for scheduling or showing interdependent time-critical factors.

Fishbone diagrams are also called 'cause and effect diagrams' and Ishikawa diagrams, after
Kaoru Ishikawa (1915-89), a Japanese professor specialising in industrial quality management
and engineering who devised the technique in the 1960s.

Ishikawa's diagram became known as a fishbone diagram, obviously, because it looks like a
fishbone:

A fishbone diagram has a central spine running left to right, around which is built a map of
factors which contribute to the final result (or problem).

For each project the main categories of factors are identified and shown as the main 'bones'
leading to the spine.

Into each category can be drawn 'primary' elements or factors (shown as P in the diagram), and
into these can be drawn secondary elements or factors (shown as S). This is done for every
category, and can be extended to third or fourth level factors if necessary.
The diagram above is a very simple one. Typically fishbone diagrams have six or more main
bones feeding into the spine. Other main category factors can include Environment,
Management, Systems, Training, Legal, etc.

The categories used in a fishbone diagram should be whatever makes sense for the project.
Various standard category sets exist for different industrial applications, however it is
important that your chosen structure is right for your own situation, rather than taking a
standard set of category headings and hoping that it fits.

At a simple level the fishbone diagram is a very effective planning model and tool - especially
for 'mapping' an entire operation.

The 'Problem' term is used in fault diagnosis and in quality management problem-solving.
Some fishbone diagrams can become very complex indeed, which is common in specialised
quality management areas, especially where systems are computerised.
Where a fishbone diagram is used for project planning of course the 'Effect' is shown as an aim
or outcome or result, not a problem.

Work breakdown structure

Example of a product oriented work breakdown structure of an aircraft system.

A work breakdown structure (WBS), in project management and systems engineering, is a

deliverable oriented decomposition of a project into smaller components. It defines and groups
a project's discrete work elements in a way that helps organize and define the total work scope
of the project.

A work breakdown structure element may be a product, data, a service, or any combination. A
WBS also provides the necessary framework for detailed cost estimating and control along
with providing guidance for schedule development and control.

One of the most important work breakdown structure design principles is called the 100% rule.
It has been defined as follows:

The 100% rule states that the WBS includes 100% of the work defined by the project scope
and captures all deliverables – internal, external, interim – in terms of the work to be completed,
including project management. The 100% rule is one of the most important principles guiding
the development, decomposition and evaluation of the WBS. The rule applies at all levels
within the hierarchy: the sum of the work at the “child” level must equal 100% of the work
represented by the “parent” and the WBS should not include any work that falls outside the
actual scope of the project, that is, it cannot include more than 100% of the work… It is
important to remember that the 100% rule also applies to the activity level. The work
represented by the activities in each work package must add up to 100% of the work necessary
to complete the work package.

Mutually exclusive elements

Mutually exclusive: In addition to the 100% rule, it is important that there is no overlap in
scope definition between two elements of a work breakdown structure. This ambiguity could
result in duplicated work or mis-communications about responsibility and authority. Such
overlap could also cause confusion regarding project cost accounting. If the WBS element
names are ambiguous, a WBS dictionary can help clarify the distinctions between WBS
elements. The WBS Dictionary describes each component of the WBS with milestones,
deliverables, activities, scope, and sometimes dates, resources, costs, quality.

Plan outcomes, not actions

If the work breakdown structure designer attempts to capture any action-oriented details in the
WBS, he will likely include either too many actions or too few actions. Too many actions will
exceed 100% of the parent's scope and too few will fall short of 100% of the parent's scope. It
is considered that the best way to adhere to the 100% rule is to define WBS elements in terms
of outcomes or results. This also ensures that the WBS is not overly prescriptive of methods,
allowing for greater ingenuity and creative thinking on the part of the project participants. For
new product development projects, the most common technique to ensure an outcome-oriented
WBS is to use a product breakdown structure. Feature-driven software projects may use a
similar technique which is to employ a feature breakdown structure. When a project provides
professional services, a common technique is to capture all planned deliverables to create a
deliverable-oriented WBS. Work breakdown structures that subdivide work by project phases
(e.g. preliminary design phase, critical design phase) must ensure that phases are clearly
separated by a deliverable also used in defining entry and exit criteria (e.g. an approved
preliminary or critical design review).

Level of detail

A question to be answered in determining the duration of activities necessary to produce a

deliverable defined by the WBS is when to stop dividing work into smaller elements. There are
several heuristics or "rules of thumb" used when determining the appropriate duration of an
activity or group of activities necessary to produce a specific deliverable defined by the WBS.

• The first is the "80 hour rule" which means that no single activity or group of activities
to produce a single deliverable should be more than 80 hours of effort.
• The second rule of thumb is that no activity or series of activities should be longer than
a single reporting period. Thus if the project team is reporting progress monthly, then
no single activity or series of activities should be longer than one month long.
• The last heuristic is the "if it makes sense" rule. Applying this rule of thumb, one can
apply "common sense" when creating the duration of a single activity or group of
activities necessary to produce a deliverable defined by the WBS.

A work package at the activity level is a task that:

• can be realistically and confidently estimated;

• makes no sense practically to break down any further;
• can be completed in accordance with one of the heuristics defined above;
• produces a deliverable which is measurable; and
• forms a unique package of work which can be outsourced or contracted out.

Coding scheme

It is common for work breakdown structure elements to be numbered sequentially to reveal the
hierarchical structure. The purpose for the numbering is to provide a consistent approach to
identifying and managing the WBS across like systems regardless of vendor or service. For
example 1.1.2 Propulsion (in the example below) identifies this item as a Level 3 WBS
element, since there are three numbers separated by a decimal point. A coding scheme also
helps WBS elements to be recognized in any written context.

A practical example of the WBS coding scheme is

1.0 Aircraft System

1.1 Air Vehicle

1.1.1 Airframe

1.1.1.1 Airframe Integration, Assembly, Test and Checkout

1.1.1.2 Fuselage

1.1.1.3 Wing

1.1.1.4 Empennage

1.1.1.5 Nacelle

1.1.1.6 Other Airframe Components 1..n (Specify)

1.1.2 Propulsion

1.1.3 Vehicle Subsystems

1.1.4 Avionics

1.2 System Engineering

1.3 Program Management

1.4 System Test and Evaluation

1.5 Training

1.6 Data

1.7 Peculiar Support Equipment

1.8 Common Support Equipment

1.9 Operational/Site Activation

1.10 Industrial Facilities

1.11 Initial Spares and Repair Parts

Critical path analysis

'Critical Path Analysis' sounds very complicated, but it's a very logical and effective method
for planning and managing complex projects. A critical path analysis is normally shown as a
flow diagram, whose format is linear (organised in a line), and specifically a time-line.

Critical Path Analysis is also called Critical Path Method - it's the same thing - and the terms
are commonly abbreviated, to CPA and CPM.

A commonly used tool within Critical Path Analysis is PERT (Program / Programme / Project
Evaluation and Review Technique) which is a specialized method for identifying related and
interdependent activities and events, especially where a big project may contain hundreds or
thousands of connected elements. PERT is not normally relevant in simple projects, but any
project of considerable size and complexity, particularly when timings and interdependency
issues are crucial, can benefit from the detailed analysis enabled by PERT methods. PERT
analysis commonly feeds into Critical Path Analysis and to other broader project management
systems, such as those mentioned here.

Critical Path Analysis flow diagrams are very good for showing interdependent factors whose
timings overlap or coincide. They also enable a plan to be scheduled according to a timescale.
Critical Path Analysis flow diagrams also enable costing and budgeting, although not quite as
easily as Gantt charts (below), and they also help planners to identify causal elements, although
not quite so easily as fishbone diagrams (below).

This is how to create a Critical Path Analysis. As an example, the project is a simple one -
making a fried breakfast.

First note down all the issues (resources and activities in a rough order), again for example:

Assemble crockery and utensils, assemble ingredients, prepare equipment, make toast, fry
sausages and eggs, grill bacon and tomatoes, lay table, warm plates, serve.

Note that some of these activities must happen in parallel - and crucially they are
interdependent. That is to say, if you tried to make a fried breakfast by doing one task at a time,
and one after the other, things would go wrong. Certain tasks must be started before others, and
certain tasks must be completed in order for others to begin. The plates need to be warming
while other activities are going on. The toast needs to be toasting while the sausages are frying,
and at the same time the bacon and sausages are under the grill. The eggs need to be fried last.
A Critical Path Analysis is a diagrammatical representation of what needs done and when.
Timescales and costs can be applied to each activity and resource. Here's the Critical Path
Analysis for making a fried breakfast:

This Critical Path Analysis example below shows just a few activities over a few minutes.
Normal business projects would see the analysis extending several times wider than this
example, and the time line would be based on weeks or months. It is possible to use MS Excel
or a similar spreadsheet to create a Critical Path Analysis, which allows financial totals and
time totals to be planned and tracked. Various specialized project management software enable
the same thing. Beware however of spending weeks on the intricacies of computer modeling,
when in the early stages especially, a carefully hand drawn diagram - which requires no
computer training at all - can put 90% of the thinking and structure in place.
The Critical Path Method (CPM) is one of several related techniques for doing project planning.
CPM is for projects that are made up of a number of individual "activities." If some of the
activities require other activities to finish before they can start, then the project becomes a
complex web of activities.

CPM can help you figure out:

• how long your complex project will take to complete

• which activities are "critical," meaning that they have to be done on time or else the
whole project will take longer

If you put in information about the cost of each activity, and how much it costs to speed up
each activity, CPM can help you figure out:

• whether you should try to speed up the project, and, if so,

• what is the least costly way to speed up the project.

Activities
An activity is a specific task. It gets something done. An activity can have these properties:

• names of any other activities that have to be completed before this one can start
• a projected normal time duration

If you want to do a speedup cost analysis, you also have to know these things about each
activity:

• a cost to complete
• a shorter time to complete on a crash basis
• the higher cost of completing it on a crash basis

CPM analysis starts after you have figured out all the individual activities in your project.

CPM Analysis Steps, By Example

This document describes the steps for doing CPM analysis for this course. The steps will be
illustrated by two examples. I recommend that you work through the examples, so that you can
follow the steps yourself when you do the homework.

Example 2 is especially valuable for you to work through. Excel has bugs that vary from
version to version. By working through Example 2, and comparing what you get with what I
got, you can find out which bugs apply to you and how to work around them when you do the
assignment.

Example 1: Activities, precedence, and times

This first example involves activities, their precedence (which activities come before other
activities), and the times the activities take. The objective is to identify the critical path and
figure out how much time the whole project will take.
Example 1 Step 1: List the activities
CPM analysis starts when you have a table showing each activity in your project. For each
activity, you need to know which other activities must be done before it starts, and how long
the activity takes.

Here's the example:

Activity Description Required Predecessor Duration

A Product design (None) 5 months

B Market research (None) 1

C Production analysis A 2

D Product model A 3

E Sales brochure A 2

F Cost analysis C 3

G Product testing D 4

H Sales training B, E 2

I Pricing H 1

J Project report F, G, I 1

Example 1 Step 2: Draw the diagram

Draw by hand a network diagram of the project that shows which activities follow which other
ones. This can be tricky. The analysis method we'll be using requires an "activity-on-arc"
(AOA) diagram. An AOA diagram has numbered "nodes" that represent stages of project
completion. You make up the nodes' numbers as you construct the diagram. You connect the
nodes with arrows or "arcs" that represent the activities that are listed in the above table.
Some conventions about how to draw these diagrams:

• All activities with no predecessor come off of node 1.

• All activities with no successor point to the last node, which has to have highest node
number.

In this example, A and B are the two activities that have no precedessor. They are represented
as arrows leading away from node 1.

J is the one activity that has no successor, in this example. It therefore points to the last node,
which is node 8. If there were more than one activity with successor, all of those activities'
arrows point to the highest number node.

Students sometimes make the mistake of creating a diagram with several starting or ending
nodes. Don't do this.

The trickiest part for me of building the above diagram was figuring what to do with activity
H. I had drawn an arrow for activity B coming off node 1 and going to mode 3. I had later
drawn an arrow for activity E coming off node 2 and going to node 6. Since H requires both B
and E, I had to erase my first E arrow and redraw it so it pointed to the same node 3 that B did.
H then comes off of node 3 and goes to node 6.

Find all of the possible paths through your diagram along the arrows from the first node to the
last. This diagram shows the four possible paths in this example.

The four paths are A D G J, A C F J, A E H I J, and B H I J.

The critical path is the path that takes the longest. In this example, the critical path is 1 -A-> 2
-D-> 4 -G-> 7 -J-> 8 which takes 13 months. The project will therefore take 13 months, if
everything is done on schedule with no delays. The time a project takes is equal to the time of
its critical path.

As managers, we must be sure that activities A, D, G, and J are done on time. If any of those
activities is late, the project will be late.

Other paths are not critical because they can waste some time without slowing the project. For
example, activity C, can take up to two extra months and not hold up the project.
Programme Evaluation Review technique (PERT)

PERT is a planning and control tool used for defining and controlling the tasks necessary to
complete a project. PERT charts and Critical Path Method (CPM) charts are often used
interchangeably; the only difference is how task times are computed. Both charts display the
total project with all scheduled tasks shown in sequence. The displayed tasks show which ones
are in parallel, those tasks that can be performed at the same time. A graphic representation
called a "Project Network" or "CPM Diagram" is used to portray graphically the
interrelationships of the elements of a project and to show the order in which the activities must
be performed.

PERT planning involves the following steps:

Identify the specific activities and milestones: The activities are the tasks of the project. The
milestones are the events that mark the beginning and the end of one or more activities.

Determine the proper sequence of activities: This step may be combined with #1 above since
the activity sequence is evident for some tasks. Other tasks may require some analysis to
determine the exact order in which they should be performed.

Construct a network diagram: Using the activity sequence information, a network diagram can
be drawn showing the sequence of the successive and parallel activities. Arrowed lines
represent the activities and circles or "bubbles" represent milestones.

Estimate the time required for each activity: Weeks are a commonly used unit of time for
activity completion, but any consistent unit of time can be used. A distinguishing feature of
PERT is it's ability to deal with uncertainty in activity completion times. For each activity, the
model usually includes three time estimates:

• Optimistic time - the shortest time in which the activity can be completed.
• Most likely time - the completion time having the highest probability.
• Pessimistic time - the longest time that an activity may take.

From this, the expected time for each activity can be calculated using the following weighted
average:

Expected Time = (Optimistic + 4 x Most Likely + Pessimistic) / 6

This helps to bias time estimates away from the unrealistically short timescales normally
assumed.

Determine the critical path. The critical path is determined by adding the times for the activities
in each sequence and determining the longest path in the project. The critical path determines
the total calendar time required for the project. The amount of time that a non-critical path
activity can be delayed without delaying the project is referred to as slack time.

If the critical path is not immediately obvious, it may be helpful to determine the following
four times for each activity:

• ES - Earliest Start time

 • EF - Earliest Finish time
• LS - Latest Start time
• LF - Latest Finish time

These times are calculated using the expected time for the relevant activities. The earliest start
and finish times of each activity are determined by working forward through the network and
determining the earliest time at which an activity can start and finish considering its
predecessor activities. The latest start and finish times are the latest times that an activity can
start and finish without delaying the project. LS and LF are found by working backward
through the network. The difference in the latest and earliest finish of each activity is that
activity's slack. The critical path then is the path through the network in which none of the
activities have slack.

The variance in the project completion time can be calculated by summing the variances in the
completion times of the activities in the critical path. Given this variance, one can calculate the
probability that the project will be completed by a certain date assuming a normal probability
distribution for the critical path. The normal distribution assumption holds if the number of
activities in the path is large enough for the central limit theorem to be applied.

Update the PERT chart as the project progresses: As the project unfolds, the estimated times
can be replaced with actual times. In cases where there are delays, additional resources may be
needed to stay on schedule and the PERT chart may be modified to reflect the new situation.

At the core, PERT is all about management probabilities. Therefore, PERT involves in many
simple statistical methods as well.

Sometimes, people categorize and put PERT and CPM together. Although CPM (Critical Path
Method) shares some characteristics with PERT, PERT has a different focus.

Same as most of other estimation techniques, PERT also breaks down the tasks into detailed
activities.

Then a Gantt chart will be prepared illustrating the interdependencies among the activities.
Then, a network of activities and their interdependencies are drawn in an illustrative manner.

In this map, a node represents each event. The activities are represented as arrows and they are
drawn from one event to another, based on the sequence.

Next, the Earliest Time (TE) and the Latest Time (TL) are figured for each activity and identify
the slack time for each activity.

When it comes to deriving the estimates, the PERT model takes a statistical route to do that.
We will cover more on this in the next two sections.

Following is an example PERT chart.

There are three estimation times involved in PERT; Optimistic Time Estimate (TOPT), Most
Likely Time Estimate (TLIKELY), and Pessimistic Time Estimate (TPESS).

In PERT, these three estimate times are derived for each activity. This way, a range of time is
given for each activity, with the most probable value, TLIKELY.

Following are further details on each estimate.

TOPT

This is the fastest time an activity can be completed. For this, the assumption is made that all
the necessary resources are available and all predecessor activities are completed as planned.

TLIKELY

Most of the times, project managers are asked only to submit one estimate. In that case, this is
the estimate that goes to the upper management.

TPESS

This is the maximum time required to complete an activity. In this case, it is assumed that many
things go wrong related to the activity. A lot of rework and resource unavailability are assumed
when this estimation is derived.

BETA probability distribution is what works behind PERT. The expected completion time (E)
is calculated as below:

E = (TOPT + 4 x TLIEKLY + TPESS) / 6

At the same time, the possible variance (V) of the estimate is calculated as below:

V = (TPESS - TOPT)^2 / 6^2

Now, following is the process we follow with the two values.

 • For every activity in the critical path, E and V are calculated.
• Then the total of all Es are taken. This is the overall expected completion time for the
project.
• Now, the corresponding V is added to each activity of the critical path. This is the
variance for the entire project. This is done only for the activities in the critical path as
only the critical path activities can accelerate or delay the project duration.
• Then, standard deviation of the project is calculated. This equals to the square root of
the variance (V).
• Now, the normal probability distribution is used for calculating the project completion
time with the desired probability.

Benefits to using a PERT chart or the Critical Path Method include:

• Improved planning and scheduling of activities.

• Improved forecasting of resource requirements.
• Identification of repetitive planning patterns which can be followed in other projects,
thus simplifying the planning process.
• Ability to see and thus reschedule activities to reflect inter project dependencies and
resource limitations following know priority rules.
• It also provides the following: expected project completion time, probability of
completion before a specified date, the critical path activities that impact completion
time, the activities that have slack time and that can lend resources to critical path
activities, and activity start and end dates.

Gantt charts

Gantt Charts (commonly wrongly called gant charts) are extremely useful project management
tools. The Gantt Chart is named after US engineer and consultant Henry Gantt (1861-1919)
who devised the technique in the 1910s.

Gantt charts are excellent models for scheduling and for budgeting, and for reporting and
presenting and communicating project plans and progress easily and quickly, but as a rule Gantt
Charts are not as good as a Critical Path Analysis Flow Diagram for identifying and showing
interdependent factors, or for 'mapping' a plan from and/or into all of its detailed causal or
contributing elements.

You can construct a Gantt Chart using MSExcel or a similar spreadsheet. Every activity has a
separate line. Create a time-line for the duration of the project (the breakfast example shows
minutes, but normally you would use weeks, or for very big long-term projects, months). You
can colour code the time blocks to denote type of activity (for example, intense, watching brief,
directly managed, delegated and left-to-run, etc.) You can schedule review and insert break
points. At the end of each line you can show as many cost columns for the activities as you
need. The breakfast example shows just the capital cost of the consumable items and a revenue
cost for labour and fuel. A Gantt chart like this can be used to keep track of progress for each
activity and how the costs are running. You can move the time blocks around to report on
actuals versus planned, and to re-schedule, and to create new plan updates. Costs columns can
show plan and actuals and variances, and calculate whatever totals, averages, ratios, etc., that
you need. Gantt Charts are probably the most flexible and useful of all project management
tools, but remember they do not very easily or obviously show the importance and inter-
dependence of related parallel activities, and they won't obviously show the necessity to
complete one task before another can begin, as a Critical Path Analysis will do, so you may
need both tools, especially at the planning stage, and almost certainly for large complex
projects.

To draw up a Gantt chart, follow these steps:

List all activities in the plan: For each task, show the earliest start date, estimated length of time
it will take, and whether it is parallel or sequential. If tasks are sequential, show which stages
they depend on.

Head up graph paper with the days or weeks through completion.

Plot tasks onto graph paper. Show each task starting on the earliest possible date. Draw it as a
bar, with the length of the bar being the length of the task. Above the task bars, mark the time
taken to complete them.

Schedule activities: Schedule them in such a way that sequential actions are carried out in the
required sequence. Ensure that dependent activities do not start until the activities they depend
on have been completed. Where possible, schedule parallel tasks so that they do not interfere
with sequential actions on the critical path. While scheduling, ensure that you make best use of
the resources you have available, and do not over-commit resources. Also, allow some slack
time in the schedule for holdups, overruns, failures, etc.

Presenting the analysis: In the final version of your Gantt chart, combine your draft analysis
(#3 above) with your scheduling and analysis of resources (#4 above). This chart will show
when you anticipate that jobs should start and finish.

A typical Gantt chart is as per following:

 5.4 SUMMARY

The key to a successful project is in the planning. Creating a project plan is the first thing you should
do when undertaking any kind of project. The stages in this planning process are as per following:
Analysis of Opportunities, Identifying the Aim of Your Plan, Exploring Options, Selecting the
Best Option, Detailed Planning, Evaluation of the Plan and its Impact.

The successful project planning includes use of tools: Brainstorming, Fish Bone Diagram,
Work breakdown structure, Critical path analysis, Programme evaluation and Review
technique, Gantt Charts.

The systematic and effective use of these tools helps in reducing time and cost for the project.

5.5 KEYWORDS

Programme Evaluation Review technique (PERT) - PERT is a planning and control tool
used for defining and controlling the tasks necessary to complete a project

Work breakdown structure - A work breakdown structure (WBS), in project management

and systems engineering, is a deliverable oriented decomposition of a project into smaller
components. It defines and groups a project's discrete work elements in a way that helps
organize and define the total work scope of the project.
 UNIT 6 PROJECT ORGANIZING

Objectives

After reading this Unit you would be able to:

• Create different types of organization structures;

• Compare different types of organization structures;
• Explain responsibilities of PMO;
• Organize for projects.

Structure

6.1 Introduction to Project Organizing

6.2 Creating Organization structures
6.3 Types of Organization Structures
6.4 Specialized organization structures
6.5 Projects Organizing Process
6.6 Project Management Office
6.7 Summary
6.8 Key Words

6.1 INTRODUCTION TO PROJECT ORGANIZING

Once we have planned the project, we need to organize the resources and activities in the
project. In this unit, we will look at different requirements of project organizing which includes
designing the organization structure, defining the role and responsibilities of different team
members and designing project management office.

6.2 CREATING ORGANIZATION STRUCTURES

An organizational structure consists of activities such as task allocation, coordination and

supervision, which are directed towards the achievement of organizational aims. It can also be
considered as the viewing glass or perspective through which individuals see their organization
and its environment. Organizations are a variant of clustered entities. An organization structure
can be created keeping in mind following 4 things:
Division of work: Complex work can be better executed by dividing it among different people.
For example, every project has some people working on different technologies. Some people
working on high level design, others do project management etc.

Departmentalization: This involves grouping people into departments based on some logic.
In some companies they are categorized into departments like Delivery, Marketing, HR etc.

Hierarchy: Here we decide who reports to whom. Engineers reports to leader. Leader reports
to Project Manager ( PM) . PM Reports to Project Director etc.

Coordination: This involves the integration of departmental activities as a whole and

monitoring the effectiveness of this integration.

6.3 TYPES OF ORGANIZATION STRUCTURES

An organization can be structured in many different ways, depending on their objectives. The
structure of an organization will determine the modes in which it operates and performs.
Organizational structure allows the expressed allocation of responsibilities for different
functions and processes to different entities such as the branch, department, workgroup and
individual. Organizational structure affects organizational action in two big ways. First, it
provides the foundation on which standard operating procedures and routines rest. Second, it
determines which individuals get to participate in which decision-making processes, and thus
to what extent their views shape the organization’s actions.

There are mainly three ways to organize to accomplish work. Nearly every organization fits
one of these types or is a combination of them. These are the pure project organization, the
functional organization, and the matrix organization. The pure project organization and the
functional organization have been around for hundreds of years; the matrix organization is a
rather recent development.

Pure Project Organization

In the pure project organization, the project manager is the supreme authority. He or she is the
ultimate decision-maker for the project and is not subject to any but the highest level of review.
This review is generally at the project level for the budget, schedule, and deliverables. These
projects are usually quite large and are done in a remote location. Building dams or remote
power plants in Third World countries would be typical applications for the pure project
organization.

Features of Pure Project Organization Structure

• Virtually separate organization for a project

• Managed in full responsibility by the project leader
• Project team members are displaced, delegated for the duration of the project
• Project team members get only briefed by the project manager

Advantages of Project Organization

• Full concentration of all involved members to the project goals
• High identification with the project
• Full line authority of the project manager
• Clear managerial authority
• Taut leadership of the project
• Fast reaction to changes/ disturbances
• Fast coping with difficulties

Disadvantages of Project Organization

• Allocation of requisite dedicated resources
• Little exchange of specialists with divisions
• Problematic capacity utilization of specialists
• Critical reintegration of the team members at the end of the project

Functional Organization
The functional organization has been around since long before the industrial revolution and
was the preferable type for commercial enterprises in the beginning and middle of the twentieth
century. The functional organization is organized on the basis of skills. A typical company sets
up departments within the company, and each of these departments will have persons of similar
skills within it. This type of organization is not strictly organized by skills. In the mechanical
engineering department, for example, there may be a few engineers with different skills such
as electrical engineers or computer engineers.

Employees within the functional divisions of an organization tend to perform a specialized set
of tasks, for instance the engineering department would be staffed only with software
engineers. This leads to operational efficiencies within that group. However it could also lead
to a lack of communication between the functional groups within an organization, making the
organization slow and inflexible.
As a whole, a functional organization is best suited as a producer of standardized goods and
services at large volume and low cost. Coordination and specialization of tasks are centralized
in a functional structure, which makes producing a limited amount of products or services
efficient and predictable. Moreover, efficiencies can further be realized as functional
organizations integrate their activities vertically so that products are sold and distributed
quickly and at low cost. For instance, a small business could make components used in
production of its products instead of buying them.

Features of functional Organization Structure

• Minimum configuration of a project organization
• Functional organization/ hierarchy remains unchanged
• Organization is extended by a project leader in a executive management team function
(on a sufficient high level)
• Project leader on management team function level
- Has only information and advising rights towards the departments
- Has no decision and directive authority
- Tracks project regarding content, deadlines and costs
- Proposes measures to line managers
- Motivates employees within the departments to actively participate in the project
towards the fulfilling of the project objectives

Advantages of Functional Organization:

• Flexibility regarding work force usage (involvement in several projects possible)
• Improved learning curve (experience from several projects)
• No change of company organization necessary
• Continued relation to department

Disadvantages of Functional Organization:

• Limited identification and responsibilities
• Limited need to solve problems across departments
• Response and decision time low (involvement of line organization!)
Matrix structure

The matrix organization is a mixture of the pure project organization and the functional
organization. It is the one that allows the concept of project management to work best. In the
matrix organization we try to have the best of both organizations without the negative aspects
of each. We try to have an organization that has a manager with authority who can be reached
easily, an organization with a lot of flexibility, and customer focus. It should be an organization
that can quickly bring the proper skills together on a temporary basis for the duration of a
project. Resources in this organization are shared. And when the project is over they have
other work to go back to. The end of the project does not mean the end of the line for them.
The matrix structure groups employees by both function and product. This structure can
combine the best of both separate structures. A matrix organization frequently uses teams of
employees to accomplish work, in order to take advantage of the strengths, as well as make up
for the weaknesses, of functional and decentralized forms. An example would be a company
that produces two products, "product a" and "product b". Using the matrix structure, this
company would organize functions within the company as follows: "product a" sales
department, "product a" customer service department, "product a" accounting, "product b"
sales department, "product b" customer service department, "product b" accounting
department. Matrix structure is amongst the purest of organizational structures, a simple lattice
emulating order and regularity demonstrated in nature.

Weak/Functional Matrix: A project manager with only limited authority is assigned to

oversee the cross- functional aspects of the project. The functional managers maintain control
over their resources and project areas.
Balanced/Functional Matrix: A project manager is assigned to oversee the project. Power is
shared equally between the project manager and the functional managers. It brings the best
aspects of functional and projectized organizations. However, this is the most difficult system
to maintain as the sharing power is delicate proposition.

Strong/Project Matrix: A project manager is primarily responsible for the project. Functional
managers provide technical expertise and assign resources as needed.

Features of Matrix Organization

• Matrix Organization is a compromise between functional organization and project
organization.
• The functional heads are given authority as regards the technical aspects of the project.
• The subordinate employees under matrix organization are under dual control.
• It is suitable to large projects.
• Effective communication system is essential for the smooth functioning of matrix
organization.
• Training of managers as well as subordinates is essential for the effective working of matrix
structure.
• Authority flows both down and across.

Advantages of Matrix Organization

• Better Co-ordination and control: Co ordination is not a serious problem in matrix
organization. Due to vertical and horizontal communication, the project manager can co-
ordinate many inter-related aspects of particular project.
• Higher Motivation: People are satisfied when the project is complemented in time. This
feeling of satisfaction raises their morale and motivates them to work for the new project.
• Excellence in inter- disciplinary specialization: In a matrix organization it is possible to
expand the technical excellence into many inters disciplinary activities
• Fullest use of available resources: A matrix organization handles number of projects
simultaneously. As the approach is project oriented, details of the resources required are
calculated accurately. Resources are transferable from one project to another.
• Helps self development and growth: Matrix organization exposes the employees to
complex situation and challenges. The process of job rotation facilitates self-development.
• Improves efficiency: Matrix organization is a time-bound project. The project cannot be
completed in time unless the employees display efficiency.

Disadvantages of Matrix Organization

• Dual Control: Under matrix organization, employees receive order from functional heads
as well as from project manager. This leads to multiplicity of authority which leads to
confusion.
• Difficult to Manage: Under matrix organization, internal operations are complicated. This
is due to horizontal and vertical lines of authority. The rule and procedures are not followed
uniformly in all departments therefore it becomes difficult to manage.
• Create Communication Gap: There is communication gap between project manager and
functional manager. This may lead to confusion.
• Complex operation: internal operation of matrix organizations is complex. Too much
shifting of staff from one project to another creates more complications
• Impact of Stress: the appointment of project manager is temporary Therefore he tries to
discredit the functional.
 6.4 SPECIALIZED ORGANIZATION STRUCTURES

In addition to above 3 types of organization structures, there are specialized organization

structures to suit specific needs of the business which are as follows:

Organizational circle: moving back to flat

The flat structure is common in small companies (entrepreneurial start-ups, university spin
offs). As the company grows it becomes more complex and hierarchical, which leads to an
expanded structure, with more levels and departments.

Often, it would result in bureaucracy, the most prevalent structure in the past. It is still,
however, relevant in former Soviet Republics, China, and most governmental organizations all
over the world. Shell Group used to represent the typical bureaucracy: top-heavy and
hierarchical. It featured multiple levels of command and duplicate service companies existing
in different regions. All this made Shell apprehensive to market changes, leading to its
incapacity to grow and develop further. The failure of this structure became the main reason
for the company restructuring into a matrix.

Starbucks is one of the numerous large organizations that successfully developed the matrix
structure supporting their focused strategy. Its design combines functional and product based
divisions, with employees reporting to two heads. Creating a team spirit, the company
empowers employees to make their own decisions and train them to develop both hard and soft
skills. That makes Starbucks one of the best at customer service.

Some experts also mention the multinational design, common in global companies, such as
Procter & Gamble, Toyota and Unilever. This structure can be seen as a complex form of the
matrix, as it maintains coordination among products, functions and geographic areas.

In general, over the last decade, it has become increasingly clear that through the forces of
globalization, competition and more demanding customers, the structure of many companies
has become flatter, less hierarchical, more fluid and even virtual.
Team
One of the newest organizational structures developed in the 20th century is team. In small
businesses, the team structure can define the entire organization. Teams can be both horizontal
and vertical. While an organization is constituted as a set of people who synergize individual
competencies to achieve newer dimensions, the quality of organizational structure revolves
around the competencies of teams in totality. For example, every one of the Whole Foods
Market stores, the largest natural-foods grocer in the US developing a focused strategy, is an
autonomous profit centre composed of an average of 10 self-managed teams, while team
leaders in each store and each region are also a team. Larger bureaucratic organizations can
benefit from the flexibility of teams as well. Xerox, Motorola, and DaimlerChrysler are all
among the companies that actively use teams to perform tasks.

Network
Another modern structure is network. While business giants risk becoming too clumsy to proact
(such as), act and react efficiently, the new network organizations contract out any business
function that can be done better or more cheaply. In essence, managers in network structures
spend most of their time coordinating and controlling external relations, usually by electronic
means. H&M is outsourcing its clothing to a network of 700 suppliers, more than two-thirds of
which are based in low-cost Asian countries. Not owning any factories, H&M can be more
flexible than many other retailers in lowering its costs, which aligns with its low-cost strategy.
The potential management opportunities offered by recent advances in complex networks
theory have been demonstrated including applications to product design and development, and
innovation problem in markets and industries.

Virtual
A special form of boundary less organization is virtual. Hedberg, Dahlgren, Hansson, and Olve
(1999) consider the virtual organization as not physically existing as such, but enabled by
software to exist. The virtual organization exists within a network of alliances, using the
Internet. This means while the core of the organization can be small but still the company can
operate globally be a market leader in its niche. According to Anderson, because of the
unlimited shelf space of the Web, the cost of reaching niche goods is falling dramatically.
Although none sell in huge numbers, there are so many niche products that collectively they
make a significant profit, and that is what made highly innovative Amazon.com so successful.

Divisional Structure
Also called a "product structure", the divisional structure groups each organizational function
into a division. Each division within a divisional structure contains all the necessary resources
and functions within it. Divisions can be categorized from different points of view. One might
make distinctions on a geographical basis (a US division and an EU division, for example) or
on product/service basis (different products for different customers: households or companies).
In another example, an automobile company with a divisional structure might have one division
for SUVs, another division for subcompact cars, and another division for sedans. Each division
may have its own sales, engineering and marketing departments.

6.5 PROJECT ORGANIZING PROCESS

A successful project management requires organizing the project by creating proper

organization structure and then working as per following process:

Job Design

“If you want people to do a good job, give them a good job to do.” Frederick Herzberg

Every manager must know the relationship between how organisation being structured, the job
within and the linkages to organisational processes.
The theory of job design is an important concept in business management and has been well
known in the private sector for over 30 years. According to its proponents, workers are
motivated by jobs in which they feel they can make a difference—and jobs can be designed
with that in mind. An employee may take on a whole position involving many tasks, or a
reduced number of tasks, depending on ability, time allotment and other constraints.

Put simply, “job design refers to the way tasks are combined to form complete jobs”. Using
job design principles results in clear job descriptions, a motivated workforce and successful
completion of tasks. People are assigned to a job because they are perceived to be able to fill
its requirements. From an employer’s perspective, the employee knows exactly what to do and
is accountable. From the employee’s perspective, the job requirements and responsibilities are
clear. A contractual element—through either a position description or the employment
contract—ensures that both employer and employee have a shared understanding of the work
to be done.

Job design theory has a basis in the work of a number of key researchers. Psychologist
A. H. Maslow identified a hierarchical scheme of five basic needs that motivate people: to stay
alive, to be safe, to be with others, to be respected and to do work that corresponds to our gifts
and abilities.

Frederick Herzberg, a noted behavioural scientist, distinguished between what he called the
maintenance and the motivational factors that affect job satisfaction (Herzberg’s Two-Factor
Theory). Maintenance factors include salary, administrative policies and working conditions.
On their own, maintenance factors cannot provide job satisfaction, although they can be reasons
for job dissatisfaction. On the other hand, motivational factors include a sense of achievement,
the perceived importance of the work, job autonomy and skill development. Workers respond
positively to the importance of the work they are doing and an opportunity for living up to their
potential (Bittel and Newstrom).

Based on these theoretical underpinnings, job design methodology has been developed for and
by larger organizations to handle the challenges associated with employing a large number of
people in a wide variety of capacities. Among features of the modern workplace that come out
of the job design model are flextime, job-sharing, job rotation and the compressed workweek.
All of these can lead to more autonomy for the worker and thereby tend to increase job
satisfaction.
In addition to revisiting the organization’s mission statement, there may be other tools
to help you identify functions in your association, including strategic plans, budget
documents, contracts, job descriptions and promotional materials. Start with whatever
you have. Some points to consider:

• Are the functions described in these tools still relevant to what your organization is
trying to accomplish? When were they last reviewed? If most of the functions are still
relevant, proceed with the task analysis process. Don’t delay job design unnecessarily to
embark on a long-term planning process.
• Are there any activities identified in your planning tools that aren’t being done?
This could mean one of two things: either you need to update the documents and
let both the organization and its stakeholders know that the organization is engaged
in that work OR you need to make the recruitment, training and delivery of those
activities a priority?
• Have you identified any new functions that your organization is ideally suited to
undertake, if you had the resources and people to assign to them?
Having identified the general functions of the organization, consider the components
and tasks of each. As in every instance where we are asked to adopt a ‘model’ for doing
something, remember that it is not that important to define functions, components and tasks
to a highly technical degree. The point is to break down the work of the organization into
manageable pieces for the purposes of creating a series of work assignments.

Since the fundamental building block for the work of the organization is found at the level of
tasks the following theory may be helpful as you commence the breakdown process. Job design
theory presents three elements to our consideration of ‘tasks’:
• Task analysis
• Task identity
• Task significance

Task analysis: identifies and describes every task to be performed on each job, the skills
necessary to perform those tasks, and the minimum acceptable standards of performance
(Dolan and Schuler, p.608). For example a paid ‘Office Manager’ might carry out a range of
tasks from reception duties, to mailroom, to bookkeeping and general office management.
While it is reasonable to expect to be able to hire a person who can speak both English and
French (in order to be able to do the reception part of the job), have good technical abilities
(for the mailroom) and some bookkeeping experience, it could be a tall order to find a volunteer
with such a mix of skills and the time/interest to be able to carry out such a range of tasks. It is
more likely that by breaking down the function of Office Management into three or more
tasks—reception, bookkeeping, mailroom—that a series of attractive volunteer assignments
will emerge.

The principle of task identity involves designing tasks with clear start and end points and
plainly articulated purposes—this task will produce result X. In this way, when individual
workers carry out the task they are given responsibility to handle it from beginning to end,
taking ownership of the product or outcome. Task identity allows volunteers to put their work
in context and in measurable terms: for example, “I answer the phones and track the calls” is
more specific than a vague, “I’m an office worker.” And when workers track the 300th call, or
finish their three-week assignment on the phones, they have something quantifiable to show
for their efforts.

Finally the principle of task significance refers to the relevance of a role within the scheme of
the organization. Identifying the significance of the task results in a clear understanding
between employer and employee of why the work assignment is important, and how the task
contributes to the achievement of the organization’s goals.

Task significance can be further enhanced through having the volunteers form positive
relationships with those they serve, whether clients of the organization, or others within the
organization who rely on volunteers. This may also require having the volunteer determine
specific feedback criteria with the client or user.

Manage, motivate, Inform, Encourage, Enable the project team

Manage the team and activities in meetings, communicating, supporting, and helping with
decisions (but not making them for people who can make them for themselves). 'Praise loudly;
blame softly.' (a wonderful maxim attributed to Catherine the Great). One of the big challenges
for a project manager is deciding how much freedom to give for each delegated activity. Tight
parameters and lots of checking are necessary for inexperienced people who like clear
instructions, but this approach is the kiss of death to experienced, entrepreneurial and creative
people. They need a wider brief, more freedom, and less checking. Manage these people by the
results they get - not how they get them. Look out for differences in personality and working
styles in your team. Misunderstanding personal styles can get in the way of team cooperation.
Your role here is to enable and translate. Face to face meetings, when you can bring team
members together, are generally the best way to avoid issues and relationships becoming
personalised and emotional. Communicate progress and successes regularly to everyone. Give
the people in your team the plaudits, particularly when someone high up expresses satisfaction
- never, never accept plaudits yourself. Conversely - you must take the blame for anything that
goes wrong - never 'dump' (your problems or stresses) on anyone in your team. As project
manager any problem is always ultimately down to you anyway. Use empathy and conflict
handling techniques, and look out for signs of stress and manage it accordingly. A happy
positive team with a basic plan will outperform a miserable team with a brilliant plan, every
time.6 - check, measure, and review project performance; adjust project plans; inform project
team and others

Check the progress of activities against the plan. Review performance regularly and at the
stipulated review points, and confirm the validity and relevance of the remainder of the plan.
Adjust the plan if necessary in light of performance, changing circumstances, and new
information, but remain on track and within the original terms of reference. Be sure to use
transparent, pre-agreed measurements when judging performance. (Which shows how essential
it is to have these measures in place and clearly agreed before the task begins.) Identify, agree
and delegate new actions as appropriate. Inform team members and those in authority about
developments, clearly, concisely and in writing. Plan team review meetings. Stick to the
monitoring systems you established. Probe the apparent situations to get at the real facts and
figures. Analyse causes and learn from mistakes. Identify reliable advisors and experts in the
team and use them. Keep talking to people, and make yourself available to all.

Follow up - train, support, measure and report project results and benefits

Traditionally this stage would be considered part of the project completion, but increasingly an
emphasised additional stage of project follow-up is appropriate.

This is particularly so in very political environments, and/or where projects benefits have
relatively low visibility and meaning to stakeholders (staff, customers, investors, etc),
especially if the project also has very high costs, as ICT projects tend to do.
ICT (information and communications technology) projects often are like this - low visibility
of benefits but very high costs, and also very high stress and risk levels too.

Project management almost always involves change management too, within which it's very
important to consider the effects of the project on people who have to adapt to the change.
There is often a training or education need. There will almost certainly be an explanation need,
in which for example methods like team briefing have proved very useful.

Whatever, when you are focused on project management it is easy to forget or ignore that many
people are affected in some way by the results of the project. Change is difficult, even when it
is good and for right reasons. Remembering this during and at the end of your project will help
you achieve a project that is well received, as well as successful purely in project management
terms.

Complete project; review and report on project; give praise and thanks to the project
team

At the end of your successful project hold a review with the team. Ensure you understand what
happened and why. Reflect on any failures and mistakes positively, objectively, and without
allocating personal blame. Reflect on successes gratefully and realistically. Write a review
report, and make observations and recommendations about follow up issues and priorities -
there will be plenty.

6.6 PROJECT MANAGEMENT OFFICE

A Project Management Office (PMO) is a group or department within a business, agency or

enterprise that defines and maintains standards for project management within the organization.
The PMO strives to standardize and introduce economies of repetition in the execution of
projects. The PMO is the source of documentation, guidance and metrics on the practice of
project management and execution. In some organisations this is known as the Program
Management Office (sometimes abbreviated to PgMO to differentiate); the subtle difference is
that program management relates to governing the management of several related projects.
Establishing a PMO group is not a short term strategy to lower costs. Surveys with companies
indicates that the longer they have an operating PMO group the better the results achieved to
accomplish project goals (which might lead to lowering costs).

PMOs may take other functions beyond standards and methodology, and participate in
Strategic Project Management either as facilitator or actively as owner of the Portfolio
Management process. Tasks may include Monitoring and Reporting on active projects
(following up project until completion), and reporting progress to top management for strategic
decisions on what projects to continue or cancel.

How a project management office (PMO) is designed and staffed for maximum effectiveness
depends on a variety of organizational factors, including targeted goals, traditional strengths
and cultural imperatives. There are three basic organizational styles for a project management
office.

The project repository: This model occurs most often in organizations that empower
distributed, business-centric project ownership, or enterprises with weak central
governance. The project office simply serves as a source of information on project
methodology and standards. Project managers continue to report to, and are funded by,
their respective business areas.

The project coach model: This model assumes a willingness to share some project
management practices across business functions and uses the project office to coordinate
the communication. Best practices are documented and shared and project performance is
monitored actively. The PMO in this model is a permanent structure with staff and has
some supervisory responsibility for all projects.

The enterprise project management office: This model also assumes a governance
process that involves the project office in all projects, regardless of size, allowing it to
assess scope, allocate resources and verify time, budget, and risk and impact assumptions
before the project is undertaken. Funding is generally a combination of direct, budgeted
allocation for baseline services and a fee-for-service charge for others.

Responsibilities of PMO

In most organizations the PMO has five main responsibilities:

Set standards for how projects are run

The PMO builds up a common set of practices, principles and templates for managing projects.
Standardization means project managers can move more easily between different projects and
new project managers get up to speed faster. Creating project management templates means
standard components can be reused which saves time and money as they are not created for
each project fresh.

Ensure project management standards are followed

While the PMO sets project management standards, it also must ensure they are followed by
performing regular assessments of projects. These processes can feedback into the standards
definition.

Gathering of project data and production of information for management review

The PMO will track the status of all projects in the organization based on updates from the
project managers. They will standardize the way this information is compiled and reported to
management. The normal way to present the information is using project dashboards which
provide a clear way to keep track of the status of projects.

Source of guidance and advice for project managers

Most PMO’s develop into a centre of excellence for project management and can provide
guidance and coaching to novice project managers or new project managers who need to
understand how the organization runs projects. In many organizations we work with, the people
running projects are not always formally trained project managers and the PMO plays a key
role in assisting this group.

Managing and facilitating the portfolio management process

For organizations that have implemented a project portfolio management approach (PPM), the
PMO manages and facilitates this process. This can include:

• Capturing project requests and ensuring each request has sufficient information to
assess the project.
• Keeping an up-to-date repository of projects underway and requests pending review.
• Implementing scoring and prioritization models to help assess which requests should
be approved.
• Managing a resource capacity plan or resource forecast to help understand resource
availability for projects.

6.7 SUMMARY

An organizational structure consists of activities such as task allocation, coordination and

supervision, which are directed towards the achievement of organizational aims. Organizations
are a variant of clustered entities. An organization structure can be created keeping in mind
following 4 things: Division of work, Departmentalization, Hierarchy, Coordination.

Organizational structure allows the expressed allocation of responsibilities for different

functions and processes to different entities such as the branch, department, workgroup and
individual.

There are mainly three ways to organize to accomplish work. Nearly every organization fits
one of these types or is a combination of them. These are the pure project organization, the
functional organization, and the matrix organization.

In the pure project organization, the project manager is the supreme authority. He or she is the
ultimate decision-maker for the project and is not subject to any but the highest level of review.
This review is generally at the project level for the budget, schedule, and deliverables.

Features of Pure Project Organization Structure are Virtually separate organization for a
project, Managed in full responsibility by the project leader, Project team members are
displaced, delegated for the duration of the project, Project team members get only briefed by
the project manager
The functional organization is organized on the basis of skills. A typical company sets up
departments within the company, and each of these departments will have persons of similar
skills within it.

Features of functional Organization Structure are Minimum configuration of a project

organization, Functional organization/ hierarchy remains unchanged, Organization is extended
by a project leader in an executive management team function (on a sufficient high level),
Project leader on management team function level - Has only information and advising rights
towards the departments, Has no decision and directive authority, Tracks project regarding
content, deadlines and costs, Proposes measures to line managers, Motivates employees within
the departments to actively participate in the project towards the fulfilling of the project
objectives.

The matrix organization is a mixture of the pure project organization and the functional
organization. It is the one that allows the concept of project management to work best. In the
matrix organization we try to have the best of both organizations without the negative aspects
of each.

6.7 KEY WORDS

• Project management office - A Project Management Office (PMO) is a group or

department within a business, agency or enterprise that defines and maintains standards for
project management within the organization.
• Task Analysis - Task analysis identifies and describes every task to be performed on each
job, the skills necessary to perform those tasks, and the minimum acceptable standards of
performance (Dolan and Schuler, p.608).
• Task Identity - The principle of task identity involves designing tasks with clear start and
end points and plainly articulated purposes. Task identity allows volunteers to put their
work in context and in measurable terms
• Task Significance - the principle of task significance refers to the relevance of a role within
the scheme of the organization. Identifying the significance of the task results in a clear
understanding between employer and employee of why the work assignment is important,
and how the task contributes to the achievement of the organization’s goals.
 UNIT 7 PROJECT SCEDULING AND CONTROL
Objectives
After reading this unit you will be able to:

• Do the scheduling of the projects;

• Arrange for scheduling inputs;
• Evaluate project progress;
• Control the project deviations.
Structure

7.1 Introduction to Project scheduling and control

7.2 Project Scheduling Inputs
7.3 Project Scheduling Process
7.4 Concurrent Project Management
7.5 Multi-tasking
7.6 Project Crashing
7.7 Project Controlling
7.8 Earned value management
7.9 Project accounting
7.10 Project Resource Management
7.11 Resource Leveling
7.12 Summary
7.13 Key Words

7.1 INTRODUCTION TO PROJECT SCHEDULING AND CONTROL

Project planning leads to creating project schedule. The scheduling has to consider different
inputs required for project. Proper scheduling is important for the success of any project. Once
schedule is made, we start the implementation of project. The project may not work as per the
plan, so we need to monitor the project process and find the deviation if any from the plan in
terms of cost and time and control the deviations. In this unit we will learn the concepts related
to project scheduling and project control.

7.2 PROJECT SCHEDULING INPUTS

In project management, a schedule consists of a list of a project's terminal elements with

intended start and finish dates. Terminal elements are the lowest element in a schedule, which
is not further subdivided. Those items are often estimated in terms of resource requirements,
budget and duration, linked by dependencies and scheduled events.
Before a project schedule can be created, the schedule maker should have a work breakdown
structure (WBS), an effort estimate for each task, and a resource list with availability for each
resource. If these components for the schedule are not available, they can be created with a
consensus-driven estimation method like Wideband Delphi. The reason for this is that a
schedule itself is an estimate: each date in the schedule is estimated, and if those dates do not
have the buy-in of the people who are going to do the work, the schedule will be inaccurate.
In many industries, such as engineering and construction, the development and maintenance
of the project schedule is the responsibility of a full time scheduler or team of schedulers,
depending on the size of the project. Though the techniques of scheduling are well developed,
they are inconsistently applied throughout industry.

Because of the uncertainty involved, the schedule is reviewed regularly, and it is often revised
while the project is in progress. It continues to develop as the project moves forward, changes
arise, risks come and go, and new risks are identified. The schedule essentially transforms the
project from a vision to a time-based plan.

Schedules also help you do the following:

• They provide a basis for you to monitor and control project activities.
• They help you determine how best to allocate resources so you can achieve the project
goal.
• They help you assess how time delays will impact the project.
• You can figure out where excess resources are available to allocate to other projects.
• They provide a basis to help you track project progress.

Several types of inputs required to create a project schedule are as per following:

Personal and project calendars – Understanding working days, shifts, and resource
availability is critical to completing a project schedule.
Description of project scope – From this, you can determine key start and end dates, major
assumptions behind the plan, and key constraints and restrictions. You can also include
stakeholder expectations, which will often determine project milestones.
Project risks – You need to understand these to make sure there's enough extra time to deal
with identified risks – and with unidentified risks (risks are identified with thorough Risk
Analysis).
Lists of activities and resource requirements – Again, it's important to determine if there
are other constraints to consider when developing the schedule. Understanding the resource
capabilities and experience you have available – as well as company holidays and staff
vacations – will affect the schedule.

A project manager should be aware of deadlines and resource availability issues that may make
the schedule less flexible.

7.3 PROJECT SCHEDULING PROCESS

Most projects should be scheduled from a start date. However, scheduling from the finish date
can be useful for determining when a project must start if it must finish on a specific date. We
can change various task and resource information to see what effect it has on the project's start
date and determine the optimum project start date.
We must schedule a project from a start date or from a finish date; it cannot be scheduled from
both start and finish dates. We pick which date we want to use (normally a start date), and
Project schedules the other date (normally a finish date).
When we need to control the start or finish date of a task, we can add a constraint to the task.
Flexible constraints work with task dependencies to make a task occur as soon or as late as the
task dependencies will allow. For example, a task with an As Soon As Possible (ASAP)
constraint and a finish-to-start dependency will be scheduled as soon as the predecessor task
finishes.
Constraints with moderate scheduling flexibility will restrict tasks from starting or finishing
before or after a date we choose. For example, a task with a Start No Earlier Than (SNET)
constraint for June 15 and a finish-to-start dependency to another task can begin June 15 if its
predecessor is finished by June 15 (or later if its predecessor finishes after June 15), but it can't
be scheduled before June 15.
With the default finish-to-start task dependency and an ASAP constraint applied to these tasks,
the successor task (the second one) is scheduled to begin as soon as the predecessor task (the
first one) is scheduled to finish.
With a SNET constraint applied, the successor task cannot begin before the constraint date,
even if (as shown here) the predecessor task is completed before the constraint date.
Inflexible constraints override any task dependencies and restrict tasks to the dates you specify.
For example, a task with a Must Start On (MSO) constraint for September 30 and a finish-to-
start dependency to another task will always be scheduled for September 30 no matter whether
its predecessor finishes early or late.
If a task constrained to a date has a predecessor that finishes too late for the successor to begin
on the date specified in the constraint, negative Slack can occur.
Constraint Scheduling
Description
Type Impact

As Soon As With this constraint, Project schedules the task as early as it can, given other
Possible Flexible scheduling parameters. No additional date restrictions are put on the task. This is the
(ASAP) default constraint for newly created tasks in projects scheduled from the start date.

As Late As With this constraint, Project schedules the task as late as it can, given other scheduling
Possible Flexible parameters. No additional date restrictions are put on the task. This is the default
(ALAP) constraint for newly created tasks in projects scheduled from the finish date.

This constraint indicates the latest possible date that you want this task to be
completed. It can be scheduled to finish on or before the specified date. A predecessor
Finish No Later
Moderate won't be able to push a successor task with an FNLT constraint past the constraint
Than (FNLT)
date. For projects scheduled from the finish date, this constraint is applied when you
enter a finish date for a task.

This constraint indicates the latest possible date that you want this task to begin. The
task can be scheduled to start on or before the specified date. A predecessor won't be
Start No Later
Moderate able to push a successor task with an SNLT constraint past the constraint date. For
Than (SNLT)
projects scheduled from the finish date, this constraint is applied when you enter a
start date for a task.

This constraint indicates the earliest possible date that you want this task to be
Finish No
completed. The task cannot be scheduled to finish any time before the specified date.
Earlier Than Moderate
For projects scheduled from the start date, this constraint is applied when you enter a
(FNET)
finish date for a task.

This constraint indicates the earliest possible date that you want this task to begin. The
Start No Earlier task cannot be scheduled to start any time before the specified date. For projects
Moderate
Than (SNET) scheduled from the start date, this constraint is applied when you enter a start date for
a task.

This constraint indicates the exact date on which a task must be scheduled to begin.
Must Start On
Inflexible Other scheduling parameters such as task dependencies, lead or lag time, resource
(MSO)
leveling, and delay can't affect scheduling the task unless this requirement is met.
 This constraint indicates the exact date on which a task must be scheduled to be
Must Finish On completed. Other scheduling parameters such as task dependencies, lead or lag time,
Inflexible
(MFO) resource leveling, and delay can't affect scheduling the task unless this requirement is
met.

Calendars determine the standard working time and nonworking time, such as weekends and
holidays, for the project. They are used to determine resource availability, how resources
assigned to tasks are scheduled, and how tasks themselves are scheduled. Project and task
calendars are used in scheduling tasks, and if resources are assigned to tasks, resource calendars
are used as well.
The calendars used in Project are:
• Base calendars These are the foundations for the other types of calendars. You can also
choose a base calendar to be the project calendar, and you can apply a base calendar to
tasks as a task calendar, or as the default hours for a resource calendar. Project provides
three base calendars, the Standard, 24-Hours, and Night Shift calendars. Resource calendars
are based on the Standard calendar by default. You can customize your own base calendar
using any of the base calendars provided.
• Project calendars These set the standard working and nonworking times for the project as
a whole. If resource calendars or task calendars are not used, tasks are scheduled during the
working time on the project calendar by default.
• Resource calendars These are based on the Standard calendar by default. You can change
working time or nonworking time for specific resources or a set of resources, ensuring that
resources are scheduled only when they're available for work. If you have changed working
or nonworking time on a resource calendar and the resource is assigned to a task, the task
is scheduled during the working time on the resource calendar.
• Task calendars These can be used to define working times for tasks outside the working
times in the project calendar. When a task calendar is assigned to a task and the resource
assigned to the task has different working times in its resource calendar, the task is
scheduled for the intersection of the two calendars' working times. But you can set a task
option to ignore resource calendars and schedule the task through the resource's
nonworking time.

If you don't assign resources to tasks in your project, Project calculates the schedule using task
durations, task dependencies, constraints, and project and task calendar information. If you do
assign resources, the tasks are also scheduled according to resources' calendars and assignment
units.

An assignment is the association of a specific task with a specific resource responsible for
completing the task. More than one resource can be assigned to a task. Both work resources
and material resources can be assigned to tasks.
Unlike work resources, assigning material resources to a task does not affect task scheduling.
For example, in your project you have a task named "Develop specifications." You also have
an engineering resource, Sean. If you assign Sean to the Develop specifications task, this
intersection of the task and resource is the assignment. The scheduling of this task depends on
Sean's resource calendar and assignment units, in addition to task information such as duration,
dependencies, constraints, and calendars.
In addition to scheduling according to task information, after you assign resources to the tasks
in your project, Project has resource and assignment information to use in calculating schedule
information, including:
The amount of work or overtime work the resource is assigned to do, and how that work is
distributed over time. Work distribution over time can also be affected by work contours.
The number of assignment units for the resource, that is, part-time, full-time, or multiple, on
the task.
The task type, which affects how a schedule changes if you revise the existing assignment. The
three task types are fixed-unit, fixed-duration, and fixed-work.
Whether the task is effort-driven. If a task is effort-driven, as resources are added or removed
on the assignment, the work remains constant for the task and is redistributed among the
resources. For fixed-unit tasks, for example, one result is that if more resources are assigned,
it will take less of a duration to complete the task.
The resource calendar in use. Project schedules assigned resources based on working and
nonworking times indicated on their resource calendars.

7.4 CONCURRENT PROJECT MANAGEMENT

Concurrent project management is a work methodology based on the parallelization of tasks

(i.e. performing tasks concurrently). It refers to an approach used in project management in
which functions of different sequential functions are integrated to reduce the elapsed time
required to bring a new product to the market. This is having its origins from concurrent
engineering.

The basic premise for concurrent engineering revolves around two concepts. The first is the
idea that all elements of a product’s life-cycle, from functionality, producibility, assembly,
testability, maintenance issues, environmental impact and finally disposal and recycling,
should be taken into careful consideration in the early design phases.

The second concept is that the preceding design activities should all be occurring at the same
time, i.e., concurrently. The idea is that the concurrent nature of these processes significantly
increases productivity and product quality. This way, errors and redesigns can be discovered
early in the design process when the project is still flexible. By locating and fixing these issues
early, the design team can avoid what often become costly errors as the project moves to more
complicated computational models and eventually into the actual manufacturing of hardware.

As mentioned above, part of the design process is to ensure that the entire product's life cycle
is taken into consideration. This includes establishing user requirements, propagating early
conceptual designs, running computational models, creating physical prototypes and
eventually manufacturing the product. Included in the process is taking into full account
funding, work force capability and time. A study in 2006 claimed that a correct implementation
of the concurrent design process can save a significant amount of money, and that organizations
have been moving to concurrent design for this reason.
Concurrent engineering replaces the more traditional sequential design flow, or ‘Waterfall
Model’. In Concurrent engineering an iterative or integrated development method is used in
stead The difference between these two methods is that the ‘Waterfall’ method moves in a
linear fashion by starting with user requirements and sequentially moving forward to design,
implementation and additional steps until you have a finished product. In this design system, a
design team would not look backwards or forwards from the step it is on to fix possible
problems. In the case that something does go wrong, the design usually must be scrapped or
heavily altered. On the other hand, the iterative design process is more cyclic in that, all aspects
of the life cycle of the product are taken into account, allowing for a more evolutionary
approach to design. The difference between the two design processes can be seen graphically
in Figure below.

Traditional “Waterfall” or Sequential Development Method vs. concurrent engineering

A significant part of the concurrent design method is that the individual engineer is given much
more say in the overall design process due to the collaborative nature of concurrent
engineering. Giving the designer ownership is claimed to improve the productivity of the
employee and quality of the product that is being produced, based on the assumption that
people who are given a sense of gratification and ownership over their work tend to work harder
and design a more robust product, as opposed to an employee that is assigned a task with little
say in the general process.

Disadvantages of Concurrent Design

Concurrent design creates its own issues, such as the implementation of early design reviews,
the dependency on efficient communication between engineers and teams, software
compatibility, and opening up the design process. A concurrent design process usually requires
that computer models (computer aided design, finite element analysis) are exchanged
efficiently, something that can be difficult in practice. If such issues are not addressed properly,
concurrent design may not work effectively.
Concurrent engineering elements

Cross-functional teams

Include members from various disciplines involved in the process, including manufacturing,
hardware and software design, marketing, and so forth

Concurrent product realization

Process activities are at the heart of concurrent engineering. Doing several things at once, such
as designing various subsystems simultaneously, is critical to reducing design time.

Incremental information sharing

It helps minimize the chance that concurrent product realization will lead to surprises. As soon
as new information becomes available, it is shared and integrated into the design. Cross
functional teams are important to the effective sharing of information in a timely fashion.

Integrated project management

It ensures that someone is responsible for the entire project, and that responsibility is not
abdicated once one aspect of the work is done.

Principal focus of CE is:

• Accelerating time-to-market
• Flexibility in equipment (with quick change-over)
• reduced lot sizes
• minimizing inventories
• simplifying design

Wester
Japanes n
e
Engineering
activity

Time
 7.5 MULTI TASKING

Multi-tasking is the act of stopping a task before it is completed and shifting to something else;
in software development the term “thrashing” is often used to describe this practice. When a
task is stopped and started there is the immediate effect of a loss of efficiency. Each time a
person has to re-start a task, time is required to become re-familiarized with the work and get
re-set in where he was in the process. It is very much like the physical set-ups done on a
machine in production. Each time you tear down a machine to do another task, you have to set
it up to run the part again.

While the loss in efficiency is not insignificant, especially in “knowledge work,” it is far from
the most important reason multi-tasking is so damaging. What happens when a task is
interrupted mid-stream is that its completion is delayed. Most people in project management
will readily agree that it is not important when a task finishes, it is important when the project
finishes. The diagram below shows three tasks a given resource must do, related to three
different projects, and when they are expected to finish: Task A after 10 days, B after 20, and
C after 30.

But if the resource has to stop and start the task even just once in the process, the actual
completion times of the tasks quickly extends, as shown below. Task A now finishes only after
20 days instead of 10, task B at 25 days rather than at 20 days, and task C may still finish on-
time at 30 days, without considering the impact of the loss in efficiency.
The delays on tasks A and B immediately translates into are delays on the downstream tasks in
those projects, who now can only start at Day 20 and 25 respectively. The impact on project A
is illustrated below. Even in a very small project like this one with just four tasks, and with
only one instance of multi-tasking, the project is delivered almost 30% late.

In most organizations where multiple projects are being done simultaneously, the resources
who do the work on a project have to serve multiple, different project managers. For these
project managers what is most important tends to be their projects. As a result they typically
create pressure on resources to do their work first, institutionalizing multi-tasking. And when
the multi-tasking starts to creep in, it initiates a negative spiral that only increases the
pressure to multi-task. If one resource starts the multi-tasking, it delays the completion of
their tasks, putting some projects behind. This increases the pressure on project managers and
executives to adjust priorities to compensate, which in turn creates more, bad multi-tasking.
It’s not hard to see how this spiral quickly becomes the reality we see in many organizations
where managers at all levels are quickly pulled into managing work priorities across the
organization on a daily basis.

On top of it, many resources who work on projects also support daily operational functions
like QA/ QC, production, engineering, customer service. This support role means that they
are frequently presented with unexpected, usually urgent things to do which readily drive
more multi-tasking. The result is that in the majority of companies there is the opportunity
and the pressure to create a significant amount of bad multi-tasking.

7.6 PROJECT CRASHING

The project manager is confronted with having to reduce the scheduled completion time of a
project to meet a deadline. Project duration can often be reduced by assigning more labor to
project activities, in the form of over time, and by assigning more resources, such as material,
equipment, etc. However, the additional labor and resources increase the project cost. So, the
decision to reduce the project duration must be based on an analysis of the trade-off between
time and cost.
Project crashing is a method for shortening the project duration by reducing the time of one or
more of the critical project activities to less than its normal activity time. The object crashing
is to reduce project duration while minimizing the cost of crashing.
Objective of Crashing

• To reduce the scheduled completion time to reap the results of the project sooner.
• As project continue over time, the team consume indirect costs.
• There may be direct financial penalties for not completing a project on time.
Key Terms related to crashing
Crashing is reducing project time by expending additional resources.
Crash time is an amount of time an activity is reduced.
Crash cost is the cost of reducing activity.
The goal of crashing is to reduce project duration at minimum cost.
To reduce project duration while minimizing the cost of crashing, the project team should
estimate require time, require the cost, crash time, crash cost for each activities. And then the
team can estimate total crash time, total crash cost, the crash cost per week to reduce project
duration at minimum cost
EXAMPLE
Direct and Indirect Costs
Project crashing costs and indirect costs have an inverse relationship; crashing costs are highest
when the project is shortened, whereas indirect costs Increase as the project duration increases.
So, the best project time is at the minimum point on the total cost curve as below:

7.7 PROJECT CONTROLLING

Project controlling should be established as an independent function in project management. It

implements verification and controlling function during the processing of a project in order to
reinforce the defined performance and formal goals. The tasks of project controlling are also:

• the creation of infrastructure for the supply of the right information and its update
• the establishment of a way to communicate disparities of project parameters
• the development of project information technology based on an intranet or the
determination of a project key performance index system (KPI)
• divergence analyses and generation of proposals for potential project regulations
• the establishment of methods to accomplish an appropriate the project structure, project
workflow organization, project control and governance
• creation of transparency among the project parameters

Fulfillment and implementation of these tasks can be achieved by applying specific methods
and instruments of project controlling. The following methods of project controlling can be
applied:

• investment analysis
• cost–benefit analyses
• value benefit Analysis
 • expert surveys
• simulation calculations
• risk-profile analyses
• surcharge calculations
• milestone trend analysis
• cost trend analysis
• target/actual-comparison

Project control is that element of a project that keeps it on-track, on-time and within budget.
Project control begins early in the project with planning and ends late in the project with post-
implementation review, having a thorough involvement of each step in the process. Each
project should be assessed for the appropriate level of control needed: too much control is too
time consuming, too little control is very risky. If project control is not implemented correctly,
the cost to the business should be clarified in terms of errors, fixes, and additional audit fees.

Control systems are needed for cost, risk, quality, communication, time, change, procurement,
and human resources. In addition, auditors should consider how important the projects are to
the financial statements, how reliant the stakeholders are on controls, and how many controls
exist. Auditors should review the development process and procedures for how they are
implemented. The process of development and the quality of the final product may also be
assessed if needed or requested. A business may want the auditing firm to be involved
throughout the process to catch problems earlier on so that they can be fixed more easily. An
auditor can serve as a controls consultant as part of the development team or as an independent
auditor as part of an audit.

Businesses sometimes use formal systems development processes. These help assure that
systems are developed successfully. A formal process is more effective in creating strong
controls, and auditors should review this process to confirm that it is well designed and is
followed in practice. A good formal systems development plan outlines:

• A strategy to align development with the organization’s broader objectives

• Standards for new systems
• Project management policies for timing and budgeting
• Procedures describing the process
• Evaluation of quality of change

7.8 EARNED VALUE MANAGEMENT

Earned value management (EVM), or Earned value project/performance management (EVPM)

is a project management technique for measuring project performance and progress in an
objective manner. Because EVM has the ability to combine measurements of: scope, schedule,
and cost, in a single integrated system, Earned Value Management is able to provide accurate
forecasts of project performance problems, which is an important contribution for project
management.

Early EVM research showed that the areas of planning and control are significantly impacted
by its use; and similarly, using the methodology improves both scope definition as well as the
analysis of overall project performance. More recent research studies have shown that the
principles of EVM are positive predictors of project success. Popularity of EVM has grown
significantly in recent years beyond government contracting, in which sector its importance
continues to rise, in part because EVM can also surface in and help substantiate contract
disputes.

Essential features of any EVM implementation include

• a project plan that identifies work to be accomplished,

• a valuation of planned work, called Planned Value (PV) or Budgeted Cost of Work
Scheduled (BCWS), and
• pre-defined “earning rules” (also called metrics) to quantify the accomplishment of
work, called Earned Value (EV) or Budgeted Cost of Work Performed (BCWP).

EVM implementations for large or complex projects include many more features, such as
indicators and forecasts of cost performance (over budget or under budget) and schedule
performance (behind schedule or ahead of schedule). However, the most basic requirement of
an EVM system is that it quantifies progress using PV and EV.

Project tracking without EVM

It is helpful to see an example of project tracking that does not include earned value
performance management. Consider a project that has been planned in detail, including a time-
phased spend plan for all elements of work. Figure 1 shows the cumulative budget (cost) for
this project as a function of time (the blue line, labeled PV). It also shows the cumulative actual
cost of the project (red line) through week 8. To those unfamiliar with EVM, it might appear
that this project was over budget through week 4 and then under budget from week 6 through
week 8. However, what is missing from this chart is any understanding of how much work has
been accomplished during the project. If the project were actually completed at week 8, then
the project would actually be well under budget and well ahead of schedule. If, on the other
hand, the project is only 10% complete at week 8, the project is significantly over budget and
behind schedule. A method is needed to measure technical performance objectively and
quantitatively, and that is what EVM accomplishes.

Project tracking with EVM

Consider the same project, except this time the project plan includes pre-defined methods of
quantifying the accomplishment of work. At the end of each week, the project manager
identifies every detailed element of work that has been completed, and sums the PV for each
of these completed elements. Earned value may be accumulated monthly, weekly, or as
progress is made.

Earned value (EV)

Figure 2 shows the EV curve (in green) along with the PV curve from Figure 1. The chart
indicates that technical performance (i.e., progress) started more rapidly than planned, but
slowed significantly and fell behind schedule at week 7 and 8. This chart illustrates the schedule
performance aspect of EVM. It is complementary to critical path or critical chain schedule
management.

Figure 3 shows the same EV curve (green) with the actual cost data from Figure 1 (in red). It
can be seen that the project was actually under budget, relative to the amount of work
accomplished, since the start of the project. This is a much better conclusion than might be
derived from Figure 1.

Figure 4 shows all three curves together – which is a typical EVM line chart. The best way to
read these three-line charts is to identify the EV curve first, then compare it to PV (for schedule
performance) and AC (for cost performance). It can be seen from this illustration that a true
understanding of cost performance and schedule performance relies first on measuring
technical performance objectively. This is the foundational principle of EVM.

Schedule variance (SV)

SV greater than 0 is good (ahead of schedule). The SV will be 0 at project completion because
then all of the planned values will have been earned.
Schedule performance index (SPI)

SPI greater than 1 is good (ahead of schedule).

In addition to using BCWS and BCWP, prior to 1998 implementations often use the term
Actual Cost of Work Performed (ACWP) instead of AC. Additional acronyms and formulas
include:

Budget at completion (BAC): The total planned value (PV or BCWS) at the end of the project.
If a project has a Management Reserve (MR), it is typically not included in the BAC, and
respectively, in the Performance Measurement Baseline.
Cost variance (CV)

CV greater than 0 is good (under budget).

Cost Performance Index (CPI)

CPI greater than 1 is good (under budget):

< 1 means that the cost of completing the work is higher than planned (bad);
= 1 means that the cost of completing the work is right on plan (good);
> 1 means that the cost of completing the work is less than planned (good or sometimes bad).

Having a CPI that is very high (in some cases, very high is only 1.2) may mean that the plan
was too conservative, and thus a very high number may in fact not be good, as the CPI is being
measured against a poor baseline. Management or the customer may be upset with the planners
as an overly conservative baseline ties up available funds for other purposes, and the baseline
is also used for manpower planning.

Estimate at completion (EAC)

EAC is the manager's projection of total cost of the project at completion.

Estimate to complete (ETC)

ETC is the estimate to complete the remaining work of the project.

To-complete performance index (TCPI)

The TCPI provides a projection of the anticipated performance required to achieve either the
BAC or the EAC. TCPI indicates the future required cost efficiency needed to achieve a target
BAC (Budget At Complete) or EAC (Estimate At Complete). Any significant difference
between CPI, the cost performance to date, and the TCPI, the cost performance needed to meet
the BAC or the EAC, should be accounted for by management in their forecast of the final cost.

For the TCPI based on BAC (describing the performance required to meet the original BAC
budgeted total):

or for the TCPI based on EAC (describing the performance required to meet a new, revised
budget total EAC):

Independent estimate at completion (IEAC)

The IEAC is a metric to project total cost using the performance to date to project overall
performance. This can be compared to the EAC, which is the manager's projection.

Limitations

EVM has no provision to measure project quality, so it is possible for EVM to indicate a project
is under budget, ahead of schedule and scope fully executed, but still have unhappy clients and
ultimately unsuccessful results. In other words, EVM is only one tool in the project manager's
toolbox.
Because EVM requires quantification of a project plan, it is often perceived to be inapplicable
to discovery-driven or Agile software development projects. For example, it may be impossible
to plan certain research projects far in advance, because research itself uncovers some
opportunities (research paths) and actively eliminates others. However, another school of
thought holds that all work can be planned, even if in weekly timeboxes or other short
increments. Thus, the challenge is to create agile or discovery-driven implementations of the
EVM principle, and not simply to reject the notion of measuring technical performance
objectively. (See the lightweight implementation for small projects, described above).
Applying EVM in fast-changing work environments is, in fact, an area of project management
research.

Traditional EVM is not intended for non-discrete (continuous) effort. In traditional EVM
standards, non-discrete effort is called “level of effort" (LOE). If a project plan contains a
significant portion of LOE, and the LOE is intermixed with discrete effort, EVM results will
be contaminated. This is another area of EVM research.

Traditional definitions of EVM typically assume that project accounting and project network
schedule management are prerequisites to achieving any benefit from EVM. Many small
projects don't satisfy either of these prerequisites, but they too can benefit from EVM, as
described for simple implementations, above. Other projects can be planned with a project
network, but do not have access to true and timely actual cost data. In practice, the collection
of true and timely actual cost data can be the most difficult aspect of EVM. Such projects can
benefit from EVM, as described for intermediate implementations, above, and Earned
Schedule.

7.9 PROJECT ACCOUNTING

Project accounting (sometimes referred to as job cost accounting) is the practice of creating
financial reports specifically designed to track the financial progress of projects, which can
then be used by managers to aid project management.
Standard accounting is primarily aimed at monitoring financial progress of organizational
elements (geographical or functional departments, divisions and the enterprise as a whole) over
defined time periods (typically weeks, months, quarters and years).
Projects differ in that they frequently cross organizational boundaries, may last for anything
from a few days or weeks to a number of years, during which time budgets may also be revised
many times. They may also be one of a number of projects that make up a larger overall project
or program.
Consequently, in a project management environment costs (both direct and overhead) and
revenues are also allocated to projects, which may be subdivided into a work breakdown
structure, and grouped together into project hierarchies. Project accounting permits reporting
at any such level that has been defined, and often allows comparison with historical as well as
current budgets.
Project accounting is commonly used by government contractors, where the ability to account
for costs by contract (and sometimes contract line item, or CLIN) is usually a requirement for
interim payments.
Percentage-of-completion is frequently independently assessed by a project manager. Funding
advances and actual-to-budget cost variances are calculated using the project budget adjusted
to percent-of-completion.
Where labor costs are a significant portion of overall project cost, it is usually necessary for
employees to fill out a timesheet in order to generate the data to allocate project costs.
The capital budget processes of corporations and governments are chiefly concerned with
major investment projects that typically have upfront costs and longer term benefits.
Investment go / no-go decisions are largely based on net present value assessments. Project
accounting of the costs and benefits can provide crucially important feedback on the quality of
these important decisions.
An interesting specialized form of project accounting is production accounting, which tracks
the costs of individual movie and television episode film production costs. A movie studio will
employ production accounting to track the costs of its many separate projects.

7.10 PROJECT RESOURCE MANAGEMENT

A successful Project Manager must effectively manage the resources assigned to the project.
This includes the labor hours of the designers, the builders, the testers and the inspectors on the
project team. It also include managing any labor subcontracts. However, managing project
resources frequently involves more than people management. The project manager must also
manage the equipment used for the project and the material needed by the people and
equipment assigned to the project.

• People
Project employees, vendor staff, subcontract labor
• Equipment
Cranes, trucks, backhoes, other heavy equipment or Development, test, and staging servers,
CD burners or Recording studio, tape decks, mixers, microphones and speakers
• Material
Concrete, pipe, rebar, insulation or CD blanks, computers, jewel cases, instruction manuals

Managing the people resources means having the right people, with the right skills and the
proper tools, in the right quantity at the right time. It also means ensuring that they know what
needs to be done, when, and how. And it means motivating them to take ownership in the
project too.

Managing direct employees normally means managing the senior person in each group of
employees assigned to your project. Remember that these employees also have a line manager
to whom they report and from whom the usually take technical direction. In a matrix
management situation, like a project team, your job is to provide project direction to them.
Managing labor subcontracts usually means managing the team lead for the subcontracted
workers, who in turn manages the workers.

The equipment you have to manage as part of your project depends on the nature of the project.
A project to construct a frozen food warehouse would need earth moving equipment, cranes,
and cement trucks. For a project to release a new version of a computer game, the equipment
would include computers, test equipment, and duplication and packaging machinery. The
project management key for equipment is much like for people resources. You have to make
sure you have the right equipment in the right place at the right time and that it has the supplies
it needs to operate properly.

Most projects involve the purchase of material. For a frozen food warehouse, this would be
freezers, the building HVAC machinery and the material handling equipment. For a project to
release a music CD by a hot new artist, it would include the CD blanks, artwork for the jewel
case, and press releases to be sent to deejays. The project management issue with supplies is to
make sure the right supplies arrive at the right time (we'll talk about the right price later).

All your skill in managing resources won't help, however, unless you can stick to the project
schedule. Time management is critical in successful project management.
Often a Project Manager is evaluated on his or her ability to complete a project within budget.
If you have effectively managed the project resources and project schedule, this should not be
a problem. It is, however, a task that requires the project manager's careful attention. You can
only manage effectively a limited number of cost items, so focus on the critical ones (see the
80-20 Rule in the sidebar).

• Costs
Estimated, actual, variability
• Contingencies
Weather, suppliers, design allowance
• Profit
Cost, contingencies, remainder

Each project task will have a cost, whether it is the cost of the labor hours of a computer
programmer or the purchase price of a cubic yard of concrete. In preparing the project budget,
each of these costs is estimated and then totaled. Some of these estimates will be more accurate
than others. A company knows what it will charge each of its projects for different
classifications of labor. Commodities like concrete are priced in a very competitive market so
prices are fairly predictable. Other estimates are less accurate. For instance, the cost of a
conveyor system with higher performance specifications that normal can be estimated to be
more expensive, but it is hard to determine whether it will be 10% more or 15% more. For an
expensive item, that can be a significant amount.

When the estimated cost of an item is uncertain, the project budget often includes a design
allowance. This is money that is set aside in the budget "just in case" the actual cost of the item
is wildly different than the estimate.

Unusual weather or problems with suppliers are always a possibility on large projects.
Companies usually include a contingency amount in the project budget to cover these kinds of
things.

So a project budget is composed of the estimated cost, plus the contingency and design
allowance, plus any profit. The project manager's job is to keep the actual cost at or below the
estimated cost, to use as little of the design allowance and contingency as possible, and to
maximize the profit the company earns on the project.
To maximize your chances of meeting your project budget, meet your project schedule. The
most common cause of blown budgets is blown schedules. Meeting the project schedule won't
guarantee you will meet the project budget, but it significantly increases your chances. And
above all, manage the project scope. Don't allow the project scope to "creep" upward without
getting budget and/or schedule adjustments to match.

Successful project management is an art and a science that takes practice. The ideas presented
above can give you a basic understanding of project management, but consider it only a
beginning. If your job or career path includes project management, and you want to improve
your skills, talk to successful project managers, read, and practice. Project management can be
a very rewarding career.

7.11 RESOURCE LEVELING

Resource leveling is a project management technique used to examine unbalanced use of

resources (usually people or equipment) over time, and for resolving over-allocations or
conflicts.

When performing project planning activities, the manager will attempt to schedule certain
tasks simultaneously. When more resources such as machines or people are needed than are
available, or perhaps a specific person is needed in both tasks, the tasks will have to be
rescheduled concurrently or even sequentially to manage the constraint. Project planning
resource leveling is the process of resolving these conflicts. It can also be used to balance the
workload of primary resources over the course of the project[s], usually at the expense of one
of the traditional triple constraints (time, cost, scope).
When using specially designed project software, leveling typically means resolving conflicts
or over allocations in the project plan by allowing the software to calculate delays and update
tasks automatically. Project management software leveling requires delaying tasks until
resources are available. In more complex environments, resources could be allocated across
multiple, concurrent projects thus requiring the process of resource leveling to be performed at
company level.
In either definition, leveling could result in a later project finish date if the tasks affected are
in the critical path.
Resource Leveling is also useful in the world of maintenance management. Many
organizations have maintenance backlogs. These backlogs consist of work orders. In a "planned
state" these work orders have estimates such as 2 electricians for 8 hours. These work orders
have other attributes such as report date, priority, asset operational requirements, and safety
concerns. These same organizations have a need to create weekly schedules. Resource-leveling
can take the "work demand" and balance it against the resource pool availability for the given
week. The goal is to create this weekly schedule in advance of performing the work. Without
resource-leveling the organization (planner, scheduler, supervisor) is most likely performing
subjective selection. For the most part, when it comes to maintenance scheduling, there are
very few logic ties and therefore no need to calculate critical path and total float.
Using the Project resource leveling function is the quickest way to level your resources. When
Project levels your resources, it goes through a series of decisions about each of the tasks in
your schedule to determine whether they can be delayed or split in order to alleviate the
resource over allocations.
The following factors are examined to determine which tasks should be delayed or split:
Available slack.
Task duration.
Task's constraints.
Task ID.
Task priority.
Task dependencies.
Scheduling dates.

Resource information is also examined in the leveling process:

Resource availability as shown in the working time calendar
Resource availability as shown by maximum units.
Resource assignment units on the task.

When Project levels resources, it only delays or splits tasks. It does not:
Reassign tasks. For example, Chris would not be substituted for Pat.
Optimize a resource's allocation. Because leveling does not move tasks earlier or reassign units,
a resource flagged as overallocated might become under allocated as a result of leveling. For
example, suppose Sean is set up for maximum units of 100 percent, and he's assigned to one
task at 60 percent and another task during the same time period at 50 percent. Leveling would
move at least one of these assignments out so they're not happening at the same time. As a
result, Sean would probably become under allocated.
Reassign units. For example, if Jane is assigned to work on two tasks that are both scheduled
at the same time, leveling won't change Jane's units so that she works on both tasks at 50
percent.
Level material resources.
Level generic resources.
We can have Project level only selected resources. You can also have Project level resources
shared across multiple projects.

7.12 SUMMARY
A project schedule makes project schedule after we have a work breakdown structure (WBS),
an effort estimate for each task, and a resource list with availability for each resource. Because
of the uncertainty involved, the schedule is reviewed regularly, and it is often revised while the
project is in progress. It continues to develop as the project moves forward, changes arise, risks
come and go, and new risks are identified. The schedule essentially transforms the project from
a vision to a time-based plan.

Several types of inputs required to create a project schedule are as per following: Personal and
project calendars, Description of project scope, Project risks, Lists of activities and resource
requirements,
A project manager should be aware of deadlines and resource availability issues that may
make the schedule less flexible.

Most projects should be scheduled from a start date. However, scheduling from the finish date
can be useful for determining when a project must start if it must finish on a specific date. We
can change various task and resource information to see what effect it has on the project's start
date and determine the optimum project start date.
We must schedule a project from a start date or from a finish date; it cannot be scheduled from
both start and finish dates. We pick which date we want to use (normally a start date), and
Project schedules the other date (normally a finish date).
When we need to control the start or finish date of a task, we can add a constraint to the task.
Flexible constraints work with task dependencies to make a task occur as soon or as late as the
task dependencies will allow. For example, a task with an As Soon As Possible (ASAP)
constraint and a finish-to-start dependency will be scheduled as soon as the predecessor task
finishes.
Project controlling should be established as an independent function in project management. It
implements verification and controlling function during the processing of a project in order to
reinforce the defined performance and formal goals. The tasks of project controlling are also:

• The creation of infrastructure for the supply of the right information and its update
• The establishment of a way to communicate disparities of project parameters
• The development of project information technology based on an intranet or the
determination of a project key performance index system (kpi)
• Divergence analyses and generation of proposals for potential project regulations
• The establishment of methods to accomplish an appropriate the project structure,
project workflow organization, project control and governance
• Creation of transparency among the project parameters

Fulfillment and implementation of these tasks can be achieved by applying specific methods
and instruments of project controlling. The following methods of project controlling can be
applied:

• Investment analysis
• Cost–benefit analyses
• Value benefit analysis
• Expert surveys
• Simulation calculations
• Risk-profile analyses
• Surcharge calculations
• Milestone trend analysis
• Cost trend analysis
• Target/actual-comparison

A successful Project Manager must effectively manage the resources assigned to the project.
This includes the labor hours of the designers, the builders, the testers and the inspectors on the
project team. It also include managing any labor subcontracts. However, managing project
resources frequently involves more than people management. The project manager must also
manage the equipment used for the project and the material needed by the people and
equipment assigned to the project.
 7.13 KEY WORDS
• Concurrent Project management - Concurrent project management refers to an approach
used in project management in which functions of different sequential functions are
integrated to reduce the elapsed time required to bring a new product to the market. This is
having its origins from concurrent engineering.
• Project Crashing - Project crashing is a method for shortening the project duration by
reducing the time of one or more of the critical project activities to less than its normal
activity time. The object crashing is to reduce project duration while minimizing the cost
of crashing.
• Earned value management - Earned value management (EVM), or Earned value
project/performance management (EVPM) is a project management technique for
measuring project performance and progress in an objective manner.
• Project Accounting - Project accounting (sometimes referred to as job cost accounting) is
the practice of creating financial reports specifically designed to track the financial progress
of projects, which can then be used by managers to aid project management.
• Resource leveling - Resource leveling is a project management technique used to examine
unbalanced use of resources (usually people or equipment) over time, and for resolving
over-allocations or conflicts.
 UNIT 8 PROJECT QUALITY

Objective
After reading this unit you would be able to:

• Differentiate between different costs of quality;

• Identify costs related to project quality;
• Do the project quality control;
• Prepare quality plan for projects;
• Manage project quality.

Structure
8.1 Introduction to project quality
8.2 Understanding quality
8.3 Cost of quality
8.4 Project quality costs
8.5 Dimensions of project quality
8.6 Project quality plan
8.7 Components of a project quality plan
8.8 Planning for project quality
8.9 Quality control in projects
8.10 Implementing quality control
8.11 Total quality management
8.12 Iso standard on project management
8.13 Summary
8.14 Key words

8.1 INTRODUCTION TO PROJECT QUALITY

Every project delivers something at the end of the project execution. When it comes to the
project initiation, the project management and the client collaboratively define the objectives
and the deliveries of the project together with the completion timelines.

During the project execution, there are a number of project deliveries made. All these deliveries
should adhere to certain quality standards (industry standards) as well as specific client
requirements.

Therefore, each of these deliveries should be validated and verified before delivering the client.
For that, there should be a quality assurance function which runs from start to the end of the
project. In this unit, we will look at the concepts in respect of quality related to projects.

8.2 UNDERSTANDING QUALITY

Quality in business, engineering and manufacturing has a pragmatic interpretation as the non-
inferiority or superiority of something; it is also defined as fitness for purpose. Quality is a
perceptual, conditional and somewhat subjective attribute and may be understood differently
by different people. Consumers may focus on the specification quality of a product/service, or
how it compares to competitors in the marketplace. Producers might measure the conformance
quality, or degree to which the product/service was produced correctly. Support personnel may
measure quality in the degree that a product is reliable, maintainable, or sustainable.

There are five aspects of quality in a business context:

• Producing - providing something.
• Checking - confirming that something has been done correctly.
• Quality Control - controlling a process to ensure that the outcomes are predictable.
• Quality Management – directing an organization so that it optimizes its performance
through analysis and improvement.
• Quality Assurance – obtaining confidence that a product or service will be satisfactory.
(Normally performed by a purchaser)

Quality applied in these forms was mainly developed by the procurement directorates of
NASA, the military and nuclear industries from the 1960's and this is why so much emphasis
was placed on Quality Assurance. The original versions of Quality Management System
Standards (eventually merged to ISO 9001) were designed to contract manufacturers to
produce better products, consistently and were focused on Producing, Checking and Quality
Control.

The subsequent move of the Quality sector towards management systems can be clearly seen
by the aggregation of the product quality requirements into one eighth of the current version of
ISO 9001. This increased focus on Quality Management has promoted a general perception
that quality is about procedures and documentation. Similar experiences can be seen in the
areas of Safety Management Systems and Environmental Management Systems.

The emergence of tools like Asset Optimization and 6 sigma is an interesting development in
the application of quality principles in business.

Managing quality is fundamental to any activity and having a clear understanding of the five
aspects, measuring performance and taking action to improve is essential to an organisations
survival and growth.

The common element of the business definitions is that the quality of a product or service
refers to the perception of the degree to which the product or service meets the customer's
expectations. Quality has no specific meaning unless related to a specific function and/or
object. Quality is a perceptual, conditional and somewhat subjective attribute.

The business meanings of quality have developed over time. Various interpretations are given
below:
American Society for Quality: "A subjective term for which each person has his or her own
definition. In technical usage, quality can have two meanings:
• The characteristics of a product or service that bear on its ability to satisfy stated or
implied needs;
• A product or service free of deficiencies."

Philip B. Crosby: "Conformance to requirements." The requirements may not fully represent
customer expectations; Crosby treats this as a separate problem.
W. Edwards Deming: concentrating on "the efficient production of the quality that the market
expects," and he linked quality and management: "Costs go down and productivity goes up as
improvement of quality is accomplished by better management of design, engineering, testing
and by improvement of processes."

Peter Drucker: "Quality in a product or service is not what the supplier puts in. It is what the
customer gets out and is willing to pay for."

ISO 9000: "Degree to which a set of inherent characteristics fulfills requirements." The
standard defines requirement as need or expectation.

Joseph M. Juran: "Fitness for use." Fitness is defined by the customer.

Six Sigma: "Number of defects per million opportunities."

Genichi Taguchi: "Uniformity around a target value." The idea is to lower the standard
deviation in outcomes, and to keep the range of outcomes to a certain number of standard
deviations, with rare exceptions.

"The loss a product imposes on society after it is shipped." This definition of quality is based
on a more comprehensive view of the production system.

8.3 COST OF QUALITY

In process improvement efforts, quality costs or cost of quality is a means to quantify the
total cost of quality-related efforts and deficiencies. It was first described by Armand V.
Feigenbaum in a 1956 Harvard Business Review article.
 Prior to its introduction, the general perception was that higher quality requires higher costs,
either by buying better materials or machines or by hiring more labor. Furthermore, while
cost accounting had evolved to categorize financial transactions into revenues, expenses,
and changes in shareholder equity, it had not attempted to categorize costs relevant to
quality, which is especially important given that most people involved in manufacturing
never set hands on the product. By classifying quality-related entries from a company's
general ledger, management and quality practitioners can evaluate investments in quality
based on cost improvement and profit enhancement Feigenbaum defined the following
quality cost areas:

Cost area Description Examples

• Quality planning
• Statistical process
control
• Investment in
quality-related
information
systems
Prevention Arise from efforts to keep
• Quality training and
costs defects from occurring at all
workforce
development
• Product-design
verification
• Systems
Costs of control development and
(Costs of management
conformance) • Test and inspection
of purchased
materials
• Acceptance testing
• Inspection
• Testing
Appraisal Arise from detecting defects • Checking labor
costs via inspection, test, audit • Setup for test or
inspection
• Test and inspection
equipment
• Quality audits
• Field testing

Arise from defects caught • Scrap

Internal internally and dealt with by • Rework
Costs of failure of failure costs discarding or repairing the • Material
control (Costs of non- defective items procurement costs
conformance)
External Arise from defects that • Complaints in
failure costs actually reach customers warranty
 • Complaints out of
warranty
• Product service
• Product liability
• Product recall
• Loss of reputation

The central theme of quality improvement is that larger investments in prevention drive even
larger savings in quality-related failures and appraisal efforts. Feigenbaum's categorization
allows the organization to verify this for itself. When confronted with mounting numbers of
defects, organizations typically react by throwing more and more people into inspection roles.
But inspection is never completely effective, so appraisal costs stay high as long as the failure
costs stay high. The only way out of the predicament is to establish the "right" amount of
prevention.

Once categorized, quality costs can serve as a means to measure, analyze, budget, and predict.

Variants of the concept of quality costs include cost of poor quality and categorization based
on account type, described by Joseph M. Juran.

Cost area Examples

• Materials scrapped or junked

• Labor and burden on product scrapped or junked
• Labor, materials, and burden necessary to effect repairs on
salvageable product
Tangible costs—factory • Extra operations added because of presence of defectives
accounts • Burden arising from excess production capacity
necessitated by defectives
• Excess inspection costs
• Investigation of causes of defects

• Discount on seconds
Tangible costs—sales • Customer complaints
accounts • Charges to quality guarantee account

• Delays and stoppages caused by defectives

Intangible costs • Customer good will
• Loss in morale due to friction between departments

ISO 9004 also accounts for "external assurance" quality costs to account for customer– or
government–required certifications (e.g., for UL, RoHS, or even ISO 9000 itself).
 8.4 PROJECT QUALITY COSTS

Rework has become an endemic feature of the procurement process in construction, which
invariably leads to time and cost overruns in projects. Thus, in order to improve the
performance of projects it is necessary to identify the causes and costs of rework.

The case study projects’ rework costs were found to be 3.15 per cent and 2.4 per cent of their
contract value. Changes initiated by the client and end-user, as well as errors and omissions in
contract documentation, were found to be the primary causes of rework. (Peter E D Love,
Amrik S Sohal, 2003)

Research undertaken by Cnuddle (1991) determined the failure costs in construction by

investigating the amount of nonconformances that occurred on-site. Cnuddle (1991) found non-
conformance cost to be between 10 per cent and 20 per cent of the total project cost.
Furthermore, it was found that 46 per cent of total deviation costs were created during design,
compared to 22 per cent for construction deviations.

The Building Research Establishment in the UK (BRE, 1981) found that errors in buildings
had 50 per cent of their origin in the design stage and 40 per cent in the construction stage. In
1987 the National Economic Development Office conducted a survey (NEDO, 1987), which
aimed to identify ways of improving quality control in building works. It was revealed that the
main factors that influenced quality were attributed to design (e.g. lack of coordination of
design, unclear and missing documentation) and poor workmanship (e.g. lack of care and
knowledge). A further study was undertaken again by NEDO in 1988, and these findings were
almost identical to the previous year’s study.

The costs of quality deviations in civil and heavy industrial engineering projects have been
found to be significantly higher. Burati et al. (1992) studied nine major engineering projects to
determine the cost associated with correcting deviations to meet specified requirements. The
results of their study indicated that, for all nine projects, quality deviations accounted for an
average of 12.4 per cent of the contract value.

A significantly lower figure was reported by Abdul-Rahman (1995), who found non-
conformance costs (excluding material wastage and head office overheads) in a highway
project to be 5 per cent of the contract value. Abdul-Rahman (1995) specifically makes the
points that the non-conformance costs may have been significantly higher in projects where
poor quality management is implemented.

Notably, Nylen (1996) found that when poor quality management practices were implemented
in a railway project, quality failures were found to be 10 per cent of the contract value. Nylen
(1996) further found that 10 per cent of the quality failures that were experienced accounted
for 90 per cent of their total cost. Here significant proportions of the quality failures were
attributable to design-related (76 per cent) issues, such as erroneous documentation and poor
communication between project team members.

According to Davis et al. (1989), without a formal systematic quality management system in
place, quality deviations may not be identifiable. Consequently, information is lost and
activities that need to be improved in order to reduce or eliminate rework cannot be ascertained.
Similarly, the BRE (1982) in the LTK has demonstrated that significant cost benefits can be
achieved by implementing a quality management system. The BRE stated that 15 per cent
savings on total construction costs could be achieved through eliminating rework, and by
spending more time and money on prevention. For example, additional time spent upstream by
designers (architects and engineers) on co-coordinating project documentation could
significantly reduce downstream quality costs during on-site production, which may ultimately
improve project performance. It is proffered that learning to design quality into internal
processes may enable designers to yield first time quality on a regular basis, which may reduce
their rework and thus improve interorganisational processes.

When it comes to the quality, not only the quality of the deliveries that matter the most. The
processes or activities that produce deliverables should also adhere to certain quality guidelines
as well.

As a principle, if the processes and activities that produce the deliverables do not adhere to
their own quality standards (process quality standards), then there is a high probability that
deliverables not meeting the delivery quality standards.

To address all the quality requirements, standards, and quality assurance mechanisms in a
project, a document called 'project quality plan' is developed by the project team. This plan acts
as the quality bible for the project and all the stakeholders of the project should adhere to the
project quality plan.
 8.5 DIMENSIONS OF PROJECT QUALITY

• Performance - the primary operating characteristics.

• Features - optional extras (the "bells" and "whistles")
• Reliability - likelihood of breakdown
• Conformance - conformance to specification
• Technical durability - length of time before the product becomes obsolete
• Serviceability - ease of service
• Aesthetics - look, smell, feel, taste
• Perceived quality - reputation
• Value for money

Quality management incorporates not just the product(s) of the project, but also the
management of the project itself. Quality management consists of three key areas: quality
planning, quality assurance, and quality control.

8.6 PROJECT QUALITY PLAN

Project quality plan is one of the mandatory documents for any type of project.
As long as a project has defined objectives and deliverables, there should be a project quality
plan to measure the delivery and process quality.

Go with prevention rather than cure.

Costs of Prevention Costs of Defects
Additional planning Scrap
Education/training of team and stakeholders Rework
Inspection and testing of internal/external
Repair
deliverables of project
Improved designs for quality purposes Replacement of defective parts and inventory
Quality staff Repairs after delivery of product
Loss of future business with stakeholder or with
Quality audits
those relating to stakeholder
Quality plan and execution Legal issues for conformance
Liability for defect
Risk to life and property

8.7 COMPONENTS OF A PROJECT QUALITY PLAN

Depending on the nature of the industry and the nature of the project, the components or the
areas addressed by a quality plan may vary. However, there are some components that can be
found in any type of quality plan.

Let's have a look at the most essential attributes of a project quality plan.
Responsibility of Management

This describes how the management is responsible for achieving the project quality. Since
management is the controlling and monitoring function for the project, project quality is mainly
a management responsibility.

Document Management and Control

Documents are the main method of communication in project management. Documents are
used for communication between the team members, project management, senior management,
and the client. Therefore, the project quality plan should describe a way to manage and control
the documents used in the project. Usually, there can be a common documentation repository
with controlled access in order to store and retrieve the documents.

Requirements Scope

The correct requirements to be implemented are listed here. This is an abstraction of the
requirements sign-off document. Having requirements noted in the project quality plan helps
the quality assurance team to correctly validate them. This way, quality assurance function
knows what exactly to test and what exactly to leave out from the scope. Testing the
requirements that are not in the scope maybe a waste for the services provider.

Design Control

This specifies the controls and procedures used for the design phase of the project. Usually,
there should be design reviews in order to analyse the correctness of the proposed technical
design. For fruitful design reviews, senior designers or the architects of the respective domain
should get involved. Once the designs are reviewed and agreed, they are signed-off with the
client. With the time, the client may come up with changes to the requirements or new
requirements. In such cases, designed maybe changed. Every time the design changes, the
changes should be reviewed and signed-off.

Development Control and Rigor

Once the construction of the project starts, all the processes, procedures, and activities should
be closely monitored and measured. By this type of control, the project management can make
sure that the project is progressing in the correct path.

Testing and Quality Assurance

This component of the project quality plan takes precedence over other components. This is
the element which describes the main quality assurance functions of the project. This section
should clearly identify the quality objectives for the project and the approach to achieve them.
.

Risks & Mitigation

This section identifies the project quality risks. Then, the project management team should
come up with appropriate mitigation plans in order to address each quality risk.
Quality Audits

For every project, regardless of its size or the nature, there should be periodic quality audits to
measure the adherence to the quality standards. These audits can be done by an internal team
or an external team.

Sometimes, the client may employ external audit teams to measure the compliance to standards
and procedures of the project processes and activities.

Defect Management

During testing and quality assurance, defects are usually caught. This is quite common when it
comes to software development projects. The project quality plan should have guidelines and
instructions on how to manage the defects.

Training Requirements

Every project team requires some kind of training before the project commences. For this, a
skill gap analysis is done to identify the training requirements at the project initiation phase. .

The project quality plan should indicate these training requirements and necessary steps to get
the staff trained.

Ensuring Quality throughout the Project

As your project moves along through each process group, over hurdles, and through barriers,
you’ll need a proven system to check the quality of your progress. You may subscribe to any
one of multiple theories in the world of project management to test the quality of your project.
All of these theories, however, have one common thread: work completed must be proven to
be in alignment with the project deliverables. This is scope verification—the process of
ensuring that the project is creating what the customer has asked for.

For example, a project to create a new application for an organization will have several
milestones in its path to completion. The desired deliverable of this project is that the
application will allow users to submit HR forms through a company web site. The project
manager can check the work in progress to verify that it is in alignment with the project
deliverable. Should the work be out of alignment, the project manager must take immediate
corrective actions to nudge the work back on track.

8.8 PLANNING FOR PROJECT QUALITY

Quality planning is a process to determine which quality standards are relevant to the project,
and how they can be implemented. Planning for quality is a fundamental exercise in the
planning phase—each deliverable must have metrics that prove its quality. In IT, this can be
bandwidth, latency, database accuracy, the speed of an application, and more.
Your organization may have a quality policy that dictates the expectations of a project in regard
to quality, how the expectations are measured, and what the outcomes of those measurements
should be. This quality policy is considered and applied to the project scope, which is important
because the project scope contains all of the work your project will undertake. What good is a
quality policy if it’s not implemented with the project work?

Depending on your organization, you may also have relevant standards and regulations that
will serve as input to your quality planning. A regulation is a law or practice that is not optional
in your industry. For example, the health care industry has the Health Insurance Portability
and Accountability Act (HIPAA) regulations as well as other regulations it has to be abide by.
A standard, on the other hand, is a rule or generally accepted practice within an industry. For
example, most software application windows close using some button in the upper-right hand
corner. While there’s no law that says this is a must, it’s a generally accepted standard
regardless of the application or operating system.

When you’re planning for quality, there are five major approaches you can rely on:

Benefit-Cost Analysis
Within every project, there will be a demand for quality—and a cost to reach that demand. A
benefit-cost analysis considers the cost to reach the level of quality in relation to the benefits
of obtaining the quality. For example, a customer may demand that a series of databases
provide 100-percent accuracy 24/7. While this seems good, the synchronization of multiple
databases after each change may result in a very costly solution. Instead of the expensive 100-
percent solution, a better solution, for example, may be a less costly approach that ensures 98-
percent accuracy.

Benchmarking
This approach uses other projects as a measure of performance on your current project. It
examines the deliverables, the project management processes, and the successes and failures
within each project to measure how the current project is performing. The problem with the
approach, especially in IT projects, is that unless the nature of the IT projects is the same, it’s
difficult to use. You can’t measure the performance metrics of a project to develop an
application against the metrics of a project to create a new network. Additionally, because
technology is changing so rapidly, benchmarks that were applicable 18 months ago are very
likely outdated and inappropriate.

Flowcharting
Flowcharting shows how the components within a system are related. This is an ideal approach
within IT. Consider an application that follows a client-server model. The front end and the
back end application must communicate over a network or series of networks. A flowchart can
illustrate the various components, how they interact, and their effect on quality. Another
example of a flowchart is a cause-and-effect diagram to illustrate the causes that are
contributing to the quality defect within the project. These diagrams are also Ishikawa, or
fishbone, diagrams.

Design of Experiments
This approach relies on statistical what-if scenarios to determine which variables within a
project will result in the best outcome. The design of experiments approach is most often used
on the product of the project, rather than the process of the project itself. For example, a project
team creating a new network may experiment with the capacity of the network cable, the
network switches, the routers, and the number of the network cards on the servers to determine
which is the best combination for the best price. Design of experiments is also used as a method
to identify which variables within a project, or product, are causing failures or unacceptable
results.

Cost of Quality Analysis

Cost of quality is the sum of all the costs to achieve the expected quality the customer demands
in the project deliverables. This includes all of the work to conform to the quality requirements
and the expense incurred from nonconformance to the quality requirements. The cost of
nonconformance is most evident when work needs to be redone and there’s wasted materials.
Technically, the cost of quality has three costs: prevention costs, appraisal costs, and failure
costs. Failure costs are associated with what could happen if the project fails: the lack of sales,
loss of customers, product returns, fines and fees, downtime, and so on.

8.9 QUALITY CONTROL IN PROJECTS

As you now know, quality is measured by the end result of a project. Obviously you cannot
wait until the end of a project to determine if quality exists. Quality control (QC) is concerned
with the quality of the actions and deliverables within a project. QC is inspection-driven; QC
reviews the deliverables to establish that the quality expected by the project stakeholders is
present.

QC is also concerned with the root cause of results that are below the quality standards, and
with eliminating the issues that are causing quality to slip so that quality issues are not
repetitive. It focuses not only on the product of a project, but also on the project management
process itself. For example, QC is used to determine why cost and schedule variances have
occurred and what corrective actions can be enforced to ensure the same mistakes don’t happen
again.

QC requires the project manager to have some understanding of statistical analysis, sampling,
and probability to track trends, predict quality results, and determine root causes in quality
issues. Trend analysis is especially useful in projects as most work within an organization is
cyclic. For example, the network servers take a processor hit every morning as users log on to
the network, check their e-mail, and open files. In the afternoon, the proxy servers may have
an increase in Internet traffic as users check the news, the weather, or the traffic for their
commutes home. In an IT project, trend analysis can allow the project team to make educated
decisions on how to react to conditions within the project.

QC must be managed throughout the project. It’s unacceptable to wait until the project is ended
to see if the deliverables are of quality. The project management must get out, look, listen, and
inspect. Throughout the project there are four fundamental facts about quality control:

• Prevention keeps quality errors out of the project. Inspection keeps quality errors away
from the customer.
• Attribute sampling means the results meet the expected quality standards or they don’t.
Variables sampling tracks the level of acceptability of the results over time.
 • Within a project you have special causes where quality excels or diminishes due to
anomalies within the project. Otherwise you expect the results to vary as part of the
project; this typical variance is simply called random causes.
• A tolerance is an acceptable range of quality for the project or deliverable. Control
limits are the outer and upper limits that the quality results must fall within. If results
are within the limits, the project is in control. If the results are out of the limits, it’s
considered to be out of control.

8.10 IMPLEMENTING QUALITY CONTROL

Quality is planned into a project, never inspected in. A goal for any project is to achieve quality
by planning for quality—and then following the plan. But how will you know if quality exists
on a project unless there is accountability? Sure, you could wait until your project is complete
and then test out the deliverables, but that’s a little late. Quality control must happen throughout
the project to ensure that quality exists.

The most accessible method to ensure quality is inspection. Once you inspect the work, you
can measure and react to the evidence you and your project team have found. There are many
different approaches to inspecting the project deliverables. Here are four of the most common:

Peer Review
One approach to QC throughout a project is to use peer review. Peer review, as its name
implies, is the process of allowing team members to review each other’s work. It is an excellent
method to ensure that each team member is completing her work and doing an excellent job.
Peer review provides for many things, including

• Ensuring that each task is checked for quality

• Allowing a team member to show others her work
• Allowing a team member to learn about other areas of the project
• Allowing the project manager to ensure the work is being completed
• Holding the team responsible for the quality of the work completed

The risk involved with peer review QA is that not all team members are up to the challenge of
reviewing another’s work or having their work reviewed by an equal. If you use this approach,
your team members must have confidence in each other’s ability to fairly review other
members’ work, and confidence in their own abilities to complete the assigned tasks.

Statistical Sampling
Statistical sampling is the process of choosing a percentage of results at random. For example,
a project creating a database and web site to sell concert tickets may require a measurement of
database accuracy, the speed of the web site, and the functionality of the overall program. This
testing must be completed on a consistent basis throughout the project, rather than on a hit-
and-miss basis.

Statistical sampling can reduce the costs of QC, but mixed results can follow if an adequate
testing plan and schedule are not followed. The science of statistical sampling, and its
requirements to be effective, is an involved process. There are many books, seminars, and
professionals devoted to the process.
Management by Walking Around
One of the most successful methods for managing quality is to allow yourself to be seen. Get
out of your office and get into the working environment. You don’t have to hover around your
team, but let them know you are available, present, and interested in their work.

So many IT project managers have a fear of being disliked, or seen as typical management, or
consider themselves too important to speak with their team. These less-than-successful project
managers alienate themselves by hiding in their offices, ignoring the opportunity to work with
the project team to ensure quality from the get-go. Don’t let this happen to you! Get involved
with the project team members and make yourself visible.

Reviews by Outside Experts

Hire an outside expert to review the project as it progresses. This approach allows the project
manager, who may not be as skilled as his team on the project’s technology, to ensure the team
is completing the assigned work with care and precision. A consultant can be brought into the
project at key milestones to make an unbiased review of the work done to date. The consultant
can accomplish many things for a project’s success. This practice

• Ensures quality and accuracy

• Allows for an unbiased review by a third party
• Creates accountability for the team completing the work
• Allows the project manager to know the true status of the work
• Allows the project manager to make any needed adjustments

Analyzing Quality
Once you’ve completed the inspection of the project and the product deliverables, now what?
Of course, you’ll be doing QC inspections on a regular basis, so you’ll need to track and analyze
the results. You’ll want to complete root cause analysis to determine why quality issues may
be random or repetitive. There are five major approaches to tracking and analyzing quality:

Using Control Charts

A control chart displays the results of your inspections over time. The results of inspections are
plotted out against a mean, and an upper and a lower control limit. The results of inspections
are measured and then added to the control chart. When results are over the control limit,
they’re out of control; otherwise, the project is acceptable. However, this approach can be a
little tricky in many IT projects. Control charts are best when you have projects that are
extremely repetitive, such as manufacturing and construction projects. That’s not to say that
you still can’t use these charts within IT projects—just be aware that the results of your
measurements may fluctuate as the nature of the work within the project changes. You can use
control charts to track server usage, update, network throughput, and more.

8.11 TOTAL QUALITY MANAGEMENT

No book on project management would be complete without at least a nod to Total Quality
Management (TQM). Total Quality Management is a process that involves all employees
within an organization working to fulfill their customers’ needs while also working to increase
productivity. TQM stems from Dr. W. Edward Deming and his management principles, which
the Japanese adopted after WWII. In the U.S., these principles were readily adopted in the
1980s after proof of their success in Japan.
The leading drive of TQM is a theory called Continuous Quality Improvement. According to
this theory, all practices within an organization are processes, and these processes can be
infinitely improved, which results in better productivity and ultimately higher profitability.

Here’s how this relates to IT project management: the processes a project manager utilizes to
communicate, schedule, and assign resources can be streamlined, improved, and modernized
to make the project easier to implement and more profitable as a whole. Examples include
Microsoft Project Server and other web solutions for project teams.

In project management, the customer is the end user of the deliverable, and the concept of
streamlining processes is dependent on the project manager and the project team. Scores of
books have been written about Total Quality Management, though one of the best books, Out
of the Crisis, is from the concept’s originator, Dr. W. Edwards Deming.

Quality project management as a process is not a magical formula, an equation you can map
out in Excel, or a dissertation from a business professor at Harvard. It is a simple thing to
describe, but fairly difficult to implement. Quality project management comes from the
dedication of the project manager and the project team to completing with gusto the required
activities in each phase to produce an excellent deliverable. Anything less should be
unacceptable.

The knowledge area of project quality management includes the organizational processes that
determine quality policies, objectives, and responsibilities. The PMBOK identifies three
processes for quality management:

• Quality Planning
• Quality Assurance
• Quality Control

Quality Planning

A good quality plan starts with a clear definition of the goal of the project. What is the product
or deliverable supposed to accomplish? What does it look like? What is it supposed to do? How
do you measure customer satisfaction? How do you determine whether or not the project was
successful?

Answering these questions and others will help you identify and define quality goals, allowing
you to discuss the approach and plans needed to achieve those goals. This includes assessing
the risks to success, setting high standards, documenting everything, and defining the methods
and tests to achieve, control, predict and verify success. Be sure to include quality management
tasks in the project plan and delegate these tasks to work groups and/or individuals who will
report and track quality metrics.

Quality Assurance

Quality assurance tests use a system of metrics to determine whether or not the quality plan is
proceeding in an acceptable manner. By using both qualitative and quantitative metrics, you
can effectively measure project quality with customer satisfaction. These tests or quality audits
will help you predict and verify the achievement of goals and identify need for corrective
actions. Additionally, quality assurance tests will help you map quality metrics to quality goals,
allowing you to report on the status of quality at periodic project review meetings.

Quality Control

Quality control involves operational techniques meant to ensure quality standards. This
includes identifying, analyzing, and correcting problems. While quality assurance occurs
before a problem is identified, quality control is reactionary and occurs after a problem has
been identified.

Quality control monitors specific project outputs and determines compliance with applicable
standards. It also identifies project risk factors, their mitigation, and looks for ways to prevent
and eliminate unsatisfactory performance.

8.12 ISO STANDARD ON PROJECT MANAGEMENT

With pressure on business for faster and cheaper results, a new ISO standard for good practice
in project management will increase efficiency and maximize the effect of investments.

ISO 21500:2012, Guidance on project management, can be used by any type of

organization, including public, private or community organizations, and for any type of project,
irrespective of complexity, size and duration.

Project management is now big business. According to the Anderson Economic Group study
commissioned by the Project Management Institute, over 24.4 million employees were
participating in projects in 11 major economies in 2006. By 2016, this demand will exist to
support 32.6 million employees in the same countries.

ISO 21500 provides high-level description of concepts and processes that are considered to
form good practice in project management. New project managers as well as experienced
managers will be able to use the project management guidance in this standard to improve
project success and achieve business results.

Miles Shepherd, Chair of the ISO project committee that developed the new standard, states:
“ISO 21500 enables people in any organization to understand how the discipline fits into a
business environment. It is also intended to be used as a basic guide, aimed at the informed
reader without an in-depth knowledge of project management.”

Additional benefits of ISO 21500 include:

• Encourage transfer of knowledge between projects and organizations for improved
project delivery
• Facilitate efficient tendering processes through the use of consistent project
management terminology
• Enable the flexibility of project management employees and their ability to work on
international projects
• Provide universal project management principles and processes

Karl Best, Secretary of the project committee, comments: “In an increasingly global economy
project managers need guidance to help them understand the basic principles of managing
projects. ISO 21500 can help those involved in projects improve the success of a wide variety
of project types.”
ISO 21500 is the first in a planned family of project management standards. It is designed to
align with related International Standards such as ISO 10006:2003, Quality management
systems − Guidelines for quality management in projects, ISO 10007:2003, Quality
management systems − Guidelines for configuration management, ISO 31000:2009, Risk
management – Principles and guidelines, and some sector-specific standards in industries such
as aerospace and IT.

ISO 21500:2012, Guidance on project management, was developed by ISO project committee
ISO/PC 236, Project management, and is available from ISO national member institutes. It may
also be obtained directly from the ISO Central Secretariat, price 140 Swiss francs respectively
through the ISO Store or by contacting the Marketing, Communication & Information
department.

8.13 SUMMARY

There are five aspects of quality in a business context:

• Producing - providing something.
• Checking - confirming that something has been done correctly.
• Quality Control - controlling a process to ensure that the outcomes are predictable.
• Quality Management – directing an organization so that it optimizes its performance
through analysis and improvement.
• Quality Assurance – obtaining confidence that a product or service will be satisfactory.

Rework has become an endemic feature of the procurement process in construction, which
invariably leads to time and cost overruns in projects. Thus, in order to improve the
performance of projects it is necessary to identify the causes and costs of rework. When it
comes to the quality, not only the quality of the deliveries that matter the most. The processes
or activities that produce deliverables should also adhere to certain quality guidelines as well.
As a principle, if the processes and activities that produce the deliverables do not adhere to
their own quality standards (process quality standards), then there is a high probability that
deliverables not meeting the delivery quality standards.

Project quality plan is one of the mandatory documents for any type of project.
As long as a project has defined objectives and deliverables, there should be a project quality
plan to measure the delivery and process quality. Go with prevention rather than cure.

Depending on the nature of the industry and the nature of the project, the components or the
areas addressed by a quality plan may vary. However, there are some components that can be
found in any type of quality plan which are: Responsibility of Management, Document
Management and Control, Requirements Scope, Design Control, Development Control and
Rigor, Testing and Quality Assurance, Risks & Mitigation, Quality Audits, Defect
Management, Training Requirements and Ensuring Quality Throughout the Project.

When you’re planning for quality, there are five major approaches you can rely on: Benefit-
cost analysis, Benchmarking, Flowcharting, Design of experiments and Cost of quality
analysis.

The knowledge area of project quality management includes the organizational processes that
determine quality policies, objectives, and responsibilities. The PMBOK identifies three
processes for quality management:

• Quality Planning
• Quality Assurance
• Quality Control

8.14 KEYWORDS

Quality - Quality in business, engineering and manufacturing has a pragmatic interpretation as

the non-inferiority or superiority of something; it is also defined as fitness for purpose.

Quality planning - Quality planning is a process to determine which quality standards are
relevant to the project, and how they can be implemented.

Total Quality Management - Total Quality Management is a process that involves all
employees within an organization working to fulfill their customers’ needs while also working
to increase productivity.
 UNIT 9 PROJECT CONTRACT

Objectives
After reading this Unit, you would be able to:

• Create a contract document;

• Arrange for project procurement;
• Arrange for sub-contracting;
• Differentiate between different types of contracts;
• Prepare SOW.
Structure
9.1 Introduction to Project Contract
9.2 Understanding contract
9.3 Elements of Contract
9.4 Contract Management
9.5 Types of Contract
9.6 Contract Process
9.7 Defining SOW for Project
9.8 Project Contracts from Financial Perspective
9.9 Sub-contracting in projects
9.10 Employer’s involvement in Subcontracts
9.11 Summary
9.12 Key Words

9.1 INTRODUCTION TO PROJECT CONTRACT

Contract is an agreement between two or more parties to accomplish a certain goal in a certain
way. For example, a project contract may take the form of an agreement between a builder and
a property owner in which the builder agrees to build a house on the property by a certain time
in a certain way, and, in exchange, the property owner makes certain remuneration. Project
contracts are important to have in the event of a dispute. In this unit we will look at meaning,
contents components and legalities related to project contract.

9.2 UNDERSTANDING CONTRACT

A contract is an agreement entered into voluntarily by two or more parties, each of whom
intends to create one or more legal obligations between or among them. The elements of a
contract are offer and acceptance by competent persons having legal capacity who exchanges
consideration to create mutuality of obligation, and, in some circumstances, do so in writing.
Proof of some or all of these elements may be done in writing, though contracts may be made
entirely orally or by conduct. At law, the remedy for breach of contract can be "damages" or
compensation of money. In equity, the remedy can be specific performance of the contract or
an injunction. Both of these remedies award the party at loss the "benefit of the bargain" or
expectation damages, which are greater than mere reliance damages, as in promissory estoppel.
The parties may be natural persons or juristic persons. A contract is a legally enforceable
promise or undertaking that something will or will not occur. The word promise can be used
as a legal synonym for contract, although care is required as a promise may not have the full
standing of a contract, as when it is an agreement without consideration.
Contract law varies greatly from one jurisdiction to another, including differences in common
law compared to civil law, the impact of received law, particularly from England in common
law countries, and of law codified in regional legislation. Regarding Australian Contract Law
for example, there are 40 relevant acts which impact on the interpretation of contract at the
Commonwealth (Federal / national) level, and an additional 26 acts at the level of the state of
NSW. In addition there are 6 international instruments or conventions which are applicable for
international dealings, such as the United Nations Convention on Contracts for the International
Sale of Goods.

9.3 ELEMENTS OF CONTRACT

At common law, the elements of a contract are offer, acceptance, intention to create legal
relations, and consideration.
Mutual Assent
At common law, mutual assent is typically reached through offer and acceptance, that is, when
an offer is met with an acceptance that is unqualified and that does not vary the offer's terms.
The latter requirement is known as the "mirror image" rule. If a purported acceptance does vary
the terms of an offer, it is not an acceptance but a counteroffer and, therefore, simultaneously
a rejection of the original offer.
Offer and Acceptance
The most important feature of a contract is that one party makes an offer for an arrangement
that another accepts. This can be called a concurrence of wills or consensus ad idem (meeting
of the minds) of two or more parties. The concept is somewhat contested. The obvious
objection is that a court cannot read minds and the existence or otherwise of agreement is
judged objectively, with only limited room for questioning subjective intention. Richard
Austen-Baker has suggested that the perpetuation of the idea of 'meeting of minds' may come
from a misunderstanding of the Latin term 'consensus ad idem', which actually means
'agreement to the [same] thing'. There must be evidence that the parties had each, from an
objective perspective, engaged in conduct manifesting their assent, and a contract will be
formed when the parties have met such a requirement. An objective perspective means that it
is only necessary that somebody gives the impression of offering or accepting contractual terms
in the eyes of a reasonable person, not that they actually did want to form a contract.
The term unilateral contract is used in contract law although ultimately there is an offerer and
an offeree and a consideration (which may be an act), Obligations are only imposed upon one
party upon acceptance by performance of a condition. In the United States, the general rule is
that in "case of doubt, an offer is interpreted as inviting the offered to accept either by promising
to perform what the offer requests or by rendering the performance, as the offeree chooses."
Offer and acceptance does not always need to be expressed orally or in writing. An implied
contract is one in which some of the terms are not expressed in words. This can take two forms.
A contract which is implied in fact is one in which the circumstances imply that parties have
reached an agreement even though they have not done so expressly. For example, by going to
a doctor for a checkup, a patient agrees that he will pay a fair price for the service. If one refuses
to pay after being examined, the patient has breached a contract implied in fact. A contract
which is implied in law is also called a quasi-contract, because it is not in fact a contract; rather,
it is a means for the courts to remedy situations in which one party would be unjustly enriched
were he or she not required to compensate the other. For example, a plumber accidentally
installs a sprinkler system in the lawn of the wrong house. The owner of the house had learned
the previous day that his neighbor was getting new sprinklers. That morning, he sees the
plumber installing them in his lawn. Pleased at the mistake, he says nothing, and then refuses
to pay when the plumber delivers the bill. Will the man be held liable for payment? Yes, if it
could be proven that the man knew that the sprinklers were being installed mistakenly, the
court would make him pay because of a quasi-contract. If that knowledge could not be proven,
he would not be liable. Such a claim is also referred to as "quantum meruit".

Consideration
Consideration is something of value given by a promisor to a promisee in exchange for
something of value given by a promisee to a promisor. Typically, the thing of value is a
payment, although it may be an act, or forbearance to act, when one is privileged to do so, such
as an adult refraining from smoking.
Consideration consists of a legal detriment and a bargain. A legal detriment is a promise to do
something or refrain from doing something that you have the legal right to do, or voluntarily
doing or refraining from doing something, in the context of an agreement. A bargain is
something the promisor (the party making promise or offer) wants, usually being one of the
legal detriments. The legal detriment and bargain principles come together in consideration and
create an exchange relationship, where both parties agree to exchange something that the other
wishes to have.
The purpose of consideration is to ensure that there is a present bargain, that the promises of
the parties are reciprocally induced. The classic theory of consideration required that a promise
be of detriment to the promissor or benefit to the promisee. This is no longer the case in the
USA; typically, courts will look to a bargained-for exchange, rather than making inquiries into
whether an individual was subject to a detriment or not. The emphasis is on the bargaining
process, not an inquiry into the relative value of consideration.

Sufficiency
Consideration must be sufficient, but courts will not weigh the adequacy of consideration. For
instance, agreeing to sell a car for a penny may constitute a binding contract. All that must be
shown is that the seller actually wanted the penny. This is known as the peppercorn rule.
Otherwise, depending the jurisdiction, the penny would constitute legally insufficient nominal
consideration. Parties may do this for tax purposes, attempting to disguise gift transactions as
contracts. Consideration is "sufficient" if it meets the test of law, whereas "adequacy" would
require an additional and subjective element of fairness or equivalence. Transfer of money is
typically recognized as an example of sufficient consideration, but in some cases it will not
suffice, for example, when one party agrees to make partial payment of a debt in exchange for
being released from the full amount. Past consideration is not sufficient. Indeed, it is an
oxymoron. For instance, in Eastwood v. Kenyon, the guardian of a young girl obtained a loan
to educate the girl and to improve her marriage prospects. After her marriage, her husband
promised to pay off the loan. It was held that the guardian could not enforce the promise
because taking out the loan to raise and educate the girl was past consideration—it was
completed before the husband promised to repay it. The insufficiency of past consideration is
related to the preexisting duty rule. The classic instance is Stilk v. Myrick, in which a captain's
promise to divide the wages of two deserters among the remaining crew if they would sail
home from the Baltic short-handed, was found unenforceable on the grounds that the crew were
already contracted to sail the ship through all perils of the sea.
The preexisting duty rule also extends beyond an underlying contract. It would not constitute
sufficient consideration for a party to promise to refrain from committing a tort or crime, for
example. However, a promise from A to do something for B if B will perform a contractual
obligation B owes to C, will be enforceable - B is suffering a legal detriment by making his
performance of his contract with A enforceable by C as well as by A.
Consideration must move from the promisee. For instance, it is good consideration for person
A to pay person C in return for services rendered by person B. If there are joint promisees, then
consideration need only to move from one of the promisees.

Formation of Contract
In addition to the elements of a contract:
• A party must have capacity to contract;
• The purpose of the contract must be lawful;
• The form of the contract must be legal;
• The parties must intend to create a legal relationship; and
• The parties must consent.
As a result, there are a variety of affirmative defenses that a party may assert to avoid his
obligation.

9.4 CONTRACT MANAGEMENT

Contract management or contract administration is the management of contracts made with

customers, vendors, partners, or employees. Contract management includes negotiating the
terms and conditions in contracts and ensuring compliance with the terms and conditions, as
well as documenting and agreeing on any changes or amendments that may arise during its
implementation or execution. It can be summarized as the process of systematically and
efficiently managing contract creation, execution, and analysis for the purpose of maximizing
financial and operational performance and minimizing risk. Common commercial contracts
include employment letters, sales invoices, purchase orders, and utility contracts. Complex
contracts are often necessary for construction projects, goods or services that are highly
regulated, goods or services with detailed technical specifications, intellectual property (IP)
agreements, and international trade.

A study has found that for "42% of enterprises...the top driver for improvements in the
management of contracts is the pressure to better assess and mitigate risks" and additionally,
“nearly 65% of enterprises report that contract lifecycle management (CLM) has improved
exposure to financial and legal risk."

9.5 TYPES OF CONTRACTS

In the world of business, contracts are used for establishing business deals and partnerships.
The parties involved in the business engagement decide the type of the contract. Usually the
type of the contract used for the business engagement varies depending on the type of the work
and the nature of the industry.
The contract is simply an elaborated agreement between two or more parties. One or more
parties may provide products or services in return to something provided by other parties
(client).
The contract type is the key relationship between the parties engaged in the business and the
contract type determines the project risk. Let' have a look at most widely used contract types.

Fixed Price (Lump Sum)

This is the simplest type of all contracts. The terms are quite straightforward and easy to
understand. To put in simple, the service provider agrees to provide a defined service for a
specific period of time and the client agrees to pay a fixed amount of money for the service.
This contract type may define various milestones for the deliveries as well as KPIs (Key
Performance Indicators). In addition, the contractor may have an acceptance criteria defined
for the milestones and the final delivery. The main advantages of this type of contract is that
the contractor knows the total project cost before the project commences.

Unit Price
In this model, the project is divided into units and the charge for each unit is defined. This
contract type can be introduced as one of the more flexible methods compared to fixed price
contract. Usually the owner (contractor/client) of the project decides on the estimates and asks
the bidders to bid of each element of the project. After bidding, depending on the bid amounts
and the qualifications of bidders, the entire project may be given to the same services provider
or different units may be allocated to different services providers. This is a good approach when
different project units require different expertise to complete.

Cost Plus
In this contract model, the services provider is reimbursed for their machinery, labour, and
other costs, in addition to contractor paying an agreed fee to the services provider. In this
method, the services provider should offer a detailed schedule and the resource allocation for
the project. Apart from that, all the costs should be properly listed and should be reported to
the contractor periodically. The payments maybe paid by the contractor at a certain frequency
(such as monthly, quarterly) or by the end of milestones.

Incentive
Incentive contracts are usually used when there is some level of uncertainty in the project cost.
Although there are nearly-accurate estimations, the technological challenges may impact on
the overall resources as well as the effort. This type of contracts is common for the projects
involving pilot programs or the project that harness new technologies. There are three cost
factors in an Incentive contract; target price, target profit, and the maximum cost. The main
mechanism of Incentive contract is to divide any target price overrun between the client and
the services provider in order to minimize the business risks for both parties.

Retainer (Time and Material - T&M)

This is one of the most beautiful engagements that can get into by two or more parties. This
engagement type is the most risk-free type where the time and material used for the project are
priced. The contractor only requires knowing the time and material for the project in order to
make the payments. This type of contracts has short delivery cycles and for each cycle separate
estimates are sent of the contractor. Once the contractor signs off the estimate and Statement
of Work (SOW), the services provider can start work. Unlike most of the other contract types,
retainer contracts are mostly used for long-term business engagements.

Percentage of Construction Fee

This type of contracts is used for engineering projects. Based on the resources and material
required, the cost for the construction is estimated. Then, the client contracts a service provider
and pays a percentage of the cost of the project as the fee for the services provider. As an
example, take the scenario of constructing a house. Assume that the estimate comes up to
$230,000. When this project is contracted to a services provider, the client may agree to pay
30% of the total cost as the construction fee, which comes up to $69,000.

Selecting the contract type is the most crucial step of establishing a business agreement with
another party. This step determines the possible engagement risks. Therefore, companies
should get into contracts where there is a minimum risk for their business. It is always a good
idea to engage in fixed bids (fixed priced) whenever the project is short-termed and predictable.
If the project nature is exploratory, it is always best to adopt retainer or cost plus contract types.

9.6 CONTRACT PROCESS

Are you outsourcing enough? This was one of the main questions asked by management
consultants during the outsourcing boom. Outsourcing was viewed as one of the best ways of
getting things done for a fraction of the original cost.

Outsourcing is closely related to make or buy decision. The corporations made decisions on
what to make internally and what to buy from outside in order to maximize the profit margins.

As a result of this, the organizational functions were divided into segments and some of those
functions were outsourced to expert companies who can do the same job for much less cost.

Make or buy decision is always a valid concept in business. No organization should attempt to
make something by their own, when they stand the opportunity to buy the same for much less
price.

This is why most of the electronic items manufactured and software systems developed in the
Asia, on behalf of the organizations in the UAS and Europe.

When you are supposed to make a make-or-buy decision, there are four numbers you need to
be aware of. Your decision will be based on the values of these four numbers. Let's have a look
at the numbers now. They are quite self-explanatory.

A. The volume
B. The fixed cost of making
C. Per-unit direct cost when making
D. Per-unit cost when buying

Now there are two formulas that use the above numbers. They are 'Cost to Buy' and 'Cost to
Make'. The higher value looses and the decision maker can go ahead with the less costly
solution.
Cost to Buy (CTB) = Volume x Per-unit cost when buying
Cost to Make (CTM) = Fixed costs + (Per-unit direct cost x volume)

Reasons for doing it yourself

There are number of reasons a company would consider when it comes to making in-house.
Following are a few.

• Cost concerns
• Desire to expand the manufacturing focus
• Need of direct control over the product
• Intellectual property concerns
• Quality control concerns
• Supplier unreliability
 • Lack of competent suppliers
• Volume too small to get a supplier attracted
• Reduction of logistic costs (shipping etc.)
• To maintain a backup source
• Political and environment reasons
• Organizational pride

Reasons for outsourcing

Following are some of the reasons companies may consider when it comes to buying from a
supplier.
• Lack of technical experience
• Supplier's expertise on the technical areas and the domain
• Cost considerations
• Need of small volume
• Insufficient capacity to produce in house
• Brand preferences
• Strategic partnerships

The Process
The make or buy decision can be in many scales. If the decision is small in nature and has less
impact on the business, then even one person can make the decision. The person can consider
the pros and cons between making and buying and finally arrive at a decision. When it comes
to larger and high impact decisions, usually organizations follow a standard method to arrive
at a decision. This method can be divided into four main stages as below.

Preparation:
• Team creation and appointment of the team leader
• Identifying the product requirements and analysis
• Team briefing and aspect/area destitution

Data Collection
• Collecting information on various aspects of make-or-buy decision
• Workshops on weightings, ratings, and cost for both make-or-buy
Data Analysis
• Analysis of data gathered

Feedback
• Feedback on the decision made

By following the above structured process, the organization can make an informed decision on
make-or-buy. Although this is a standard process for making the make-or-buy decision, the
organizations can have their own varieties.

9.7 DEFINING SOW FOR PROJECT

When it comes to implementing or constructing large and complex systems (such as an

enterprise software system), the work requirements and conditions should be properly
documented. Statement of Work (SOW) is such document that describes what needs to be done
in the agreed contract. Usually the SOW is written in a precise and definitive language that is
relevant to the field of business. This prevents any misinterpretations of terms and
requirements. A SOW covers the work requirements for a specific project and addresses the
performance and design requirements at the same time. Whenever requirements are detailed or
contained within a supplementary document, SOW makes reference to the specific document.

The SOW defines the scope and the working agreements between two parties, typically
between a client and a service provider. Therefore, SOW carries a legal gravity as well.

Purpose of SOW: The main purpose of a SOW is to define the liabilities, responsibilities, and
work agreements between clients and service providers. A well-written SOW will define the
scope of the engagement and Key Performance Indicators (KPIs) for the engagement.
Therefore, the KPIs can be used to determine whether the service provider has met conditions
of the SOW and use it as a baseline for future engagements. SOW contains all details of non-
specifications requirements of the contractor or services provider's effort. Whenever
specifications are involved, the references are made from SOW to specific specification
documents. These specification documents can be functional requirements or non-functional
requirements. Functional requirements (in a software system) define how the software should
behave functionally and non-functional requirements detail other characteristics of the software
such as performance, security, maintainability, configuration management etc.
Format of SOW: The SOW formats differ from one industry to another. Regardless of the
industry, some key areas of the SOW are common. Following are the commonly addressed
areas in a SOW.

Scope: This section describes the work to be done in a technical manner. If the system to be
built is a software system, this section defines the hardware and software requirements along
with the exact work to be done in terms of the final system. If there is anything 'out of scope',
those areas are also mentioned under a suitable sub heading.

Location: The location where the work is performed is mentioned under this section. This
section also details the hardware and software specifications. In addition to that, a description
about human resources and how they work are addressed here.

Timelines: This defines the timeline allocated for the projects. It includes the development
time, warranty time, and maintenance time. In addition to calendar time, the man days (total
effort) required to complete the project is also noted.

Delivery schedule: This section of the SOW describes the deliveries and the due dates for the
deliveries.

Standards: The standards (internal or external) are defined in this section. All deliveries and
work done should comply with the standards defined in this section of the document.

Acceptance Criteria: This section defines the minimum requirements for accepting
deliverables. It also describes the criteria used for acceptance.

Mode of contract and payments:

There are a number of engagement models when it comes to contracting a service provider. In
the domain of software development, there are two distinct contract models; fixed bid and a
retainer. In fixed bid, the project cost is a constant and it is up to the services provider to
optimize the resource allocation in order to maintain the profit margins. The client does not
worry about the number of resources, as long as the delivery schedule is met. In the retainer
model, the client pays for the number of resources allocated to the project.

Since SOW is an integrated part of a project, almost all senior members of the project team
should become aware of terms and conditions of the SOW. Sometimes, especially in software
development projects, a penalty is applied if the delivery dates are missed. Therefore, everyone
should be aware of such demanding terms of a SOW.

9.8 PROJECT CONTRACTS FROM FINANCIAL PERSPECTIVE

Engineering, Procurement and Construction Contract

The most common project finance construction contract is the engineering, procurement and
construction (EPC) contract. An EPC contract generally provides for the obligation of the
contractor to build and deliver the project facilities on a turnkey basis, i.e., at a certain pre-
determined fixed price, by a certain date, in accordance with certain specifications, and with
certain performance warranties. EPC contract is quite complicated in terms of legal issue,
therefore the project company the EPC contractor shall have enough experiences and
knowledge about the nature of project to avoid their faults and minimize the risks during the
contract execution.

An EPC contract differs from a turnkey contract in that, under a turnkey contract, all aspects
of construction are included from design to engineering, procurement and construction whereas
in the EPC contract the design aspect is not included. Other alternative forms of construction
contract are project management approach and alliance contracting. Basic contents of an EPC
contract are:

• Description of the project

• Price
• Payment
• Completion date
• Completion guarantee and liquidated damages (LDs):
• Performance guarantee and LDs
• Cap under LDs

Operation and Maintenance Agreement

An operation and maintenance (O&M) agreement is an agreement between the project
company and the operator. The project company delegates the operation, maintenance and
often performance management of the project to a reputable operator with expertise in the
industry under the terms of the O&M agreement. The operator could be one of the sponsors of
the project company or third-party operator. In other cases the project company may carry out
by itself the operation and maintenance of the project and may eventually arrange for the
technical assistance of an experienced company under a technical assistance agreement. Basic
contents of an O&M contract are:

• Definition of the service

• Operator responsibility
• Provision regarding the services rendered
• Liquidated damages
• Fee provisions

Concession Deed
An agreement between the project company and a public-sector entity (the contracting
authority) is called a concession deed. The concession agreement concedes the use of a
government asset (such as a plot of land or river crossing) to the project company for a specified
period. A concession deed would be found in most projects which involve government such as
in infrastructure projects. The concession agreement may be signed by a national/regional
government, a municipality, or a special purpose entity set up by the state to grant the
concession. Examples of concession agreements include contracts for the following:

• A toll-road or tunnel for which the concession agreement giving a right to collect
tolls/fares from public or where payments are made by the contracting authority based
on usage by the public.
• A transportation system (e.g., a railway / metro) for which the public pays fares to a
private company)
• Utility projects where payments are made by a municipality or by end-users.
• Ports and airports where payments are usually made by airlines or shipping companies.
 • Other public sector projects such as schools, hospitals, government buildings, where
payments are made by the contracting authority.

Shareholders Agreement
The shareholders agreement (SHA) is an agreement between the project sponsors to form a
special purpose company (SPC) in relation to the project development. This is the most basic
of structure held by the sponsors in project finance transaction. This is an agreement between
the sponsors and deals with:

• Injection of share capital

• Voting requirements
• Resolution of disputes
• Dividend policy
• Management of the SPV
• Disposal and pre-emption rights

Off-Take Agreement
An off-take agreement= is an agreement between the project company and the offtaker (the
party who is buying the product / service the project produces / delivers). In a project financing
the revenue is often contracted (rather to the sold on a merchant basis). The off-take agreement
governs mechanism of price and volume which make up revenue. The intention of this
agreement is to provide the project company with stable and sufficient revenue to pay its project
debt obligation, cover the operating costs and provide certain required return to the sponsors.

The main off-take agreements are:

• Take-or-pay contract: under this contract the off-taker – on an agreed price basis – is
obligated to pay for product on a regular basis whether or not the off-taker actually
takes the product.
• Power purchase agreement: commonly used in power projects in emerging markets.
The purchasing entity is usually a government entity.
• Take-and-pay contract: the off-taker only pays for the product taken on an agreed price
basis.
• Long-term sales contract: the off-taker agrees to take agreed-upon quantities of the
product from the project. The price is however paid based on market prices at the time
of purchase or an agreed market index, subject to certain floor (minimum) price.
Commonly used in mining, oil and gas, and petrochemical projects where the project
company wants to ensure that its product can easily be sold in international markets,
but off-takers not willing to take the price risk
• Hedging contract: found in the commodity markets such as in an oilfield project.
• Contract for Differences: the project company sells its product into the market and not
to the off-taker or hedging counterpart. If however the market price is below an agreed
level, the off taker pays the difference to the project company, and vice versa if it is
above an agreed level.
• Throughput contract: a user of the pipeline agrees to use it to carry not less than a certain
volume of product and to pay a minimum price for this.
 Supply Agreement
An supply agreement is between the project company and the supplier of the required feedstock
/ fuel.

If a project company has an off-take contract, the supply contract is usually structured to match
the general terms of the off-take contract such as the length of the contract, force majeure
provisions, etc. The volume of input supplies required by the project company is usually linked
to the project’s output. Example under a PPA the power purchaser who does not require power
can ask the project to shut down the power plant and continue to pay the capacity payment –
in such case the project company needs to ensure its obligations to buy fuel can be reduced in
parallel. The degree of commitment by the supplier can vary.

The main supply agreements are:

• Fixed or variable supply: the supplier agrees to provide a fixed quantity of supplies to
the project company on an agreed schedule, or a variable supply between an agreed
maximum and minimum. The supply may be under a take-or-pay or take-and-pay.
• Output / reserve dedication: the supplier dedicates the entire output from a specific
source, e.g., a coal mine, its own plant. However the supplier may have no obligation
to produce any output unless agreed otherwise. The supply can also be under a take-or-
pay or take-and-pay.
• Interruptible supply: some supplies such as gas are offered on a lower cost interruptible
basis – often via a pipeline also supplying other users.
• Tolling contract: the supplier has no commitment to supply at all, and may choose not
to do so if the supplies can be used more profitably elsewhere. However the availability
charge must be paid to the project company.

Loan Agreement
A loan agreement is made between the project company (borrower) and the lenders. Loan
agreement governs relationship between the lenders and the borrowers. It determines the basis
on which the loan can be drawn and repaid, and contains the usual provisions found in a
corporate loan agreement. It also contains the additional clauses to cover specific requirements
of the project and project documents.

Basic terms of a loan agreement include the following provisions.

• General conditions precedent

• Conditions precedent to each drawdown
• Availability period, during which the borrower is obliged to pay a commitment fee
• Drawdown mechanics
• An interest clause, charged at a margin over base rate
• A repayment clause
• Financial covenants - calculation of key project metrics / ratios and covenants
• Dividend restrictions
• Representations and warranties
• The illegality clause
 Inter-creditor Agreement
Intercreditor agreement is agreed between the main creditors of the project company. This is
the agreement between the main creditors in connection with the project financing. The main
creditors often enter into the Intercreditor Agreement to govern the common terms and
relationships among the lenders in respect of the borrower’s obligations.

Intercreditor agreement will specify provisions including the following.

• Common terms
• Order of drawdown
• Cashflow waterfall
• Limitation on ability of creditors to vary their rights
• Voting rights
• Notification of defaults
• Order of applying the proceeds of debt recovery
• If there is a mezzanine funding component, the terms of subordination and other
principles to apply as between the senior debt providers and the mezzanine debt
providers.

Tripartite Deed
The financiers will usually require that a direct relationship between itself and the counterparty
to that contract be established which is achieved through the use of a tripartite deed (sometimes
called a consent deed, direct agreement or side agreement). The tripartite deed sets out the
circumstances in which the financiers may “step in” under the project contracts in order to
remedy any default.

A tripartite deed would normally contain the following provision.

• Acknowledgement of security: confirmation by the contractor or relevant party that it

consents to the financier taking security over the relevant project contracts.
• Notice of default: obligation on the relevant project counterparty to notify the lenders
directly of defaults by the project company under the relevant contract.
• Step-in rights and extended periods: to ensure that the lenders will have sufficient notice
/period to enable it to remedy any breach by the borrower.
• Receivership: acknowledgement by the relevant party regarding the appointment of a
receiver by the lenders under the relevant contract and that the receiver may continue
the borrower’s performance under the contract.
• Sale of asset: terms and conditions upon which the lenders may transfer the borrower’s
entitlements under the relevant contract.

Tripartite deed can give rise to difficult issues for negotiation but is a critical document in
project financing.

Common Terms Agreement

Agreement between the borrower and the lender for the cost, provision and repayment of debt.
The term sheet outlines the key terms and conditions of the financing. The term sheet provides
the basis for the lead arrangers to complete the credit approval to underwrite the debt, usually
by signing the agreed term sheet. Generally the final term sheet is attached to the mandate letter
and is used by the lead arrangers to syndicate the debt. The commitment by the lenders is
usually subject to further detailed due diligence and negotiation of project agreements and
finance documents including the security documents. The next phase in the financing is the
negotiation of finance documents and the term sheet will eventually be replaced by the
definitive finance documents when the project reaches financial close.

9.9 SUB-CONTRACTING IN PROJECTS

A sub-contractor is a party which agrees to perform part or all of the obligations of another
party (main contractor) under a separate contract (master contract) with the ultimate employer
(employer). The sub-contractor will usually be engaged by a main contractor to perform a
specific task as part of the master contract.

Main contractors usually sub-contract obligations because they:

• Require additional resources: for instance if they undertake a particularly big job, such
as a multi-site construction project;
• Are responsible for making the professional appointments: for instance the architect,
structural engineer, mechanical & electrical engineer and project manager;
• require additional specialist advice or expertise: more specialized consultants include
archaeological consultants, traffic management consultants and surveyors;
• Are required by law to appoint them: for instance a co-coordinator in relation to health
and safety.

Drafting the Sub-Contract

The main contractor will be responsible to the employer for its obligations under the master
contract, regardless of whether any breach is caused by the sub-contractor failing to perform
its obligations under the sub-contract.

The sub-contractor has to understand its obligations and must deliver in a timeframe and
manner which will enable the main contractor to perform its obligations under the main
contract.
From the main contractor's perspective, it will be important that the terms of the main contract
are reflected in, or stepped down to, the sub-contract. This avoids 'gaps' in the main contractor's
obligations under the master contract and the sub-contractor's obligations under the sub-
contract. Any gaps are likely to mean liability sitting with the main contractor:
There is no fixed approach to sub-contracting, and different approaches have their advantages
and disadvantages:
Standard form sub-contract:
• There are many different standard forms of sub-contract which are recognized
in the construction industry. These seek to provide an "off the shelf" contract
for the parties to use;
• The main advantage of using this method is avoiding the need to draft the sub-
contract from scratch and hopefully saving time negotiating it. Standard forms
can also be useful if the same parties are involved on repeat projects;

The main disadvantages are:

• They will not reflect project-specific risks or unusual provisions in the master
contract;
 • They will usually be drafted to benefit one party more than the other. It is
important to remember that it will still be necessary to review the sub-contract
and it is possible that amendments will be needed;
• Some obligations cannot be stepped down to the sub-contract;
• The same standard form will not suit all sub-contractors on all projects, and
should be reviewed regularly to ensure that changes in the law and lessons
learned on previous projects can be taken into account;

Incorporating the terms of the main master contract by reference into a framework contract;
• This is commonly a short sub-contract obliging the sub-contractor to identify
and comply with the relevant terms of the master contract;
• Advantages of using this method are:
• There is no need to amend or redraft the sub-contract if changes are made to the
master contract, as these changes will simply be incorporated by reference;
• Any issues caused by having to cross-reference between the two documents will
be reduced or eliminated;
• This method also encourages the sub-contractor to focus on and carry out a
proper review of the provisions of the actual master contract;
• The main disadvantages are:
• The risk that the sub-contractor will not identify everything and creating 'gaps'
between the master contract and sub-contract (see above);
• Having to determine the contractual effect of master contract terms if these are
not clearly drafted - it is not always clear how certain terms would have been
stepped down to the sub-contract;
• Some terms are only relevant to the master contract and should not be stepped
down to the sub-contract. This could lead to ambiguities and disputes about
whether or not the sub-contractor should or should not have done something;
• Certain clauses which are unique to the sub-contract will still need to be drafted;

bespoke sub-contract:
- This is the most common approach, particularly on complex projects;
- Each master contract clause will be reviewed to consider whether the obligations in that
clause should be stepped down to the sub-contractor. Amendments and additional
drafting will be required to ensure that the clauses work correctly in the sub-contract;
- The main advantage of using this method is that it allows the parties to address any
unique issues

The main disadvantages are:

• They will take longer to complete;
• Sub-contract redrafts are generally necessary each time the master contract is
amended.

9.10 EMPLOYER'S INVOLVEMENT IN SUB-CONTRACTS

The employer, while negotiating the master contract with the main contractor, will want to
make sure the main contractor will meet the performance requirements set out in the master
contract and that the sub-contract costings match up. It will therefore want to review the main
contractor's sub-contracting arrangements.
The main contractor should be allowed to manage the delivery of the construction project, but
best practice is for the employer not to sign the master contract until the sub-contract(s) are
agreed and ready for execution.

Examples of the issues which the employer should look out for are:

Sub-contracting assignment and notation: the employer will want control over the sub-
contractor further sub-contracting its work. For instance, it will want any future sub-contractor
to have the technical expertise and financial strength to perform its obligations;

Liquidated damages: if the master contract requires the main contractor to pay liquidated
damages to the employer for late completion of the works, the employer should ensure that the
main contractor will be able to recover enough under its sub-contract to pay the employer. This
will avoid the main contractor not having sufficient funds to pay the employer;

Collateral warranties: collateral warranties create a direct contractual link, which would not
otherwise exist, between the employer and the sub-contractor. This allows the employer to
make a contractual claim against sub-contractors, should sub-contractors fail to perform their
obligations under the sub-contract; should the employer have to step-in and replace the main
contractor in the sub-contract, it will have to ensure that it is happy with the sub-contract as a
whole and the obligations it might assume;

Breakage costs: the employer should ensure that it is comfortable with any breakage costs
payable if the sub-contract is terminated early, since it will be potentially liable for various
termination scenarios under the main contract.

The Main Contractor's Principal Concerns In Sub-Contracts

Examples of the issues which the main contractor should look out for are:
Headroom: the main contractor should give itself enough time under the sub-contract to enable
it to perform its obligations under the master contract, bearing in mind that the sub-contractor
may be 'on the ground' and in possession of the relevant information.

Examples are:
Notifications and time limits: if the main contractor is obliged to notify the employer within
for instance 20 days of an event which might cause delays and therefore give rise to an
entitlement to an extension of time, it will need to ensure that the corresponding period in the
sub-contract is less than 20 days, to give it time to pass information up the contractual chain to
the employer;

Exercising rights: if the employer has 20 days to exercise a right under the master contract
which has been stepped down to the sub-contract, the main contractor will want more than 20
days to exercise the right under the sub-contract;

Information: the same principle applies to information which the sub-contractor will need to
give to the employer under the master contract. The sub-contractor should be obliged to provide
the same information under the sub-contract;

Extensions of time and other reliefs: the main contractor will want to ensure that it is entitled
to the same remedies and reliefs under the main contract as the sub-contractor is entitled to
under the sub-contract. This avoids the situation where the sub-contractor may be entitled to
for instance an extension of time under the sub-contract, to which the main contractor is not
entitled under the main contract;

Certification of completion: again, the main contractor will want to ensure that certificates
issued by third parties confirming completion of the works apply to both the sub-contract and
master contract, to avoid inconsistency and potentially achieving completion under one, but
not both, of the contracts;

Payment: the main contractor will want to ensure that it is not obliged to pay its sub-contractors
before it has been paid by the employer. Recent changes to the Construction Act are aimed
among other things at the abolition of conditional payment clauses and introducing a 'fairer'
payment regime, and improving rights for contractors to suspend their work in non-payment
circumstances;

Dispute resolution: the main contractor will not want to be bound by a decision under the
dispute resolution procedure (DRP) in the master contract while it is still involved in the sub-
contract DRP. Recent changes to the Construction Act are aimed among other things at to
encouraging the use of adjudication for the resolution of disputes;

Is there more than one sub-contractor? The main contractor will wish to ensure that each sub-
contractor is obliged not to do anything which would harm the project by preventing other sub-
contractor from performing its obligations. For an example of how this is dealt with in PPP
projects, see our guide to interface agreements;

Caps on liability: are they lower in the sub-contract than in the master contract, and does the
main contractor want to take the risk of the gap? What about small, specialist sub-contractors
who are unable to accept the same level of liability under the master contract?

9.11 SUMMARY

Every project involves some sort of contract or the other. At common law, the elements of a
contract are offer, acceptance, intention to create legal relations, and consideration.
In addition to the elements of a contract:
• A party must have capacity to contract;
• The purpose of the contract must be lawful;
• The form of the contract must be legal;
• The parties must intend to create a legal relationship; and
• The parties must consent.
As a result, there are a variety of affirmative defenses that a party may assert to avoid his
obligation.
There are various types of contracts. Usually the type of the contract used for the business
engagement varies depending on the type of the work and the nature of the industry. These
include following types: Fixed Price (Lump Sum), Unit Price, Cost Plus, Incentive, Retainer
(Time and Material - T&M) and Percentage of Construction Fee.
When it comes to implementing or constructing large and complex systems (such as an
enterprise software system), the work requirements and conditions should be properly
documented. Statement of Work (SOW) is such document that describes what needs to be done
in the agreed contract.
Usually the SOW is written in a precise and definitive language that is relevant to the field of
business. This prevents any misinterpretations of terms and requirements.

A SOW covers the work requirements for a specific project and addresses the performance and
design requirements at the same time.

The main purpose of a SOW is to define the liabilities, responsibilities, and work agreements
between clients and service providers.

A well-written SOW will define the scope of the engagement and Key Performance Indicators
(KPIs) for the engagement.

Most project involve appointing sub-contractors for projects. The sub-contractor will usually
be engaged by a main contractor to perform a specific task as part of the master contract.
Main contractors usually sub-contract obligations because they:
• require additional resources: for instance, if they undertake a particularly big job, such
as a multi-site construction project;
• are responsible for making the professional appointments: for instance the architect,
structural engineer, mechanical & electrical engineer and project manager;
• require additional specialist advice or expertise: more specialized consultants include
archaeological consultants, traffic management consultants and surveyors;
• are required by law to appoint them: for instance, a co-coordinator in relation to health
and safety.

9.12 KEYWORDS

Contract - A contract is an agreement entered into voluntarily by two or more parties, each of
whom intends to create one or more legal obligations between or among them.
Sub-Contractor - A sub-contractor is a party which agrees to perform part or all of the
obligations of another party (main contractor) under a separate contract (master contract) with
the ultimate employer (employer).
Consideration - Consideration is something of value given by a promissor to a promisee in
exchange for something of value given by a promisee to a promissor.
Contract management - Contract management or contract administration is the management
of contracts made with customers, vendors, partners, or employees.
 UNIT 10 PROJECT PROCUREMENT

Objectives

After reading this unit, you will be able to:

• Explain the concept of procurement;

• Arrange for procurement of resources for projects;
• Carry out the purchase process;
• Prepare the procurement documents.

Structure

1.1 Introduction to Project Procurement

1.2 Procurement Process
1.3 Procurement System
1.4 Acquisition Process
1.5 Procurement Performance
1.6 Procurement methods
1.7 Purchasing
1.8 Turnkey projects
1.9 Planning for Procurement
1.10Selecting Supplier for Project
1.11Robinson Model
1.12Summary
1.13Keywords

10.1INTRODUCTION TO PROJECT PROCUREMENT

Procurement is the acquisition of goods or services. It is favorable that the goods/services are
appropriate and that they are procured at the best possible cost to meet the needs of the purchaser in
terms of quality and quantity, time, and location ( Weele 2010) . Corporations and public bodies often
define processes intended to promote fair and open competition for their business while minimizing
exposure to fraud and collusion. Procurement in projects is critical for the successful completion of
the projects both in terms of cost as well as time. In this unit we will discuss different aspects related
to project procurement which includes purchasing of material, hiring of equipments and outsourcing.

10.2PROCUREMENT PROCESS

Almost all procurement decisions include factors such as delivery and handling, marginal benefit, and
price fluctuations. Procurement generally involves making buying decisions under conditions of
scarcity. If good data is available, it is good practice to make use of economic analysis methods such
as cost-benefit analysis or cost-utility analysis.
An important distinction made between analyses without risk and those with risk. Where risk is
involved, either in the costs or the benefits, the concept of expected value may be employed.
 Direct procurement and indirect procurement
TYPES
Direct
Indirect procurement
procurement
Raw material Capital
Maintenance, repair,
and production goods and
and operating supplies
goods services
Quantity Large Low Low
F
E Frequency High Relatively high Low
A
Value Industry specific Low High
T
U Nature Operational Tactical Strategic
R
E Crude oil in Crude oil
S Examples petroleum Lubricants, spare parts storage
industry facilities

Based on the consumption purposes of the acquired goods and services, procurement activities are
often split into two distinct categories. The first category being direct, production-related procurement
and the second being indirect, non-production-related procurement.

Direct procurement occurs in manufacturing settings only. It encompasses all items that are part of
finished products, such as raw material, components and parts. Direct procurement, which is the focus
in supply chain management, directly affects the production process of manufacturing firms. In
contrast, indirect procurement activities concern “operating resources” that a company purchases to
enable its operations. It comprises a wide variety of goods and services, from standardized low value
items like office supplies and machine lubricants to complex and costly products and services; like
heavy equipment and consulting services.

The procurement process can be divided into five steps.

Define the Business Need

You need to understand what the fundamental business requirement is. At this point, it is important to
understand the difference between a requirement and a solution. For example, the business requirement
is to source some software to help to get information published on the company intranet. An item of
software to publish information on the company intranet is a solution – not a requirement. The
requirement is to be able to publish information on the intranet. It may be that an outsourced solution
is a better option.
Develop the Procurement Strategy
Depending on the scale of your project, there could be a very wide range of potential solutions and
approaches to your business need and a number of ways of researching the market and selecting a
supplier.
Supplier Selection and Evaluation
After researching the market and establishing your procurement approach, you need to evaluate the
solutions available. This may involve a formal tender process or an on-line auction. You criteria for
comparing different solutions and suppliers are critical. Weight the key criteria heavily and don’t attach
too much importance to aspects that will have little impact on the solution.
Negotiation and Award
Even when you have selected a supplier it is important that detailed negotiations are undertaken. This
is not just about price. Think in terms of Total Cost of Ownership. A cheap product is not so cheap if
the carriage costs are huge or if the maintenance contract is onerous.
Consider carefully the process by which the goods or services will be ordered and approved; how they
will be delivered and returned if necessary; how the invoice process will work and on what terms
payment will be made. Considering the whole Purchase to Pay process (P2P) at the outset can reduce
costs and risk significantly.
Induction and Integration
No goods or services should be ordered of delivered until the contract is signed, but this is not the end.
It is vital that the supplier is properly launched integrated. The P2P process needs to be in place and
need to be understood on both the buy-side and the supplier side. Any service levels that have been
agreed need to be measured and KPIs put in place. Regular reviews should be established.

10.3PROCUREMENT SYSTEMS

Another common procurement issue is the timing of purchases. Just-in-time is a system of timing the
purchases of consumables so as to keep inventory costs low. Just-in-time is commonly used by
Japanese companies but widely adopted by many global manufacturers from the 1990s onwards.
Typically a framework agreement setting terms and price is created between a supplier and purchaser,
and specific orders are then called-off as required.
Procurement may also involve a bidding process i.e.,Tendering. A company may want to purchase a
given product or service. If the cost for that product/service is over the threshold that has been
established (e.g.: Company X policy: "any product/service desired that is over $1,000 requires a
bidding process"), depending on policy or legal requirements, Company X is required to state the
product/service desired and make the contract open to the bidding process. The concept of total cost
also comes into play. At times, it is not just the low price points, but other factors like quality, flexibility
and timing that are considered in the tendering process as well. Company X may have ten submitters
that state the cost of the product/service they are willing to provide. Then, Company X will usually
select the lowest bidder. If the lowest bidder is deemed incompetent to provide the desired
product/service even after a low quoted price, Company X will then select the submitter who has the
next best price, and is competent to provide the product/service. In the European Union there are strict
rules on procurement processes that must be followed by public bodies, with contract value thresholds
dictating what processes should be observed (relating to advertising the contract, the actual process
etc.).
Procurement life cycle in modern businesses usually consists of five steps:
Identification of Need: This is an internal step for a company that involves understanding of the
company needs by establishing a short term strategy (three to five years) followed by defining the
technical direction and requirements.
Supplier Identification: Once the company has answered important questions like: Make-buy,
multiple vs. single suppliers, then it needs to identify who can provide the required product/service.
There are many sources to search for supplier; more popular ones being Ariba, Alibaba, other suppliers
and trade shows.
Supplier Communication: When one or more suitable suppliers have been identified, requests for
quotation, requests for proposals, requests for information or requests for tender may be advertised, or
direct contact may be made with the suppliers. References for product/service quality are consulted,
and any requirements for follow-up services including installation, maintenance, and warranty are
investigated. Samples of the P/S being considered may be examined or trials undertaken.
Negotiation: Negotiations are undertaken, and price, availability, and customization possibilities are
established. Delivery schedules are negotiated, and a contract to acquire the P/S is completed.
Supplier Liaison
During this phase, the company evaluates the performance of the P/S and any accompanying service
support, as they are consumed. Supplier scorecard is a popular tool for this purpose. When the P/S has
been consumed or disposed of, the contract expires, or the product or service is to be re-ordered,
company experience with the P/S is reviewed. If the P/S is to be re-ordered, the company determines
whether to consider other suppliers or to continue with the same supplier.
Logistics Management: Supplier preparation, expediting, shipment, delivery, and payment for the
P/S are completed, based on contract terms. Installation and training may also be included.
Additional Step - Tender Notification: Some institutions choose to use a notification service in order
to raise the competition for the chosen opportunity. These systems can either be direct from their e-
tendering software, or as a re-packaged notification from an external notification company.

10.4ACQUISITION PROCESS
The US Defense Acquisition University (DAU) defines procurement as the act of buying goods and
services for the government. DAU defines acquisition as the conceptualization, initiation, design,
development, test, contracting, production, deployment, Logistics Support (LS), modification, and
disposal of weapons and other systems, supplies, or services (including construction) to satisfy
Department of Defense needs, intended for use in or in support of military missions.
Acquisition is therefore a much wider concept than procurement, covering the whole life cycle of
acquired systems. Multiple acquisition models exist, one of which is provided in the following section.
The acquisition process for major systems in industry is shown in the next figure. The process is
defined by a series of phases during which technology is defined and matured into viable concepts,
which are subsequently developed and readied for production, after which the systems produced are
supported in the field.

Model of the Acquisition Process

The process allows for a given system to enter the process at any of the development phases. For
example, a system using unproven technology would enter at the beginning stages of the process and
would proceed through a lengthy period of technology maturation, while a system based on mature
and proven technologies might enter directly into engineering development or, conceivably, even
production. The process itself includes four phases of development:
Concept Exploration: During this stage, concept studies are undertaken to define alternative concepts
and to provide information about capability and risk that would permit an objective comparison of
competing concepts.
Concept and Technology Development: is intended to explore alternative concepts based on
assessments of operational needs, technology readiness, risk, and affordability.
System Development and Demonstration phase: This phase could be entered directly as a result of a
technological opportunity and urgent user need, as well as having come through concept and
technology development.
Sustenance and Disposal phase: The last and longest phase is the Sustenance and Disposal phase of
the program. During this phase all necessary activities are accomplished to maintain and sustain the
system in the field in the most cost-effective manner possible.

10.5PROCUREMENT PERFORMANCE

In July 2011, Ardent Partners published a research report that presented a comprehensive, industry-
wide view into what is happening in the world of procurement today by drawing on the experience,
performance, and perspective of nearly 250 Chief Procurement Officers and other procurement
executives. The report includes the main procurement performance and operational benchmarks that
procurement leaders use to gauge the success of their organizations. This report found that the average
procurement department manages 60.6% of total enterprise spend. This measure commonly called
"spend under management" refers to the percentage of total enterprise spend (which includes all direct,
indirect, and services spend) that a procurement organization manages or influences. The average
procurement department also achieved an annual savings of 6.7% in the last reporting cycle, sourced
52.6% of its addressable spend, and has a contract compliance rate of 62.6%

10.6PROCUREMENT METHODS
Procurement is generally based on competitive bidding. Depending on the type, complexity, size and
value of the project and its procurement elements, commonly used methods of solicitation include:
Request for Quotation (RFQ)
An RFQ is an informal invitation to submit a quotation, usually for goods/services/civil works at a
value between US$2,500 and $100,000. Prices, and other commercial terms and conditions are
requested and award is made to the lowest priced technically acceptable offer.
Invitation to Bid (ITB)
An ITB is a formal invitation to submit a bid, usually associated with requirements that are clearly and
concisely defined, with an estimated procurement value of US$100,000 or more. Normally price is the
sole determinant in making an award. Where all technical criteria are met, award is made to the lowest
bidder.
Request for Proposal (RFP)
An RFP is a formal request to submit a proposal, usually associated with requirements for services,
which cannot be clearly or concisely defined, with an estimated procurement value of US$ 100,000 or
more. Price is only one of several factors comprising the evaluation criteria. Award is made to the
qualified bidder whose bid substantially conforms to the requirement set forth on the solicitation
documents and is evaluated to be the lowest cost to UNDP.
In some cases, exceptions to competition are being made and direct contracting is used. This usually
happens when a Long-Term Agreement (LTA) is in place, either globally (IAPSO or HQ) or locally
(at country office level). For values less than US$2,500, country offices may engage in local Shopping.
Evaluation of offers
Depending on the procurement method, different factors take on the key role in the evaluation process.
When evaluating RFQs and ITBs, the price is the most important element. In contrast to this, and RFP
requires a technical evaluation. The technical component primarily determines whether the proposal
will be accepted or declined. Additionally, UNDP evaluates its products and services based on the
following criteria:
Goods:
• Meet technical specifications
• Delivery
• Environmentally sound
• Quality Assurance
• Accuracy of documentation
• Speed of response
• Customer service
Services:
• Provides Technical Solutions
• Competency
Contract modalities / Types of contracts
Generally there are several contract modalities, amongst others:
• Lump Sum (Fixed Price Contract)
• Time and Material Contract
• Retainer Fee contract
• Percentage Contracts
• Long Term Agreements (Call off through contracts)
Long-term agreements (LTA) reduce administrative efforts by a single tendering exercise over the life
of the arrangement. They are awarded on a 1-year renewable basis and exist on the country level as
well as globally, administered by HQ.
Advantages include:
• quality assurance and legal requirements will have been dealt with at the outset
• the supplier benefits in terms of planning stock levels and continuity of supply
• a mutually beneficial longer-term working relationship can be established
A formal procurement process is sometime seen as cumbersome or bureaucratic but for any
procurement exercise it is important to follow a few key steps. If you are not a procurement expert,
you will make mistakes. No doubt you will learn from them but why learn from your mistakes when
you can learn from someone else’s.
A procurement process template provides a model and a framework to work within to:
 • Save you time; ensure that you get the right solution to meet your business needs;
• Ensure you pay the right price (that’s the right price, not necessarily the lowest price!);
• Ensure you avoid overlooking vital steps that may come back to haunt you later.

By using a standard procurement process, you will find that suppliers will be familiar with the steps
you take. They will know what to expect and will know that they are dealing with a professional
organization
Every project is different. Some procurement projects are small and every step of a formal process
may not be required. Alternatively, some projects are highly complex or regulated and a generic
framework will not be appropriate or sufficient. Despite this, every procurement project follows the
same broad process. The key thing to remember is to adapt the process to fit the project.

10.7PURCHASING
Purchasing is the formal process of buying goods and services. The Purchasing Process can vary from
one organization to another, but there are some common key elements.
The process usually starts with a 'Demand' or requirements – this could be for a physical part
(inventory) or a service. A requisition is generated, which details the requirements (in some cases
providing a requirements speciation) which actions the procurement department. A Request for
Proposal (RFP) or Request for Quotation (RFQ) is then raised. Suppliers send their quotations in
response to the RFQ, and a review is undertaken where the best offer (typically based on price,
availability and quality) is given the purchase order.
Purchase orders (PO) can be of various types, including:
• Standard - a onetime buy;
• Planned - an agreement on a specific item at an approximate date; and
• Blanket - an agreement on specific terms and conditions: date and quantity and amount are not
specified.
Purchase Orders are normally accompanied by Terms and Conditions which form the contractual
agreement of the Transaction. The Supplier then delivers the products/service and the customer records
the delivery (in some cases this goes through a Goods Inspection Process). An invoice is sent by the
supplier which is cross-checked with the Purchase Order and Document which specifying that the
goods received. The payment is made and transferred to GL.
Steps in Purchasing
The purchasing process for companies breaks down into eight clear steps. In the first step the company
identifies a need, for which the answer is the purchase of a product. The final step is the execution of
a purchase contract. The steps in between build an organized, informed process that results in the
company purchasing the right product for the need from a qualified supplier whose product is the most
durable for the price.

Identify Need: Identify the need for a product purchase. For example, a lawn company wants to offer
mowing services to its clients. To do this it needs to purchase a mower. Thus, the need to make a
purchase of a product, a mower, is identified.

Select Specific Product: Select a specific product to meet the need. For example the lawn company
must select which type of mower from the many push and riding varieties on the market meets the
company’s need for a mower the best.

Appoint Purchase Team: Put a team together to manage the purchase process, including finalizing the
list of required technical specifications for the product and the bid solicitation and award process.

Specify Technical Specifications

Arrive at a list of required technical specifications for the product to ensure it meets the company’s
needs.

Budget for Purchase: Establish a budget for the purchase relying on the range of prices identified by
the research done in earlier Step.

Research Potential Suppliers: Research the various product types that fit the need along with their
suppliers to identify the most durable model at the best price. If the lawn company decides to purchase
a riding mower, research is conducted into which brand and manufacturer provides the most durable
product for the price asked.

Solicit Bids: Solicit bids from the manufacturers and suppliers of the identified product that meets all
the required technical specifications.

Award Contract: Select a supplier from the bids submitted and award the purchase contract.

10.8 TURNKEY PROJECT

A turnkey or a turnkey project (also spelled turn-key) is a type of project that is constructed so that it
could be sold to any buyer as a completed product. This is contrasted with build to order, where the
constructor builds an items to the buyers exact specifications, or when an incomplete product is sold
with the assumption that the buyer would complete it.

A turnkey project or contract as described by Duncan Wallace,(1984) is …. a contract where the

essential design emanates from, or is supplied by, the Contractor and not the owner, so that the legal
responsibility for the design, suitability and performance of the work after completion will be made to
rest … with the contractor …. ‘Turnkey’ is treated as merely signifying the design responsibility as
the contractor’s.
Turnkey refers to something that is ready for immediate use, generally used in the sale or supply of
goods or services. Turnkey is often used to describe a home built on the developer's land with the
developer's financing ready for the customer to move in. If a contractor builds a "turnkey home" they
frame the structure and finish the interior. Everything is completed down to the cabinets and carpet.
"Turnkey" is commonly used in the construction industry, for instance, in which it refers to the
bundling of materials and labor by sub-contractors. 'Turnkey' is also commonly used in motorsports to
describe a car being sold with drive train (engine, transmission, etc.) to contrast with a vehicle sold
without one so that other components may be re-used.

Similarly, this term may be used to advertise the sale of an established business, including all the
equipment necessary to run it, or by a business-to-business supplier providing complete packages for
business start-up. An example would be the creation of a "turnkey hospital" which would be building
a complete medical center with installed high-tech medical equipment.

The term turnkey is also often used in the technology industry, most commonly to describe pre-built
computer "packages" in which everything needed to perform a certain type of task (e.g. audio editing)
is put together by the supplier and sold as a bundle. This often includes a computer with pre-installed
software, various types of hardware, and accessories. Such packages are commonly called appliances.
A website with a ready-made solution and some configurations is called a turnkey website. Turnkey
websites are becoming more popular as the internet grows.

Turnkey products are synonymous to "off-the-shelf" solutions and not customized. In real estate,
turnkey is defined as delivering a location that is ready for occupation. The turnkey process includes
all of the steps involved to open a location including the site selection, negotiations, space planning,
and construction coordination and complete installation.

10.9PLANNING FOR PROCUREMENT

Procurement planning is the process of identifying which part of the project should be procured from
resources outside of the organization. Generally, procurement decisions are made early on in the
planning processes. Procurement planning centers on four elements:

• Whether or not procurement is needed

• What to procure
• How much to procure
• When to procure

Referring to the Scope Statement

The project’s scope statement serves an input to making procurement decisions. As the project scope
statement defines the project work, and only the required work, to complete the project, it also defines
the limitations of the project. Knowing these limits of what the project includes can help the project
manager, the contract specialists, or other procurement professional, determine what needs to be
purchased and what does not.

Referring to the Product Description

The product description defines the details and requirements for acceptance of the project. This
information also serves as valuable input to what needs to be procured - and to what does not. The
product description defines what the end result of the project will be. When dealing with vendors to
procure a portion of the project, the work to be procured must support the requirements of the project
customer.
A statement of work (SOW) may define the work to be accomplished within the project, but it generally
does not define the product description as a whole. However, when an entire project is to be procured
from a vendor, the SOW and the product description become one and the same.

Relying on Procurement Resources

Often an organization will have resources for managing the procurement process, including contracting
and negotiating on behalf of the project. If, however, the performing organization has no such resources
for the project manager to rely upon, then it is up to the project manager to supply the procurement
management resources, including capabilities for negotiating and for obtaining in a fiscally responsible
way the right products or services for a fair price on behalf of the performing organization.

Evaluating the Market Conditions

Part of procurement management is to determining what sources are available to provide the needed
products or services for the project. An evaluation of the marketplace is needed to determine what
products and services are available and from whom and on what terms and conditions they are
available.

While in most free market enterprise societies there are multiple vendors offering comparable
products, there may be times when choices of vendors are limited. There are three specific terms to
know for the procurement planning:

• Sole source - Only one qualified seller exists in the marketplace.

• Single source - The performing organization prefers to contract with a specific seller.
• Oligopoly - There are very few sellers and the actions of one seller will have a direct affect on the
other seller’s prices and the overall market condition.

Evaluating Assumptions, Constraints, and Other Factors

The project assumptions and constraints can have direct influence on the procurement process. For
example, a project with a time constraint to complete a project by a given deadline may be forced to
procure additional laborers to complete portions of the project work in order to complete the project
as scheduled Completing Procurement Planning.

Procurement planning should be done early in the planning processes, with certain exceptions. As
needs arise, as project conditions change, or as other circumstances demand, procurement planning
may be required throughout the project. Whenever procurement planning happens early in the project,
as preferred, or later in the project, as needed, a logical approach to securing the proper resources is
necessitated.

Determining to Make or Buy

The decision to make or buy a product is a fundamental aspect of management. In some conditions it
is more cost effective to buy—while in others it makes more sense to create an in-house solution. The
make-or-buy-analysis should be made in the initial scope definition to determine if the entire project
should be completed in-house or procured. As the project evolves, additional make-or-buy decisions
are needed.
The initial costs of the solution for the in-house or procured product must be considered, but so too
must the ongoing expenses of the solutions. For example, a company may elect to lease a piece of
equipment. The ongoing expenses of leasing the piece of equipment should be weighed against the
expected ongoing expenses of purchasing the equipment and the monthly costs to maintain, insure,
and manage the equipment.
For example, following details show the mathematical approach to determining the whether it is better
to create a software program in-house or buy one from a software company. The in-house solution will
cost your company $25,000 to create your own software package and, based on historical information,
another $2,500 per month to maintain the software.
The development company has a solution that will cost your company $17,000 to purchase, but the
development company requires a maintenance plan for each software program installed, which will
cost your company $2,700 per month. The difference between making the software and buying the
software is $8,000. The difference between supporting the software the organization has made and
allowing the external company to support their software is only $200 per month.
The $200 per month is divided into the difference between creating the software internal and buying
the software—which is $8,000 divided by $200—40 months. If the software is to be replaced within
40 months, the company should buy the software. If the software will not be replaced within forty
months, it should build the software.

There are multiple reasons why an organization may choose to make or buy. Here are some common
examples or reasons for making: Reasons to Buy
• Less costly
• Use in-house skills
• Control of work
• Control of intellectual property
• Learn new skills
• Available staff
• Focus on core project work Here are some common examples or reasons for buying:
• Less costly
• In-house skills aren’t available or don’t exist
• Small volume of work
• More efficient
• Transfer risks
• Available vendor
• Allows project to focus on other work items

Using Expert Judgment

Procurement planning can rely on expert judgment. It may be beneficial to rely on the wisdom of
others—those in the performing organization or subject matter experts—to determine the need for
procurement. Expert judgment for procurement management planning can come from the following:
• Units or individuals within the performing organization
• Consultants and subject matter experts
• Professional, trade, or technical associations
• Industry groups

Determining the Contract Type

There are multiple types of contracts when it comes to procurement. The project work, the market, and
the nature of the purchase determine the contract type. Here are some general rules that project
managers, should know:
• A contract is a formal agreement between the buyer and the seller. Contracts can be oral or
written—though written is preferred.
• Contracts should clearly state all requirements for product acceptance.
• Any changes to the contract must be formally approved, controlled, and documented.
• A contract is not fulfilled until all of the requirements of the contract are met.
• Contracts can be used as a risk mitigation tool, as in transferring the risk.
• All contracts have some level of risk; depending on the contract type, the risk can be transferred to
the seller. If a risk response strategy is to transfer, risks associated with procurement are considered
secondary risks and must go through the risk management process.
• There are legal requirements governing contracts. In order for a contract to be valid, it must:
- Contain an offer
- Have been accepted
- Provide for a consideration (payment)
- Be for a legal purpose
- Be executed by someone with capacity and authority
- The terms and conditions of the contract should define breaches, copyrights, intellectual
rights, and force majeure.

10.10 SUPPLIER SELECTION FOR PROJECT

Most of the project leaders are coming to a point in their project, where they have to initiate a
process to select a supplier. Following is one of the supplier selection processes:
• Defining Role and responsibilities of the project leader
• Requirements definition
• Identification of potential suppliers
• Call for bids
• Selection of the supplier
• Contract administration
In this unit, we will tackle the most important points about requirements, definition, and in particular,
the supplier assessment grid.
Roles and Responsibilities of the Project Leader
The project leader has to ensure that the process is efficient, effective and ethical, that it is implemented
and followed. In concrete terms, when selecting a supplier:
• The process is effective if the selected supplier delivers the expected goods and services, those
which will contribute to meeting the project goals and objectives.
• The process is efficient if the time allocated to the supplier is reasonable so they can provide
quality responses to the call for bids.
• The process is ethical, if all suppliers get the same information and that the selection decision
is made based on pre-established and objective criteria.

The responsibility of the project leader is to make sure that those three elements are considered during
the planning of the selection process.
It is interesting to note that the project leader does not have to be involved neither in the supplier
evaluation proper, nor in the selection of the candidates. He only has to make sure that the evaluation
is performed by competent people.
Requirements definition vs. assessment grid
The first step is to define the requirements to the supplier. Those requirements are both functional –
the supplier has to conform to a specific need – and non-functional – the supplier has to prove he is
competent to fill the mandate. Precise and clear requirements avoid bad surprises down the road.
The Assessment Grid
The best way to select the best supplier is to define the decision criteria in advance, including:
The acceptable minimum and/or maximum position. Supplier outside the limits are simply eliminated.
For example, one can demand a certain delivery deadline, a maximal cost, a minimal number of
customer references, or a must requirement, which must be met at 100%. Such requirements are
considered as basic.
An assessment grid with all the criteria and how to translate these into a score. Will the evaluation be
made as a percentage, a value between 1 and 4, 1 and 10, etc.? It should be clear how to evaluate each
criterion. For example, if the suppliers were asked to provide customer references, with a description
of the project; the assessment grid could take into account the relevance of this project. If the project
was practically identical, the maximum score is awarded (100%, 4, 10…). If the project is quite
different, a low score is awarded, and so on. More specific assessment grids result in higher quality of
evaluation.
The weight of each criterion is in relation with others. Requirements do not have the same value. We
already talked about the acceptable minima, those affecting the go/no-go. They normally have the
same value for all suppliers passing this initial filter. A weighting must be defined for the remaining
criteria. Most often, some technical requirements are more important than others.
In the end, the assessment grid allows to quickly compare the different suppliers. If this grid is prepared
in parallel with the requirements definition, the RFP document will be more complete and the selection
phase will be simplified.

Categories of Criteria
The assessment criteria, closely linked to the requirements, can belong to one of 5 categories:
• The quality of the responses to the RFP
• The depth of the supplier
• The past experience of the supplier
• Respect of the deadlines
• Cost of the goods and services

The quality of the responses: For each requirement, the response quality can be evaluated. Did the
supplier understand? Is the proposed solution adequate? Is it clear the supplier knows what he is talking
about? Does he understand the goals of the project?
The depth of the supplier: Next, the supplier’s technical competence can be evaluated. What is the
profile of the individuals assigned to the project? Is the project team composition clear and firm? What
is the size of the company? What is its production capacity? Can they run the project without over-
committing themselves? How long do they exist for? Are they in a good financial situation? What kind
of contracts do they have with their employees, are they permanent employees, contractual…? Was
there a contact with the technical team or just with sales? What skills does the supplier have to manage
his part of the project? Did we already work with this supplier? If yes, how did the other project leaders
rate them?
The supplier’s past experience: Has the supplier already done similar projects? Are customer
references available? How did their other customers rate them?
Respect of the deadlines: Are the proposed milestones realistic? Are they based on solid estimates?
Are those estimates available?
Costs: What exactly is proposed by the supplier? Are the cost estimates reasonable? Can they allow
the supplier to earn a decent (but not exaggerated) margin? Obviously, each project has its own
assessment grid. From project to project, some criteria might not be needed, while new ones may have
to be defined.
Supplier selection must produce stellar results as companies increase their focus on supply-chain
management and push more requirements down the chain to their partners. Business continues, but
with different strategies. For example, Siemens AG plans to reduce costs by centralizing 47% of its
procurement spending by 2010, compared to its current level of 29%. Clearly, companies are viewing
changes in supplier management as a way to gain more value from their partners. Consequently,
performance expectations are increasing, and companies are using their supplier partnerships as a
means of driving innovation. Using the right supplier selection tools can play a critical role in building
value-based relationships.

10.11 ROBINSON MODEL

For every procurement project, a formal and professional procurement process will save time, save
money and reduce risk. This unit shows you how to hit the ground running with a procurement project
and to deliver a professional result.
The past two decades have witnessed a fundamental change in the role of purchasing functions in many
organisations. Traditionally purchasing has had a rather obscure position in most companies, as it has
been considered as a separate function just dealing with operational issues, such as making orders and
receiving deliveries from suppliers. However, nowadays the role of purchasing among project
organisations’ activities has become more and more important. In other words, the needs of the
customers are to become more sophisticated and therefore the offerings provided by companies are to
be more differentiated as well. Thus, also the purchasing function has to be more sophisticated in order
to ensure the effectiveness of the firm. This of course requires a well-designed and competent
purchasing function playing an important role in the company’s business processes.
The productivity of purchasing is particularly significant for most project organisations, because of the
fact that the gains attained through successful purchasing operations influence directly the bottom line
of the companies’ income statement. Organisations’ Project purchasing functions often involve large
expenditures, draining a large proportion of a company’s income or a public organisation’s budget.
The purchasing process has been broadly defined as the set of actions and dynamic factors that begins
with the identification of a stimulus for action and ends with the specific commitment to action. The
phases of the organisational buying process have been formulated by several researchers, each of them
presenting more or less similar listings of the phases constituting the industrial buying process. One of
the most often cited illustrations of this purchasing process is the Buy-Phase model presented
Robinson, Faris and Wind (1967). According to this, the process of making a purchasing act goes
through eight phases, beginning with the recognition of the need and ending as the purchased product’s
performance is evaluated.
The Steps in The Purchasing Process (Robinson et al. 1967 p. 14).
According to the buy-phase model (Robinson et al. 1967), the acquisition of a product or service begins
as the need is identified (Stage 1). The following steps include determination of the characteristics and
quantity of the needed item (Step 2), and preparing description of these (Stage 3), searching for
potential suppliers (Stage 4), acquisition and analysis of the proposals (Stage 5) and selecting the best
supplier (Stage 6). Finally, the practical order procedures must be selected (Stage 7) and after receiving
the product, the performance must also be evaluated (Stage 8). This kind of description of the
purchasing conducted in organisations is, however, not in accordance with all the buying situations
taking place in industrial organisations. Evidently, such a complicated and long process is not needed
in every buying situation and this has lead researchers to use another perspective as well. The way
companies conduct their purchasing activities is affected by the kind of products they are buying.
Several different kinds of product classifications have been formulated for this purpose.

10.12 SUMMARY

Procurement is the acquisition of goods or services. Almost all procurement decisions include factors
such as delivery and handling, marginal benefit, and price fluctuations. Procurement generally involves
making buying decisions under conditions of scarcity. If good data is available, it is good practice to
make use of economic analysis methods such as cost-benefit analysis or cost-utility analysis. Based on
the consumption purposes of the acquired goods and services, procurement activities are often split
into two distinct categories. The first category being direct production-related procurement and the
second being indirect non-production-related procurement.

The procurement process can be divided into five steps: Define the business need, Develop the
Procurement Strategy, Supplier Selection and Evaluation, Negotiation and award, Induction and
Integration.

Procurement life cycle in modern businesses usually consists of following steps:

Identification of need, Supplier Identification, Supplier Communication, Negotiation, Supplier
Liaison, Logistics Management, Tender Notification

The US Defense Acquisition University (DAU) defines procurement as the act of buying goods and
services for the government. DAU defines acquisition as the conceptualization, initiation, design,
development, test, contracting, production, deployment, Logistics Support (LS), modification, and
disposal of weapons and other systems, supplies, or services (including construction) to satisfy
Department of Defense needs, intended for use in or in support of military missions.
Procurement is generally based on competitive bidding. Depending on the type, complexity, size and
value of the project and its procurement elements.

The Purchasing process usually starts with a 'Demand' or requirements – this could be for a physical
part (inventory) or a service. A requisition is generated, which details the requirements (in some cases
providing a requirements speciation) which actions the procurement department. A Request for
Proposal (RFP) or Request for Quotation (RFQ) is then raised. Suppliers send their quotations in
response to the RFQ, and a review is undertaken where the best offer (typically based on price,
availability and quality) is given the purchase order.

Purchase orders (PO) can be of various types, including:

•Standard - a onetime buy;
•Planned - an agreement on a specific item at an approximate date; and
•Blanket - an agreement on specific terms and conditions: date and quantity and amount are not
specified.

Procurement planning is the process of identifying which part of the project should be procured from
resources outside of the organization. Generally, procurement decisions are made early on in the
planning processes. Procurement planning centers on four elements:
• Whether or not procurement is needed
• What to procure
• How much to procure
• When to procure
Most of the project leaders are coming to a point in their project, where they have to initiate a process
to select a supplier. Following is one of the supplier selection processes:
• Defining Roles and responsibilities of the project leader
• Requirements definition
• Identification of potential suppliers
• Call for bids
• Selection of the supplier
• Contract administration
For every procurement project, a formal and professional procurement process will save time, save
money and reduce risk. The purchasing process has been broadly defined as the set of actions and
dynamic factors that begins with the identification of a stimulus for action and ends with the specific
commitment to action. As per Robinson Model, Purchasing includes following steps: Problem
Recognition, Need description, Product Specification, Supplier Search, Proposal Solicitation, Supplier
Selection, Order preparation, Performance Evaluation

10.13 KEYWORDS
Request for Quotation (RFQ) - An RFQ is an informal invitation to submit a quotation. The request
is given by buyer to the prospective sellers.
Invitation to Bid (ITB) - An ITB is a formal invitation to submit a bid, usually associated with
requirements that are clearly and concisely defined; with high procurement value normally price is the
sole determinant in making an award. Where all technical criteria are met, award is made to the lowest
bidder.
Request for Proposal (RFP) - An RFP is a formal request to submit a proposal, usually associated
with requirements for services, which cannot be clearly or concisely defined, with high procurement
value. Price is only one of several factors comprising the evaluation criteria. Award is made to the
qualified bidder whose bid substantially conforms to the requirement set forth on the solicitation
documents and is evaluated to be the lowest cost.
Purchasing - Purchasing is the formal process of buying goods and services. The Purchasing Process
can vary from one organization to another, but there are some common key elements.
Turnkey Project - A turnkey or a turnkey project (also spelled turn-key) is a type of project that is
constructed so that it could be sold to any buyer as a completed product.
 UNIT 11 PROJECT CLOSING

Objectives

After reading this unit, you will be able to:

• Arrange for project closing;

• Undertake the closing out phase activities;
• Explain the responsibilities of project leader in closing of a project;
• Arrange for resources for project closing.

Structure

11.1 Introduction to Project Closing

11.2 Purpose of Project Closing
11.3 Elements of Project Closing
11.4 Turnover of Projects
11.5 Lessons Learned
11.6 Project Close Out Report
11.7 Post Implementation Review
11.8 Analyzing Project Results
11.9 Responsibilities of Project Leader
11.10 Project Closure Activities as Given by PMP
11.11 Summary
11.13 Keywords

11.1INTRODUCTION TO PROJECT CLOSING

Project Closing includes the formal acceptance of the project and the ending thereof. Administrative
activities include the archiving of the files and documenting lessons learned.

This phase consists of:

Project close: Finalize all activities across all of the process groups to formally close the project or a
project phase.

Contract closure: Complete and settle each contract (including the resolution of any open items) and
close each contract applicable to the project or project phase.
In this unit, we will discuss the activities required to be done in closing phase and importance of closing
phase of projects.

11.2PURPOSE OF PROJECT CLOSING

The purpose of the closing phase in the project management lifecycle is to confirm completion of
project deliverables to the satisfaction of the project sponsor, and to communicate final project
disposition and status to all participants and stakeholders. There are two parts to closing a project in
Computing Services.
Project closure ensures that all participants and stakeholders to the project are informed of follow-on
activities (e.g. new projects, service transitions, OLAs, service portfolio updates, etc.), and have
sufficient opportunity to communicate and coordinate with related projects and/or production service
owners.

In the case of discovery projects, emphasis is placed on the findings and recommendations report. In
the case of delivery projects, the emphasis is on implementation and transition to the production and
operational environment. Closing activities also include identification and capture of lessons learned
and best practices, and archival of project deliverables for subsequent reference, organizational
learning and reuse.

11.3ELEMENTS OF PROJECT CLOSING

The Project Closeout Phase is the last phase in the project lifecycle.

Closeout begins when the user accepts the project deliverables and the project oversight authority
concludes that the project has meet the goals established. The major focus of project closeout is
administrative closure and logistics. Project closeout includes the following key elements:

• Turnover of project deliverables to operations

• Redistributing resources—staff, facilities, equipment, and automated systems
• Closing out financial accounts
• Completing, collecting, and archiving project records
• Documenting the successes of the project
• Documenting lessons learned
• Planning for Post Implementation Review

11.4TURNOVER OF PROJECTS

The most important aspect of project closeout is the physical turnover of control of the product, good,
or service delivered by the project. All project deliverables will need to be maintained and supported
after the project team disbands. An operational unit of the organization (for which the deliverable is
developed) assumes responsibility for the support of the deliverable. Procedures for this turnover and
acceptance by the operational unit must be determined. Turnover and acceptance activities include but
are not limited to knowledge transfer, documentation transfer, and physical transfer of the deliverable.

A formal acknowledgement of receipt (acceptance) of the project deliverable is executed by the

operations and project managers.

Administrative Closure
Administrative closure involves the preparation of administrative documentation, collection of project
documentation, disposition of project documents, and logistics activities that ensure that the project
resources are redistributed. Administrative closure includes, but is not limited to, task such as
archiving, financial account closure, facilities turnover (or closure), contract closure, and personnel
reassignment.

Collecting Project Archive Data

Historic project data is an important source of information to help improve future projects. Typically,
the following project data is archived:

• Project notebook
• Project concept document
• Project Charter
• Project Plan
• Project management and oversight review records
• Correspondence
• Meeting notes
• Status reports
• Contract file
• Technical documents, files, program, tools, etc.

All records should be stored. Summary technical information should be electronically stored for
historical reference to facilitate later review. The project archive should include a description of the
files being submitted, the application (including version) used to create the archived materials, and a
point of contact.

Personnel
If personnel have been committed to the project full-time, it is important to get the people back into
the available resource pool as quickly as possible. This will ensure that the staff stays busy and that
other projects within the organization do not fall short of resources. In some cases, employee
performance reports or other documentation must be prepared for personnel assigned to the project
manager. In matrix organizations, the project manager should communicate to the functional manager
information about the performance of the employee. The project manager should also make
recommendations for recognition of performance as the case may warrant. Before any employee is
officially transferred, the project manager or his representative must ensure that all project materials
and property are turned over by the employee. The project manager must also ensure that each
employee’s project hours have been accounted for and charged to the project.

Facilities
If the project team has occupied agency facilities for a long period of time during the project, it is a
good idea to let the controlling facilities personnel know that the space used for the project will become
available again. Be sure to check facilities guidance documentation to determine whether changes
made to the project team area (structure, equipment, or technical modifications) are the responsibility
of the project team after the project is complete. Returning the facility and equipment to its original
state could add unanticipated cost and manpower to a project.

Financial Account Closure

Financial closure is the process of completing and terminating the financial and budgetary aspects of
the project. Financial closure includes both (external) contract closure and (internal) project account
closure. All expenditures must be accounted for and reconciled with the project account. When
financial closure is completed, all expenditures made during the project have been paid as agreed to in
purchase orders, contracts, or inter-agency agreements.

Contract Closure
Contract closure is the process of terminating contracts with external organizations or businesses.
These contracts may be vehicles for providing technical support, consulting, or any number of services
supplied during the project that the agency decided not to perform with internal resources. Contracts
can be brought to closure for a variety of reasons, including contract completion, early termination, or
failure to perform. Contract closure is a typical but important part of project management. It is a simple
process, but close attention should be paid so that no room is left for liability of the agency.

In order to close a contract, it is important to collect all of the pertinent documentation for review. This
will include all of the original contracts and supporting documentation such as schedules, contract
changes, and performance reports. This documentation needs to be reviewed thoroughly to ensure
there are no unrealized contract issues that could result in legal liability. A thorough review of the
procurement and contracting documents must include contract milestones, services provided, or
deliverables and documentation delivered.

To formally close a contract, the agency provides the contracted company or organization with a formal
written notice stating the completion of the contract and reason for termination. Standard verbiage for
acceptance and closure is usually found in the original contract itself.

It is also a good idea to keep a complete set of contractual records for the project in a safe and accessible
place in case they need to be referenced at any point in the future.

11.5LESSONS LEARNED

Lessons learned are the documentation of the experience gained during a project. These lessons come
from working with or solving real-world problems. Lessons learned document identified problems and
how to solve them. Lessons learned are gathered to help eliminate the occurrence of the same problems
in future projects.
Lessons learned typically provide: a brief discussion of the problem to identify its nature, source, and
impact; site any references that provide additional detail (references may include project reports, plans,
issue logs, change management documents); and general literature or guidance used from another
source; and, recording the corrective actions taken and results.

Lessons Learned Sessions

In addition to communicating the closure of a project in writing, it is also advisable to have a
mechanism for group review. Lessons learned sessions are valuable closure and release mechanisms
for team members, regardless of the project's success. The lessons learned session is typically a
meeting or a series of meetings that may include the following:
• Project team
• Stakeholder representation—including external project oversight
• Executive management
• Maintenance and operation staff

For a lessons learned session to be successful the problems encountered by the project team must be
openly presented. It is important, however, that the problem discussions do not merely point a finger
at some target other than the project team; responsibility and ownership for problem areas are critical
to developing useful recommendations for future processes.

Problems that were encountered should be prioritized with focus on the top five to ten problems. It is
not necessary to document every small thing that happened. However, all legitimate problems and
issues should be discussed as requested by customers or management.

Lessons Learned Format

There are numerous formats for documenting lessons learned. Typically, each lesson learned is
documented on a single page. The document should contain in its heading the name of the project,
date, and point of contact for the lesson learned. The body should describe the lesson learned in the
following paragraphs:

Statement of the Problem: Describe the problem that occurred. Provide sufficient detail to establish
what happened.

Discussion: Describe in detail the cause and impact of the problem.

References: Provide any references used or other sources of information that may be helpful in
understanding the problem or corrective actions.

Corrective Actions: Identify what corrective actions were taken and discuss the results. If a corrective
action was not taken, but became apparent later, identify this action as well.

Project Closeout Transition Checklist

The Project Transition Checklist provides a vehicle to verify completion of a project phase before
beginning the next phase. The transition checklist used at the closeout phase focuses on completion of
project tasks and satisfying acceptance criteria. Additionally, the transition checklist forces the project
team and using organization to address the issue transfer for both the deliverable and associated
documentation. Project Closeout Transition Checklist is a list of questions that indicates necessary
actions have been accomplished before completing the Project Closeout Report. The checklist provides
a status column where the completion status of project elements is recorded. Comments or plans to
complete items that have not been addressed are also documented on the checklist.

11.6PROJECT CLOSEOUT REPORT

Project close out report generally includes following details:

General Information
Basic information that identifies the project.

Project Title – The proper name used to identify this project.

Project Working Title – The working name or acronym used to identify the project. If an acronym is
used, define the specific meaning of each letter.

Proponent Secretary – The Secretary to whom the proponent agency is assigned or the Secretary that
is sponsoring an enterprise project.

Proponent Agency – The agency that will be responsible for the management of the project.

Prepared by – the person(s) preparing this document.

Date/Control Number – The date the report is finalized and the change or configuration item control
number assigned.

Project Deliverables
List all product or service deliverables in the first column. In the second column record the date that
each deliverable listed in the first column was accepted.

Describe any contingencies or conditions related to the acceptance of the deliverables listed in the first
column.

Performance Baseline
Evaluate how the project performed against each of the performance goals established in the Project
Performance Plan. Copy the first two columns from the Project Performance Plan. In the third column,
record the results of the measurement of performance prescribed in the Project Performance Plan.

D. Cost (Budget) Baseline

State the actual cost of the project and compare it to the planned cost baseline. In the Variance column,
record the difference between planned and actual cost. Provide the reason for the variance in the
Explanation column. Include in the explanation information on any approved changes to the cost
baseline and their impact on the project. Document and explain all cost and funding variances,
including approved changes to the cost baseline.

E. Schedule Baseline
Compare the initial approved schedule baseline against the actual completion dates. Extract the WBS
Elements, Start Dates, and Finish Dates from the baseline schedule and record them in the WBS
Element, Planned Start Date, and Planned Finish Date Columns. Record the Actual Start Date and
Actual Finish Date for each WBS element in the columns with those headings. In the Explanation for
Change column, provide a brief reason for any difference(s) and describe the impact on the project.

F. Scope
Document any changes to the project scope and describe the impact of each change on performance,
cost, or schedule baselines in the appropriate column.

G. Operations and Maintenance

Describe the plan for operation and maintenance of the product, goods, or service delivered by the
project. State the estimated annual cost to operate and maintain the product, good, or service. If the
estimated cost differs from the original cost estimate in the project proposal, identify where and why
the estimated cost differs. If the operation and maintenance plan is not in place, specify when the plan
will be completed and what the impact is of not having a plan for the operations and maintenance of
the product, goods, or services delivered.

H. Project Resources - List the resources used by the project in the first column. In the second column,
identify to whom the resource was transferred. In the next column, indicate when the resource was
transferred. Account for all project resources specified in the Resource Plan and utilized by the project.

I. Project Documentation
Identify all project documentation materials stored in the project library or other repository. Identify
the type of media used and the disposition of the project documentation (see Communications Plan).

J. Lessons Learned
Identify lessons learned for feedback to the Commonwealth Project Management process. Lessons
learned are identified as problems (or issues). Provide a brief discussion of the problem that identifies
its nature, source, and impact. Site any references that provide additional detail. References may
include project reports, plans, issue logs, change management documents, and general literature or
guidance used that comes from another source. Record the corrective actions taken and results in the
last column.

K. Dates for Post Implementation Review and Report

Identify the date for completing the post implementation report and the person responsible for this
action.

L. Approval
The person(s) making the report authenticate its contents by signing as appropriate.

11.7POST IMPLEMENTATION REVIEW

A Post Implementation Review and Report documents the successes and failures of the project
deliverable. The review process should be directed by the project sponsor or manager. The review is a
collection of data from the organization and users about the deliverable. The data will be used in a
report that is focused on how well the deliverable performed, how well users accepted the deliverable,
and what is the actual cost to operate and maintain the deliverable. Fundamentally, the report addresses
whether or not the projected return on investment was achieved.

The report will specifically address:

• How well the deliverable solved the Business Problem identified in the Project Charter
• Impact the deliverable had on the Agency Core Business Activities
• Project Performance Measures
• Actual operational cost versus projected operational cost
• User acceptance or satisfaction with the delivered product
• Organizational change required or resulting from the deliverable
• Actual Return on Investment for the period versus projected return on investment

11.8ANALYZING PROJECT RESULTS

The next section details the key project performance metrics, including an assessment (rating) for each
type of performance metric (cost, schedule, change, and quality), and a brief explanation of the team’s
performance associated with the metric. The discussion in this section is generally organized based
upon the type of performance metric.

Budget Performance
Budget performance metrics describe how effectively the team was able to manage to the baseline
project budget. Budget performance metrics include:

Final Cost: What was the final actual cost of the project?

Breakdown by Component: Breakdown of the final cost by cost category (same costs categories that
have been tracked and reported throughout the project life cycle). It is helpful to provide the breakdown
with both total cost by category, as well as % of total.

Budget Variances: What is the difference between the baseline budgeted costs and the actual cost?
This should be detailed in dollars and as a percent of the project budget. Detailing the variance by cost
category clarifies the source of the cost variances.

Budget Performance Rating: Based upon the % budget variance, assign a Green/Yellow/Red rating to
budget performance for the project. The budget rating is best defined at the beginning of the project in
the cost management section of the project management plan (e.g., Green <10%, Yellow 11-20%,
Red>20%).

Explanations for Key Variances: Represents a descriptive narrative explaining the key budget
variances. I find it beneficial in the variance description to quantify how much each variance source
accounts for the total variance (in dollars or as a percent).

Schedule Performance
Schedule performance metrics describe how effectively the team was able to manage to the baseline
project schedule. Schedule performance metrics include:

Total Duration: What was the actual duration of the project (from the start date to the end date)? Even
though people may be close to the project, it is surprising how many do not know the day it started, or
how long they have been working on it.

Schedule Variances: What is the difference (in days) between the baseline end date and the actual end
date? This should be detailed in days and as a percent of the total project duration. To provide
clarification of the cause of the variance it is also helpful to provide the variances (days and percent)
for each of the project phases/milestones.

Schedule Performance Rating: Based upon the % schedule variance, assign a Green/Yellow/Red
rating to schedule performance for the project. The schedule rating is best defined at the beginning of
the project in the schedule management section of the project management plan (e.g., Green <10%,
Yellow 11-20%, Red>20%).

Explanations for Key Variances: Represents a descriptive narrative of the schedule variance
explanations. Again, I find it beneficial in the variance description to quantify how much each variance
source accounts for the total variance (in days or as a percent).
Change Management
Change management metrics highlight the team’s ability to manage change throughout the project life
cycle. Key change metrics include:

Total number of changes: Breakdown of the total number of change requests submitted, and the
number that were approved and implemented. In addition, it is often helpful to provide a breakdown
of the approved/implemented requests in terms of the number that impacted scope, schedule and cost.

Impact of the change: Sum of the impact of the approved/implemented change request on the project
schedule (days) and budget (cost). This represents the cumulative impact of change on the project.

Highlight of key changes: A detailed description of the key changes that were implemented. In this
section it may also be appropriate to highlight changes that were not approved, particularly if they are
intended to be deferred to future product releases.

Approved change vs. Total variance: A comparison of the total impact of change on the project vs.
the total project variances (schedule and budget) provides a good indication of how much change
accounts for the total project variances. In other words, were project variances managed in a proactive
manner (via the change management process) or reactive manner (via after the fact variance
explanations) throughout the project.

Other Metrics
There are often other metrics of interest about the project that may not have been within the scope of
the normal performance reporting by the project manager. Some examples include:

Duration / Effort by Phase: One of the questions that is often asked about projects is what was the
breakdown of time and/or effort in each of the project phases? Although each project is going to be a
little different, this is information that will be useful for assessing the reasonableness of plans for future
projects. Another interesting measure is the percent of the total effort for specific functions (e.g.,
project management, requirements definition, coding, testing, and training). This type of metric can be
used for estimating high level resource requirements for future projects.

Benefits Realized to-date: What benefits have been realized to-date as a result of the project? How do
the results compare to the expected benefits identified in the project charter? Because the project
closure is likely happening soon after the product is implemented, these may represent “preliminary”
results (with an explanation of when more conclusive results will be communicated).

Benchmark comparisons: How did the performance on this project compare to other projects (within
the project office, company, or compared with industry data)? What were some of the differentiators
for this project compared to that data (either positive or negative)?

QA Metrics: What were the number / percentage of defects reported within each project phase? Test
cycle? What was the closure vs. discovery rate for defects? What conclusions can be drawn from the
QA metrics?

Feedback & Next Steps

The final section of the Project Closure summarizes the process and results of gathering stakeholder
feedback.
Process: Summary of the feedback survey and lessons learned processes. Who was solicited for
feedback? What was the response (# of surveys, # of participants)? How was the lessons learned
discussion organized and facilitated?

Rating Metrics: What was the average score for each question? What was the number of very high or
very low scores for specific questions? I often include commentary as to why the score is the way it is
(if you received comments that help explain some of the scoring).

Key Themes: What were some of the common themes from comments on the survey or during the
lessons learned session?

Opportunities: What are the high priority opportunities (those opportunities to improve, or leverage
what was done well for future projects / product releases)?

Next Steps: What are the action items to ensure that the opportunities are moved forward in the right
direction? Where possible, include owner assignments and target dates in this section of the document.

Project Closure Reporting Process

Limited Original Work: If the project execution and closure activities (product performance reporting,
product validation, and stakeholder feedback/lessons learned) have been effectively performed, the
project closure report represents a summarization related effort, versus an effort involving a significant
amount of original work.

Executive Summary: Many of the stakeholders consuming the Project Closure Report are looking for
high points about what was delivered, how effectively was it delivered, and what have we learned from
it. Make sure you include an Executive Summary section in the beginning of the report that effectively
communicates the information these Stakeholders are looking for.

Variance Explanations: Ensure that variance explanations are fact based, and describe the impact the
source of the variance had on the performance metric (e.g., the specific source accounts for x% of the
total variance).

Next Steps: The Project Closure Report clearly links the project performance to the lessons learned
and the continuous improvement related next steps. Stakeholders will be “scratching their heads” if
the lessons learned and next steps are not related to the project performance (cost, schedule, change,
or quality).

11.9RESPONSIBILITIES OF PROJECT LEADER

Applicability and use of closure deliverables is largely dependent upon project attributes (size, scope,
complexity, etc.) and project performance across the key dimensions of scope, schedule, cost and
quality (for example, were there issues with scope, cost, budget, customer satisfaction, etc.?).

For a completed project, the project lead is responsible to:

 • Confirm, preferably in writing, from the project sponsor and/or customers that the project is
complete.
• If applicable, complete the Closure Report (Optional but recommended)
• Work to schedule and conduct a Lessons Learned Meeting. Meeting notes produced during the
lessons learned should be attached to the project briefcase
• If your project has created or significantly changed a divisional service, ensure that the service
is reflected in the Service Portfolio.
• Arrange for an appropriate celebration of the work completed. Remember to have fun!
• Close and deactivate the project.

11.10 PROJECT CLOSURE ACTIVITIES AS GIVEN BY PMP

A project life cycle incorporates everything from the planning phases to the closing activities that
complete the work. Projects are temporary, meaning they have specific end dates slated for completion,
whether you're developing a software program, customizing a product for a client or developing a new
product. Project closure activities ensure the product you created meets project requirements. The
project closure period also allows you to review the successes and shortcomings for future reference.

The Project Closure Phase is the fourth and last phase in the project life cycle. In this phase, you will
formally close your project and then report its overall level of success to your sponsor.

Project Closure involves handing over the deliverables to your customer, passing the documentation
to the business, cancelling supplier contracts, releasing staff and equipment, and informing
stakeholders of the closure of the project.

After the project has been closed, a Post Implementation Review is completed to determine the
project’s success and identify the lessons learned.

The activities taken to close a project and the templates which help you to complete each activity, are
shown in the following diagram.

Activities
1.
Perform
Project Closure

2.
Review
Project Completion
The first step taken when closing a project is to create a Project Closure Report. It is extremely
important that you list every activity required to close the project within this Project Closure report, to
ensure that project closure is completed smoothly and efficiently. Once the report has been approved
by your sponsor, the closure activities stated in the report are completed.

Between one and three months after the project has been closed and the business has begun to
experience the benefits provided by the project, you need to complete a Post Implementation Review.
This review allows the business to identify the level of success of the project and list any lessons
learned for future projects.

Transfer Deliverable Goods

Depending on the nature of a project, delivering the product to the client is sometimes a step in the
closing process. For example, if you developed a new software program for a specific client, delivering
that software is necessary to close the project. Projects of this nature often require training on the use
of the deliverable goods. In the software example, the transfer might require you to send an employee
to train the recipients how to properly use the program. You are also able to solicit feedback from the
clients on the product itself and the working relationship throughout the project.

Analyze Project

One part of project closure is analysis. Analysis involves the project participants looking back over the
project successes and failures. Conduct a group meeting or individual interviews of the people who
worked on the project. Use the meeting to review the projects outcome in addition to finding out how
the participants felt were roadblocks in the process. Ask for suggestions on making future projects
more successful based on the process and outcome of the closing project.

Finalize Documentation

All projects include documentation of the process, including the initial project requirements,
documentation of the development phases, and the testing records. Any documentation related to the
project should be retained for future reference if necessary. Create a cover sheet for all of the
documentation that provides a brief overview and outline of the project and a list of participants
involved. Organize the documentation chronologically as the project progressed so you or others are
able to easily locate information in the future.

Reassign Resources

At the conclusion of a project, you often have staff members with free time. When closing the project,
you need to reassign those staff members to other projects or duties in the workplace. If you used
contract workers rather than full-time staff the closing phase gives you a chance to determine if you
are able to offer the contributors a different contract position on another project.

11.11 SUMMARY

Project Closing includes the formal acceptance of the project and the ending thereof. Administrative
activities include the archiving of the files and documenting lessons learned. This phase consists of:
Project close and Contract closure.

The purpose of the closing phase in the project management lifecycle is to confirm completion of
project deliverables to the satisfaction of the project sponsor, and to communicate final project
disposition and status to all participants and stakeholders.

The major focus of project closeout is administrative closure and logistics. Project closeout includes
the following key elements:
• Turnover of project deliverables to operations
• Redistributing resources—staff, facilities, equipment, and automated systems
• Closing out financial accounts
• Completing, collecting, and archiving project records
• Documenting the successes of the project
• Documenting lessons learned
• Planning for Post Implementation Review

The most important aspect of project closeout is the physical turnover of control of the product, good,
or service delivered by the project. All project deliverables will need to be maintained and supported
after the project team disbands. An operational unit of the organization (for which the deliverable is
developed) assumes responsibility for the support of the deliverable. Procedures for this turnover and
acceptance by the operational unit must be determined.

Project close out report generally includes following details: General Information, Project
Deliverables, Performance Baseline, Cost (Budget) Baseline, Schedule Baseline, Scope, Operations
and Maintenance, Project Resources, Project Documentation, Lessons Learned, Dates for Post
Implementation Review and Report, Approval

A Post Implementation Review and Report documents the successes and failures of the project
deliverable. The review is a collection of data from the organization and users about the deliverable.
The data will be used in a report that is focused on how well the deliverable performed, how well users
accepted the deliverable, and what is the actual cost to operate and maintain the deliverable.

The project close out includes the key project performance metrics, including an assessment (rating)
for each type of performance metric (cost, schedule, change, and quality). This includes review of
Budget Performance, Schedule Performance, Change Management, Duration / Effort by Phase,
Benefits Realized to-date, Benchmark comparisons, QA Metrics, Feedback & Next Steps

Project Closure Activities As Given by PMP are: Transfer Deliverable Goods, Analyze Project,
Finalize Documentation, Reassign Resources, Project Closure Phase

11.12 KEYWORDS

Administrative Closure - Administrative closure involves the preparation of administrative

documentation, collection of project documentation, disposition of project documents, and logistics
activities that ensure that the project resources are redistributed.

Lessons Learned - Lessons learned are the documentation of the experience gained during a project.
These lessons come from working with or solving real-world problems.

Project Closeout Transition Checklist - Project Closeout Transition Checklist is a list of questions
that indicates necessary actions have been accomplished before completing the Project Closeout
Report.
 UNIT 12 PROJECT RISK MANAGEMENT

Objectives

After reading this unit, you will be able to:

• Identify Risks in the project;

• Evaluate risks in the project;
• Arrange for managing risks in the projects;
• Reduce or avoid risks in the project.

Structure

12.1 Introduction to Project Risk Management

12.2 Risk Management Concept
12.3 Principles of Risk Management
12.4 Risk Identification
12.5 Risk Assessment
12.6 Hierarchy of Risk
12.7 Risk Options
12.8 Risk Management Plan
12.9 Areas of Risk Management
12.10 Project Risk Management Process
12.11 Positive Risk Management
12.12 Risk Communication
12.13 Summary
12.14 Keywords

12.1INTRODUCTION TO PROJECT RISK MANAGEMENT

In recent years all sectors of the economy have focused on management of risk in projects as the key
to making organizations successful in delivering their objectives whilst protecting the interests of their
stakeholders. Risk is uncertainty of outcome, and good risk management allows an organization to:

• Have increased confidence in achieving its desired outcomes;

• Effectively constrain threats to acceptable levels;
• Take informed decisions about exploiting opportunities.
Good risk management also allows stakeholders to have increased confidence in the organization’s
corporate governance and ability to deliver. In this unit we will look at the process of risk management
in the projects.
 12.2RISK MANAGEMENT CONCEPT

Risk management is the identification, assessment, and prioritization of risks (defined in ISO 31000
as the effect of uncertainty on objectives, whether positive or negative) followed by coordinated and
economical application of resources to minimize, monitor, and control the probability and/or impact
of unfortunate events or to maximize the realization of opportunities. Risks can come from uncertainty
in financial markets, project failures (at any phase in design, development, production, or sustainment
life-cycles), legal liabilities, credit risk, accidents, natural causes and disasters as well as deliberate
attack from an adversary, or events of uncertain or unpredictable root-cause. Several risk management
standards have been developed including the Project Management Institute, the National Institute of
Standards and Technology, actuarial societies, and ISO standards. Methods, definitions and goals vary
widely according to whether the risk management method is in the context of project management,
security, engineering, industrial processes, financial portfolios, actuarial assessments, or public health
and safety.

The strategies to manage risk typically include transferring the risk to another party, avoiding the risk,
reducing the negative effect or probability of the risk, or even accepting some or all of the potential or
actual consequences of a particular risk.

Certain aspects of many of the risk management standards have come under criticism for having no
measurable improvement on risk, whether the confidence in estimates and decisions seem to increase

A widely used vocabulary for risk management is defined by ISO Guide 73, "Risk management.
Vocabulary."

In ideal risk management, a prioritization process is followed whereby the risks with the greatest loss
(or impact) and the greatest probability of occurring are handled first, and risks with lower probability
of occurrence and lower loss are handled in descending order. In practice the process of assessing
overall risk can be difficult, and balancing resources used to mitigate between risks with a high
probability of occurrence but lower loss versus a risk with high loss, but lower probability of
occurrence can often be mishandled.
Intangible risk management identifies a new type of a risk that has a 100% probability of occurring
but is ignored by the organization due to a lack of identification ability. For example, when deficient
knowledge is applied to a situation, a knowledge risk materializes. Relationship risk appears when
ineffective collaboration occurs. Process-engagement risk may be an issue when ineffective
operational procedures are applied. These risks directly reduce the productivity of knowledge workers,
decrease cost effectiveness, profitability, service, quality, reputation, brand value, and earnings quality.
Intangible risk management allows risk management to create immediate value from the identification
and reduction of risks that reduce productivity.

Risk management also faces difficulties in allocating resources. This is the idea of opportunity cost.
Resources spent on risk management could have been spent on more profitable activities. Again, ideal
risk management minimizes spending (or manpower or other resources) and also minimizes the
negative effects of risks.

Method for the most part, these methods consist of the following elements, performed, more or less,
in the following order.

• Identify, characterize threats

• Assess the vulnerability of critical assets to specific threats
• Determine the risk (i.e. the expected likelihood and consequences of specific types of attacks on
specific assets)
• Identify ways to reduce those risks
• Prioritize risk reduction measures based on a strategy

12.3PRINCIPLES OF RISK MANAGEMENT

The International Organization for Standardization (ISO) identifies the following principles of risk
management:

Risk management should:

• Create value – resources expended to mitigate risk should be less than the consequence of inaction,
or (as in value engineering), the gain should exceed the pain
• Be an integral part of organizational processes
• Be part of decision-making process explicitly address uncertainty and assumptions be systematic
and structured
• Be based on the best available information
• Be tolerable
• Take human factors into account
• Be transparent and inclusive
• Be dynamic, iterative and responsive to change
• Be capable of continual improvement and enhancement
• Be continually or periodically re-assessed

Process According to the standard ISO 31000 "Risk management – Principles and guidelines on
implementation," the process of risk management consists of several steps as follows:

Establishing the context involves:

• identification of risk in a selected domain of interest
• planning the remainder of the process
• mapping out the following:
- the social scope of risk management
- the identity and objectives of stakeholders
- the basis upon which risks will be evaluated, constraints.
• defining a framework for the activity and an agenda for identification
• developing an analysis of risks involved in the process
• mitigation or solution of risks using available technological, human and organizational resources

12.4RISK IDENTIFICATION

After establishing the context, the next step in the process of managing risk is to identify potential
risks. Risks are about events that, when triggered, cause problems. Hence, risk identification can start
with the source of problems, or with the problem itself.

Source analysis: Risk sources may be internal or external to the system that is the target of risk
management.

Examples of risk sources are: stakeholders of a project, employees of a company or the weather over
an airport.

Problem analysis: Risks are related to identified threats. For example: the threat of losing money, the
threat of abuse of confidential information or the threat of accidents and casualties. The threats may
exist with various entities, most important with shareholders, customers and legislative bodies such as
the government.
When either source or problem is known, the events that a source may trigger or the events that can
lead to a problem can be investigated. For example: stakeholders withdrawing during a project may
endanger funding of the project; confidential information may be stolen by employees even within a
closed network; lightning striking an aircraft during takeoff may make all people on board immediate
casualties.

The chosen method of identifying risks may depend on culture, industry practice and compliance. The
identification methods are formed by templates or the development of templates for identifying source,
problem or event. Common risk identification methods are:
Objectives-based risk identification: Organizations and project teams have objectives. Any event that
may endanger achieving an objective partly or completely is identified as risk.

Scenario-based risk identification: In scenario analysis different scenarios are created. The scenarios
may be the alternative ways to achieve an objective, or an analysis of the interaction of forces in, for
example, a market or battle. Any event that triggers an undesired scenario alternative is identified as
risk – see Futures Studies for methodology used by Futurists.

Taxonomy-based risk identification: The taxonomy in taxonomy-based risk identification is a

breakdown of possible risk sources. Based on the taxonomy and knowledge of best practices, a
questionnaire is compiled. The answers to the questions reveal risks.

Common risk checking: In several industries, lists with known risks are available. Each risk in the list
can be checked for application to a particular situation.

Risk charting: This method combines the above approaches by listing resources at risk, threats to those
resources, modifying factors which may increase or decrease the risk and consequences it is wished to
avoid. Creating a matrix under these headings enables a variety of approaches. One can begin with
resources and consider the threats they are exposed to and the consequences of each. Alternatively,
one can start with the threats and examine which resources they would affect, or one can begin with
the consequences and determine which combination of threats and resources would be involved to
bring them about.

12.5RISK ASSESSMENT

Once risks have been identified, they must then be assessed as to their potential severity of impact
(generally a negative impact, such as damage or loss) and to the probability of occurrence. These
quantities can be either simple to measure, in the case of the value of a lost building, or impossible to
know for sure in the case of the probability of an unlikely event occurring. Therefore, in the assessment
process it is critical to make the best educated decisions in order to properly prioritize the
implementation of the risk management plan.
Even a short-term positive improvement can have long-term negative impacts. Take the "turnpike"
example. A highway is widened to allow more traffic. More traffic capacity leads to greater
development in the areas surrounding the improved traffic capacity. Over time, traffic thereby
increases to fill available capacity. Turnpikes thereby need to be expanded in a seemingly endless
cycle. There are many other engineering examples where expanded capacity (to do any function) is
soon filled by increased demand. Since expansion comes at a cost, the resulting growth could become
unsustainable without forecasting and management.

The fundamental difficulty in risk assessment is determining the rate of occurrence since statistical
information is not available on all kinds of past incidents. Furthermore, evaluating the severity of the
consequences (impact) is often quite difficult for intangible assets. Asset valuation is another question
that needs to be addressed. Thus, best educated opinions and available statistics are the primary sources
of information. Nevertheless, risk assessment should produce such information for the management of
the organization that the primary risks are easy to understand and that the risk management decisions
may be prioritized. Thus, there have been several theories and attempts to quantify risks. Numerous
different risk formulae exist, but perhaps the most widely accepted formula for risk quantification is:
Rate (or probability) of occurrence multiplied by the impact of the event equals risk magnitude

Composite Risk Index - The above formula can also be re-written in terms of a Composite Risk Index,
as follows:

Composite Risk Index = Impact of Risk event x Probability of Occurrence

The impact of the risk event is commonly assessed on a scale of 1 to 5, where 1 and 5 represent the
minimum and maximum possible impact of an occurrence of a risk (usually in terms of financial
losses). However, the 1 to 5 scale can be arbitrary and need not be on a linear scale.

The probability of occurrence is likewise commonly assessed on a scale from 1 to 5, where 1 represents
a very low probability of the risk event actually occurring while 5 represents a very high probability
of occurrence. This axis may be expressed in either mathematical terms (event occurs once a year,
once in ten years, once in 100 years etc.) or may be expressed in "plain English" – event has occurred
here very often; event has been known to occur here; event has been known to occur in the industry
etc.). Again, the 1 to 5 scale can be arbitrary or non-linear depending on decisions by subject-matter
experts.

The Composite Index thus can take values ranging (typically) from 1 through 25, and this range is
usually arbitrarily divided into three sub-ranges. The overall risk assessment is then Low, Medium or
High, depending on the sub-range containing the calculated value of the Composite Index. For
instance, the three sub-ranges could be defined as 1 to 8, 9 to 16 and 17 to 25.

Note that the probability of risk occurrence is difficult to estimate, since the past data on frequencies
are not readily available, as mentioned above. After all, probability does not imply certainty.

Likewise, the impact of the risk is not easy to estimate since it is often difficult to estimate the potential
loss in the event of risk occurrence.

Further, both the above factors can change in magnitude depending on the adequacy of risk avoidance
and prevention measures taken and due to changes in the external business environment. Hence it is
absolutely necessary to periodically re-assess risks and intensify/relax mitigation measures, or as
necessary. Changes in procedures, technology, schedules, budgets, market conditions, political
environment, or other factors typically require re-assessment of risks.

12.6HIERARCHY OF RISK

The management of risk at strategic, programme and operational levels needs to be integrated so that
the levels of activity support each other. In this way the risk management strategy of the organization
will be led from the top and embedded in the normal working routines and activities of the
organization. All staff should be aware of the relevance of risk to the achievement of their objectives
and training to support staff in risk management should be available.
(Source: SU report Risk: improving government’s capability to handle risk and uncertainty, Nov 2002)

Managers at each level therefore need to be equipped with appropriate skills which will allow them to
manage risk effectively and the organization as a whole needs a means of being assured that risk
management is being implemented in an appropriate way at each level. Every organization should have
a risk management strategy, designed to achieve the principles set out in this publication. The
application of that strategy should be embedded into the organization’s business systems, including
strategy and policy setting processes, to ensure that risk management is an intrinsic part of the way
business is conducted.

12.7RISK COMMUNICATION

Risk communication is a complex cross-disciplinary academic field. Problems for risk communicators
involve how to reach the intended audience, to make the risk comprehensible and relatable to other
risks, how to pay appropriate respect to the audience's values related to the risk, how to predict the
audience's response to the communication, etc. A main goal of risk communication is to improve
collective and individual decision making. Risk communication is somewhat related to crisis
communication.

Seven cardinal rules for the practice of risk communication (as expressed by the U.S. Environmental
Protection Agency and several of the field's founders)

• Accept and involve the public/other consumers as legitimate partners (e.g. stakeholders).
• Plan carefully and evaluate your efforts with a focus on your strengths, weaknesses, opportunities,
and threats (SWOT).
• Listen to the stakeholder’s specific concerns.
• Be honest, frank, and open.
• Coordinate and collaborate with other credible sources.
• Meet the needs of the media.
• Speak clearly and with compassion.
 12.8RISK OPTIONS

Following are the common risk management options:

Risk Mitigation
Risk mitigation measures are usually formulated according to one or more of the following major risk
options, which are:

• Design a new business process with adequate built-in risk control and containment measures from
the start.
• Periodically re-assess risks that are accepted in ongoing processes as a normal feature of business
operations and modify mitigation measures.
• Transfer risks to an external agency (e.g. an insurance company).
• Avoid risks altogether (e.g. by closing down a particular high-risk business area).

Later research has shown that the financial benefits of risk management are less dependent on the
formula used but are more dependent on the frequency and how risk assessment is performed.

In business it is imperative to be able to present the findings of risk assessments in financial, market,
or schedule terms. Robert Courtney Jr. (IBM, 1970) proposed a formula for presenting risks in
financial terms. The Courtney formula was accepted as the official risk analysis method for the US
governmental agencies. The formula proposes calculation of ALE (annualized loss expectancy) and
compares the expected loss value to the security control implementation costs (cost-benefit analysis).

Potential Risk Treatments

Once risks have been identified and assessed, all techniques to manage the risk fall into one or more
of these four major categories:

• Avoidance (eliminate, withdraw from or not become involved)

• Reduction (optimize – mitigate)
• Sharing (transfer – outsource or insure)
• Retention (accept and budget)

Ideal use of these strategies may not be possible. Some of them may involve trade-offs that are not
acceptable to the organization or person making the risk management decisions. Another source, from
the US Department of Defense, Defense Acquisition University, calls these categories ACAT, for
Avoid, Control, Accept, or Transfer. This use of the ACAT acronym is reminiscent of another ACAT
(for Acquisition Category) used in US Defense industry procurements, in which Risk Management
figures prominently in decision making and planning.

Risk Avoidance
This includes not performing an activity that could carry risk. An example would be not buying a
property or business in order to not take on the legal liability that comes with it. Another would be not
flying in order not to take the risk that the airplane was to be hijacked. Avoidance may seem the answer
to all risks, but avoiding risks also means losing out on the potential gain that accepting (retaining) the
risk may have allowed. Not entering a business to avoid the risk of loss also avoids the possibility of
earning profits.

Hazard Prevention
Hazard prevention refers to the prevention of risks in an emergency. The first and most effective stage
of hazard prevention is the elimination of hazards. If this takes too long, is too costly, or is otherwise
impractical, the second stage is mitigation.

Risk Reduction
Risk reduction or "optimization" involves reducing the severity of the loss or the likelihood of the loss
from occurring. For example, sprinklers are designed to put out a fire to reduce the risk of loss by fire.
This method may cause a greater loss by water damage and therefore may not be suitable. Halon fire
suppression systems may mitigate that risk, but the cost may be prohibitive as a strategy.

Acknowledging that risks can be positive or negative, optimizing risks means finding a balance
between negative risk and the benefit of the operation or activity; and between risk reduction and effort
applied. By an offshore drilling contractor effectively applying HSE Management in its organization,
it can optimize risk to achieve levels of residual risk that are tolerable.

Modern software development methodologies reduce risk by developing and delivering software
incrementally. Early methodologies suffered from the fact that they only delivered software in the final
phase of development; any problems encountered in earlier phases meant costly rework and often
jeopardized the whole project. By developing in iterations, software projects can limit effort wasted to
a single iteration.

Outsourcing could be an example of risk reduction if the outsourcer can demonstrate higher capability
at managing or reducing risks. For example, a company may outsource only its software development,
the manufacturing of hard goods, or customer support needs to another company, while handling the
business management itself. This way, the company can concentrate more on business development
without having to worry as much about the manufacturing process, managing the development team,
or finding a physical location for a call center.

Risk Sharing
Briefly defined as "sharing with another party the burden of loss or the benefit of gain, from a risk,
and the measures to reduce a risk."

The term of 'risk transfer' is often used in place of risk sharing in the mistaken belief that you can
transfer a risk to a third party through insurance or outsourcing. In practice if the insurance company
or contractor go bankrupt or end up in court, the original risk is likely to still revert to the first party.
As such in the terminology of practitioners and scholars alike, the purchase of an insurance contract is
often described as a "transfer of risk." However, technically speaking, the buyer of the contract
generally retains legal responsibility for the losses "transferred", meaning that insurance may be
described more accurately as a post-event compensatory mechanism. For example, a personal injuries
insurance policy does not transfer the risk of a car accident to the insurance company. The risk still
lies with the policy holder namely the person who has been in the accident. The insurance policy
simply provides that if an accident (the event) occurs involving the policy holder then some
compensation may be payable to the policy holder that is commensurate to the suffering/damage.

Some ways of managing risk fall into multiple categories. Risk retention pools are technically retaining
the risk for the group but spreading it over the whole group involves transfer among individual
members of the group. This is different from traditional insurance, in that no premium is exchanged
between members of the group up front, but instead losses are assessed to all members of the group.

Risk Retention
Risk retention Involves accepting the loss, or benefit of gain, from a risk when it occurs. True self-
insurance falls in this category. Risk retention is a viable strategy for small risks where the cost of
insuring against the risk would be greater over time than the total losses sustained. All risks that are
not avoided or transferred are retained by default. This includes risks that are so large or catastrophic
that they either cannot be insured against or the premiums would be infeasible. War is an example
since most property and risks are not insured against war, so the loss attributed by war is retained by
the insured. Also any amounts of potential loss (risk) over the amount insured is retained risk. This
may also be acceptable if the chance of a very large loss is small or if the cost to insure for greater
coverage amounts is so great it would hinder the goals of the organization too much.

12.9RISK MANAGEMENT PLAN

Select appropriate controls or countermeasures to measure each risk. Risk mitigation needs to be
approved by the appropriate level of management. For instance, a risk concerning the image of the
organization should have top management decision behind it whereas IT management would have the
authority to decide on computer virus risks.

The risk management plan should propose applicable and effective security controls for managing the
risks. For example, an observed high risk of computer viruses could be mitigated by acquiring and
implementing antivirus software. A good risk management plan should contain a schedule for control
implementation and responsible persons for those actions.

According to ISO/IEC 27001, the stage immediately after completion of the risk assessment phase
consists of preparing a Risk Treatment Plan, which should document the decisions about how each of
the identified risks should be handled. Mitigation of risks often means selection of security controls,
which should be documented in a Statement of Applicability, which identifies which particular control
objectives and controls from the standard have been selected, and why.

Implementation - Implementation follows all of the planned methods for mitigating the effect of the
risks. Purchase insurance policies for the risks that have been decided to be transferred to an insurer,
avoid all risks that can be avoided without sacrificing the entity's goals, reduce others, and retain the
rest.

Review and evaluation of the plan - Initial risk management plans will never be perfect. Practice,
experience, and actual loss results will necessitate changes in the plan and contribute information to
allow possible different decisions to be made in dealing with the risks being faced.

Risk analysis results and management plans should be updated periodically. There are two primary
reasons for this:

• To evaluate whether the previously selected security controls are still applicable and effective
• To evaluate the possible risk level changes in the business environment. For example, information
risks are a good example of rapidly changing business environment.

Limitations

Prioritizing the risk management processes too highly could keep an organization from ever
completing a project or even getting started. This is especially true if other work is suspended until the
risk management process is considered complete.
It is also important to keep in mind the distinction between risk and uncertainty. Risk can be measured
by impacts x probability.

If risks are improperly assessed and prioritized, time can be wasted in dealing with risk of losses that
are not likely to occur. Spending too much time assessing and managing unlikely risks can divert
resources that could be used more profitably. Unlikely events do occur but if the risk is unlikely enough
to occur it may be better to simply retain the risk and deal with the result if the loss does in fact occur.
Qualitative risk assessment is subjective and lacks consistency. The primary justification for a formal
risk assessment process is legal and bureaucratic.

12.10 AREAS OF RISK MANAGEMENT

As applied to corporate finance, risk management is the technique for measuring, monitoring and
controlling the financial or operational risk on a firm's balance sheet. See value at risk.

The Basel II framework breaks risks into market risk (price risk), credit risk and operational risk and
also specifies methods for calculating capital requirements for each of these components.

Enterprise Risk Management

In enterprise risk management, a risk is defined as a possible event or circumstance that can have
negative influences on the enterprise in question. Its impact can be on the very existence, the resources
(human and capital), the products and services, or the customers of the enterprise, as well as external
impacts on society, markets, or the environment. In a financial institution, enterprise risk management
is normally thought of as the combination of credit risk, interest rate risk or asset liability management,
market risk, and operational risk.

In the more general case, every probable risk can have a pre-formulated plan to deal with its possible
consequences (to ensure contingency if the risk becomes a liability).

From the information above and the average cost per employee over time, or cost accrual ratio, a
project manager can estimate:

• the cost associated with the risk if it arises, estimated by multiplying employee costs per unit time
by the estimated time lost (cost impact, C where C = cost accrual ratio * S).

• the probable increase in time associated with a risk (schedule variance due to risk, Rs where Rs =
P * S):

Sorting on this value puts the highest risks to the schedule first. This is intended to cause the greatest
risks to the project to be attempted first so that risk is minimized as quickly as possible.

This is slightly misleading as schedule variances with a large P and small S and vice versa are not
equivalent. (The risk of the RMS Titanic sinking vs. the passengers' meals being served at slightly the
wrong time).

• the probable increase in cost associated with a risk (cost variance due to risk, Rc where Rc = P*C
= P*CAR*S = P*S*CAR) sorting on this value puts the highest risks to the budget first.
Risk in a project or process can be due either to Special Cause Variation or Common Cause Variation
and requires appropriate treatment. That is to re-iterate the concern about extreme cases not being
equivalent in the list immediately above.

12.11 PROJECT RISK MANAGEMENT PROCESS

In project management, risk management includes the following activities:

• Planning how risk will be managed in the particular project. Plans should include risk management
tasks, responsibilities, activities and budget.
• Assigning a risk officer – a team member other than a project manager who is responsible for
foreseeing potential project problems. Typical characteristic of risk officer is a healthy skepticism.
• Maintaining live project risk database. Each risk should have the following attributes: opening
date, title, short description, probability and importance. Optionally a risk may have an assigned
person responsible for its resolution and a date by which the risk must be resolved.
• Creating anonymous risk reporting channel. Each team member should have the possibility to
report risks that he/she foresees in the project.
• Preparing mitigation plans for risks that are chosen to be mitigated. The purpose of the mitigation
plan is to describe how this particular risk will be handled – what, when, by whom and how will it
be done to avoid it or minimize consequences if it becomes a liability.
• Summarizing planned and faced risks, effectiveness of mitigation activities, and effort spent for
the risk management.

Risk Management for Megaprojects

Megaprojects (sometimes also called "major programs") are extremely large-scale investment projects,
typically costing more than US$1 billion per project. Megaprojects include bridges, tunnels, highways,
railways, airports, seaports, power plants, dams, wastewater projects, coastal flood protection schemes,
oil and natural gas extraction projects, public buildings, information technology systems, aerospace
projects, and defense systems. Megaprojects have been shown to be particularly risky in terms of
finance, safety, and social and environmental impacts. Risk management is therefore particularly
pertinent for megaprojects and special methods and special education have been developed for such
risk management.

Risk Management Regarding Natural Disasters

It is important to assess risk in regard to natural disasters like floods, earthquakes, and so on. Outcomes
of natural disaster risk assessment are valuable when considering future repair costs, business
interruption losses and other downtime, effects on the environment, insurance costs, and the proposed
costs of reducing the risk. There are regular conferences in Davos to deal with integral risk
management.

IT Risk Management
Information technology is increasingly pervasive in modern life in every sector.

IT risk is a risk related to information technology. This is a relatively new term due to an increasing
awareness that information security is simply one facet of a multitude of risks that are relevant to IT
and the real-world processes it supports.

A number of methodologies have been developed to deal with this kind of risk.
ISACA's Risk IT framework ties IT risk to enterprise risk management.
Risk Management Techniques in Petroleum and Natural Gas
For the offshore oil and gas industry, operational risk management is regulated by the safety case
regime in many countries. Hazard identification and risk assessment tools and techniques are described
in the international standard ISO 17776:2000, and organizations such as the IADC (International
Association of Drilling Contractors) publish guidelines for HSE Case development which are based
on the ISO standard. Further, diagrammatic representations of hazardous events are often expected by
governmental regulators as part of risk management in safety case submissions; these are known as
bow-tie diagrams. The technique is also used by organizations and regulators in mining, aviation,
health, defense, industrial and finance.

12.12 POSITIVE RISK MANAGEMENT

Positive Risk Management is an approach that recognizes the importance of the human factor and of
individual differences in propensity for risk taking. It draws from the work of a number of academics
and professionals who have expressed concerns about scientific rigor of the wider risk management
debate, or who have made a contribution emphasizing the human dimension of risk.

Firstly, it recognizes that any object or situation can be rendered hazardous by the involvement of
someone with an inappropriate disposition towards risk; whether too risk taking or too risk averse.

Secondly, it recognizes that risk is an inevitable and ever-present element throughout life: from
conception through to the point at the end of life when we finally lose our personal battle with life
threatening risk.

Thirdly, it recognizes that every individual has a particular orientation towards risk; while at one
extreme people may by nature be timid, anxious and fearful, others will be adventurous, impulsive and
almost oblivious to danger. These differences are evident in the way we drive our cars, in our diets, in
our relationships, in our careers.

Finally, Positive Risk Management recognizes that risk taking is essential to all enterprise, creativity,
heroism, education, scientific advance – in fact to any activity and all the initiatives that have
contributed to our evolutionary success and civilization. It is worth noting how many enjoyable
activities involve fear and willingly embrace risk taking.

Within the entire Risk Management literature (and this section of Wikipedia) you will find little or no
reference to the human part of the risk equation other than what might be implied by the term
'compliant'. This illustrates the narrow focus that is a hall mark of much current risk management
practice. This situation arises from the basic premises of traditional risk management and the practices
associated with health and safety within the working environment. There is a basic logic to the idea
that any accident must reflect some kind of oversight or situational predisposition that, if identified,
can be rectified. But, largely due to an almost institutionalized neglect of the human factor, this
situationally focused paradigm has grown tendrils that reach into every corner of modern life and into
situations where the unintended negative consequences threaten to outweigh the benefits.

Positive Risk Management views both risk taking and risk aversion as complementary and of equal
value and importance within the appropriate context. As such, it is seen as complementary to the
traditional risk management paradigm. It introduces a much-needed balance to risk management
practices and puts greater onus on management skills and decision making. It is the dynamic approach
of the football manager who appreciates the offensive and defensive talents within the available pool
of players. Every organization has roles better suited to risk takers and roles better suited to the risk
averse. The task of management is to ensure that the right people are placed in each job. The graveyard
of former greats is littered with examples where the balance of risk went seriously awry; the ENRON
and RBS stories have become iconic references in the pantheon of corporate governance and corporate
mortality. Eastman Kodak might be a nominee for the opposite pole – the corporately risk averse.

Positive Risk Management relies on the ability to identify individual differences in propensity for risk
taking. The science in this area has been developing rapidly over the past decade within the domain of
personality assessment. Once an area of almost tribal allegiance to different schools of thought, today
there is wide spread consensus about the structure of personality assessment and its status within the
framework of the cross disciplinary progress being made in our understanding of Human Nature. The
Five Factor Model (FFM) of personality has been shown to have relevance across many different
cultures, to remain consistent over adult working life and to be significantly heritable. Within this
framework there are many strands which have a clear relationship to risk tolerance and risk taking. For
example, Eysenck (1973) reports that personality influences whether we focus on what might go wrong
or on potential benefits; Nicholson et al. (2005) report that higher extroversion is related to greater risk
tolerance; McCrae and Costa (1997) link personality to tolerance of uncertainty, innovation and
willingness to think outside the box; Kowert, 1997) links personality to adventurousness, imagination,
the search for new experiences and actively seeking out risk. Building from these foundations of well
validated assessment practices, more specialized assessments have been developed, including
assessment of Risk Type.

Business Continuity Risk Management

Business continuity Risk management is simply a practice of systematically selecting cost effective
approaches for minimizing the effect of threat realization to the organization. All risks can never be
fully avoided or mitigated simply because of financial and practical limitations. Therefore all
organizations have to accept some level of residual risks.

Whereas risk management tends to be preemptive, business continuity planning (BCP) was invented
to deal with the consequences of realized residual risks. The necessity to have BCP in place arises
because even very unlikely events will occur if given enough time. Risk management and BCP are
often mistakenly seen as rivals or overlapping practices. In fact these processes are so tightly tied
together that such separation seems artificial. For example, the risk management process creates
important inputs for the BCP (assets, impact assessments, cost estimates etc.). Risk management also
proposes applicable controls for the observed risks. Therefore, risk management covers several areas
that are vital for the BCP process. However, the BCP process goes beyond risk management's
preemptive approach and assumes that the disaster will happen at some point.

12.13 SUMMARY

Risk management is the identification, assessment, and prioritization of risks followed by coordinated
and economical application of resources to minimize, monitor, and control the probability and/or
impact of unfortunate events or to maximize the realization of opportunities.
The strategies to manage risk typically include transferring the risk to another party, avoiding the risk,
reducing the negative effect or probability of the risk, or even accepting some or all of the potential or
actual consequences of a particular risk.

Risk management method consists of the following elements, performed, more or less, in the following
order.
• identify, characterize threats
• assess the vulnerability of critical assets to specific threats
• determine the risk (i.e. the expected likelihood and consequences of specific types of attacks on
specific assets)
• identify ways to reduce those risks
• prioritize risk reduction measures based on a strategy

The management of risk at strategic, programme and operational levels needs to be integrated so that
the levels of activity support each other. In this way the risk management strategy of the organization
will be led from the top and embedded in the normal working routines and activities of the
organization. All staff should be aware of the relevance of risk to the achievement of their objectives
and training to support staff in risk management should be available.
Risk mitigation measures are usually formulated according to one or more of the following major risk
options, which are:

• Avoidance (eliminate, withdraw from or not become involved)

• Reduction (optimize – mitigate)
• Sharing (transfer – outsource or insure)
• Retention (accept and budget)

According to ISO/IEC 27001, the stage immediately after completion of the risk assessment phase
consists of preparing a Risk Treatment Plan, which should document the decisions about how each of
the identified risks should be handled. Mitigation of risks often means selection of security controls,
which should be documented in a Statement of Applicability, which identifies which particular control
objectives and controls from the standard have been selected, and why.
In project management, risk management includes the following activities:
• Planning how risk will be managed in the particular project.
• Assigning a risk officer
• Maintaining live project risk database.
• Creating anonymous risk reporting channel.
• Preparing mitigation plans for risks that are chosen to be mitigated.
• Summarizing planned and faced risks, effectiveness of mitigation activities, and effort spent for
the risk management.

12.14 KEYWORDS

• Risk Identification - Risk identification is the process of determining risks that could potentially
prevent the program, enterprise, or investment from achieving its objectives. It includes
documenting and communicating the concern.
• Risk assessment - Risk assessment is the determination of quantitative or qualitative value of risk
related to a concrete situation and a recognized threat (also called hazard). Quantitative risk
assessment requires calculations of two components of risk (R):, the magnitude of the potential
loss (L), and the probability (p) that the loss will occur. In all types of engineering of complex
systems sophisticated risk assessments are often made within Safety engineering and Reliability
engineering when it concerns threats to life, environment or machine functioning.
• Risk Mitigation – Risk Mitigation is systematic reduction in the extent of exposure to a risk and/or
the likelihood of its occurrence. Also called risk reduction.
• Risk communication - Risk communication is an interactive process of exchange of information
and opinion on risk among risk assessors, risk managers, and other interested parties.
 UNIT 13 SPECIAL CASES IN PROJECT MANAGEMENT

Objectives

After reading this unit, you will be able to:

• Arrange for project management using event chain methodology

• Arrange for organizing software projects
• Differentiate between agile project management and extreme project management
• Compare different approaches to software project managements

Structure

13.1 Introduction to Special Cases to Project Management

13.2 Event Chain methodology
13.3 Agile Project management
13.4 Extreme project management
13.5 Software project Management
13.6 Software prototyping
13.7 V – Model
13.8 Spiral Model
13.9 Rapid application development
13.10 Dynamic systems development method
13.11 Rational Unified Process
13.12 Test-driven development
13.13 Feature-driven development
13.14 Benefits realization management
13.15 Critical chain project management
13.16 Summary
13.17 Keywords

13.1INTRODUCTION TO SPECIAL CASES TO PROJECT MANAGEMENT

So far we have learnt concepts, issues and processes related to project management. These are the concepts
which are more or less applicable for all the projects. But in recent years, the project management approach
has been changing and some customized project management processes are getting developed to suit
special conditions. These could be related to IT industry, service industry or dynamic operations. In this
unit, we will look at these special cases which include agile project management, event chain
methodology, critical chain project management, extreme project management and project management
in IT industry.

13.2EVENT CHAIN METHODOLOGY

Event chain methodology is an uncertainty modeling and schedule network analysis technique that is
focused on identifying and managing events and event chains that affect project schedules. Event chain
methodology is the next advance beyond critical path method and critical chain project management.
Event chain methodology helps to mitigate the effect of motivational and cognitive biases in estimating
and scheduling. In many cases, project managers intentionally or unintentionally create project schedules
that are impossible to implement. The methodology also simplifies the process of defining risks and
uncertainties in project schedules, particularly by improving the ability to provide reality checks and to
visualize multiple events. Event chain methodology is used to perform more accurate quantitative analysis
while taking into account such factors as relationships between different events and actual moments of
the events.

Event Chain Methodology Principles

Moment of risk and state of activity

Moment of Risk and State of Activity

An activity (task) in most real-life processes is not a continuous uniform procedure. Tasks are affected by
external events, which transform an activity from one state to another. One of the important properties of
an event is the moment when an event occurs during the course of an activity. This moment, when an
event occurs, in most cases is probabilistic and can be defined using statistical distribution.
Event Chains
Events can cause other events, which will create event chains. These event chains can significantly affect
the course of the project. For example, requirement changes can cause an activity to be delayed. To
accelerate the activity, the project manager allocates a resource from another activity, which then leads to
a missed deadline. Eventually, this can lead to the failure of the project.
Monte Carlo Simulations
Once events and event chains are defined, quantitative analysis using Monte Carlo simulation can be
performed to quantify the cumulative effect of the events. Probabilities and effects of risks are used as
input data for Monte Carlo simulation of the project schedule. In most real life projects, it is necessary to
supplement the information regarding the uncertainties expressed as an event, with distributions related
to duration, start time, cost, and other parameters.
Critical Event Chains
The single events or the event chains that have the most potential to affect the projects are the “critical
events” or “critical chains of events.” By identifying critical events or critical chains of events, we can
mitigate their negative effects. These critical chains of events can be identified by analyzing the
correlations between the main project parameters, such as project duration or cost, and the event chains.
Performance Tracking with Event Chains
Monitoring the activity's progress ensures that updated information is used to perform the analysis. During
the course of the project, the probability and time of the events can be recalculated based on actual data.
The main issue with performance tracking is forecasting an activity’s duration and cost if an activity is
partially completed and certain events are assigned to the activity. The simple heuristic approach to this
problem is to analyze the moment of risk, which is defined as one of the event parameters. Advanced
analysis can be performed using a Bayesian approach.
Event Chain Diagrams
Event Chain Diagrams are visualizations that show the relationships between events and tasks and how
the events affect each other. The simplest way to represent these chains is to depict them as arrows
associated with certain tasks or time intervals on the Gantt chart. Different events and event chains can be
displayed using different colors. Events can be global (for all tasks in the project) and local (for a particular
task). By using Event Chain Diagrams to visualize events and event chains, the modeling and analysis of
risks and uncertainties can be significantly simplified.

Event Chain Methodology Phenomena

Repeated Activities

Repeated Activity

Sometimes events can cause the start of an activity that has already been completed. This is a very common
scenario for real life projects; sometimes a previous activity must be repeated based on the results of a
succeeding activity. Modeling of these scenarios using event chain methodology is simple. The original
project schedule does not need to be updated, as all that is required is to define the event and assign it to
an activity that points to the previous activity. In addition, a limit to the number of times an activity can
be repeated needs to be defined.
Event Chains and Risk Mitigation

Mitigation Plan
If event or event chain occurs during the course of a project, it may require some mitigation effort. In
some cases, mitigation plans can be generated. Mitigation plans are an activity or group of activities (small
schedule) that augment the project schedule if a certain event occurs. The solution is to assign the
mitigation plan to an event or event chain. These small schedules will be triggered when an event chain
occurs. The same mitigation plan can be used for different events.

Resource Allocation Based on Events

One potential event is the reassignment of a resource from one activity to another, which can occur under
certain conditions. For example, if an activity requires more resources to complete it within a fixed period,
this will trigger an event to reallocate the resource from another activity. Reallocation of resources can
also occur when activity duration reaches a certain deadline or the cost exceeds a certain value. Events
can be used to model different situations with resources, e.g. temporary leave, illness, vacations, etc.

13.3AGILE PROJECT MANAGEMENT

Agile project management is an iterative method of determining requirements for engineering and
information technology development projects in a highly flexible and interactive manner, for example
agile software development. It requires empowered individuals from the relevant business, with supplier
and customer input. There are also links to lean techniques, Kanban and Six Sigma. Agile techniques are
best used in small-scale projects or on elements of a wider programme of work, or on projects that are too
complex for the customer to understand and specify before testing prototypes.
Agile techniques may also be called extreme project management. It is a variant of iterative life cycle
where deliverables are submitted in stages. One difference between agile and iterative development is that
the delivery time in agile is in weeks rather than months.
The Agile Project Leadership Network provides a community of practice for those using agile methods,
with international conferences and online forums. Their Declaration of Interdependence extends the Agile
Manifesto further into the value stream and emphasizes the collaborative, whole-business nature of this
work. In Agile Project Management, Scrum is the agile process with the most to say about the management
of a project, so let’s use it as our model process for answering this question. On a Scrum project, there are
three roles: product owner, ScrumMaster, and team.
The product owner is responsible for the business aspects of the project, including ensuring the right
product is being built and in the right order. A good product owner can balance competing priorities, is
available to the team, and is empowered to make decisions about the product. The ScrumMaster serves as
the team's coach, helping team members work together in the most effective manner possible. A good
ScrumMaster views the role as one of providing a service to the team, removing impediments to progress,
facilitating meetings and discussions, and performing typical project management duties such tracking
progress and issues. The team itself assumes the responsibility for determining how to best achieve the
product goals (as established by the product owner). Team members will collaboratively decide which
person should work on which tasks, which technical practices are necessary to achieve stated quality goals,
and so on.

From looking at these three roles we can see that the agile project management responsibility is divided
among a project's product owner, ScrumMaster, and team. In Agile project management the world may
come to view the Scrum Master as a 21st century version of the project manager. Unlike a traditional
project manager, the ScrumMaster is not viewed as the person to credit (or blame) for the success (or
failure) of the project. The Scrum Master’s authority extends only to the process. The ScrumMaster is an
expert on the process and on using it to get a team to perform to its highest level. But, a ScrumMaster does
not have many of the traditional responsibilities - scope, cost, personnel, risk management among them -
that a project manager does.

13.4EXTREME PROJECT MANAGEMENT

In critical studies of project management it has been noted that several PERT based models are not well
suited for the multi-project company environment of today. Most of them are aimed at very large-scale,
one-time, non-routine projects, and currently all kinds of management are expressed in terms of projects.
Using complex models for "projects" (or rather "tasks") spanning a few weeks has been proven to cause
unnecessary costs and low maneuverability in several cases. Instead, project management experts try to
identify different "lightweight" models, such as Extreme Programming and Scrum. The generalization of
Extreme Programming to other kinds of projects is extreme project management, which may be used in
combination with the process modeling and management principles of human interaction management.
Scrum is an iterative and incremental agile software development framework for managing software
projects and product or application development. Scrum focuses on project management institutions where
it is difficult to plan ahead. Mechanisms of empirical process control, where feedback loops that constitute
the core management technique are used as opposed to traditional command-and-control management. Its
approach to planning and managing projects is by bringing decision-making authority to the level of
operation properties and certainties.
Scrum as applied to product development was first referred to in "New New Product Development Game"
(Harvard Business Review 86116:137–146, 1986) and later elaborated in "The Knowledge Creating
Company" both by Ikujiro Nonaka and Hirotaka Takeuchi (Oxford University Press, 1995). Today there
are records of Scrum used to produce financial products, Internet products, and medical products.

13.5SOFTWARE PROJECT MANAGEMENT

Software project management is the art and science of planning and leading software projects. It is a sub-
discipline of project management in which software projects are planned, implemented, monitored and
controlled. Companies quickly understood the relative ease of use that software programming had over
hardware circuitry, and the software industry grew very quickly in the 1970s and 1980s.
To manage new development efforts, companies applied proven project management methods, but project
schedules slipped during test runs, especially when confusion occurred in the gray zone between the user
specifications and the delivered software. To be able to avoid these problems, software project
management methods focused on matching user requirements to delivered products, in a method known
now as the waterfall model. Since then, analysis of software project management failures has shown that
the following are the most common causes.

• Unrealistic or unarticulated project goals

• Inaccurate estimates of needed resources
• Badly defined system requirements
• Poor reporting of the project's status
• Unmanaged risks
• Poor communication among customers, developers, and users
• Use of immature technology
• Inability to handle the project's complexity
• Sloppy development practices
• Poor project management
• Stakeholder politics
• Commercial pressures

The first three items in the list above show the difficulties articulating the needs of the client in such a way
that proper resources can deliver the proper project goals. Specific software project management tools are
useful and often necessary, but the true art in software project management is applying the correct method
and then using tools to support the method. Without a method, tools are worthless. Since the 1960s, several
proprietary software project management methods have been developed by software manufacturers for
their own use, while computer consulting firms have also developed similar methods for their clients.
Today software project management methods are still evolving, but the current trend leads away from the
waterfall model to a more cyclic project delivery model that imitates a Software release life cycle.

13.6SOFTWARE PROTOTYPING
Software prototyping refers to the activity of creating prototypes of software applications, i.e., incomplete
versions of the software program being developed. It is an activity that can occur in software development
and is comparable to prototyping as known from other fields, such as mechanical engineering or
manufacturing.
A prototype typically simulates only a few aspects of, and may be completely different from, the final
product.
Prototyping Has Several Benefits: The software designer and implementer can get valuable feedback from
the users early in the project. The client and the contractor can compare if the software made matches the
software specification, according to which the software program is built. It also allows the software
engineer some insight into the accuracy of initial project estimates and whether the deadlines and
milestones proposed can be successfully met. The degree of completeness and the techniques used in the
prototyping have been in development and debate since its proposal in the early 1970s.
The original purpose of a prototype is to allow users of the software to evaluate developers' proposals for
the design of the eventual product by actually trying them out, rather than having to interpret and evaluate
the design based on descriptions. Prototyping can also be used by end users to describe and prove
requirements that developers have not considered, and that can be a key factor in the commercial
relationship between developers and their clients. Interaction design in particular makes heavy use of
prototyping with that goal.
This process is in contrast with the 1960s and 1970s monolithic development cycle of building the entire
program first and then working out any inconsistencies between design and implementation, which led to
higher software costs and poor estimates of time and cost. The monolithic approach has been dubbed the
"Slaying the (software) Dragon" technique, since it assumes that the software designer and developer is a
single hero who has to slay the entire dragon alone. Prototyping can also avoid the great expense and
difficulty of changing a finished software product.

Outline of the prototyping process:

The process of prototyping involves the following steps.
• Identify basic requirements
• Determine basic requirements including the input and output information desired. Details, such as
security, can typically be ignored.
• Develop Initial Prototype
• The initial prototype is developed that includes only user interfaces.
• Review
• The customers, including end-users, examine the prototype and provide feedback on additions or
changes.
• Revise and Enhance the Prototype

Using the feedback both the specifications and the prototype can be improved. Negotiation about what is
within the scope of the contract/product may be necessary. If changes are introduced then a repeat of steps
#C and #D may be needed.

Dimensions of prototypes
Nielsen summarizes the various dimension of prototypes in his book Usability Engineering

Horizontal Prototype
A common term for a user interface prototype is the horizontal prototype. It provides a broad view of an
entire system or subsystem, focusing on user interaction more than low-level system functionality, such
as database access. Horizontal prototypes are useful for:

• Confirmation of user interface requirements and system scope

• Demonstration version of the system to obtain buy-in from the business
• Develop preliminary estimates of development time, cost and effort.

Vertical Prototype
A vertical prototype is a more complete elaboration of a single subsystem or function. It is useful for
obtaining detailed requirements for a given function, with the following benefits:
• Refinement database design
• Obtain information on data volumes and system interface needs, for network sizing and performance
engineering
• Clarifies complex requirements by drilling down to actual system functionality
Advantages of Prototyping
There are many advantages to using prototyping in software development – some tangible, some abstract.

• Reduced time and costs: Prototyping can improve the quality of requirements and specifications
provided to developers. Because changes cost exponentially more to implement as they are detected
later in development, the early determination of what the user really wants can result in faster and less
expensive software.
• Improved and increased user involvement: Prototyping requires user involvement and allows them to
see and interact with a prototype allowing them to provide better and more complete feedback and
specifications. The presence of the prototype being examined by the user prevents many
misunderstandings and miscommunications that occur when each side believe the other understands
what they said. Since users know the problem domain better than anyone on the development team
does, increased interaction can result in final product that has greater tangible and intangible quality.
The final product is more likely to satisfy the users desire for look, feel and performance.

13.7V – MODEL

The V-model represents a software development process (also applicable to hardware development)
which may be considered an extension of the waterfall model. Instead of moving down in a linear way,
the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model
demonstrates the relationships between each phase of the development life cycle and its associated phase
of testing. The horizontal and vertical axes represent time or project completeness (left-to-right) and level
of abstraction (coarsest-grain abstraction uppermost), respectively.
Requirements Analysis
In the Requirements analysis phase, the requirements of the proposed system are collected by analyzing
the needs of the user(s). This phase is concerned with establishing what the ideal system has to perform.
However, it does not determine how the software will be designed or built. Usually, the users are
interviewed and a document called the user requirements document is generated.
The user requirements document will typically describe the system’s functional, interface, performance,
data, security, etc. requirements as expected by the user. It is used by business analysts to communicate
their understanding of the system to the users. The users carefully review this document as this document
would serve as the guideline for the system designers in the system design phase. The user acceptance
tests are designed in this phase. See also Functional requirements.
There are different methods for gathering requirements of both soft and hard methodologies including;
interviews, questionnaires, document analysis, observation, throw-away prototypes, use cases and static
and dynamic views with users.
System Design
Systems design is the phase where system engineers analyze and understand the business of the proposed
system by studying the user requirements document. They figure out possibilities and techniques by which
the user requirements can be implemented. If any of the requirements are not feasible, the user is informed
of the issue. A resolution is found and the user requirement document is edited accordingly.
The software specification document which serves as a blueprint for the development phase is generated.
This document contains the general system organization, menu structures, data structures etc. It may also
hold example business scenarios, sample windows, reports for the better understanding. Other technical
documentation like entity diagrams, data dictionary will also be produced in this phase. The documents
for system testing are prepared in this phase.
Architecture Design
The phase of the design of computer architecture and software architecture can also be referred to as high-
level design. The baseline in selecting the architecture is that it should realize all which typically consists
of the list of modules, brief functionality of each module, their interface relationships, dependencies,
database tables, architecture diagrams, technology details etc. The integration testing design is carried out
in the particular phase.
Module Design
The module design phase can also be referred to as low-level design. The designed system is broken up
into smaller units or modules and each of them is explained so that the programmer can start coding
directly. The low level design document or program specifications will contain a detailed functional logic
of the module, in pseudocode:

• database tables, with all elements, including their type and size
• all interface details with complete API references
• all dependency issues
• error message listings
• complete input and outputs for a module

Unit Testing
In computer programming, unit testing is a method by which individual units of source code are tested to
determine if they are fit for use. A unit is the smallest testable part of an application. In procedural
programming a unit may be an individual function or procedure. Unit tests are created by programmers or
occasionally by white box testers. The purpose is to verify the internal logic code by testing every possible
branch within the function, also known as test coverage. Static analysis tools are used to facilitate in this
process, where variations of input data are passed to the function to test every possible case of execution.
Integration Testing
In integration testing the separate modules will be tested together to expose faults in the interfaces and in
the interaction between integrated components. Testing is usually black box as the code is not directly
checked for errors.
System Testing
System testing will compare the system specifications against the actual system. After the integration test
is completed, the next test level is the system test. System testing checks if the integrated product meets
the specified requirements. Why is this still necessary after the component and integration tests? The
reasons for this are as follows:

Reasons for system test:

In the lower test levels, the testing was done against technical specifications, i.e., from the technical
perspective of the software producer. The system test, though, looks at the system from the perspective of
the customer and the future user. The testers validate whether the requirements are completely and
appropriately met.

Example: The customer (who has ordered and paid for the system) and the user (who uses the system) can
be different groups of people or organizations with their own specific interests and requirements of the
system.
Many functions and system characteristics result from the interaction of all system components,
consequently, they are only visible on the level of the entire system and can only be observed and tested
there.

User Acceptance Testing

Acceptance testing is the phase of testing used to determine whether a system satisfies the requirements
specified in the requirements analysis phase. The acceptance test design is derived from the requirements
document. The acceptance test phase is the phase used by the customer to determine whether to accept the
system or not.

Acceptance testing helps

• To determine whether a system satisfies its acceptance criteria or not.
• To enable the customer to determine whether to accept the system or not.
• To test the software in the "real world" by the intended audience.
• Purpose of acceptance testing.
• To verify the system or changes according to the original needs.

Procedure for UAT

Define the acceptance criteria:
• Functionality requirements
• Performance requirements
• Interface quality requirements
• Overall software quality requirements

Develop an acceptance plan:

• Project description
• User responsibilities
• Acceptance description

Release Testing
Release testing is a phase that determines if the software is suitable for the organisation of the end-user.
How is compatibility with other systems ensured? Is the performance of the software optimized?
The V-Model has been criticized by Agile advocates and others as an inadequate model of software
development for numerous reasons. Criticisms include:

• It is too simple to accurately reflect the software development process, and can lead managers into a
false sense of security. The V-Model reflects a project management view of software development
and fits the needs of project managers, accountants and lawyers rather than software developers or
users.
• Although It is easily understood by novices, that early understanding is useful only if the novice goes
on to acquire a deeper understanding of the development process and how the V-Model must be
adapted and extended in practice. If practitioners persist with their naive view of the V-Model they
will have great difficulty applying it successfully.
• It is inflexible and encourages a rigid and linear view of software development and has no inherent
ability to respond to change.
• It provides only a slight variant on the waterfall model and is therefore subject to the same criticisms
as that model. It provides greater emphasis on testing, and particularly the importance of early test
planning. However, a common practical criticism of the V-Model is that it leads to testing being
squeezed into tight windows at the end of development when earlier stages have overrun but the
implementation date remains fixed.
• It is consistent with, and therefore implicitly encourages, inefficient and ineffective testing
methodologies. It implicitly promotes writing test scripts in advance rather than exploratory testing; it
encourages testers to look for what they expect to find, rather than discover what is truly there. It also
encourages a rigid link between the equivalent levels of either leg (e.g. user acceptance test plans being
derived from user requirements documents), rather than encouraging testers to select the most effective
and efficient way to plan and execute testing.
• It lacks coherence and precision. There is widespread confusion about what exactly the V-Model is.
If one boils it down to those elements that most people would agree upon it becomes a trite and
unhelpful representation of software development. Disagreement about the merits of the V-Model
often reflects a lack of shared understanding of its definition.
 13.8SPIRAL MODEL

The spiral model is a software development process combining elements of both design and prototyping-
in-stages, in an effort to combine advantages of top-down and bottom-up concepts. Also known as the
spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in
information technology (IT). This model of development combines the features of the prototyping and the
waterfall model. The spiral model is intended for large, expensive and complicated projects. The spiral
model combines the idea of iterative development (prototyping) with the systematic, controlled aspects of
the waterfall model. It allows for incremental releases of the product, or incremental refinement through
each time around the spiral. The spiral model also explicitly includes risk management within software
development. Identifying major risks, both technical and managerial, and determining how to lessen the
risk helps keep the software development process under control. The spiral model is based on continuous
refinement of key products for requirements definition and analysis, system and software design, and
implementation (the code). At each iteration around the cycle, the products are extensions of an earlier
product. This model uses many of the same phases as the waterfall model, in essentially the same order,
separated by planning, risk assessment, and the building of prototypes and simulations.

Documents are produced when they are required, and the content reflects the information necessary at that
point in the process. All documents will not be created at the beginning of the process, nor all at the end.
Like the product they define, the documents are works in progress. The idea is to have a continuous stream
of products produced and available for user review. The spiral lifecycle model allows for elements of the
product to be added in when they become available or known. This assures that there is no conflict with
previous requirements and design. This method is consistent with approaches that have multiple software
builds and releases and allows for making an orderly transition to a maintenance activity. Another positive
aspect is that the spiral model forces early user involvement in the system development effort. For projects
with heavy user interfacing, such as user application programs or instrument interface applications, such
involvement is helpful. Starting at the center, each turn around the spiral goes through several task regions:
 • Determine the objectives, alternatives, and constraints on the new iteration.
• Evaluate alternatives and identify and resolve risk issues.
• Develop and verify the product for this iteration.
• Plan the next iteration
13.9 RAPID APPLICATION DEVELOPMENT

Rapid application development (RAD) is a software development methodology that uses minimal
planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved
with writing the software itself. The lack of extensive pre-planning generally allows software to be written
much faster, and makes it easier to change requirements.
The Rapid application development (RAD) is a software development methodology that involves methods
like iterative development and software prototyping. According to Whitten (2007), it is a merger of various
structured techniques, especially data-driven Information Engineering, with prototyping techniques to
accelerate software systems development.
In rapid application development, structured techniques and prototyping are especially used to define
users' requirements and to design the final system. The development process starts with the development
of preliminary data models and business process models using structured techniques. In the next stage,
requirements are verified using prototyping, eventually to refine the data and process models. These stages
are repeated iteratively; further development results in "a combined business requirements and technical
design statement to be used for constructing new systems".

Four phases of RAD

Requirements Planning phase: combines elements of the system planning and systems analysis phases of
the System Development Life Cycle (SDLC). Users, managers, and IT staff members discuss and agree
on business needs, project scope, constraints, and system requirements. It ends when the team agrees on
the key issues and obtains management authorization to continue.

User design phase: during this phase, users interact with systems analysts and develop models and
prototypes that represent all system processes, inputs, and outputs. The RAD groups or subgroups
typically use a combination of Joint Application Development (JAD) techniques and CASE tools to
translate user needs into working models. User Design is a continuous interactive process that allows users
to understand, modify, and eventually approve a working model of the system that meets their needs.

Construction phase: focuses on program and application development task similar to the SDLC. In RAD,
however, users continue to participate and can still suggest changes or improvements as actual screens or
reports are developed. Its tasks are programming and application development, coding, unit-integration
and system testing.

Cutover phase: resembles the final tasks in the SDLC implementation phase, including data conversion,
testing, changeover to the new system, and user training. Compared with traditional methods, the entire
process is compressed. As a result, the new system is built, delivered, and placed in operation much sooner.
Its tasks are data conversion, full-scale testing, system changeover, user training.

13.10 DYNAMIC SYSTEMS DEVELOPMENT METHOD

Dynamic systems development method (DSDM) is an agile project delivery framework, primarily used
as a software development method. First released in 1994, DSDM originally sought to provide some
discipline to the rapid application development (RAD) method. In 2007 DSDM became a generic
approach to project management and solution delivery. DSDM is an iterative and incremental approach
that embraces principles of Agile development, including continuous user/customer involvement.

DSDM fixes cost, quality and time at the outset and uses the MoSCoW prioritisation of scope into musts,
shoulds, coulds and won't haves to adjust the project deliverable to meet the stated time constraint. DSDM
is one of a number of Agile methods for developing software and non-IT solutions, and it forms a part of
the Agile Alliance.

The most recent version of DSDM, launched in 2007, is called DSDM Atern. The name Atern is a
shortening of Arctic Tern - a collaborative bird that can travel vast distances and epitomizes many facets
of the method which are natural ways of working e.g. prioritization and collaboration.

The previous version of DSDM (released in May 2003) which is still widely used and is still valid is
DSDM 4.2 which is a slightly extended version of DSDM version 4. The extended version contains
guidance on how to use DSDM with Extreme Programming.
 13.11 RATIONAL UNIFIED PROCESS
The Rational Unified Process (RUP) is an iterative software development process framework created by
the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive
process, but rather an adaptable process framework, intended to be tailored by the development
organizations and software project teams that will select the elements of the process that are appropriate
for their needs. RUP is a specific implementation of the Unified Process.

RUP is based on a set of building blocks, or content elements, describing what is to be produced, the
necessary skills required and the step-by-step explanation describing how specific development goals are
to be achieved. The main building blocks, or content elements, are the following:

• Roles (who) – A Role defines a set of related skills, competencies and responsibilities.
• Work Products (what) – A Work Product represents something resulting from a task, including all
the documents and models produced while working through the process.
• Tasks (how) – A Task describes a unit of work assigned to a Role that provides a meaningful
result.

Within each iteration, the tasks are categorized into nine disciplines:

Six "engineering disciplines"

- Business Modeling
- Requirements
- Analysis and Design
- Implementation
- Test
- Deployment

Three supporting disciplines

- Configuration and Change Management
- Project Management
- Environment
The RUP has determined a project life cycle consisting of four phases. These phases allow the process to
be presented at a high level in a similar way to how a 'waterfall'-styled project might be presented, although
in essence the key to the process lies in the iterations of development that lie within all of the phases. Also,
each phase has one key objective and milestone at the end that denotes the objective being accomplished.
The visualization of RUP phases and disciplines over time is referred to as the RUP hump chart. It includes
Inception Phase, Elaboration Phase, Construction Phase, Transition Phase.

13.12 TEST-DRIVEN DEVELOPMENT

Test-driven development (TDD) is a software development process that relies on the repetition of a very
short development cycle: first the developer writes an (initially failing) automated test case that defines a
desired improvement or new function, then produces the minimum amount of code to pass that test, and
finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed
or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires
confidence.
Test-driven development is related to the test-first programming concepts of extreme programming, begun
in 1999, but more recently has created more general interest in its own right.
Programmers also apply the concept to improving and debugging legacy code developed with older
techniques.

13.13 FEATURE-DRIVEN DEVELOPMENT

Feature-driven development (FDD) is an iterative and incremental software development process. It is

one of a number of agile methods for developing software and forms part of the Agile Alliance. FDD
blends a number of industry-recognized best practices into a cohesive whole. These practices are all driven
from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working
software repeatedly in a timely manner.
FDD is a model-driven short-iteration process that consists of five basic activities. For accurate state
reporting and keeping track of the software development project, milestones that mark the progress made
on each feature are defined.

13.14 BENEFITS REALIZATION MANAGEMENT

Benefits realization management (BRM) enhances normal project management techniques through a focus
on agreeing what outcomes should change (the benefits) during the project, and then measuring to see if
that is happening to help keep a project on track. This can help to reduce the risk of a completed project
being a failure as instead of attempting to deliver agreed requirements the aim is to deliver the benefit of
those requirements. An example of delivering a project to requirements could be agreeing on a project to
deliver a computer system to process staff data with the requirement to manage payroll, holiday and staff
personnel records. Under BRM the agreement would be to use the suppliers suggested staff data system
to see an agreed reduction in staff hours processing and maintaining staff data (benefit reduce HR
headcount).

The project development stages

Traditionally, project management includes a number of elements: four to five process groups, and a
control system. Regardless of the methodology or terminology used, the same basic project management
processes will be used. Major process groups generally include:
• Initiation
• Planning or design
• Production or execution
• Monitoring and controlling
• Closing

In project environments with a significant exploratory element (e.g., research and development), these
stages may be supplemented with decision points (go/no go decisions) at which the project's continuation
is debated and decided. An example is the Phase–gate model.

13.15 CRITICAL CHAIN PROJECT MANAGEMENT

Critical chain project management (CCPM) is a method of planning and managing projects that puts the
main emphasis on the resources required to execute project tasks. It was developed by Eliyahu M.
Goldratt. This is in contrast to the more traditional methods derived from critical path and PERT
algorithms, which emphasize task order and rigid scheduling. A Critical Chain project network will tend
to keep the resources levelly loaded, but will require them to be flexible in their start times and to quickly
switch between tasks and task chains to keep the whole project on schedule.
Critical chain project management is based on methods and algorithms derived from Theory of
Constraints. The idea of CCPM was introduced in 1997 in Eliyahu M. Goldratt's book, Critical Chain.
Application of CCPM has been credited with achieving projects 10% to 50% faster and/or cheaper than
the traditional methods (i.e. CPM, PERT, Gantt, etc.) developed from 1910 to 1950s.
From numerous studies by Standish Group and others as of 1998 for traditional project management
methods, only 44% of projects typically finish on time, projects usually complete at 222% of the duration
originally planned, 189% of the original budgeted cost, 70% of projects fall short of their planned scope
(technical content delivered), and 30% are cancelled before completion.
These traditional statistics are mostly avoided through CCPM. Typically, CCPM case studies report 95%
on-time and on-budget completion when CCPM is applied correctly. Mabin and Balderstone, in their
meta-analysis of seventy-eight published case studies, found that implementing Critical Chain resulted in
mean reduction in lead-times of 69%, mean reduction of cycle-times of 66%, mean improvement in due
date performance of 60%, mean reduction in inventory levels of 50% and mean increases in revenue /
throughput of 68%.
With traditional project management methods, 30% of the lost time and resources are typically consumed
by wasteful techniques such as bad multi-tasking, student syndrome, In-box delays, and lack of
prioritization.
In project management, the critical chain is the sequence of both precedence- and resource-dependent
terminal elements that prevents a project from being completed in a shorter time, given finite resources.
If resources are always available in unlimited quantities, then a project's critical chain is identical to its
critical path.
CCPM planning aggregates the large amounts of safety time added to tasks within a project into the buffers
in order to protect due-date performance, and to avoid wasting this safety time through bad multitasking,
student syndrome, Parkinson's Law and poorly synchronized integration.
Critical chain project management uses buffer management instead of earned value management to assess
the performance of a project. Some project managers feel that the earned value management technique is
misleading, because it does not distinguish progress on the project constraint (i.e. on the critical chain)
from progress on non-constraints (i.e. on other paths). Event chain methodology can be used to determine
a size of project, feeding, and resource buffers.

13.16 SUMMARY

The project management uses different approached depending on the conditions and situations. These
include following approaches.
Event chain methodology helps to mitigate the effect of motivational and cognitive biases in estimating
and scheduling. In many cases, project managers intentionally or unintentionally create project schedules
that are impossible to implement. The methodology also simplifies the process of defining risks and
uncertainties in project schedules, particularly by improving the ability to provide reality checks and to
visualize multiple events. Event chain methodology is used to perform more accurate quantitative analysis
while taking into account such factors as relationships between different events and actual moments of
the events.
Using complex models for "projects" (or rather "tasks") spanning a few weeks has been proven to cause
unnecessary costs and low maneuverability in several cases. Instead, project management experts try to
identify different "lightweight" models, such as Extreme Programming and Scrum.
Scrum is an iterative and incremental agile software development framework for managing software
projects and product or application development.

Software prototyping refers to the activity of creating prototypes of software applications, i.e., incomplete
versions of the software program being developed. It is an activity that can occur in software development
and is comparable to prototyping as known from other fields, such as mechanical engineering or
manufacturing.
The process of prototyping involves the following steps
• Identify basic requirements
• Determine basic requirements including the input and output information desired. Details, such as
security, can typically be ignored.
• Develop Initial Prototype
• The initial prototype is developed that includes only user interfaces.
• Review
• The customers, including end-users, examine the prototype and provide feedback on additions or
changes.
• Revise and Enhance the Prototype

The V-model represents a software development process (also applicable to hardware development) which
may be considered an extension of the waterfall model. Instead of moving down in a linear way, the
process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model
demonstrates the relationships between each phase of the development life cycle and its associated phase
of testing. The horizontal and vertical axes represents time or project completeness (left-to-right) and level
of abstraction (coarsest-grain abstraction uppermost), respectively.
The Rapid application development (RAD) is a software development methodology that involves methods
like iterative development and software prototyping. According to Whitten (2007), it is a merger of various
structured techniques, especially data-driven Information Engineering, with prototyping techniques to
accelerate software systems development.
Dynamic systems development method (DSDM) is an agile project delivery framework, primarily used
as a software development method. DSDM is an iterative and incremental approach that embraces
principles of Agile development, including continuous user/customer involvement.
The Rational Unified Process (RUP) is an iterative software development process framework created by
the Rational Software Corporation, a division of IBM since 2003. RUP is based on a set of building blocks,
or content elements, describing what is to be produced, the necessary skills required and the step-by-step
explanation describing how specific development goals are to be achieved. The main building blocks, or
content elements, are the following: Roles (who), Work Products (what), and Tasks (how). Within each
iteration, the tasks are categorized into nine disciplines.
Test-driven development (TDD) is a software development process that relies on the repetition of a very
short development cycle: first the developer writes an (initially failing) automated test case that defines a
desired improvement or new function, then produces the minimum amount of code to pass that test, and
finally refactors the new code to acceptable standards.
FDD is a model-driven short-iteration process that consists of five basic activities. For accurate state
reporting and keeping track of the software development project, milestones that mark the progress made
on each feature are defined.
Benefits realization management (BRM) enhances normal project management techniques through a focus
on agreeing what outcomes should change (the benefits) during the project, and then measuring to see if
that is happening to help keep a project on track. This can help to reduce the risk of a completed project
being a failure as instead of attempting to deliver agreed requirements the aim is to deliver the benefit of
those requirements.
Critical chain project management (CCPM) is a method of planning and managing projects that puts the
main emphasis on the resources required to execute project tasks.
Critical chain project management uses buffer management instead of earned value management to assess
the performance of a project. Some project managers feel that the earned value management technique is
misleading, because it does not distinguish progress on the project constraint (i.e. on the critical chain)
from progress on non-constraints (i.e. on other paths). Event chain methodology can be used to determine
a size of project, feeding, and resource buffers.

13.17 KEYWORDS

• Event chain methodology - Event chain methodology is an uncertainty modeling and schedule
network analysis technique that is focused on identifying and managing events and event chains that
affect project schedules. Event chain methodology is the next advance beyond critical path method
and critical chain project management.
• Agile Project management - Agile project management is an iterative method of determining
requirements for engineering and information technology development projects in a highly flexible
and interactive manner, for example agile software development. It requires empowered individuals
from the relevant business, with supplier and customer input.
• Software project management - Software project management is the art and science of planning
and leading software projects. It is a sub-discipline of project management in which software projects
are planned, implemented, monitored and controlled.
• Spiral model - The spiral model is a software development process combining elements of both design
and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts.
• Feature-driven development- Feature-driven development (FDD) is an iterative and incremental
software development process. It is one of a number of Agile methods for developing software and
forms part of the Agile Alliance.