?

Project Management Concepts

Subject: PROJECT MANAGEMENT CONCEPTS Credits: 4

SYLLABUS

Concept and Characteristics of a project

Introduction, Projects, Project Management Phases, Project Management Knowledge Areas, Uncertainty of
Project Resources, The Triple Constraint, Project Management vs. Program Management, Complications
Involving IT Projects, Characteristics of Projects.

Importance of project management

Introduction, Description, Importance

Types of project
Introduction, Project Planning

Project Organizational Structure

Project Management, Trends in Modern Management, Strategic Planning and Project Programming, Effects of
Project Risks on Organization, Organization of Project Participants, Traditional Designer-Constructor
Sequence, Professional Construction Management, Owner-Builder Operation, Turnkey Operation, Leadership
and Motivation for the Project Team, Interpersonal Behavior in Project Organizations, Perceptions of Owners
and Contractors.

Project life cycle

Introduction, Phases

Statement of Work
Introduction, Next Steps, Purpose, Format of SOW, Sample Report.

Work Breakdown Structure

Overview, Work Breakdown Structures, Purpose, The WBS Module

IT in Projects
Introduction, Projects, Challenges and Changes, Project Culture, Business Leadership, Competitive Advantage,
Principles of IT project management, Role of offices in IT Projects, IT Projects: a Misnomer.

Team Building Process

Introduction, Groups, Encouraging work groups, Teams, Techniques, Roles and Rules.

Suggested Readings:
Project Management, Jack R. Meredith and Samuel J. Mantel, Wiley India
Project Management, John M. Nicholas and Herman Steyn, Pearson Education
 CHAPTER 1
Concept and Characteristics of a project

Learning Objectives

To know more about Project Management.

To analyse the Projects and its types.
To recognise the different phases of a Project.
To explain about the external project management.
To know the steps involved in Forward and Backward Pass.

1.1 Introduction

Project management is becoming increasingly important. In the past, project management

consisted mainly of collecting metrics and project data for evaluation, then making
adjustments in order to increase productivity and efficiency. Project managers were also
responsible for managing human capital (making sure that a project had enough "people" to
get all tasks completed). With the rapid proliferation of technology, the importance of project
management has increased exponentially in terms of the tasks required of a project manager,
as well as the knowledge necessary to perform these tasks.

Project definition usually starts with some vision or idea. An individual and her family, a
company, or a government entity wants to create something, the desired project result.
Maybe, it is the first home, a new IT system, or a bridge across a 1-mile wide river. At this
point, at the beginning of the project, we have only fuzzy ideas of where to go. There is just
this vision on a very high level, but we do not yet know how the result will look like or how
we could get there.

As we explained in section Project Management Process, we want to be in control of our

project at all times. In implementation and closure phase, this means being able to compare
results of action with required results. Therefore, we need a project plan that contains all
necessary actions and required results. Moreover, we only can create such a plan if we know
enough details about the project goal and requirements or specifications of the desired project
results.
We have to refine our vision into a clear goal, and then, break down this goal into sub-goals
and sub-sub-goals, until we can define even detailed requirements or specifications our
desired end result has to fulfill. In order to support this process of defining more and more
detailed characteristics of the project result we need to follow certain criteria of how to setup
goals, requirements, or specifications: we need to define SMART goals, requirements, and
specifications.

1.2 Projects

Projects exist in every type of human enterprise. They are unique, complex undertakings that
create new products, facilities, services, and events, among other things, bring about major
organizational and other desired changes or recovery from natural or man-made disasters.
Projects have starting and ending points in time and progress through a number of life cycle
phases.

The discipline of project management has evolved because the more traditional, well-
established industrial age principles and methods for managing our classical functional
organizations (involving ongoing, repetitive operations of various kinds) do not work well for
planning, controlling, and managing projects, programs, or project portfolios. Projects are
comprised of diverse tasks that require diverse specialist skills, and hence cut across the
traditional functional organizational lines. They are temporary endeavors with a finite
lifetime and so do not provide stable organizational homes for the people involved. The
challenge is to accomplish the right projects at the right time while providing stable homes
that develop the diverse skills needed for all the specialists who contribute to the projects.
Key differentiating characteristics of PM when compared to functional organization
management are:

Assignment of integrative responsibilities related to each project, program and project

portfolio (as defined in the following section):

General manager/managing director

Portfolio steering groups (or portfolio governance committees)
Project and program sponsors (or directors)
Manager of project management (or Chief Projects Officer/CPO) (the Project
Management Office/PMO)
Project and program managers
Affected functional (specialist) managers and functional project leaders.

Application of integrative and predictive practices, methods, systems and tools for producing
and effectively using the information required to plan, schedule, monitor, and control the
scope, risks, schedules, resources and costs of projects, programs and project portfolios,
integrating their entire life cycles. Iterative processes are sometimes required, (for software or
R&D projects) but these still have a predictive objective for the entire project.

Building and directing each project and program team, comprised of the multidisciplined
functional managers and specialists needed to create, plan, execute, and manage each project
and program.

In almost every case the evolution of the PM discipline within a complex organization results
in a project/functional matrix of responsibilities that can range from a weak to a strong
matrix, referring to the authority of the project and program managers to give project
direction to the project team members.

1.3 Project Management Phases

1.3.1 Managing the Total Project Life Cycle:

The primary difference between projects and an ongoing enterprise as something to be

managed is that the project has a life cycle: it starts, is executed, and it ends. More
elaborately, a project has a number of life cycle phases, the simplest definition of which
includes concept, definition, execution, and closeout phases. The practice of PM has moved
from focusing in the early years on planning and controlling the execution of projects to
include presently the conceptual phases, and project portfolio management (discussed later)
provides the needed linkage between strategic growth management of the organization and
PM. Extension of the project life cycle to include achieving the desired results from
completion of a project is now a reality for some practitioners.

1.3.2 Achieving the Project Benefits:

We currently see movement toward including within the PM discipline the important post-
completion objective of achieving the benefits from completion of the project. Projects
frequently require changes in the organization itself in order to gain the benefits from the
results of the project. Thus project management often encompasses organizational change
brought on by the successful completion of a project. This can be considered as a post-
completion project phase, perhaps named ―
project results integration‖ or ―
project benefits
realization.‖ If the project has been executed under contract for an external customer, then the
primary benefit will be whatever financial profit has been realized under the contract, plus of
course the experience gained and the possibility of future business with that customer, or with
other customers using the experience gained. For the customer or purchaser of the project it is
necessary to integrate the project results (new information system, new office building, new
process plant, new product, for example) into the ongoing business operations.

Project management, in a broad sense, can be defined as a set of tools, skills, techniques, and
knowledge that can be applied to a project in order to fulfill that project's requirements.
Project management consists of a loosely defined process for completing projects
successfully. This process generally consists of five phases:

Project Initiation - Deals with selecting and starting a project

 Project Planning - Once a project is initiated, it must be planned. This is by far the
largest and most important phase of project management. Without a good project
plan, the project is doomed to failure.
Project Execution - Once the plan is in place, the project team needs to execute the
plan to reach the project goals.
Project Control - Throughout the execution phase, a level of control needs to be in
place to manage potential problems and monitor progress.
Project Closure - This phase is often times overlooked, but is very important. This
phase describes how to officially close out a project with a client or sponsor.

1.4 Project Management Knowledge Areas

The process of planning and executing a piece of work from inception to completion to
achieve safe achievement of objectives on time, within cost limits and to the specified
standards of quality.

The organising, planning, directing, coordinating and controlling of all project resources from
inception to completion to achieve project objectives on time, within cost, and to required
quality standards.

Most authors agree that project management is about achieving time, cost and quality targets,
within the context of overall strategic and tactical client requirements, by using project
resources. There is also general agreement that project management is concerned with the life
cycle of the project: planning and controlling the project from inception to completion .
Project resources are resources that are wholly or partly allocated to the project and under the
control of the project manager.

Another facet of project management involves choosing the optimum position in relation to
the success criteria.

The need for integrated planning and control procedures, together with a recent
corresponding success of project management, is caused by the changing nature of industrial
projects over the past fifty years. Generally, as industry has evolved, it has become more
complex. Technological processes have become more complex and this has been coupled
with more and more complicated organizational and administrative procedures. Technology
and organizational processes, like plants and animals, tend to evolve over time into ever more
complex and sophisticated structures.
They come in many different degrees of complexity, from launching a space mission to
designing and printing a company newsletter, and across all projects they require the
commitment of a wide range of resources and the application of a wide and varied range of
skills by the project manager.

Project management is therefore about deciding the various success and failure criteria of a
project and then organizing and running the project as a single entity so that all the success
criteria are met. This process involves setting up and managing a project team that may
consist of a number of different individuals with different specializations. The project
manager must weld this group of individuals into a team and then drive the team to perform
successfully. The team itself, like the project, will only last a certain time. Once the project is
completed the project team will probably be disbanded or be moved on to the next project.

Along with the five phases of project management set forth by the Project Management
Institute in the Project Management Body of Knowledge (PMBOK), project management
also consists of nine knowledge areas. These knowledge areas represent the competencies
that project managers must develop in order to be successful. A successful project manager
will need to demonstrate the following skills consistently throughout the five phases of
project management. They are:

Scope Management
Time Management
Cost Management
Quality Management
Human Resource Management
Communications Management
Risk Management
Procurement Management
Integration Management

1.4.1 Internal Project Management

The most common form of project management is the formation of a project team operating
within an existing organizational structure. This format is commonly known as internal, or
nonexecutive, project management most firms are organized around functional groups that
specialize in particular areas. A typical structure would have separate sections such as sales
and marketing, finance and accounting, and operations. Each section or group makes a
specialized contribution to the whole.

The disadvantage of this structure is that people tend to become compartmentalized and work
rigidly on functional tasks. In order to make more efficient use of resources, project teams
can be set up to operate across these functional boundaries.

In this structure, the project manager takes (or is allocated) individuals from their normal
functional units and reallocates them to one or more projects. Each person therefore, now has
functional and project responsibilities. Projects operating across functional structures offer
good flexibility in the use of people. Staffs are primarily employed to perform a functional
task but are temporarily assigned to projects that require their particular expertise. In
addition, individual experts can be effectively used across a number of projects.

If there is a broad base of expertise within a functional department, it can be employed on

different projects with relative ease. The internal system also has the advantage that specialist
knowledge can easily be built up and shared within the function. Continuity of expertise,
procedures and administration is maintained within the function despite any personnel
changes that may occur.

The main characteristics of the system are as follows:

A single designated person, namely the project manager, is responsible for managing
the project organization.

The project manager acts (to some extent) independently and outside the normal
functional authority structure.

The project manager has equal authority to the functional managers over shared
(project and functional) resources.

The project manager acts as a single leader and brings together the efforts of the
various functional and project resources in order to achieve the project objectives.

Projects generally require a number of different functional specialists to work

together. The work is therefore often carried out by a range of different functional
specialists working as a multidisciplinary group under the leadership of the project
manager.

The project manager is responsible for integrating this multidisciplinary group into a
multidisciplinary project team.
 The project manager has to negotiate with individual functional managers for the use
of shared project functional resources. Functional resources often remain under the
direct control of the functional manager.

The project focuses on delivering the project objectives in relation to time, cost and
quality. The functional managers have to concentrate on maintaining an ongoing pool
of functional resources to support the primary goals of the organization. As a result
there is the potential for conflict between functional and project managers over shared
resources. This arises particularly in terms of the quality of people that functional
managers will release onto projects and the time for which they are required by the
project.

In project organizations, the virtue of these informal lines is recognized and formalized
through the creation of a horizontal hierarchy to augment the vertical hierarchy. This hybrid
organization enables people in different functional areas to be formed into highly integrated
project teams.

Given their temporary nature, an organization working on projects must be flexible, so that it
can alter structure and resources to meet the shifting requirements of different projects.

In the role of project manager, a single person is given project responsibility and is held
accountable for project success. This emphasis on project goals versus functional goals is a
major feature distinguishing project and functional management roles. Project managers often
depend on people who report directly to other managers on an ongoing basis but are assigned
to them as required.

Thus the task of project management is more complicated and diverse than in other
management areas.

1.4.2 External Project Management

External project management is where an external project manager is appointed on a

consultancy basis and acts as an external agent on behalf of the client. The external project
manager appoints other external consultants to form an external project team. The team then
works under the control of the external project manager to deliver the project within the
success criteria as defined by the client.

The main characteristics of an external project management structure are the following:
 The external project manager acts as an agent on behalf of the client. The consultancy
contract is a form of agency agreement.

The external system is more flexible than the internal system. External consultants
can be hired as required as a function of workload demand.

Instructions and communications between the external consultants and the client have
to cross the organizational boundary. This boundary acts as an interface and
represents a barrier to effective communication.

Team allegiance tends to be lower in external structures. The objectives of the

external consultants do not correspond to the objectives of the client, and the external
consultants owe no allegiance to the client organization.

There is no inbuilt knowledge of the firm. This can sometimes be a disadvantage.

1.4.3 The Knowledge Areas

Eight of the knowledge areas can be divided into two sections. The first section covers scope
management, time management, cost management, and quality management. These are
considered primary knowledge areas because they directly impact the project manager's
ability to fulfill the objectives set forth for the project. The project manager is the individual
responsible for working with all individuals and parties involved in the project to ensure the
goals of the project are achieved.

The second section of knowledge areas includes human resource management,

communications management, risk management, and procurement management. These could
be considered enabling knowledge areas: the knowledge areas that enable the project
objectives to be achieved through various processes.

The ninth knowledge area is integration management. This is an all-encompassing knowledge

area. A project manager needs to master all eight of the previously described knowledge
areas, as well as develop the ability to integrate these knowledge areas to successfully
complete a project. Integration both affects, and is affected by, the other eight knowledge
areas.

Each phase of project management encompasses certain knowledge areas.For example, in the
planning phase, scope planning must take place, which is a part of the knowledge area of
scope management. Along the same lines, in the controlling phase, scope change control must
take place, which is also a part of the knowledge area of scope management. As you move
through each phase of project management, the appropriate knowledge areas will be covered.
Mastering these knowledge areas at each phase of a project is vitally important for project
managers as it significantly increases the potential for the project to end successfully. Project
managers not only need to master these knowledge areas, but also need to work with the
project team, clients, sponsors, and stakeholders to successfully fulfill the requirements and
complete the goals of the project.

1.4.4 The Rise of Project Management

Project management has seen an increase in popularity over the past decade. Some reasons
for this include the following:

Approximately $10 trillion is spent annually on projects of all kinds

Over 16 million individuals now consider themselves professional project managers
The average salary for a project manager in 2001 was $82,000 per year

Why has project management become so popular? For one, project management offers a
variety of control mechanisms for projects. Project management can help control issues that
arise related to a project's budget, human capital, communications, resources, quality, and
time frames. These are all important aspects of completing a project successfully, and project
management will help track, manage, and control these variables.

After reading all of this, there may still be some confusion—What exactly is a project?
Organizations may define projects somewhat differently, but for the purposes of this topic:

Project - is defined as any temporary undertaking to get a new activity accomplished that
meets customer needs. This definition has several different components that need to be
examined more closely in order to get an accurate view of what constitutes a project.

1.4.5 Project vs. Process

We can define a project as any temporary undertaking to get a new activity accomplished
that meets customer needs.

The first key item to look at is the term "temporary" in the definition of project. All projects,
no matter how big or small, should have an official start and end date. An important
distinction needs to be made between a process and a project. Process is something that often
does not have start and end dates, but is something that is continuous.

With the proliferation of the Internet and e-commerce systems, many ticketing agencies
created Web sites and online ticketing systems. The creation of these Web sites and online
ticketing systems were a project—management put together a team of individuals to identify
requirements and build e-commerce systems. These projects had specific start and end dates.
Once the e-commerce systems were in place, individuals could then go to a Web site and
place orders over the Internet. Once an order was placed, the system processed the orders,
and tickets were printed and mailed to recipients. This became process that the system
performed each time an order was placed.

1.4.6 Project Goals and Customer Needs

Project is a temporary undertaking used to accomplish a new activity that will meet hte
customers needs. The next item to examine in the definition of project is the phrase "new
activity accomplished." Projects have a clear goal that needs to be accomplished by the end of
the project. Sometimes the goal of the project is tangible (a new software application) and
other times it is not (implementing a new employee process improvement technique).
Projects are usually new in the sense that the organization has a specific need for something
that is not yet present (the reason a project is conceived).

Projects also need to meet customer needs. This is true for both internal and external projects.
With external projects, the customer is usually the individual or organization that has hired
the project team. With internal projects, the customer can be a boss, a different department, or
other individuals/groups within the organization. In some instances, the individuals will also
be clients and/or stakeholders, terms that will be examined in detail later.

1.5 Uncertainty of Project Resources

Aside from the words and phrases contained in the definition of a project, projects also
involve a set of resources. These resources can include human capital, technology
infrastructure, or other assets. Most large projects require a project team, which will consist
of several team members with various skills who need to work together to complete the
project successfully. Managing team members in large projects is absolutely critical to
success.
One final note about the characteristics of a project is that each project usually has some
degree of uncertainty. When undertaking a project, it is extremely rare to be able to clearly
define the project's objectives, budget, timeline, and resources accurately from the start.
Projects that involve technology sometimes have a high level of uncertainty. Technology is
always changing, and as technology changes, so must project plans and strategies. One of the
primary tasks of a project manager is to be able to deal with uncertainty, and do his or her
best to limit the degree of uncertainty throughout the project.

Beyond technology uncertainty, however, is human uncertainty. Every project involves a

team of human beings tasked with fulfilling a goal. Whenever a group is formed, team
dynamics become important. Every person in a team contributes with a unique set of life and
work experiences, personality traits and flaws, family pressures and needs, and actual job
skills. As you might imagine, managing the human element of every project sometimes
proves to be the most difficult task.

1.6 The Triple Constraint

When undertaking a large project, it is extremely important to understand and take into
account the triple constraint. The triple constraint involves three primary constraints that most
projects will have: Time, cost, and scope. Time refers to the schedule or time constraints
related to the project. Cost involves the budget and all other monetary issues related to the
project. There is no single minimum or maximum amount of hours or dollars that defines
projects overall. Each has its own requirements. Scope deals with the goals of the project, and
the work involved in reaching those goals.

These three constraints are interrelated. If one constraint changes then the other two
constraints will also be affected. For example, if a project team is building a new Web site for
a large company, and the company decides to add an e-commerce area to the Web site, this
will affect the project's scope. The scope of the project will increase, and the time it takes to
complete the project will increase, as well as the project budget. It is possible that the
timeline may stay the same after the scope has increased, but then the budget would almost
certainly need to be increased to account for extra personnel to work on the project.

One responsibility of a project manager is to identify which of the three constraints is

most important to the project sponsor or stakeholders. Is the sponsor's number one
priority to have a fully functional product to meet customer needs, to have a product out the
door by a specific date, or to have a project completed within a specific budget amount? The
project will be planned and executed slightly differently depending on the priorities of the
client.

1.6.1 Adding Quality: The Quadruple Constraint

There is an additional constraint to every project: quality. A project manager may efficiently
prioritize and manage a project within a legitimate scope, within budget, and on time, but the
project may not satisfy the client's expectations.

This is where quality comes into play. In some instances, quality will be of the utmost
importance to the client, and the other constraints will not impact the project significantly. In
other projects the client is more interested in simply getting a product or service rolled out,
regardless of the degree of quality. Some even argue that the triple constraint involves quality
in the place of scope, and that when working with a client, the project manager needs to
determine what the client is most concerned with: quality, cost, or time. Obviously, a client
will want all three of these items, a high quality deliverable completed very quickly and at an
affordable cost.

In reality, the project manager needs to decide which two are the most important in each
instance, and base the project plan on those two. If a client wants something quick and at a
low cost, the quality may not be very good. If a client wants something of high quality at a
low budget, a somewhat longer timeline may be necessary to avoid excess staff time and
overtime costs. If the client wants something quickly and of high quality, the budget will
need to be higher to staff a larger project team and possibly pay overtime. As you can see, all
of these items are interrelated. Be sure to take quality into consideration along with the triple
constraint, as all four forms a "quadruple constraint" and are very important.

1.7 Project Management vs. Program Management

In many organizations, there will be both program and project managers. Some people think
these two types of managers perform the same duties, but this is not the case. The term
project has already been defined;

1.7.1 Program

It refers to a collection of projects that are centrally managed and often have interrelated
goals. For example, an IT department in a large organization has several projects which
include creating a new, dynamic Web site, creating a corporate Intranet, and building a
corporate-wide content management system. All of these initiatives are individual projects
and each could have a project manager.

But all of these projects also fall under a single program, which could have a program
manager. The program manager provides leadership for all project managers, makes sure
there is appropriate communication between project managers, and makes sure overarching
goals are achieved. It is important to differentiate between these two types of managers, as
each manager has significantly different roles and responsibilities.

1.8 Complications Involving IT Projects

Because we are primarily concerned with IT project management, we must discuss skill sets
that go beyond traditional project management. The nature of technology is that of change.
Technology has a lifespan of approximately 18 months before an "upgrade" or new and
improved technology is released. With long-term IT projects, this may have a profound
impact. What should a project manager do if, in the middle of a large 2-year project, a new
technology is released that would improve the quality of the final deliverable?

These are things that IT project managers need to understand how to deal with because these
issues arise often. One suggestion is to always keep your sponsor and stakeholder informed
concerning these decision points. It would make sense in the scenario outlined above for the
project manager to put together a document outlining what additional features the new
technology could provide, as well as what impact it would have on the project scope, time,
and budget if the new technology were to be implemented.

You are essentially offering the sponsor a choice: To continue with the original project plan
with the current technology, or to deviate from the project plan and incorporate the new
technology. As an IT project manager, it is your responsibility to not only keep the sponsor
informed, but also offer your professional opinion and guidance regarding this critical
decision point in the project.

1.8.1 Key IT Project Manager Duties

As mentioned earlier, a project manager needs to be very well organized and have solid
communication skills. Projects always involve uncertainty. By being organized, project
managers can deal with uncertainty in a more efficient manner. The project manager is also
responsible for keeping the project team informed and on task, delivering essential
information to keep the project moving forward in a timely manner.

One additional skill that is extremely helpful to IT project managers is to have a solid
understanding of technology, both hardware and software, how these technologies work, and
potential uses for these technologies. Since the late 1980s and early 1990s, when technology
started to play a larger and larger role in everyday life, many IT projects failed due to poor
management. Organizations tended to simply transition good managers to the IT department
to manage large-scale IT projects. Because general project managers did not have IT-specific
skills, this failed miserably, still fails in many places, and will continue to fail in the future if
this remains the strategy for managing IT projects.

Putt's Law states that the technology field is dominated by two types of people:

1. those who understand what they do not manage

2. those who manage what they do not understand.

This is a recipe for failure. Many organizations can attest to this from past experiences. This
course is designed to create individuals who enter the technology workforce able to both
manage and understand technology-centric projects, as well as effectively work within IT
project teams.

1.9 Characteristics of Projects

A project can generally be defined by its characteristics where the following apply.

It involves a single, definable purpose, product or result.

It usually has defined constraints or targets in terms of cost, schedule (time), and
performance requirements

It uses skills and talents from multiple professions and organizations.

Projects often involve advanced technology and rely on task interdependencies that may
introduce new and unique problems. Task and skill requirements vary from project to project

It is unique. A project is generally a one-off activity that is never repeated exactly.

Generally, one piece of impact damage will be unique.
 It is somewhat unfamiliar. It may encompass new technology and hence possess
significant elements of uncertainty and risk. Failure of the project might jeopardize
the organization or its goals.

It is a temporary activity. It is undertaken to accomplish a goal within a given period

of time; once the goal is achieved, the project ceases to exist.

It is part of the process involved in working to achieve a goal. During the process, a
project passes through several distinct phases; as a result, tasks, people, organizational
structure; and resources change as the project moves from one phase to the next.
Projects usually have clear start and finish points. In the case of the aircraft repair,
there will be an inspection, an appraisal, a solution, implementation, finalization and
testing.

It is part of an interlinked process. Projects are very rarely carried out in isolation.
There is usually some interlinking between different projects that are being run by any
particular organization.

It is generally of secondary importance to the organization. Projects are generally not

the primary objective of the organization. There are exceptions such as pure research
and development organizations and companies that are established purely to plan and
execute a single project.

It is relatively complex. Projects involve multidisciplinary teams and have defined

aims and objectives. In organizational terms they therefore tend to be relatively
complex as compared to the standard functional processes that operate within the
organization.

From the project characteristics highlighted above, it is clear that projects require a unique
form of management. Hence the concept of project management evolved in order to plan,
coordinate and control the many complex and often diverse activities involved in projects.

Project management is, in essence, the general management of an organization. Good project
management therefore requires the effective application of a wide range of general
management skills in order to achieve the desired goals. Skills that senior corporate
executives use daily in directing whole organizations are equally relevant to project
management, and include:

financial awareness;
 marketing appreciation;

technical knowledge;

planning skills;

strategic awareness;

quality management.

Project management covers the whole range of functional management areas. Skills are often
required in all of these areas to secure project success. Almost universally, the traditional
organisation has been structured as a pyramidal hierarchy with vertical manager–subordinate
relationships and departments along functional, geographic or product lines. Authority and
formal communication flow down from the top. Departments tend to be highly specialized
and operate independently. Traditional organisations become very efficient in what they do
and are well suited to a stable environment. They are fairly rigid and therefore less suitable to
the unstable and dynamic environments that characterize project situations.

Review Questions

1. What is Project Management?

2. What is an External Project Management?
3. What are the reasons for the rise of Project Management?
4. What is Project Vs Process? Explain?

Discussion Questions
Explain the Project Goals and the requirement of Customer need in a certain Project?

Application Exercises

1. What do you mean by Triple constraints?

2. What is the difference between Project Management and Program Management?
3. What are the key duties of IT Project Manager?
 Introduction to Project Management Concepts
CHAPTER 2 – Importance of project management

Learning Objectives

To know more about Project Management.

To analyse the importance of Project Management.
To recognise the different phases of a Project.
To explain about the external project management.
To know more about the roles and duties of Project Manager.

2.1 Introduction
Project management as a management discipline underpins much economic activity. In
industries as diverse as pharmaceuticals, software and aerospace, projects drive business. And
in the public sector, it is effective project management that translates politicians' promises of
new roads, schools and hospitals into gleaming new constructions that improve everyday life.
So you'd imagine that it would be possible to place some sort of figure on the importance of
project management to the UK economy. How much GDP does it drive? In which sectors of
the economy? And as the economy evolves, how fast is project management's prominence
increasing?

Think again. As a conversation with the UK's Office of National Statistics reveals, the official
Input-Output tables that record and analyse the makeup of economic activity within the UK
go into no finer detail than at the level of individual industries. We know that the GDP of the
UK economy in 2002 amounted to some £1044bn, up 5% from £994bn the year before. We
know which industries contributed the most to that overall GDP figure, and which
contributed least. But we know nothing in terms of officially tabulated government statistics -
about the extent of project management's contribution to that GDP.

2.2 Description
Project management is the most critical business skill and competency of today that forms the
basic building block of knowledge based company for businesses and professions in oil and
gas, petroleum, petrochemicals, chemicals, metal and mining, infrastructures, buildings, IT,
Healthcare, Finance, Telecoms, Manufacturing, and many more services and banking
industries. Fortune Magazine calls project management "Career Number 1" on earth. PMI
reported recently that nowadays more and more companies and government agencies are
adopting and making Project Management a strategic competency.

The old school thought that the project management knowledge is only applicable to some
physical project development is now history. Organizations and companies of today see and
understand that knowledge in project management brings about into their businesses ability to
plan the cost, time, and resource elements, to implement the plan, and to monitor and control
the outcome of a project with much more certainty to achieving their business destiny. Good
project management is now perceived an insurance policy in business. It prevents project
disasters.

In today's project environment, project managers are challenged to meet the demands of both
customers and their own organization management in delivering projects to at least be on
time, within budget and within scope. This responsibility cannot rest with the project
manager alone. In order to achieve these objectives, all members of the project management
team must become aware of and use sound project management practices. Project
management team shall therefore equip themselves with project management knowledge and
skills that will enable them to support the planning, implementation, and monitoring
requirements of the project.

Most people spend a lot of time in formal educations with expectation to succeed in career
life. Living life to the fullest would mean to always have an opportunity to explore,
appreciate, and expand our life potential for better achievements and be able to actualize
ourselves in society. We have aspirations to someday achieving our life potential to become a
figure, a model, or be in a role we have so much wanted and would fight for to achieve. In
many cases, we have not or may not yet find the right opportunity to do so. This could due to
lack of experience, expertise, knowledge, or simply just lack the determination to leave our
comfort zone to seize opportunity to learn & succeed when there is one available. Seize
chance to fight for what we believe we can achieve and do not let anybody including yourself
kill your dream will be key to achieving your dream.

American researchers employed by the Project Management Institute have an answer - of

sorts. On the basis of data released by the Bureau of Economic Analysis, part of the US
Department of Commerce, they estimated in 2001 that the US public and private sectors
combined spend some $2.3trn on projects every year, an amount equivalent to a quarter of
America's GDP. Construction, R&D, software development, organisational change, IT
systems - add it all together and that's the price tag. Extrapolating further, they estimated that
project-related spending accounted for almost $10trn of the world's global GDP.

On that basis, given the UK GDP of £1044bn in 2002, project-related expenditure of a

quarter of GDP yields a GDP figure of £261bn. This, of course, relies on the UK economy
being structurally similar enough to the American economy for the American estimate of
project management's contribution to GDP to hold true. While there are undoubted
differences between the two economies, they are unlikely to be significant enough to
materially affect the extrapolated UK figure. A 10% deviation either way, for example, would
indicate a range of £235bn to £287bn

There is, however, one slight problem to address when considering project management vis-
à-vis GDP estimates. And it is here that a note of caution must be injected.

Take two hypothetical projects, identical in all respects except the caliber of their project
management. One project comes in on budget, having used the planned resources. The other
dramatically exceeds its budget, using far more resources than planned. Which has the greater
contribution to GDP? The latter. Overtime payments, additional employees, replacements for
materials wasted or otherwise found faulty perversely, these additional expenditures
contribute positively to GDP, not negatively.

As a result, while GDP-based estimates of the value of project management to the UK

economy are useful starting points, a more rounded insight into the value of project
management to the UK economy must come from more qualitative data.

It’s not a secret that well being of a company is in many ways determined by success or
failure of executed projects, so it’s never a wise choice to underestimate an importance of
project management. In the article we’ll analyze stages of project management, reasons why
project fail and ways how to avoid that.

Overall project life cycle consists of five phases: definition, planning, execution, control and
closure. These steps are universal for any project whether you are planning to launch a new
product to the market, hire new accountant or through a corporate party.

Definition of the project: On this stage project manager defines the projects and the
results that are expected to be achieved.
Planning the project is probably the most challenging part of managing the project,
because on this stage all project activities should be defined and deadlines should be fixed
 for each task. During this phase project manager estimates the budget and decides how
many people they need for the execution of the project. Also on this stage risks are being
defined and manager analyzes what obstacles might interfere with the project.

Executing the project is perhaps, once project is carefully planned and team is build
project manager assigns people and allocates the budget to project tasks.

Controlling the project is perhaps the most nerve-racking stage because things seem to
never work out the way you planned. Deadlines change, people get on sick leaves, you
have to reassign the tasks and it can be quite challenging without proper software that
would help you build and rearrange workflows, assign people to tasks, send them
notifications and track your project in real-time. With Comindware Tracker you’ll be able
to do all those things without the help of a system administrator. The system is so easily
customized to all your needs that you’ll be able to build as many workflows you need
with a simple clicks of the button. Having software that allows you to rearrange workflow
in the real-time can be crucial for the project because it will allow your team get new
information without any delays and work more efficiently.

Closure of the project: During this stage the project results are discussed with the people
invested in its outcome.

2.3 Importance

All organizations use projects as the way to translate strategies into actions and objectives
into realities. Many companies are project-intensive as they live and breathe project
management because they are in that kind of business, such as construction, aerospace,
engineering design, engineer-procure-construct (EPC), general contractors, consulting,
software, and so on. For them, organizing around projects is a natural way of life as almost all
senior staff have "come up through the ranks", and top management understands what it takes
to be successful in project work. On the other hand are less project-intensive organizations
such as food, retailing and textiles. But even such companies have projects, e.g., setting up a
new distribution depot or a new plant. Even in public sector, it is effective project
management that translates politicians' visions of new roads, schools and hospitals into
gleaming new constructions that improve everyday life.
When creating a project plan it must be documented in order to identify the scope of the
project. This is the only way you can avoid scope creep. Scope creep is the evil villain in
every project manager's life.

"Scope Creep," also called "requirement creep," refers to uncontrolled changes or continuous
growth in a project's scope. This phenomenon can occur when the scope of a project was not
properly defined, documented, or controlled. It is generally considered a negative occurrence,
and needs to be avoided. Documenting the idea of the project entails a manager to create a
Work Breakdown Structure. The WBS illustrates a map of the project and aids in the efforts
to align all elements involved in the project into workable components. The framework of the
WBS provides the project manager with detailed estimates of cost and the controls needed to
maintain the schedule of the development.

Project management is the discipline of planning, organizing, motivating and controlling

resources to achieve specific goals. Very few people start in the field as full-fledged project
managers. Most are offered an assistant position on a project management team. The
superheroes that show these strong skills sets required of project managers are hard to come
by.

Realization of objectives is not easy, though; especially in today's increasingly complex and
high-stake world – richer technology, distributed / global / outsourced workgroups, culture
differences due to inorganic growth, cost pressures, new services and products, mass
customization needs for demanding customers, compressed time-to-market, increasing
market volumes and stricter regulatory requirements. Numerous studies and observations
have shown that strong business growth or other ambitious endeavors frequently bring the
following risks in deployment of strategies to manage the endeavors:
o Delays due to ineffective project planning, monitoring, coordination, risk-
management and follow-through
o Poor realization of financial goals due to ineffective scope management and
staff utilization / accountability
o Customer dissatisfaction due to lack of responsiveness, communications and
stakeholder management

Thus, the key for most organizations to remain competitive in a high-growth and fast-
changing environment is strong delivery capability made possible by uniform and effective
processes, structure, and discipline of planning and monitoring initiatives that translate
strategy into reality.

Project Management is a competency that leaders can use in their organizations to handle
increasing complexity with higher success rates and acceptance, and lower uncertainty and
costs. Following are just a few examples of the organizational inefficiencies that pose the
above-mentioned risks, but can be effectively handled through use of the Project
Management competency:
o Schedules managed in silos and dependencies are not integrated.
o Delays in one area not communicated to a dependent area, so resources not
allocated efficiently.
o Schedules having short-term forecast range. Long-term planning at the
activity-level non-existent.
o Schedules not identifying true critical paths and not including non-working
time and defect estimates.
o Many communication channels informal, and therefore information not
documented and communicated to all appropriate stakeholders in a timely
manner.
o Responsibility for decision-making not clearly defined (decisions affecting
shifting priorities or resources, changing dates, etc.).
o Lack of proactive risk identification and management.
o Inadequate reporting - lack of visibility / insight into the true status of the
projects.
o Frequently forgotten or delayed activities and decisions

The art of managing projects is about having consistency in achieving stated objectives
within limits of time, budget, and stakeholders' satisfaction, by directing and coordinating
human and material resources. Project Management is a way of life for enhanced
collaboration, governance, execution-discipline, responsiveness, and alignment of
organizational elements and procedures with features of products and operations. Project
Management skills are quite different from technical design, engineering or construction
skills usually associated with most projects, and cover aspects outside of the scope of these
technical areas that have to be well managed, if the project objectives are to be met. Project
Management also differs from traditional management in that it brings in cross-functional
collaboration, governance, execution-discipline, responsiveness, and alignment of
organizational elements and procedures with features of end-products of projects. It can help
leaders bring in agility in innovation, growth and response to changes in the external
environment.

Applying effective Project Management for deployment of strategy and goals can thus
provide organizations the following advantages:
Business advantage through timely achievement of goals, optimal resource utilization
and information based decision making
Competitive advantage through workforce energized by culture of execution and
collaboration and customer satisfied by getting the "right" results reliably

Project Management can also bring in some tangible benefits for individuals at various levels
in organizations. For example, through project management:
Executives get accurate and timely information so that they can make sound business
decisions and make course corrections quickly so they can maintain a competitive
edge.
People who execute understand their roles and responsibilities and how their work
relates to the bigger picture. Minimization of conflicts and confusions through
effective communications increases productivity and enthusiasm.

It can be concluded that project management as a management discipline, individual

competency and organizational culture underpins much economic activity and is a critical
source of multiple advantages. The specialized role of project management in bringing agility
to organizations that want to innovate, whether it is for new products or new initiatives,
cannot be ignored.

Start with finding the project champion. Every project needs a champion who can bring
together the resources to make it happen. Your champion must be someone who is passionate
about the project, believes it will make a positive impact on the organization, and is willing to
put in the time and effort to make the project succeed. It could be an executive director, an
administrator, a clinician, or anyone who understands the client data requirements. Begin by
identifying the project champion. Try to find someone who is a leader within the
organization. As with most iniatives, the chance for success is better if the project receives
support from the people at the top. Make sure your project champion is always kept in the
communication loop. Involve them in all of the major decisions regarding the project. Let
them know when key milestones have been achieved and invite them to celebrate with the
rest of the team.

2.3.1 Designate a Project Manager

In addition to a champion, your project needs a project manager. This is the person who will
be responsible for setting the objectives for the project, keeping the team on track, and
making sure the goals are achieved. A project manager is accountable for continually
balancing the golden triangle of time, money, and system features. All three of these must be
reconsidered and prioritized several times throughout the process. The project manager must
be given enough time in their workday to devote to managing the project. Some of their
duties may need to be temporarily reassigned until the project is completed.

2.3.2 Identify the Subject Matter Experts

Within the organization are many people who have expert knowledge of your current client
data management system. Some may have actually designed and built the system. Others may
not have developed the system, but use it on a daily basis. And still others may never use the
system directly, but receive important reports, spreadsheets, and other bits of information that
are produced by the system. Subject matter experts from all of these groups need to be
represented within the project team. The SMEs can tell the system developers what the
system needs to do, and how they intend to use it. They also participate throughout the
process in testing the system design to make sure it is fast, accurate and user friendly.

2.3.3 Arrange for Technical Support

You might need to bring in outside help to design, develop and/or purchase a new client data
system. Or you might have people within your own organization who can create it. Either
way, once the system is completed, someone with technical knowledge will be needed to
keep it up and running. Identify this person early in the process and consult with them often
while designing and building the new system. Ask for their input on hardware, network and
security issues. If you don't have someone on staff with this kind of technical expertise, be
sure to find someone who will volunteer or who can be trained to be the administrator of the
new system. This may involve create user logins and passwords, writing reports and queries,
making modifications, doing backups, and handling updates.

2.3.4 Develop a Communication Plan

Once you have your team in place, you will need a plan for how you will communicate with
each other about the project. There are many options for this, depending on your access to
technology and the internet. You can use phone, email, or collaborative websites. Decide as a
group who needs to be informed of issues and included in decisions. You will also need a
shared calendar for arranging meetings and setting target dates for project milestones.

Once you have your team assembled and your communication plan in order, you are ready to
take the next big step: Creating the Vision Scope Document.

Review Questions

5. What is Project Management?

6. What is the duty of Project Manager?
7. What is the necessity of a Project Manager?
8. What is GDP?

Discussion Questions
Explain the importance of Project Management? State its features?

Application Exercises

4. Describe the art of managing a Project?

5. Why an organization requires a Project Manager? State with example?
6. What steps are required so as to launch a new Product?
 Introduction to Project Management Concepts
CHAPTER 3 – Types of project

Learning Objectives

To know more about Project Management.

To analyse types of Project Management.
To recognise Project Planning.
To explain about Project preparation and analysis.
To know more about the roles and duties of Project Manager.

3.1 Introduction

Often projects form a clear and distinct portion of a larger, less precisely identified program.
The whole program might possibly be analyzed as a single project, but by and large it is
better to keep projects rather small, close to the minimum size that is economically,
technically, and administratively feasible. Similarly, it is generally better in planning projects
to analyze successive increments or distinct phases of activity; in this way the return to each
relatively small increment can be

judged separately. If a project approaches program size, there is a danger that high returns
from one part of it will mask low returns from another. A 100,000-hectare land settlement
program may well be better analyzed as five 20,000-hectare projects if the soils and slopes in
some parts are markedly different from those in others. Analyzing the whole project may hide
the fact that it is economically unwise to develop some parts of the 100,000-hectare area
instead of moving on to an entirely different region. When arranging for external financing or
planning the administrative structure, it is sometimes convenient for planners to group several
closely related projects into a single, larger "package." In these instances it may still be
preferable to retain the separate analyses of individual components, in a composite of the
whole, rather than to aggregate them into a single, overall analysis.

Again, all we can say in general about a project is that it is an activity for which money will
be spent in expectation of returns and which logically seems to lend itself to planning,
financing, and implementing as a unit. It is the smallest operational element prepared and
implemented as a separate entity in a national plan or program of agricultural development. It
is a specific activity, with a specific starting point and a specific ending point, intended to
accomplish specific objectives. Usually it is a unique activity noticeably different from
preceding, similar investments, and it is likely to be different from succeeding ones, not a
routine segment of an ongoing program. It will have a well-defined sequence of investment
and production activities, and a specific group of benefits, that we can identify, quantify, and,
usually in agricultural projects, determine a money value for.

If development can be pictured as a progression with many dimensions-temporal, spatial,

sociocultural, financial, economic-projects can be seen as the temporal and spatial units, each
with a financial and economic value and a social impact, that make up the continuum. A
project is an undertaking an observer can draw a boundary around-at least a conceptual
boundary-and say "this is the project." As well as its time sequence of investments,
production, and benefits, the project normally will have a specific geographic location or a
rather clearly understood geographic area of concentration. Probably there will also be a
specific clientele in the region whom the project is intended to reach and whose traditional
social pattern the project will affect.

Given the usefulness of the project format in the development process, the project has
increasingly been used as a "time slice" of a long-term program for a region, a commodity, or
a function such as agricultural extension. Although such projects normally have a definite
beginning and end, the importance of these starting and finishing points is reduced. Such ,a
use of the project format also makes quantification of benefits more difficult because some
benefits may not be realized until subsequent phases of the program that are not included in
the project. Often a project will have a partially or wholly independent administrative
structure and set of accounts and will be funded through a specifically defined financial
package. I hope that, after following the methodology presented

3.2 Project Planning

Project selection must always be based in part on numerical indicators of the value of costs
and returns. These can often be measured through valuation at the market prices-the prices at
which goods or services are actually traded. Unfortunately, however, market prices may be
misleading indicators of the use and return of real resources, so governments need to look at
other aspects of potential investments to judge the real effects the investments will have. For
this, good project analysis is a tremendous asset, since the investment proposal can be valued
to reflect the true scarcity of resources when market prices do not. (Note that by market
prices we refer to the actual prices at which goods and services are traded in a generalized
system of exchange, not to the particular place at which the exchange takes place. To talk of a
village "market" or a wholesale "market" is to use the word in a slightly different sense. This
may seem an obvious distinction, but in project analysis it does make a difference whether
the "market price" is collected in the appropriate "market," and we will return to this issue
later.)

Well-analyzed projects often become the vehicle for obtaining outside assistance when both
the country and the external financing agency agree on a specific project activity and know
the amount of resources involved, the timing of loan disbursements, and the benefits likely to
be realized. But project analysis should not be confined to only those investments for which
external financing will be sought. The more investments there are that can be analyzed as
projects, the more likely it is that the total use of resources for development will be efficient
and effective. To concentrate a high proportion of available analytical skills on preparing
projects for external assistance, and to leave investment of local resources basically
unplanned, is a wasteful allocation of talent. If carefully designed and high-yielding projects
are offset by essentially unplanned investments, then the net contribution to national
objectives is substantially undermined.

Sound planning requires good projects, but effective project preparation and analysis must be
set in the framework of a broader development plan. Projects are a part of an overall
development strategy and a broader planning process; as such, they must fit appropriately.
Governments must allocate their available financial and administrative resources among
many sectors and many competing programs. Project analysis can help improve this
allocation, but it alone cannot be relied upon to achieve the optimal balance of objectives.
Within the broad strategy, analysts must identify potential projects that address the policy or
production targets and priorities. Further, to make a realistic estimate about the course of a
project, some idea must be gained of what other development activities will be taking place
and what policies are likely to be pursued. Will employment growth make labor relatively
more productive and thus more expensive to use in the project? Will input supplies be
available at the time the project needs them? Will quotas be relaxed? Will food grain prices
be allowed to rise? Integration of plans and projects becomes all the more important as the
size of the project grows larger relative to the total economy. If the project alone is likely to
have a significant effect on the availability of resources and on prices in the economy as a
whole, then it must be very carefully planned in coordination with other investments and
within an appropriate policy framework included in the national plan.
For the project itself, some elements used in agricultural project analysis should not be
worked out in isolation by the individual analyst. All the projects being prepared and
analyzed should use a consistent set of assumptions about such things as the relative scarcity
of investment funds, foreign exchange, and labor. All project analyses should use the same
assumptions about the social policies and objectives to be reflected in such decisions as the
location of the project, the size of the landholding to be established, the amount of social
services to be included, and the like.

3.2.1 Project Preparation and Analysis

To design and analyze effective projects, those responsible must consider many aspects that
together determine how remunerative a proposed investment will be. All these aspects are
related. Each touches on the others, and a judgment about one aspect affects judgments about
all the others. All must be considered and reconsidered at every stage in the project planning
and implementation cycle. A major responsibility of the project analyst is to keep questioning
all the technical specialists who are contributing to a project plan to ensure that all relevant
aspects have been explicitly considered and allowed for. Here we will divide project
preparation and analysis into six aspects: technical, institutional-organizational-managerial,
social, commercial, financial, and economic. These categories derive from those suggested by
Ripman (1964), but alternative groupings would be equally valid for purposes of discussion.

3.2.1.1 Technical aspects

The technical analysis concerns the project's inputs (supplies) and outputs (production) of real
goods and services. It is extremely important, and the project framework must be defined
clearly enough to permit the technical analysis to be thorough and precise. The other aspects
of project analysis can only proceed in light of the technical analysis, although the technical
assumptions of a project plan will most likely need to be revised as the other aspects are
examined in detail. Good technical staff are essential for this work; they may be drawn from
consulting firms or technical assistance agencies abroad. They will be more effective if they
have a good understanding of the various aspects of project analysis, but technical staff, no
matter how competent, cannot work effectively if they are not given adequate time or if they
do not have the sympathetic cooperation and informed supervision of planning officials.

The technical analysis will examine the possible technical relations in a proposed agricultural
project: the soils in the region of the project and their potential for agricultural development;
the availability of water, both natural (rainfall, and its distribution) and supplied (the
possibilities for developing irrigation, with its associated drainage works); the crop varieties
and livestock species suited to the area; the production supplies and their availability; the
potential and desirability of mechanization; and pests endemic in the area and the kinds of
control that will be needed. On the basis of these and similar considerations, the technical
analysis will determine the potential yields in the project area, the coefficients of production,
potential cropping patterns, and the possibilities for multiple cropping. The technical analysis
will also examine the marketing and storage facilities required for the successful operation of
the project, and the processing systems that will be needed.

The technical analysis may identify gaps in information that must be filled either before
project planning or in the early stages of implementation (if allowance is made for the project
to be modified as more information becomes available). There may need to be soil surveys,
groundwater surveys, or collection of hydrological data. More may need to be known about
the farmers in the project, their current farming methods, and their social values to ensure
realistic choices about technology. Field trials may be needed to verify yields and other
information locally.

As the technical analysis proceeds, the project analyst must continue to make sure that the
technical work is thorough and appropriate, that the technical estimates and projections relate
to realistic conditions, and that farmers using the proposed technology on their own fields can
realize the results projected.

3.2.1.2 Institutional-organizational-managerial aspects

A whole range of issues in project preparation revolves around the overlapping institutional,
organizational, and managerial aspects of projects, which clearly have an important effect on
project implementation.

One group of questions asks whether the institutional setting of the project is appropriate. The
sociocultural patterns and institutions of those the project will serve must be considered. Does
the project design take into account the customs and culture of the farmers who will
participate? Will the project involve disruption of the ways in which farmers are accustomed
to working? If it does, what provisions are made to help them shift to new patterns? What
communication systems exist to bring farmers new information and teach them new skills?
Changing customary procedures is usually slow. Has enough time been allowed for farmers
to accept the new procedures, or is the project plan overly optimistic about rates of
acceptance?
To have a chance of being carried out, a project must relate properly to the institutional
structure of the country and region. What will be the arrangements for land tenure? What size
holding will be encouraged? Does the project incorporate local institutions and use them to
further the project? How will the administrative organization of the project relate to existing
agencies? Is there to be a separate project authority? What will be its links to the relevant
operating ministries? Will the staff be able to work with existing agencies or will there be
institutional jealousies? Too often a project's organization simply builds up opposition within
other agencies; at the very least, the project analyst must be sure such friction is minimized.
He should arrange for all agencies concerned to have an opportunity to comment on the
proposed organization of the project and ensure that their views enter in the deliberation to
the fullest extent possible.

The organizational proposals should be examined to see that the project is manageable. Is the
organization such that lines of authority will be clear? Are authority and responsibility
properly linked? Does the organizational design encourage delegation of authority, or do too
many people report directly to the project director? Does the proposed organization take
proper account of the customs and organizational procedures common in the country and
region? Or, alternatively, does it introduce enough change in organizational structure to break
out of ineffective traditional organizational forms? Are ample provisions included for
managers and government supervisors to obtain up-to-date information on the progress of the
project? Is a special monitoring group needed? What about training arrangements? Does the
project have sufficient authority to keep its accounts in order and to make disbursements
promptly?

Managerial issues are crucial to good project design and implementation. The analyst must
examine the ability of available staff to judge whether they can administer such large-scale
public sector activities as a complex water project, an extension service, or a credit agency. If
such skills are scarce or absent, should this be reflected in a less complex project
organization? Perhaps the technical analysis of the project should be consulted and the
project design concentrates on fewer or less complex technological innovations. When
managerial skills are limited, provision may have to be made for training, especially of
middle-level personnel. In some cases expatriate managers may have to be hired, and this
may raise other problems, such as the acceptance of the project manager by the local people
and the loss of the experience the expatriate manager gained while working on the project
when the manager leaves the country. In many instances it would be preferable if possible to
design the organization of the project to avoid the need for management services of
expatriates.

In agricultural projects the analyst will also want to consider the managerial skills of the
farmers who will participate. A project design that assumes new and complex managerial
skills on the part of participating farmers has obvious implications for the rate of
implementation. If farmers with past experience limited to crop production are to become
dairy farmers, enough time must be allotted for them to gain their new skills; the project
design cannot assume that they will be able to make the shift overnight. There must be
extension agents who can help farmers learn the new skills, and provision must be made for
these agents in the organizational design and in the administrative costs of the project.

In considering the managerial and administrative aspects of project design, not only are we
concerned that managerial and administrative problems will eventually be overcome, but that
a realistic assessment is made of how fast they will be resolved. The contribution an
investment makes to creating new income is very sensitive to delays in project
implementation.

3.2.1.3 Social aspects

We have mentioned the need for analysts to consider the social patterns and practices of the
clientele a project will serve. More and more frequently, project analysts are also expected to
examine carefully the broader social implications of proposed investments. We have noted
proposals to include weights for income distribution in the formal analytical framework so
that projects benefiting lower-income groups will be favored. In the analytical system
outlined in this book, such weights are not incorporated, so it is all the more important in the
project design that explicit attention be paid to income distribution.

Other social considerations should also be carefully considered to determine if a proposed

project is as responsive to national objectives as it can be. There is a question about creating
employment opportunities that is closely linked to, though not quite the same as, the question
of income distribution. For social reasons, many governments want to emphasize growth in
particular regions and want projects that can be implemented in these regions. The project
analyst will want to consider carefully the adverse effects a project may have on particular
groups in particular regions. In the past, the introduction of high-yielding seed varieties and
fertilizers, coupled with the easy availability of tractors, has led to displacement of tenant
farmers and has forced them into the ranks of the urban unemployed. Can the project be
designed to minimize such effects, or be accompanied by policy changes that will? Changes
in technology or cropping patterns may change the kind of work done by men and women. In
some areas the introduction of mechanical equipment or of cash crops has deprived women of
work they needed to support their children. Will a proposed project have such an adverse
effect on the income of working women and their families?

There are also considerations concerning the quality of life that should be a part of any
project design. A rural development project may well include provisions for improved rural
health services, for better domestic water supplies, or for increased educational opportunities
for rural children. Project analysts will want to consider the contribution of alternative
projects or other designs of essentially the same project in furthering these objectives.

Those designing or reviewing projects will also want to consider the issue of adverse
environmental impact. Irrigation development may reduce fish catches or increase the
incidence of schistosomiasis in regions where this snail-transmitted disease is endemic, and
waste from industrial plants may pollute water. Project sites may be selected with an eye to
preserving notable scenic attractions or to preserving unique wildlife habitats. It is far better
to ensure preservation of the environment by appropriate project design than to incur the
expense of retrofitting technology or reclaiming land after an environmentally unsound
project has been implemented.

3.2.1.4 Commercial aspects

The commercial aspects of a project include the arrangements for marketing the output
produced by the project and the arrangements for the supply of inputs needed to build and
operate the project.

On the output side, careful analysis of the proposed market for the project's production is
essential to ensure that there will be an effective demand at a remunerative price. Where will
the products be sold? Is the market large enough to absorb the new production without
affecting the price? If the price is likely to be affected, by how much? Will the project still be
financially viable at the new price? What share of the total market will the proposed project
supply? Are there suitable facilities for handling the new production? Perhaps provision
should be included in the project for processing, or maybe a separate marketing project for
processing and distribution is in order (Austin 1981). Is the product for domestic
consumption or for export? Does the proposed project produce the grade or quality that the
market demands? What financing arrangements will be necessary to market the output, and
what special provisions need to be made in the project to finance marketing? Since the
product must be sold at market prices, a judgment about future government price supports or
subsidies may be in order.

On the input side, appropriate arrangements must be made for farmers to secure the supplies
of fertilizers, pesticides, and high-yielding seeds they need to adopt new technology or
cropping patterns. Do market channels for inputs exist, and do they have enough capacity to
supply new inputs on time? What about financing for the suppliers of inputs and credit for the
farmers to purchase these supplies? Should new channels be established by the project or
should special arrangements be made to provide marketing channels for new inputs?

Commercial aspects.of a project also include arrangements for the procurement of equipment
and supplies. Are the procurement procedures such that undue delays can be avoided? Are
there procedures for competitive bidding to ensure fair prices? Who will draw up the
specifications for procurement?

Finally, there are the two aspects of project analysis that are the primary concerns of this
book, the financial and the economic.

3.2.1.5 Financial aspects

The financial aspects of project preparation and analysis encompass the financial effects of a
proposed project on each of its various participants. In agricultural projects the participants
include farmers, private sector firms, public corporations, project agencies, and perhaps the
national treasury. On the basis of these budgets, judgments are formed about the project's
financial efficiency, incentives, creditworthiness, and liquidity.

A major objective of the financial analysis of farms is to judge how much farm families
participating in the project will have to live on. The analyst will need budget projections that
estimate year by year future gross receipts and expenditures, including the costs associated
with production and the credit repayments farm families must make, to determine what
remains to compensate the family for its own labor, management skills, and capital. Part of
the income the family will receive may be in food that is consumed directly in the household,
so a judgment must be made about this quantity and its value. Even if a family realizes a
considerable increase in income or "net incremental benefit" by participating in the project-as
a result, say, of borrowing to purchase fertilizers to increase rice production-its absolute
income may still be so low that nearly all of the incremental production is consumed in the
household. Financial analysis must judge whether the family will then have sufficient cash to
repay the production credit for fertilizer. If not, the analyst may have to make a policy
judgment about how much to subsidize families with very low incomes.

The farm budget becomes the basis for shaping the credit terms to be made available. The
analyst must judge whether farmers will need loans to finance on-farm investment (and if so,
what proportion the farmers should invest from their own resources) or to meet some
production costs, and whether seasonal short-term credit should be provided for working
capital to finance inputs and pay for hired labor. In tree-crop projects with long development
periods, such as those for oil palm or citrus, the analyst must judge whether farmers will have
adequate income to live on during the period before the trees begin to bear, or whether
special financing arrangements must be made to sustain them. The objective of all these
judgments is to shape credit terms that will be generous enough to encourage farmers to
participate in the project, yet be stiff enough that the society as a whole can capture fairly
promptly a share of the benefit from the increased production. This benefit can, in turn, be
used to hasten growth by relending it to other farmers or by reinvesting it elsewhere in the
economy.

The analysis of farm income will also permit assessment of the incentives for farmers to
participate in the project. What will be the probable change in farm income? What will be the
timing of this change? How likely are price changes or fluctuations that could affect farm
income severely enough that farmers will refuse to run the risk of participating in the project?
What will be the effect of subsidy arrangements on farm income, and what changes in
government policy might affect the income earned by farmers? Will new subsidies be needed
to provide sufficient incentive for the project to proceed?

A similar group of considerations applies to the financial analysis of private firms involved in
the project. Will they have capital for expanding facilities? Will they have the working
capital needed to carry inventories of farm supplies or stocks of processed goods awaiting
sale? What return will the firms realize on their capital investment, and is this sufficiently
attractive?

An analysis of the financial aspects of the project's administration will also be needed. What
investment funds will the project need and when? What will be the operating expenses when
the project is under way? Will these expenses depend on budget allocations or will the project
produce sufficient revenue to cover its administrative costs? Will changes in government
policy be needed to finance the project, such as water charges levied in a new irrigation
project? What about salary scales for project personnel? How will replacement of equipment
be financed?

Finally, the fiscal impact of some projects will need to be considered. Will the increased
output yield significant new tax revenues, perhaps from an export tax? Will new subsidies be
needed to encourage farmers to participate, and how much will subsidies have to grow as
project implementation proceeds? If the administrative costs of the project are not to be met
from revenues, how will this affect the national budget in the future? If the project investment
is to be financed by a grant or by borrowing from abroad, while the operation and
maintenance cost is to be financed from domestic resources, how will this affect the treasury?

The methodology of discounted cash flow discussed in chapters 9 and 10 shows the way in
which this financial analysis customarily is set up and the usual elements included in the cost
and benefit streams. The methodology enables an estimate of the return to the equity capital
of each of the various project participants, public or private. It is then a policy decision
whether to change that return by income taxes, special lending terms, price subsidies, or any
of the other tools open to society.

3.2.1.6 Economic aspects

The economic aspects of project preparation and analysis require a determination of the
likelihood that a proposed project will contribute significantly to the development of the total
economy and that its contribution will be great enough to justify using the scarce resources it
will need. The point of view taken in the economic analysis is that of the society as a whole.

The financial and economic analyses are thus complementary-the financial analysis takes the
viewpoint of the individual participants and the economic analysis that of the society. But,
because the same discounted cash flow measures (discussed in chapter 9) are applied in the
financial analysis to estimate returns to a project participant and in the economic analysis to
estimate returns to society, confusion between the two analyses easily arises. There are three
very important distinctions between the two that must be kept in mind. These qualifications
are summarized here and are taken up in greater detail later.

First, in economic analysis taxes and subsidies are treated as transfer payments. The new
income generated by a project includes any taxes the project can bear during production and
any sales taxes buyers are willing to pay when they purchase the project's product. These
taxes, which are part of the total project benefit, are transferred to the government, which acts
on behalf of the society as a whole, and are not treated as costs. Conversely, a government
subsidy to the project is a cost to the society, since the subsidy is an expenditure of resources
that the economy incurs to operate the project. In financial analysis such adjustments are
normally unnecessary; taxes are usually treated as a cost and subsidies as a return.

Second, in financial analysis market prices are normally used. These take into account taxes
and subsidies. From these prices come the data used in the economic analysis. In economic
analysis, however, some market prices may be changed so that they more accurately reflect
social or economic values. These adjusted prices are called "shadow" or "accounting" prices
and in the analytical system recommended here are efficiency prices, as noted earlier. In both
financial and economic analysis projected prices are used, so both rely to a substantial extent
on what are, in effect, hypothetical prices.

Third, in economic analysis interest on capital is never separated and deducted from the gross
return because it is part of the total return to the capital available to the society as a whole and
because it is that total return, including interest, that economic analysis is designed to
estimate. In financial analysis, interest paid to external suppliers of money may be deducted
to derive the benefit stream available to the owners of capital. But interest imputed or "paid"
to the entity from whose point of view the financial analysis is being done is not treated as a
cost because the interest is part of the total return to the equity capital contributed by the
entity. Hence, it is a part of the financial return that entity receives.

The methodology of comparing costs and benefits discussed in chapters 9 and 10 is the same
for either an economic or a financial measurement of project worth, but what is defined as a
cost and what is considered a benefit are different. For the moment, it is enough to recognize
that there is a difference between economic and financial analysis; we will discuss the
differences in detail later.

Policymakers must be concerned about the investment of scarce capital resources that will
best further national objectives. This is true whether the resources committed are being
invested by the government directly or by individuals within the economy. The techniques of
economic analysis presented here help identify those projects that make the greatest
contribution to national income. The economic analysis in general allows for remuneration to
labor and other inputs either at market prices or at shadow prices that are intended in the
system recommended here to better approximate efficiency prices or "opportunity costs"-the
amount we must give up if we transfer a resource from its present use to the project. The
remainder is then compared with the capital stream necessary for the project. Those projects
with the best return to capital, given the total resources available, are then selected for
implementation. Inherent in this approach is the assumption that capital is the most important
limit to faster economic growth. What is not implicit in the approach is that capital alone
causes economic growth. All the productive factors combined in a project contribute to the
new income created, but the methods we will be discussing do not address themselves to the
question of what the proportionate contribution of each factor is.

Although the analysis will determine the amount of the income stream generated over and
above the costs of labor and other inputs, it does not specify who actually receives it. Part of a
project's benefit is usually taken through taxes for purposes outside the project. Part is
generally made available to compensate capital owners (including governments) for the use
of their money. Part may become the basis of an indirect transfer of income, as is the case if
farmers benefiting from a land settlement project are charged less than the full cost of
establishing their holdings. The economic analysis applied in this book is silent about such
distribution. Once the analyst knows what the more economically remunerative alternatives
are likely to be, however, he can choose those that have better effects on income distribution
or other social objectives. Although the formal economic analysis will not decide issues of
income distribution, the final decision on project investment will be an informed one that is
then made in accord with views about income distribution.

Review Questions

9. What is Project Management Aspects?

10. What is the Technical aspect of Project Management?
11. What are institutional organizational managerial aspects of Project Management?
12. What are the societal aspects of Project Management?

Discussion Questions
Explain the importance of Project Management? State its features?

Application Exercises

7. Describe the Financial aspects of Project Management?

8. What are the Commercial aspects of Project Management?
9. What is an economic aspect of Project Management?
 Introduction to Project Management Concepts
CHAPTER 4 – Project Organizational Structure

Learning Objectives

To know about the basic Ingredients in Project Management.

To analyse Trends in Modern Management.
To recognise Strategic Planning and Project Programming.
To explain about effects of Project Risks on Organization.
To know more about Organization of Project Participants.

4.1 Project Management

The management of construction projects requires knowledge of modern management as well

as an understanding of the design and construction process. Construction projects have a
specific set of objectives and constraints such as a required time frame for completion. While
the relevant technology, institutional arrangements or processes will differ, the management
of such projects has much in common with the management of similar types of projects in
other specialty or technology domains such as aerospace, pharmaceutical and energy
developments.

Generally, project management is distinguished from the general management of

corporations by the mission-oriented nature of a project. A project organization will generally
be terminated when the mission is accomplished. According to the Project Management
Institute, the discipline of project management can be defined as follows:

Project management is the art of directing and coordinating human and material resources
throughout the life of a project by using modern management techniques to achieve
predetermined objectives of scope, cost, time, quality and participation satisfaction.

By contrast, the general management of business and industrial corporations assumes a

broader outlook with greater continuity of operations. Nevertheless, there are sufficient
similarities as well as differences between the two so that modern management techniques
developed for general management may be adapted for project management.

The basic ingredients for a project management framework may be represented schematically
in Figure 4-1. A working knowledge of general management and familiarity with the special
knowledge domain related to the project are indispensable. Supporting disciplines such as
computer science and decision science may also play an important role. In fact, modern
management practices and various special knowledge domains have absorbed various
techniques or tools which were once identified only with the supporting disciplines. For
example, computer-based information systems and decision support systems are now
common-place tools for general management. Similarly, many operations research techniques
such as linear programming and network analysis are now widely used in many knowledge or
application domains. Hence, the representation in Figure 4-1 reflects only the sources from
which the project management framework evolves.

Figure 4-1: Basic Ingredients in Project Management

Specifically, project management in construction encompasses a set of objectives which may

be accomplished by implementing a series of operations subject to resource constraints.
There are potential conflicts between the stated objectives with regard to scope, cost, time
and quality, and the constraints imposed on human material and financial resources. These
conflicts should be resolved at the onset of a project by making the necessary tradeoffs or
creating new alternatives. Subsequently, the functions of project management for
construction generally include the following:

1. Specification of project objectives and plans including delineation of scope,

budgeting, scheduling, setting performance requirements, and selecting project
participants.
2. Maximization of efficient resource utilization through procurement of labor, materials
and equipment according to the prescribed schedule and plan.
3. Implementation of various operations through proper coordination and control of
planning, design, estimating, contracting and construction in the entire process.
 4. Development of effective communications and mechanisms for resolving conflicts
among the various participants.

The Project Management Institute focuses on nine distinct areas requiring project manager
knowledge and attention:

1. Project integration management to ensure that the various project elements are
effectively coordinated.
2. Project scope management to ensure that all the work required (and only the required
work) is included.
3. Project time management to provide an effective project schedule.
4. Project cost management to identify needed resources and maintain budget control.
5. Project quality management to ensure functional requirements are met.
6. Project human resource management to development and effectively employ project
personnel.
7. Project communications management to ensure effective internal and external
communications.
8. Project risk management to analyze and mitigate potential risks.
9. Project procurement management to obtain necessary resources from external sources.

These nine areas form the basis of the Project Management Institute's certification program
for project managers in any industry.

4.2 Trends in Modern Management

In recent years, major developments in management reflect the acceptance to various degrees
of the following elements:

a. the management process approach,

b. the management science and decision support approach,
c. the behavioral science approach for human resource development,
d. sustainable competitive advantage. These four approaches complement each
other in current practice, and provide a useful groundwork for project
management.

The management process approach emphasizes the systematic study of management by

identifying management functions in an organization and then examining each in detail.
There is general agreement regarding the functions of planning, organizing and controlling. A
major tenet is that by analyzing management along functional lines, a framework can be
constructed into which all new management activities can be placed. Thus, the manager's job
is regarded as coordinating a process of interrelated functions, which are neither totally
random nor rigidly predetermined, but are dynamic as the process evolves. Another tenet is
that management principles can be derived from an intellectual analysis of management
functions. By dividing the manager's job into functional components, principles based upon
each function can be extracted. Hence, management functions can be organized into a
hierarchical structure designed to improve operational efficiency, such as the example of the
organization for a manufacturing company shown in Figure 4-2. The basic management
functions are performed by all managers, regardless of enterprise, activity or hierarchical
levels. Finally, the development of a management philosophy results in helping the manager
to establish relationships between human and material resources. The outcome of following
an established philosophy of operation helps the manager win the support of the subordinates
in achieving organizational objectives.

Figure 4-2: Illustrative Hierarchical Structure of Management Functions

The management science and decision support approach contributes to the development of a
body of quantitative methods designed to aid managers in making complex decisions related
to operations and production. In decision support systems, emphasis is placed on providing
managers with relevant information. In management science, a great deal of attention is given
to defining objectives and constraints, and to constructing mathematical analysis models in
solving complex problems of inventory, materials and production control, among others. A
topic of major interest in management science is the maximization of profit, or in the absence
of a workable model for the operation of the entire system, the suboptimization of the
operations of its components. The optimization or suboptimization is often achieved by the
use of operations research techniques, such as linear programming, quadratic programming,
graph theory, queuing theory and Monte Carlo simulation. In addition to the increasing use of
computers accompanied by the development of sophisticated mathematical models and
information systems, management science and decision support systems have played an
important role by looking more carefully at problem inputs and relationships and by
promoting goal formulation and measurement of performance. Artificial intelligence has also
begun to be applied to provide decision support systems for solving ill-structured problems in
management.

The behavioral science approach for human resource development is important because
management entails getting things done through the actions of people. An effective manager
must understand the importance of human factors such as needs, drives, motivation,
leadership, personality, behavior, and work groups. Within this context, some place more
emphasis on interpersonal behavior which focuses on the individual and his/her motivations
as a socio-psychological being; others emphasize more group behavior in recognition of the
organized enterprise as a social organism, subject to all the attitudes, habits, pressures and
conflicts of the cultural environment of people.

The major contributions made by the behavioral scientists to the field of management
include:

o the formulation of concepts and explanations about individual and group

behavior in the organization,
o the empirical testing of these concepts methodically in many different
experimental and field settings,
o the establishment of actual managerial policies and decisions for operation
based on the conceptual and methodical frameworks.

Sustainable competitive advantage stems primarily from good management strategy. As

Michael Porter argues that:

Strategy is creating fit among a company's activities. The success of a strategy depends on
doing many things well - not just a few - and integrating among them. If there is no fit among
activities, there is no distinctive strategy and little sustainability.
In this view, successful firms must improve and align the many processes underway to their
strategic vision. Strategic positioning in this fashion requires:

Creating a unique and valuable position.

Making trade-offs compared to competitors
Creating a "fit" among a company's activities.

Project managers should be aware of the strategic position of their own organization and the
other organizations involved in the project. The project manager faces the difficult task of
trying to align the goals and strategies of these various organizations to accomplish the
project goals. For example, the owner of an industrial project may define a strategic goal as
being first to market with new products. In this case, facilities development must be oriented
to fast-track, rapid construction. As another example, a contracting firm may see their
strategic advantage in new technologies and emphasize profit opportunities from value
engineering.

4.3 Strategic Planning and Project Programming

The programming of capital projects is shaped by the strategic plan of an organization, which
is influenced by market demands and resources constraints. The programming process
associated with planning and feasibility studies sets the priorities and timing for initiating
various projects to meet the overall objectives of the organizations. However, once this
decision is made to initiate a project, market pressure may dictate early and timely
completion of the facility.

Among various types of construction, the influence of market pressure on the timing of
initiating a facility is most obvious in industrial construction. Demand for an industrial
product may be short-lived, and if a company does not hit the market first, there may not be
demand for its product later. With intensive competition for national and international
markets, the trend of industrial construction moves toward shorter project life cycles,
particularly in technology intensive industries.

In order to gain time, some owners are willing to forego thorough planning and feasibility
study so as to proceed on a project with inadequate definition of the project scope. Invariably,
subsequent changes in project scope will increase construction costs; however, profits derived
from earlier facility operation often justify the increase in construction costs. Generally, if the
owner can derive reasonable profits from the operation of a completed facility, the project is
considered a success even if construction costs far exceed the estimate based on an
inadequate scope definition. This attitude may be attributed in large part to the uncertainties
inherent in construction projects. It is difficult to argue that profits might be even higher if
construction costs could be reduced without increasing the project duration. However, some
projects, notably some nuclear power plants, are clearly unsuccessful and abandoned before
completion, and their demise must be attributed at least in part to inadequate planning and
poor feasibility studies.

The owner or facility sponsor holds the key to influence the construction costs of a project
because any decision made at the beginning stage of a project life cycle has far greater
influence than those made at later stages, as shown schematically in Figure 2-3. Moreover,
the design and construction decisions will influence the continuing operating costs and, in
many cases, the revenues over the facility lifetime. Therefore, an owner should obtain the
expertise of professionals to provide adequate planning and feasibility studies. Many owners
do not maintain an in-house engineering and construction management capability, and they
should consider the establishment of an ongoing relationship with outside consultants in order
to respond quickly to requests. Even among those owners who maintain engineering and
construction divisions, many treat these divisions as reimbursable, independent organizations.
Such an arrangement should not discourage their legitimate use as false economies in
reimbursable costs from such divisions can indeed be very costly to the overall organization.
Figure 4-3: Ability to Influence Construction Cost Over Time

Finally, the initiation and execution of capital projects places demands on the resources of the
owner and the professionals and contractors to be engaged by the owner. For very large
projects, it may bid up the price of engineering services as well as the costs of materials and
equipment and the contract prices of all types. Consequently, such factors should be taken
into consideration in determining the timing of a project.

4.3.1 Examples

4.3.1.1 Setting priorities for projects

A department store planned to expand its operation by acquiring 20 acres of land in the
southeast of a metropolitan area which consists of well established suburbs for middle
income families. An architectural/engineering (A/E) firm was engaged to design a shopping
center on the 20-acre plot with the department store as its flagship plus a large number of
storefronts for tenants. One year later, the department store owner purchased 2,000 acres of
farm land in the northwest outskirts of the same metropolitan area and designated 20 acres of
this land for a shopping center. The A/E firm was again engaged to design a shopping center
at this new location.

The A/E firm was kept completely in the dark while the assemblage of the 2,000 acres of land
in the northwest quietly took place. When the plans and specifications for the southeast
shopping center were completed, the owner informed the A/E firm that it would not proceed
with the construction of the southeast shopping center for the time being. Instead, the owner
urged the A/E firm to produce a new set of similar plans and specifications for the northwest
shopping center as soon as possible, even at the sacrifice of cost saving measures. When the
plans and specifications for the northwest shopping center were ready, the owner
immediately authorized its construction. However, it took another three years before the
southeast shopping center was finally built.

The reason behind the change of plan was that the owner discovered the availability of the
farm land in the northwest which could be developed into residential real estate properties for
upper middle income families. The immediate construction of the northwest shopping center
would make the land development parcels more attractive to home buyers. Thus, the owner
was able to recoup enough cash flow in three years to construct the southeast shopping center
in addition to financing the construction of the northeast shopping center, as well as the land
development in its vicinity.

While the owner did not want the construction cost of the northwest shopping center to run
wild, it apparently was satisfied with the cost estimate based on the detailed plans of the
southeast shopping center. Thus, the owner had a general idea of what the construction cost
of the northwest shopping center would be, and did not wish to wait for a more refined cost
estimate until the detailed plans for that center were ready. To the owner, the timeliness of
completing the construction of the northwest shopping center was far more important than
reducing the construction cost in fulfilling its investment objectives.

4.3.1.2 Resource Constraints for Mega Projects

A major problem with mega projects is the severe strain placed on the environment,
particularly on the resources in the immediate area of a construction project. "Mega" or
"macro" projects involve construction of very large facilities such as the Alaska pipeline
constructed in the 1970's or the Panama Canal constructed in the 1900's. The limitations in
some or all of the basic elements required for the successful completion of a mega project
include:

engineering design professionals to provide sufficient manpower to complete the

design within a reasonable time limit.
construction supervisors with capacity and experience to direct large projects.
the number of construction workers with proper skills to do the work.
 the market to supply materials in sufficient quantities and of required quality on time.
the ability of the local infrastructure to support the large number of workers over an
extended period of time, including housing, transportation and other services.

To compound the problem, mega projects are often constructed in remote environments away
from major population centers and subject to severe climate conditions. Consequently,
special features of each mega project must be evaluated carefully.

4.4 Effects of Project Risks on Organization

The uncertainty in undertaking a construction project comes from many sources and often
involves many participants in the project. Since each participant tries to minimize its own
risk, the conflicts among various participants can be detrimental to the project. Only the
owner has the power to moderate such conflicts as it alone holds the key to risk assignment
through proper contractual relations with other participants. Failure to recognize this
responsibility by the owner often leads to undesirable results. In recent years, the concept of
"risk sharing/risk assignment" contracts has gained acceptance by the federal
government. Since this type of contract acknowledges the responsibilities of the owners, the
contract prices are expected to be lower than those in which all risks are assigned to
contractors.

In approaching the problem of uncertainty, it is important to recognize that incentives must

be provided if any of the participants is expected to take a greater risk. The willingness of a
participant to accept risks often reflects the professional competence of that participant as
well as its propensity to risk. However, society's perception of the potential liabilities of the
participant can affect the attitude of risk-taking for all participants. When a claim is made
against one of the participants, it is difficult for the public to know whether a fraud has been
committed, or simply that an accident has occurred.

Risks in construction projects may be classified in a number of ways. One form of

classification is as follows:

1. Socioeconomic factors
o Environmental protection
o Public safety regulation
o Economic instability
o Exchange rate fluctuation
 2. Organizational relationships
o Contractual relations
o Attitudes of participants
o Communication
3. Technological problems
o Design assumptions
o Site conditions
o Construction procedures
o Construction occupational safety

The environmental protection movement has contributed to the uncertainty for construction
because of the inability to know what will be required and how long it will take to obtain
approval from the regulatory agencies. The requirements of continued re-evaluation of
problems and the lack of definitive criteria which are practical have also resulted in added
costs. Public safety regulations have similar effects, which have been most noticeable in the
energy field involving nuclear power plants and coal mining. The situation has created
constantly shifting guidelines for engineers, constructors and owners as projects move
through the stages of planning to construction. These moving targets add a significant new
dimension of uncertainty which can make it virtually impossible to schedule and complete
work at budgeted cost. Economic conditions of the past decade have further reinforced the
climate of uncertainty with high inflation and interest rates. The deregulation of financial
institutions has also generated unanticipated problems related to the financing of
construction.

Uncertainty stemming from regulatory agencies, environmental issues and financial aspects
of construction should be at least mitigated or ideally eliminated. Owners are keenly
interested in achieving some form of breakthrough that will lower the costs of projects and
mitigate or eliminate lengthy delays. Such breakthroughs are seldom planned. Generally, they
happen when the right conditions exist, such as when innovation is permitted or when a basis
for incentive or reward exists. However, there is a long way to go before a true partnership of
all parties involved can be forged.

During periods of economic expansion, major capital expenditures are made by industries
and bid up the cost of construction. In order to control costs, some owners attempt to use
fixed price contracts so that the risks of unforeseen contingencies related to an overheated
economy are passed on to contractors. However, contractors will raise their prices to
compensate for the additional risks.

The risks related to organizational relationships may appear to be unnecessary but are quite
real. Strained relationships may develop between various organizations involved in the
design/construct process. When problems occur, discussions often center on responsibilities
rather than project needs at a time when the focus should be on solving the problems.
Cooperation and communication between the parties are discouraged for fear of the effects of
impending litigation. This barrier to communication results from the ill-conceived notion that
uncertainties resulting from technological problems can be eliminated by appropriate contract
terms. The net result has been an increase in the costs of constructed facilities.

The risks related to technological problems are familiar to the design/construct professions
which have some degree of control over this category. However, because of rapid advances in
new technologies which present new problems to designers and constructors, technological
risk has become greater in many instances. Certain design assumptions which have served the
professions well in the past may become obsolete in dealing with new types of facilities
which may have greater complexity or scale or both. Site conditions, particularly subsurface
conditions which always present some degree of uncertainty, can create an even greater
degree of uncertainty for facilities with heretofore unknown characteristics during operation.
Because construction procedures may not have been fully anticipated, the design may have to
be modified after construction has begun. An example of facilities which have encountered
such uncertainty is the nuclear power plant, and many owners, designers and contractors have
suffered for undertaking such projects.

If each of the problems cited above can cause uncertainty, the combination of such problems
is often regarded by all parties as being out of control and inherently risky. Thus, the issue of
liability has taken on major proportions and has influenced the practices of engineers and
constructors, who in turn have influenced the actions of the owners.

Many owners have begun to understand the problems of risks and are seeking to address
some of these problems. For example, some owners are turning to those organizations that
offer complete capabilities in planning, design, and construction, and tend to avoid breaking
the project into major components to be undertaken individually by specialty participants.
Proper coordination throughout the project duration and good organizational communication
can avoid delays and costs resulting from fragmentation of services, even though the
components from various services are eventually integrated.
Attitudes of cooperation can be readily applied to the private sector, but only in special
circumstances can they be applied to the public sector. The ability to deal with complex
issues is often precluded in the competitive bidding which is usually required in the public
sector. The situation becomes more difficult with the proliferation of regulatory requirements
and resulting delays in design and construction while awaiting approvals from government
officials who do not participate in the risks of the project.

4.5 Organization of Project Participants

The top management of the owner sets the overall policy and selects the appropriate
organization to take charge of a proposed project. Its policy will dictate how the project life
cycle is divided among organizations and which professionals should be engaged. Decisions
by the top management of the owner will also influence the organization to be adopted for
project management. In general, there are many ways to decompose a project into stages. The
most typical ways are:

Sequential processing whereby the project is divided into separate stages and each
stage is carried out successively in sequence.
Parallel processing whereby the project is divided into independent parts such that all
stages are carried out simultaneously.
Staggered processing whereby the stages may be overlapping, such as the use of
phased design-construct procedures for fast track operation.

It should be pointed out that some decompositions may work out better than others,
depending on the circumstances. In any case, the prevalence of decomposition makes the
subsequent integration particularly important. The critical issues involved in organization for
project management are:

How many organizations are involved?

What are the relationships among the organizations?
When are the various organizations brought into the project?

There are two basic approaches to organize for project implementation, even though many
variations may exist as a result of different contractual relationships adopted by the owner
and builder. These basic approaches are divided along the following lines:
 1. Separation of organizations. Numerous organizations serve as consultants or
contractors to the owner, with different organizations handling design and
construction functions. Typical examples which involve different degrees of
separation are:
o Traditional sequence of design and construction
o Professional construction management
2. Integration of organizations. A single or joint venture consisting of a number of
organizations with a single command undertakes both design and construction
functions. Two extremes may be cited as examples:
o Owner-builder operation in which all work will be handled in house by force
account.
o Turnkey operation in which all work is contracted to a vendor which is
responsible for delivering the completed project

Since construction projects may be managed by a spectrum of participants in a variety of

combinations, the organization for the management of such projects may vary from case to
case. On one extreme, each project may be staffed by existing personnel in the functional
divisions of the organization on an ad-hoc basis as shown in Figure 2-4 until the project is
completed. This arrangement is referred to as the matrix organization as each project manager
must negotiate all resources for the project from the existing organizational framework. On
the other hand, the organization may consist of a small central functional staff for the
exclusive purpose of supporting various projects, each of which has its functional divisions as
shown in Figure 4-5. This decentralized set-up is referred to as the project oriented
organization as each project manager has autonomy in managing the project. There are many
variations of management style between these two extremes, depending on the objectives of
the organization and the nature of the construction project. For example, a large chemical
company with in-house staff for planning, design and construction of facilities for new
product lines will naturally adopt the matrix organization. On the other hand, a construction
company whose existence depends entirely on the management of certain types of
construction projects may find the project-oriented organization particularly attractive. While
organizations may differ, the same basic principles of management structure are applicable to
most situations.
Figure 4-4: A Matrix Organization

Figure 4-5: A Project-Oriented Organization

To illustrate various types of organizations for project management, we shall consider two
examples, the first one representing an owner organization while the second one representing
the organization of a construction management consultant under the direct supervision of the
owner.

4.5.1 Matrix Organization of an Engineering Division

The Engineering Division of an Electric Power and Light Company has functional
departments as shown in Figure 2-6. When small scale projects such as the addition of a
transmission tower or a sub-station are authorized, a matrix organization is used to carry out
such projects. For example, in the design of a transmission tower, the professional skill of a
structural engineer is most important. Consequently, the leader of the project team will be
selected from the Structural Engineering Department while the remaining team members are
selected from all departments as dictated by the manpower requirements. On the other hand,
in the design of a new sub-station, the professional skill of an electrical engineer is most
important. Hence, the leader of the project team will be selected from the Electrical
Engineering Department.

Figure 4-6: The Matrix Organization in an Engineering Division

4.5.2 Example of Construction Management Consultant Organization

When the same Electric Power and Light Company in the previous example decided to build
a new nuclear power plant, it engaged a construction management consultant to take charge
of the design and construction completely. However, the company also assigned a project
team to coordinate with the construction management consultant as shown in Figure 4-7.
Figure 4-7: Coordination between Owner and Consultant

Since the company eventually will operate the power plant upon its completion, it is highly
important for its staff to monitor the design and construction of the plant. Such coordination
allows the owner not only to assure the quality of construction but also to be familiar with the
design to facilitate future operation and maintenance. Note the close direct relationships of
various departments of the owner and the consultant. Since the project will last for many
years before its completion, the staff members assigned to the project team are not expected
to rejoin the Engineering Department but will probably be involved in the future operation of
the new plant. Thus, the project team can act independently toward its designated mission.

4.6 Traditional Designer-Constructor Sequence

For ordinary projects of moderate size and complexity, the owner often employs a designer
(an architectural/engineering firm) which prepares the detailed plans and specifications for
the constructor (a general contractor). The designer also acts on behalf of the owner to
oversee the project implementation during construction. The general contractor is responsible
for the construction itself even though the work may actually be undertaken by a number of
specialty subcontractors.

The owner usually negotiates the fee for service with the architectural/engineering (A/E)
firm. In addition to the responsibilities of designing the facility, the A/E firm also exercises to
some degree supervision of the construction as stipulated by the owner. Traditionally, the
A/E firm regards itself as design professionals representing the owner who should not
communicate with potential contractors to avoid collusion or conflict of interest. Field
inspectors working for an A/E firm usually follow through the implementation of a project
after the design is completed and seldom have extensive input in the design itself. Because of
the litigation climate in the last two decades, most A/E firms only provide observers rather
than inspectors in the field. Even the shop drawings of fabrication or construction schemes
submitted by the contractors for approval are reviewed with a disclaimer of responsibility by
the A/E firms.

The owner may select a general constructor either through competitive bidding or through
negotiation. Public agencies are required to use the competitive bidding mode, while private
organizations may choose either mode of operation. In using competitive bidding, the owner
is forced to use the designer-constructor sequence since detailed plans and specifications
must be ready before inviting bidders to submit their bids. If the owner chooses to use a
negotiated contract, it is free to use phased construction if it so desires.

The general contractor may choose to perform all or part of the construction work, or act only
as a manager by subcontracting all the construction to subcontractors. The general contractor
may also select the subcontractors through competitive bidding or negotiated contracts. The
general contractor may ask a number of subcontractors to quote prices for the subcontracts
before submitting its bid to the owner. However, the subcontractors often cannot force the
winning general contractor to use them on the project. This situation may lead to practices
known as bid shopping and bid peddling. Bid shopping refers to the situation when the
general contractor approaches subcontractors other than those whose quoted prices were used
in the winning contract in order to seek lower priced subcontracts. Bid peddling refers to the
actions of subcontractors who offer lower priced subcontracts to the winning general
subcontractors in order to dislodge the subcontractors who originally quoted prices to the
general contractor prior to its bid submittal. In both cases, the quality of construction may be
sacrificed, and some state statutes forbid these practices for public projects.

Although the designer-constructor sequence is still widely used because of the public
perception of fairness in competitive bidding, many private owners recognize the
disadvantages of using this approach when the project is large and complex and when market
pressures require a shorter project duration than that which can be accomplished by using this
traditional method.

4.7 Professional Construction Management

Professional construction management refers to a project management team consisting of a
professional construction manager and other participants who will carry out the tasks of
project planning, design and construction in an integrated manner. Contractual relationships
among members of the team are intended to minimize adversarial relationships and contribute
to greater response within the management group. A professional construction manager is a
firm specialized in the practice of professional construction management which includes:

Work with owner and the A/E firms from the beginning and make recommendations
on design improvements, construction technology, schedules and construction
economy.
Propose design and construction alternatives if appropriate, and analyze the effects of
the alternatives on the project cost and schedule.
Monitor subsequent development of the project in order that these targets are not
exceeded without the knowledge of the owner.
Coordinate procurement of material and equipment and the work of all construction
contractors, and monthly payments to contractors, changes, claims and inspection for
conforming design requirements.
Perform other project related services as required by owners.

Professional construction management is usually used when a project is very large or

complex. The organizational features that are characteristics of mega-projects can be
summarized as follows:

The overall organizational approach for the project will change as the project
advances. The "functional" organization may change to a "matrix" which may change
to a "project" organization (not necessarily in this order).
Within the overall organization, there will probably be functional, project, and matrix
sub organizations all at the same time. This feature greatly complicates the theory and
the practice of management, yet is essential for overall cost effectiveness.
Successful giant, complex organizations usually have a strong matrix-type sub
organization at the level where basic cost and schedule control responsibility is
assigned. This sub organization is referred to as a "cost center" or as a "project" and is
headed by a project manager. The cost center matrix may have participants assigned
from many different functional groups. In turn, these functional groups may have
technical reporting responsibilities to several different and higher tiers in the
 organization. The key to a cost effective effort is the development of this project sub
organization into a single team under the leadership of a strong project manager.
The extent to which decision-making will be centralized or decentralized is crucial to
the organization of the mega-project.

Consequently, it is important to recognize the changing nature of the organizational structure

as a project is carried out in various stages.

4.7.1 Managing of the Alaska Pipeline Project

The Alaska Pipeline Project was the largest, most expensive private construction project in
the 1970's, which encompassed 800 miles, thousands of employees, and 10 billion dollars.

At the planning stage, the owner (a consortium) employed a Construction Management

Contractor (CMC) to direct the pipeline portion, but retained centralized decision making to
assure single direction and to integrate the effort of the CMC with the pump stations and the
terminals performed by another contractor. The CMC also centralized its decision making in
directing over 400 subcontractors and thousands of vendors. Because there were 19 different
construction camps and hundreds of different construction sites, this centralization caused
delays in decision making.

At about the 15% point of physical completion, the owner decided to reorganize the decision
making process and change the role of the CMC. The new organization was a combination of
owner and CMC personnel assigned within an integrated organization. The objective was to
develop a single project team responsible for controlling all subcontractors. Instead of having
nine tiers of organization from the General Manager of the CMC to the subcontractors, the
new organization had only four tiers from the Senior Project Manager of the owner to
subcontractors. Besides unified direction and coordination, this reduction in tiers of
organization greatly improved communications and the ability to make and implement
decisions. The new organization also allowed decentralization of decision making by treating
five sections of the pipeline at different geographic locations as separate projects, with a
section manager responsible for all functions of the section as a profit center.

At about 98% point of physical completion, all remaining activities were to be consolidated
to identify single bottom-line responsibility, to reduce duplication in management staff, and
to unify coordination of remaining work. Thus, the project was first handled by separate
organizations but later was run by an integrated organization with decentralized profit
centers. Finally, the organization in effect became small and was ready to be phased out of
operation.

4.8 Owner-Builder Operation

In this approach an owner must have a steady flow of on-going projects in order to maintain a
large work force for in-house operation. However, the owner may choose to subcontract a
substantial portion of the project to outside consultants and contractors for both design and
construction, even though it retains centralized decision making to integrate all efforts in
project implementation.

4.8.1 Army Corps of Engineers Organization

The District Engineer's Office of the U.S. Army Corps of Engineers may be viewed as a
typical example of an owner-builder approach as shown in Figure 4-8.

Figure 4-8: Organization of a District of Corps of Engineers

In the District Engineer's Office of the U.S. Corps of Engineers, there usually exist an
Engineering Division and an Operations Division, and, in a large district, a Construction
Division. Under each division, there are several branches. Since the authorization of a project
is usually initiated by the U.S. Congress, the planning and design functions are separated in
order to facilitate operations. Since the authorization of the feasibility study of a project may
precede the authorization of the design by many years, each stage can best be handled by a
different branch in the Engineering Division. If construction is ultimately authorized, the
work may be handled by the Construction Division or by outside contractors. The Operations
Division handles the operation of locks and other facilities which require routine attention
and maintenance.

When a project is authorized, a project manager is selected from the most appropriate branch
to head the project, together with a group of staff drawn from various branches to form the
project team. When the project is completed, all members of the team including the project
manager will return to their regular posts in various branches and divisions until the next
project assignment. Thus, a matrix organization is used in managing each project.

4.9 Turnkey Operation

Some owners wish to delegate all responsibilities of design and construction to outside
consultants in a turnkey project arrangement. A contractor agrees to provide the completed
facility on the basis of performance specifications set forth by the owner. The contractor may
even assume the responsibility of operating the project if the owner so desires. In order for a
turnkey operation to succeed, the owner must be able to provide a set of unambiguous
performance specifications to the contractor and must have complete confidence in the
capability of the contractor to carry out the mission.

This approach is the direct opposite of the owner-builder approach in which the owner wishes
to retain the maximum amount of control for the design-construction process.

4.9.1 Example of a Turnkey Organization

A 150-Mw power plant was proposed in 1985 by the Texas-New Mexico Power Company of
Fort Worth, Texas, which would make use of the turnkey operation. Upon approval by the
Texas Utility Commission, a consortium consisting of H.B. Zachry Co., Westinghouse
Electric Co., and Combustion Engineering, Inc. would design, build and finance the power
plant for completion in 1990 for an estimated construction cost of $200 million in 1990
dollars. The consortium would assume total liability during construction, including debt
service costs, and thereby eliminate the risks of cost escalation to rate payers, stockholders
and the utility company management.

4.10 Leadership and Motivation for the Project Team

The project manager, in the broadest sense of the term, is the most important person for the
success or failure of a project. The project manager is responsible for planning, organizing
and controlling the project. In turn, the project manager receives authority from the
management of the organization to mobilize the necessary resources to complete a project.

The project manager must be able to exert interpersonal influence in order to lead the project
team. The project manager often gains the support of his/her team through a combination of
the following:

Formal authority resulting from an official capacity which is empowered to issue

orders.
Reward and/or penalty power resulting from his/her capacity to dispense directly or
indirectly valued organization rewards or penalties.
Expert power when the project manager is perceived as possessing special knowledge
or expertise for the job.
Attractive power because the project manager has a personality or other
characteristics to convince others.

In a matrix organization, the members of the functional departments may be accustomed to a

single reporting line in a hierarchical structure, but the project manager coordinates the
activities of the team members drawn from functional departments. The functional structure
within the matrix organization is responsible for priorities, coordination, administration and
final decisions pertaining to project implementation. Thus, there are potential conflicts
between functional divisions and project teams. The project manager must be given the
responsibility and authority to resolve various conflicts such that the established project
policy and quality standards will not be jeopardized. When contending issues of a more
fundamental nature are developed, they must be brought to the attention of a high level in the
management and be resolved expeditiously.

In general, the project manager's authority must be clearly documented as well as defined,
particularly in a matrix organization where the functional division managers often retain
certain authority over the personnel temporarily assigned to a project. The following
principles should be observed:

The interface between the project manager and the functional division managers
should be kept as simple as possible.
The project manager must gain control over those elements of the project which may
overlap with functional division managers.
 The project manager should encourage problem solving rather than role playing of
team members drawn from various functional divisions.

4.11 Interpersonal Behavior in Project Organizations

While a successful project manager must be a good leader, other members of the project team
must also learn to work together, whether they are assembled from different divisions of the
same organization or even from different organizations. Some problems of interaction may
arise initially when the team members are unfamiliar with their own roles in the project team,
particularly for a large and complex project. These problems must be resolved quickly in
order to develop an effective, functioning team.

Many of the major issues in construction projects require effective interventions by

individuals, groups and organizations. The fundamental challenge is to enhance
communication among individuals, groups and organizations so that obstacles in the way of
improving interpersonal relations may be removed. Some behavior science concepts are
helpful in overcoming communication difficulties that block cooperation and coordination. In
very large projects, professional behavior scientists may be necessary in diagnosing the
problems and advising the personnel working on the project. The power of the organization
should be used judiciously in resolving conflicts.

The major symptoms of interpersonal behavior problems can be detected by experienced

observers, and they are often the sources of serious communication difficulties among
participants in a project. For example, members of a project team may avoid each other and
withdraw from active interactions about differences that need to be dealt with. They may
attempt to criticize and blame other individuals or groups when things go wrong. They may
resent suggestions for improvement, and become defensive to minimize culpability rather
than take the initiative to maximize achievements. All these actions are detrimental to the
project organization.

While these symptoms can occur to individuals at any organization, they are compounded if
the project team consists of individuals who are put together from different organizations.
Invariably, different organizations have different cultures or modes of operation. Individuals
from different groups may not have a common loyalty and may prefer to expand their energy
in the directions most advantageous to themselves instead of the project team. Therefore, no
one should take it for granted that a project team will work together harmoniously just
because its members are placed physically together in one location. On the contrary, it must
be assumed that good communication can be achieved only through the deliberate effort of
the top management of each organization contributing to the joint venture.

4.12 Perceptions of Owners and Contractors

Although owners and contractors may have different perceptions on project management for
construction, they have a common interest in creating an environment leading to successful
projects in which performance quality, completion time and final costs are within prescribed
limits and tolerances. It is interesting therefore to note the opinions of some leading
contractors and owners who were interviewed in 1984.

From the responses of six contractors, the key factors cited for successful projects are:

well defined scope

extensive early planning
good leadership, management and first line supervision
positive client relationship with client involvement
proper project team chemistry
quick response to changes
engineering managers concerned with the total project, not just the engineering
elements.

Conversely, the key factors cited for unsuccessful projects are:

ill-defined scope
poor management
poor planning
breakdown in communication between engineering and construction
unrealistic scope, schedules and budgets
many changes at various stages of progress
lack of good project control

The responses of eight owners indicated that they did not always understand the concerns of
the contractors although they generally agreed with some of the key factors for successful and
unsuccessful projects cited by the contractors. The significant findings of the interviews with
owners are summarized as follows:
 All owners have the same perception of their own role, but they differ significantly in
assuming that role in practice.
The owners also differ dramatically in the amount of early planning and in providing
information in bid packages.
There is a trend toward breaking a project into several smaller projects as the projects
become larger and more complex.
Most owners recognize the importance of schedule, but they adopt different
requirements in controlling the schedule.
All agree that people are the key to project success.

Review Questions

13. What is Traditional Designer-Constructor Sequence?

14. What is Professional Construction Management?
15. Explain Owner-Builder Operation?
16. What is Turnkey Operation in Project Management?

Discussion Questions
Explain the importance of Construction Management Consultant Organization? State
its features with examples?

Application Exercises

10. Describe the Leadership and Motivation for the Project Team?
11. What are Interpersonal Behavior in Project Organizations?
12. What are the Perceptions of Owners and Contractors?
 Introduction to Project Management Concepts
CHAPTER 5 – Project life cycle

Learning Objectives

To know about the phases of Project Life Cycle.

To analyse templates of various phases.
To recognise Project Plan and Resource Plan.
To explain about Project Execution & Control.
To know more about Post Implementation Review.

5.1 Introduction

The project life cycle consists of four phases such as:

initiation,
planning,
execution
evaluation

The MPMM Project Management Methodology is an excellent resource for this part of the
Unit. The Initiation phase begins by defining the:

scope,
purpose,
objectives,
resources,
deliverables,
timescales
structure

of the project. The next step is to develop a Business Case, including several possible
solutions and a cost/benefit analysis for each. A Feasibility Study should then be carried out
to ensure that the chosen solution is feasible and has an acceptable level of risk. The next step
is to define the Terms of Reference, followed by the appointment of the project team. The
final step is to carry out Phase Review before seeking approval to proceed. The first step of
the Planning phase is the creation of a detailed Project Plan which the project manager will
refer throughout the project to monitor and control time, cost and quality. The project
manager will then create the following plans:

Resource Plan: to identify the staffing, equipment and materials needed

Financial Plan: to quantify the financial expenditure required
Quality Plan: to set quality targets and specify Quality Control methods
Risk Plan: to identify risks and plan actions needed to minimise them
Acceptance Plan: to specify criteria for accepting deliverables

Finally, a Phase Review is carried out to assess the deliverables produced to date and approve
the start of the Project Execution phase. During the Project Execution phase the project team
produces the deliverables while the project manager monitors and controls the project
delivery by undertaking:

Time Management: tracking and recording time spent on tasks against the Project
Plan
Cost Management: identifying and recording costs against the project budget
Quality Management: reviewing the quality of the deliverables and management
processes
Change Management: reviewing and implementing requests for changes to the project
Risk Management: assessing the level of project risk and taking action to minimize it
Issue Management: identifying and resolving project issues
Acceptance Management: identifying the completion of deliverables and gaining the
customers acceptance
Communications Management: keeping stakeholders informed of project progress,
risks and issues

Once the customer has accepted the deliverables and a Phase Review has been carried out to
determine whether the project objectives have been achieved, the project is ready for Closure.
A Project Closure Report should list all of the actions required. When this has been approved,
the listed actions are completed to release project resources, hand over deliverables, and
inform all stakeholders that the project is now closed. Shortly after the project has been
closed, an Evaluation also known as a Post-Implementation Review should be carried out to
determine the project's overall success and find out whether the benefits stated in the original
Business Case were actually realised. Any lessons learned should be documented for future
projects.
 5.2 Phases
The Project Life Cycle refers to a logical sequence of activities to accomplish the project’s
goals or objectives. Regardless of scope or complexity, any project goes through a series of
phases during its life. Typically the Project Life Cycle consists of four primary phases, as it is
presented in the following diagram:

Figure 5.1: Project Lifecycle

5.2.1 Project Initiation.

In this phase a business problem or an opportunity is identified and a Business Case which
provides alternative solutions is defined. Prior, during or after the development of the
Business Case, a Cost/ Benefit Analysis and a feasibility study are usually conducted to
identify the alternative with the maximum net benefit and investigate the likelihood of each
solution option addressing the business problem. As an outcome of the Business Case a final
recommended solution is put forward. Once the recommended solution is approved, the
Executive and the Project Manager are appointed in order to participate in the preparation of
the ―
Project Fiche‖, which outlines the scope, objectives, activities, structure, budget,
implementation schedule, risks, constraints and assumptions of the project. When the Project
Fiche is approved, the remaining members of the Project Management Team is appointed.

The initiation phase is the beginning of the project. In this phase, the idea for the project is

explored and elaborated. The goal of this phase is to examine the feasibility of the
project. In
addition, decisions are made concerning who is to carry out the project, which party will
be involved and whether the project has an adequate base of support among
 those who are involved.

In this phase, the current or prospective project leader writes a proposal, which contains a
description of the above-mentioned matters. Examples of this type of project proposal include
business plans and grant applications. The prospective sponsors of the project evaluate the
proposal and, upon approval, provide the necessary financing. The project officially begins at
the time of approval.

Questions to be answered in the initiation phase include the following:

Why this project?
Is it feasible?
Who are possible partners in this project?
What should the results be?
What are the boundaries of this project (what is outside the scope of the project)?

The ability to say no is an important quality in a project leader. Projects tend to expand
once people have become excited about them. The underlying thought is, while we are at
it, we might as well Projects to which people keep adding objectives and projects that
keep expanding are nearly certain to go off schedule, and they are unlikely to achieve their
original goals.

In the initiation phase, the project partners enter a (temporary) relationship with each other.
To prevent the development of false expectations concerning the results of the project, it
makes sense to explicitly agree on the type of project that is being started:
a research and development project;
a project that will deliver a prototype or 'proof of concept';
a project that will deliver a working product.

The choice for a particular type of project largely determines its results. For example, a
research and development project delivers a report that examines the technological feasibility
of an application. A project in which a prototype is developed delivers all of the
functionalities of an application, but they need not be suitable for use in a particular context
(e.g. by hundreds of users). A project that delivers a working product must also consider
matters of maintenance, instructions and the operational management of the application.
Many misunderstandings and conflicts arise because the parties that are involved in a project
 are not clear on these matters. Customers may expect a working product, while the members
of the project team think they are developing a prototype. A sponsor may think that the
project will produce a working piece of software, while the members of the project team
must first examine whether the idea itself is technically feasible.

Fig: 5.2

5.2.1.1 Business Case

This Business Case Template will help you build a Business Case for your project or
organization. By completing the sections included within this template, you can document the
return on investment for your solution, thereby creating a compelling Business Case for
approval by your sponsor. It will help you identify the detailed benefits and costs of your
solution, giving your sponsor confidence that the solution recommended is the most viable
solution available. This will help you to gain approval of the business case and secure the
funding you need, to get started. By using this Business Case Template you can:
Research the business problem or opportunity
Identify the alternative solutions available
Quantify the benefits and costs of each solution
Recommend a preferred solution to your sponsor
Identify any risks and issues with implementation
Present the solution for funding approval

This Business Case Template also includes:

Real-life examples in each section

Detailed procedures guiding you step-by-step
Tables to help you quantify the benefits and costs
Guidance on the methods of choosing a preferred solution
A best practice approach to ensure your success.

This template is unique, as it includes all of the detailed procedures needed when writing
Business Cases within your organization. It takes you through the process of completing a
Business Case, giving you practical examples along the way.

5.2.1.2 Feasibility Study

This Feasibility Study Template will help you to conduct feasibility studies in your
organization. It takes you through the process of completing a Feasibility Study by defining
the business problem / opportunity, the alternative solutions available and the recommended
solution for implementation. You can use this Feasibility Study sample to assess the
feasibility of any type of solution, within any type of business environment.

You can also use this Feasibility Study template to:

Research the business problem or opportunity

Document the business requirements for a solution
Identify all of the alternative solutions available
Review each solution to determine its feasibility
List any risks and issues with each solution
Choose a preferred solution for implementation
 Document the results in a feasibility report

This Feasibility Study template also includes:

Dozens of practical, real-life examples

A diagram describing feasibility assessments
Procedures which help you to assess feasibility
Tables to help you write up the feasibility outcome
A best practice process to achieve the best feasibility results

The Feasibility Study template is different, as it includes all of the information needed to
perform a feasibility study quickly and easily. It provides you with guidance, to ensure that
all of the required elements of a feasibility study are adequately covered. It will also save you
time and effort, as the template is pre-filled making it quick and easy to complete.

5.2.1.3 Project Charter

This Project Charter Template will help you to define the scope of your project. Writing the
Project Charter is typically one of the most challenging steps in the Project Life Cycle, as it
defines the parameters within which the project must be delivered. It sets out the project
vision, objectives, scope and implementation, thereby giving the team clear boundaries within
which the project must be delivered.

This Project Charter template will help you to:

Identify the project vision and objectives

Define the complete scope of the project
List all of the critical project deliverables
State the customers and project stakeholders
List the key roles and their responsibilities
Create an organizational structure for the project
Document the overall implementation plan
List any risks, issues and assumptions

The Project Charter template includes:

All of the sections within a Project Charter document

Detailed instructions which help you to complete each section
 Tables and real-life examples, to step you through the document
Actual role definitions, to save you time writing them
A sample project plan for implementation
An example organization chart
Helpful hints and tips to guide you

This template is unique, as it is pre-completed and it already includes all of the information
needed to create a Project Charter within a very short period of time. The practical examples,
charts and tables will save you time, as you only need to "fill in the gaps" to build a
comprehensive Project Charter document for your project team.

5.2.1.4 Project Job Description

This Project Manager Job Description template lists all of the responsibilities of a Project
Manager role within a project. Although it has been completed for a Project Management
role, you can use this template to write a Job Description for any role within an organization.
Completing a Project Job Description is actually a time consuming and challenging task, as it
defines the targets for a role. It also defines how those targets are going to be measured and
how the performance of the role will be assessed. This template will help you to create Job
Descriptions for your organization, faster than ever before.

This Job Description template will help you to:

Define the real purpose of the role

List the key responsibilities of the role
Define who this role will be reporting to
Create a detailed Organizational Chart
List the skills and experience needed
Define any relevant qualifications
Set out the key performance criteria
Identify the salary and working conditions

To help you complete these tasks, this template will provide you with:

A complete worked example of a Job Description

Instructions for every section within the document
A sample list of skills and experience needed
 An Organization Chart diagram
Examples of key performance criteria
Lots of helpful hints and practical tips

This comprehensive template describes how to complete a detailed Job Description for any
role in your organization, with very little effort. It also includes lots of practical, real-life
examples to help you to fill-in the gaps, saving you time and energy.

Whether you need to create a management, project or team role, this template has all of the
relevant sections and procedures needed to create a professional Job Description today.

5.2.1.5 Project Office Checklist

This Project Office checklist helps you to set up and run a Project Management Office
(PMO) within an organization. It lists the roles, equipment, standards and processes needed to
run a Project Management Office today. Establishing a Project Management Office is a
challenging task. You need to put in place the right PMO tools to support projects adequately
and ensure project buy-in. This checklist helps you do that, by listing each of the critical
items needed to set up and run a Project Management Office quickly and efficiently.

This Project Office checklist will help you to:

Identify the right location for your PMO team

Ensure that you have the correct infrastructure
Procure the right PMO equipment and tools
Define the PMO roles and responsibilities
Put in place suitable standards and processes
Implement relevant project management templates
Offer Project Management Office services to projects.

To help you run a Project Management Office, this checklist also provides:

Examples of project roles, standards and processes

A list of the project management templates required
Sets of questions, to help you determine your PMO status
A list of PMO equipment items and services
This checklist lists all of the business critical tools required to run a professional and efficient
Project Management Office environment. Whether you are setting up a PMO, or you're
running a PMO currently, this checklist will help you ensure that you are providing a high
level of support to projects.

5.2.1.6 Project Review Form -Initiation Phase

A Project Review is an assessment of the status of a project, at a particular point in time. The
first time in the project life cycle that a project review is undertaken is at the end of the first
project phase, called "Initiation". During this project review, a decision is made as to whether
or not the team has met the objectives and is approved to proceed to the next project phase,
being the "Planning" phase. Performing a project management review at the end of each
phase is critical to the success of the project, because it allows the Project Sponsor to control
the progress of the project and make sure that it passes through each Project Phase smoothly.

This Project Review Form is completed at the end of the Initiation project phase to tell the
sponsor whether the project has achieved its objectives to date. First, a Project Management
Review is conducted to measure the deliverables produced by the project, then the results of
the review are documented on this Project Review form which is presented to the sponsor for
approval. Project Phase reviews are conducted at the end of the Initiation, Planning and
Execution phases within a project. This form helps you to complete a project review for the
'Initiation' project phase.

The form helps you to document the results of your Project Review, by stating whether the:

Project is currently delivering to schedule

Budget allocated was sufficient at this point
Deliverables have been produced and approved
Risks have been controlled and mitigated
Issues were identified and resolved
Changes were properly managed
Project is on track

The form helps you to:

Document the results of your Project Review

Clearly communicate the progress of your project to your sponsor
 List any risks or issues which have impacted the project
Show sponsor the deliverables produced to date
Seek approval to proceed to the next phase

By implementing Phase Reviews, you are putting in place the necessary "check-points" to
monitor and control the project, thereby ensuring its success.

5.2.2 Project Planning.

This phase includes the planning of all the elements/ parameters of the project so to be ready
for implementation. In this perspective, the following plans must be developed: Activities
Schedule (definition of activities and tasks sequence, time scheduling), Risk Plan
(highlighting of possible risks and actions to mitigate them), Resource Plan (determination of
the labor, equipment, material needed in each task/stage), Cost Plan (identification of the
internal and external costs and their occurrence in time), Quality Plan (setting of quality
targets for the project deliverables and definition of processes for quality assurance and
control), Issue Management Plan (definition of process for identifying, assessing and
resolving issues related to the project), Change Management Plan (definition of process for
managing requests for changes that have a direct impact on the project), Acceptance Plan
(setting of acceptance criteria for the project deliverables and definition of the processes for
executing the acceptance tests), Communication Plan (definition of information to be
distributed to the stakeholders and selection of the appropriate distribution methods). In
addition, it is a common practice during this Phase to define the Performance Indicators to be
used in a later stage for monitoring the project implementation progress and evaluating the
project’s performance against predefined objectives and targets.

The Project Planning Phase is the second phase in the project life cycle. It involves creating
of a set of plans to help guide your team through the execution and closure phases of the
project.

The plans created during this phase will help you to manage time, cost, quality, change, risk
and issues. They will also help you manage staff and external suppliers, to ensure that you
deliver the project on time and within budget.
There are 10 Project Planning steps you need to take to complete the Project Planning
Phase efficiently. These steps and the templates needed to perform them, are shown in the
following diagram.
Fig: 5.3

5.2.2.1 Project Plan

A Project Plan sets out the phases, activities and tasks needed to deliver a project. The
timeframes required delivering the project, along with the resources and milestones are also
shown in the Project Plan. Using this Project Plan Template, you can quickly and easily
create a comprehensive Project Management Plan for your project, as it already lists the
commonly used tasks needed to complete projects from start to finish. This Project Plan
Template will help you to quickly and easily create a Project Plan for your project. You can
use it to create your own customized project management plan for delivering your project on
time and under budget.

If you want to create a Project Plan for your project within a few easy steps, then this project
plan template will tell you how to do it. Each project planning step is described in detail and
is accompanied by a suite of practical tips and hints.

By using this Project Plan template, you can:

Identify all of the phases, activities and tasks

Sum up the effort needed to complete those tasks
 Document all of the project inter-dependencies
List the planning assumptions and constraints
Create a detailed project planning schedule

This Project Plan Template will also help you to:

Define the project scope & milestones

Identify the Work Breakdown Structure
Set and agree the target delivery dates
Monitor and control the allocation of resource
Report on the progress of the project, to the sponsor

The Project Plan is the most important document in the project, as it provides the Project
Manager with a roadmap ahead, and it tells them during the journey whether they are on-
track. Using this Project Plan template, you can create a comprehensive project management
plan for your project today.

5.2.2.2 Resource Plan

A Resource Plan summarizes the level of resources needed to complete a project. A properly
documented Resource Plan will specify the exact quantities of labor, equipment and materials
needed to complete your project. This Resource Planning template also helps you gain
approval from your Sponsor, ensuring their buy-in. This Project Resource Management Plan
helps you to identify all of the resources required to complete your project successfully.
Using this Resource Plan, you will be able to identify the quantity of labor, equipment and
materials needed to deliver your project.

You will then create a resource schedule, which enables you to plan the consumption of each
type of resource, so that you know that you will have enough resources to complete the
project.

This Resource Planning template will help you identify the:

Types of labor required for the project

Roles and key responsibilities for each labor type
Number of people required to fill each role
Items of equipment to be used and their purposes
 Types and quantities of equipment needed
Total amount of materials needed

This Resource Plan template will also help you to:

Plan the dates for using or consuming these resources

Identify the amount of resource required per project activity
Create a detailed resource utilization schedule

5.2.2.3 Financial Plan

A Financial Plan identifies the Project Finance (i.e. money) needed to meet specific
objectives. The Financial Plan defines all of the various types of expenses that a project
will incur (labor, equipment, materials and administration costs) along with an estimation
of the value of each expense. The Financial Plan also summarizes the total expense to be
incurred across the project and this total expense becomes the project budget. As part of
the Financial Planning exercise, a schedule is provided which states the amount of money
needed during each stage of the project. The Financial Planning Template will help you to
quickly and easily create a Financial Plan for your project. A Financial Plan enables you
to set a "budget", against which you measure your expenditure. To deliver you project
"within budget", you need to produce the project deliverables at a total cost which does
not exceed that stated in the budget. Using this financial plan template, you can create a
detailed budget against which to measure the success of your project.

This Financial Plan template will help you to identify the:

Types of labour costs to be incurred during the project

Items of equipment needed to deliver the project
Various materials needed by the project
Unit costs for labor, equipment and materials
Other costs types such as administration
Amount of contingency needed

You can then use the Financial Plan template to create a budget by:

Calculating the total cost involved in completing the project

Identifying the total cost of each project activity
 Creating a schedule of expenses

Creating a project budget is an extremely important part in any project, as it gives you a goal
post to aim for. This Financial Plan will help you meet that goal post, by giving you a
clear process and template for creating a budget for your project.

5.2.2.4 Quality Plan

A Quality Plan helps you schedule all of the tasks needed to make sure that your project
meets the needs of your customer. It comprises two parts; the Quality Assurance Plan lists
the independent reviews needed and the Quality Control Plan lists the internal reviews
needed to meet your quality targets. By using Quality Assurance and Quality Control
techniques, you can create a comprehensive Quality Management Plan for your project.
Create a Quality Assurance Plan and Quality Control Plan, using this quality management
plan template. It will help you to set quality targets for your project to ensure that the
deliverables produced, meet the needs of your customer. You can then use it to schedule
quality control and quality assurance activities, to assure your customer that the quality
targets will be met.

You can use this Quality Plan to set quality targets by:

Identifying the customers requirements

Listing the project deliverables to be produced
Setting quality criteria for these deliverables
Defining quality standards for the deliverables
Gaining your customers agreement with the targets set

You can then use this Quality Plan to monitor and control quality by:

Identifying the quality control tasks needed to control quality

Creating a Quality Control Plan, by scheduling the control activities
Listing the quality assurance activities required to assure quality
Building a Quality Assurance Plan, by creating an activity schedule

Quality Planning is a critical part of any project. It enables you to agree a set of quality
targets with your customer. It then helps you to monitor and control the level of quality
produced by the project, to ensure that you meet the quality targets set. By using this
 quality plan template, you can set quality targets and ensure that your project produces
deliverables which meet your customers needs, thereby ensuring your success.

5.2.2.5 Risk Plan

A Risk Plan helps you to foresee risks, identify actions to prevent them from occurring and
reduce their impact should they eventuate. The Risk Management Plan is created as part
of the Risk Planning process. It lists of all foreseeable risks, their ranking and priority, the
preventative and contingent actions, along with a process for tracking them. This Risk
Plan template will help you perform these steps quickly and easily. This project Risk
Management Plan helps you to identify risks and implement a plan to reduce them. It
helps you do this, by giving you a complete risk management plan, showing you how to
take action to reduce risk in your project. Using this risk plan, you can monitor and
control risks effectively, increasing you chances of achieving success.

This Risk Planning template will help you to:

Identify risks within your project

Categorize and prioritize each risk
Determine the likelihood of the risks occurring
Identify the impact on the project if risk does occur

You can then use this Risk Plan template to:

Identify preventative actions to prevent the risk from occuring

List contingent actions to reduce the impact, should the risk occur
Schedule these actions within an acceptable timeframe
Monitor the status of each risk throughout the project

Creating a Risk Management Plan is a critical step in any project, as it helps you to reduce
the likelihood of risk from occurring. Regardless of the type of risk, you will be able to
use this template to put in place processes and procedures for reducing the likelihood of
risk occurring, thereby helping you to deliver your project successfully.

5.2.3 Project Execution & Control.

This phase involves the execution of each activity and task defined at the Project Schedule.
During the implementation of the activities and tasks a series of management processes
 are undertaken to monitor and control: time, resources, cost, risks, quality, issues,
changes, deliverables acceptance procedure, communication, etc.

The Implementing Agency is fully responsible for the achievement of all project outcomes.
However, in case that an Implementing Agency decides to subcontract the execution of
parts or of the whole project, it assumes the function of and the responsibilities for
monitoring and controlling the contractors.

The Project Execution Phase is the third phase in the project life cycle. In this phase, you will
build the physical project deliverables and present them to your customer for signoff.
The Project Execution Phase is usually the longest phase in the project life cycle and it
typically consumes the most energy and the most resources.

To enable you to monitor and control the project during this phase, you will need to
implement a range of management processes. These processes help you to manage:

time,
cost,
quality,
change,
risks
issues

They also help you to manage procurement, customer acceptance and communications.
Fig: 5.4

5.2.3.1 Time Management

Project Time Management is all about recording the time spent by people on a project. To
record time spent, the team implement a Project Time Management Process. This time
process involves recording the time spent on tasks, using Timesheets. The time process
helps the manager know which tasks has been worked on, when and for how long.

5.2.3.2 Cost Management Process

A Cost Management process helps you control expenses within an organization. By

purchasing the Project Cost Management process advertised here, you can ensure that all
expenses are approved before they are paid. Using this project Cost Management process,
you can ensure that your project is delivered within budget.

5.2.3.3 Quality Management Process

A Quality Management Process is a set of procedures that are followed to ensure that the
deliverables produced by a team are "fit for purpose". The start of the Quality
Management Process involves setting quality targets, which are agreed with the customer.
A "Quality Assurance Process" and "Quality Control Process" are then undertaken, to
measure and report the actual quality of deliverables. As part of the Quality Management
Process, any quality issues are identified and resolved quickly.

5.2.3.4 Change Process

A Change Process, or Change Management Process, is a set of procedures that help teams to
control change effectively. It's not that you have to prevent change from happening; it's
how you manage change once it occurs that really matters. This is where a Change
 Process is invaluable. The Change Process allows you to record change requests, and
review and approve those requests, before implementing them. This Change Process
makes change management easy.

5.2.3.5 Risk Process

A Risk Process, or Risk Management Process, describes the steps you need to take to
identify, monitor and control risk. Within the Risk Process, a risk is defined as any future
event that may prevent you to meet your team goals. A Risk Process allows you to
identify each risk, quantify the impact and take action now to prevent it from occurring
and reduce the impact should it eventuate.

5.2.3.6 Issue Process

An Issue Process, or Issue Management Process, is a set of procedures that help you manage
issues as they occur. Whether you're part of a project or operational team, issues will
occur on a regular basis affecting the ability to meet your team goals. That's when an Issue
Process is invaluable. An Issue Process helps you record each issue and identify the
actions needed to resolve it. As part of the Issue Process, an approval step is included to
ensure that the right actions are taken, at the right time.

5.2.3.7 Procurement Management Process

A Procurement Management Process, or Procurement Process, is a method by which items

are purchased from external suppliers. The procurement management process involves
managing the ordering, receipt, review and approval of items from suppliers. A
procurement process also specifies how the supplier relationships will be managed, to
ensure a high level of service is received. This is a critical task in Procurement
Management. In essence, the procurement process helps you "get what you have paid for".

5.2.3.8 Acceptance Process

An Acceptance Management Process is a series of steps that you take to complete User
Acceptance Testing. When a project is nearly complete, one of the final steps is to
perform User Acceptance Testing with the customer. As part of the User Acceptance
Testing process, the customer will be asked to review the project deliverables and confirm
that they are "fit for purpose". By using this User Acceptance Testing process, you can
confirm that your customer is happy and sign off the project as complete.
5.2.3.9 Communication Process

A Communication Process, or Communications Management Process, is a set of steps that

are taken every time formal communications are undertaken in an organization. A
Communications Process is undertaken as part of Communications Management and
helps to ensure that your stakeholders are kept regularly informed. For example as part of
the project life cycle, the team implement a Communication Process to make sure that the
entire team is kept informed of the status of the project.

5.2.3.10 Project Management Review

A Project Management Review is an exercise undertaken at the end of each Project Phase to
identify the current status of the project. The Project Review identifies the deliverables
which have been produced to date and determines whether or not the project has met the
objectives set. The outcome of the Project Management Review is documented on a
project Phase Review Form and this states whether the project is currently on track, within
schedule and under budget.

5.2.4 Project Closure.

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, canceling 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 projects success and identify the
lessons learned. This phase includes all activities and tasks that ensure that the project is
completely finished and the contract is properly closed. It also includes the evaluation of the
processes used in the project and of the outcomes achieved.

Fig: 5.5
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 auctioned.

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.

5.2.4.1 Project Closure Report

A Project Closure Report describes how you intend to close your projects. The Project
Closure Report confirms that the objectives have been met, the deliverables have been
handed over to the customer and that project closure can commence. Every Project Manager
needs to complete a Project Closure Report to gain agreement from their Sponsor that the
project is ready for closure. Once the Project Closure Report has been approved, the Manager
can proceed with the actions needed to close the project swiftly. This Project Closure report
helps you take the steps needed to formally wind-up your project. The report helps you
undertake the Project Closure phase within a project, by documenting all of the tasks needed
to complete your project and hand over the deliverables to your customer.

It is critical that you complete the Project Closure phase properly, as the manner within which
these closure steps are taken will determine the final success of your project.

Using this Project Closure Report you can perform Project Closure by:
Identifying the project completion criteria
Listing any outstanding activities or deliverables
Creating a plan for passing deliverables to your customer
Planning the handover of project documentation
Closing supplier contracts and agreements
Releasing projects resources to the business
Communicating the closure of the project
This Project Closure Report is unique because it:
Includes pre-formatted sections and tables
Lists all of the key activities needed to close a project
Contains step-by-step instructions to help you complete it
Has lots of practical examples, tips and hints
Is pre-completed to save you time and effort

Written by project experts, this Project Closure Report helps you to document all of the steps
needed to close your projects quickly and efficiently.

5.2.4.2 A Post Implementation Review

Post Project Review, is performed after a project is complete. The purpose of a Post
Implementation Review is to determine whether the project was successful and identify any
lessons learned. A Post Implementation Review also looks at whether the project produced
the required deliverables within the agreed timeframe. The overall achievements are also
documented in the Post Implementation Review report. This Post Implementation Review
template will help you to perform a post project review for your project, soon after it has
finished.
By performing a post project review, you can identify the project successes, deliverables,
achievements and lessons learned.

The post project review is the last critical step in the project life cycle, as it allows an
independent party to validate the success of the project and give confidence to the
stakeholders that it has met the objectives it set out to achieve.

This template helps you perform a Post Implementation Review by:

Measuring the benefits and objectives
Deciding whether the project was within scope
Assessing the final deliverables produced
Reviewing the project against schedule
Comparing the expenditure against budget
Stating the final outcome of the project
The Post Implementation Review template also helps you to:
Identify the key project achievements and milestones
Document any lessons learned for future projects
Communicate its success to stakeholders

This Post Implementation Review template provides you with the steps needed to review a
project and document its overall level of success. It includes all of the sections, tables and
practical examples you need, to document a Post Implementation review today.

Review Questions

17. What is Project Plan?

18. What is Resource Planning?
19. Explain Project Execution & Control with examples?
20. What is Quality Management Process?

Discussion Questions
Explain Project Execution Phase with the help of illustrations? What is the nature of
the Project in this phase?

Application Exercises

13. Describe about the Project Closure with examples?

14. What is Project Closure Report?
15. What is Post Implementation Review?
 Introduction to Project Management Concepts
CHAPTER 6 – Statement of Work

Learning Objectives

To know about Statement of Work.

To analyse value of SOW.
To recognise the steps involved in SOW.
To explain about Sample Report.
To know more about project deliverables.

6.1 Introduction

The Statement of Work, or SOW, is the bible for the work the project must produce. The
SOW is a key governance tool whether it is being used to direct work for a vendor or
contractor, or used to direct the work internally, the SOW must contain a description of all
the work that is expected. The description need not be at the detail level, indeed for large
projects capturing detail in the SOW is not practical, but should be comprehensive and
include work that produces the projects deliverables as well as administrative work such as
project reporting.

The SOW will form a key part of the contract if the work is being done by a vendor or
contractor. Work captured in this document is part of the vendor's contractual obligation to
you. Work not contained in the SOW will only be done if it is mutually agreed upon, or
introduced to the project through a change request. The SOW is also important to the internal
team, although there are no legal implications, because resourcing will be planned to
accommodate only that work described in the SOW. This article was written for the purpose
of providing the project management practitioner with tips and tricks for producing an
effective SOW.

The SOW is a valuable organisational tool to capture the work of the project. Its value lies in
its ability to capture all the critical work elements of your project and is useful in two
situations: to form a part of a contract with an external vendor or consultant, or as an
intermediate planning step for a large complex project where the work is being done
internally. You don't need an SOW when your project is small and simple enough for you to
directly translate your Scope Statement into your Work Breakdown Structure tool, for
example MS Project.

An SOW is very helpful when the project is large and complex because it allows you to
engage Subject Matter Experts in the type of work to be performed who don't have access to
MS Project. Descriptions of the work to be performed can be contributed by anyone with
written communication skills and a technical command of the work. The SOW also serves as
a communications tool, communicating the scope baseline for the project.

The SOW should be written after your Scope Statement, during the planning phase of your
project. Your Scope Statement should be written first and it should capture, in very general
terms, the product of the project. Let's say your organisation is launching a project to develop
a software based system to capture and track orders for software. Your Scope Statement
would include that language. It would probably also include a list of the users it should
support such as order entry clerks, software engineers who configure the orders, managers
who generate reports from the system, and shipping clerks who ship the orders. You may also
include the features you want in the system, such as whether it is Internet or Intranet
accessible, how many orders it is to store, what information it should store about each order,
how the system will collect payment for the order, etc. The Scope Statement will give you
information about what it is you need to build.

Now that you know what it is you are building, you need to capture details on how you are
going to build it. Now you need to author your SOW. The Statement of Work defines the
work to be done, so it must be written before the work can be scheduled, or broken down in
your Work Breakdown Structure.

Start your SOW with the information in your Scope Statement. All the elements captured in
your Scope Statement should appear in your SOW. The Scope Statement tends to capture the
deliverables of your project at a high level; your SOW will contain these deliverables, when
they are to be delivered by, and how the deliverables will be built. The SOW should also
contain information about deliverables at a more detailed level. For example, if your Scope
Statement includes an order capture and management system, you might break that
deliverable down into a database to capture, store and track the information, a front end to
interface with users and a reporting system to manage reports.
The SOW information categories comprises of:
Scope of work: A detailed description of the work, the software and hardware to be
used, and the exact nature of the work.
Location of the work: Where the location of the work to be done would be other than
a standard location. This would be applicable to an SOW for work to be performed
offshore.
Period of performance: The start and finish date for the project, maximum billable
hours per time period, etc.
Deliverables schedule: Due dates for the deliverables of the project. This would
include completion dates for development, QA testing, User Acceptance Testing, etc.
Applicable standards: Industry standards or other standards imposed on the project
deliverables. These should include any standards such as ISO, CMM, CMMI, etc.
Acceptance criteria: These would include any quality standards that must be met, for
example zero priority 1 defects. They should also include any other conditions that
must be met such as number of test cases, number of test cases executed, etc.
Specialised requirements: These will include any special qualifications for the
workforce, such as a PMP certified Project Manager.

Scope of work, period of performance, and deliverables schedule are all mandatory
information. The rest are optional and will only apply to those projects where they are
applicable. For example, noting that work is to be performed in the performing organisations
office space adds no value. Noting the work space, and who is responsible for providing it
will be relevant to a SOW covering work to be done by a consulting organisation.

The scope of work to be performed should include administrative work as well as work on
the project deliverables. Administrative work also includes project management work. You
may not want to include project management work if you will be performing the work for an
internal client. On the other hand, including it will help to set client/sponsor expectations.
Include the reports and other communications you intend to use to keep your stakeholders
informed on project progress. You should also include any information that you will need
from the team, such as progress reports. Include administrative work such as entering project
time into a time tracking tool, if the use of such a tool isn't a standard operating practice for
the project team.
Don't try to capture too much information about deliverables or how the work will be done.
Remember that you set expectations when you put information in the SOW. It will be
difficult to change anything you've captured in the SOW (you'll need a change request
approved by your sponsors or customers). You should not attempt to capture details about
deliverables for projects where an iterative SDLC is used. Describing the methodology to be
used and only the major deliverables will be sufficient. Using a Waterfall methodology will
allow you to capture more detail about doing the work and the project deliverables.

6.2 Next Steps

Your next step will be to have your project sponsors, or the customer for the project, approve
the SOW. The SOW will now become the official scope baseline for your project. Anything
detailed in the SOW must be present in the final product.

Your SOW captures the work the project team will do, but at a high level of detail. You will
need to break these items down further in order to complete your Work Breakdown Structure
(WBS). You may find that uniquely identifying each item in your SOW will help you ensure
that all the deliverables and work packages described in your SOW are represented in your
WBS. You should also check your SOW against the Scope Statement to ensure that all the
items in the Scope Statement are represented in the SOW.

The start and end dates you capture in your SOW should be captured in your WBS. If you are
using MS Project or similar tool to support your WBS, the start date will be the first entry in
the tool. You will use the end date as a constraint. Once you have completed the capture of all
the information in your WBS, the breakdown of that work, and the scheduling of the tasks,
you will need to check the resultant end date against the end date from your SOW. You will
use the schedule dates from your SOW for major deliverables in the same way.

You should use your SOW as a communications tool to explain the work of the project to
your stakeholders. You can do this by posting the SOW on a publicly readable site with other
project documents for public consumption. Remember to update the SOW when a change
that modifies the work of the project is approved.

Taking care to capture the right information about the work of your project, taking pains to
ensure the information is as accurate as possible, and making good use of that information for
the rest of your planning activities will save planning time down the road. Just keep in mind
that it is a "living" document and that changes to any elements represented in the SOW
should be reflected in it.

6.3 Purpose

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 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.

6.4 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.

6.4.1. 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.

6.4.2. 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.
6.4.3. 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.

6.4.4. Delivery schedule:

This section of the SOW describes the deliveries and the due dates for the deliveries.

6.4.5. 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.

6.4.6. Acceptance Criteria:

This section defines the minimum requirements for accepting deliverables. It also describes
the criteria used for acceptance.

6.4.7. 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.

6.5 Sample Report

6.5.1. Project Overview

In this, the IT Project Manager provides a brief overview of the project. Much of this
information may be extracted from the Project Charter or Feasibility / Business Case Study
and modified or updated as required. A format of the report is shown.

Background
(A short summary of the project’s history and proposed approach, including:

Short statement of the problem to be resolved

Time line or review of major dates in the project development process
Client organizational units and key individuals involved in advancing the project
Alternative solutions or implementation strategies evaluated
Proposed approach )

Purpose / objectives
(The key end results that the project will achieve when successfully executed. Measurable
performance indicators for anticipated benefits may also be listed here.)

Anticipated benefits
(Describe what the organization will gain through completion of this project.)

Software or technology products proposed

(A brief description of any new software or technology that will be deployed as part of the
project.)

Business processes impacted

(Review major changes in the way business will be conducted once the project is complete.)

Customers / End users impacted

(Identify the specific individuals or groups whose work will be most affected during and after the
project’s execution.)
6.5.2 Detailed Scope

The Detailed Scope includes a list of the specific requirements that the IT project must
satisfy. It also includes a listing of the deliverables that will be generated by the Project
Team, as well as those deliverables that are specifically excluded from the scope.

Requirements
(List the key technical and functional requirements for the project. Highlight up to 20
requirements that you consider to be essential to the ultimate success of the project. In the
Appendix, attach a complete listing of these requirements (i.e., Requirements Document) or
reference the file path for shared access to an electronic copy of this document.)

Deliverables Included in Scope

(List all deliverables referenced in the Project Schedule and provide a brief description of the
related acceptance criteria for each. Provide a copy of the completed Log as an Appendix to
this document. Do not list project deliverables here.)

[ ] Deliverables Log available as an Appendix

Deliverables Not Included in Scope
(In the table below, list the deliverables that have been specifically excluded from this project.)

DELIVERABLE COMMENT (OPTIONAL)

6.5.3. Project Schedule

List all milestones and major project deliverables in the table below and indicate the planned
completion date for each item. This information should be taken from the completed Project
Schedule. Add more rows to this table as necessary. Provide a copy of the Project Schedule
as an Appendix to this document, and/or reference the file path for shared access to an
electronic copy of this document.

Project Schedule
MILESTONE OR MAJOR PROJECT DELIVERABLE PLANNED
COMPLETION
DATE

6.5.3 Project Budget

Budget Cost Detail

(Enter total budget hours and costs for the project. Provide a copy of the Project Budget as an
Appendix to this document.)

HOURS COSTS

Agency Labor $

Contract Labor $

Non-Labor Costs N/A $

TOTAL HOURS / $
IMPLEMENTATION
COST

Project Implementation Cost Responsibility

(The list of Cost Center(s) and associated WBS Number(s) for agency project funding and
enter the portion of the total project cost/Total Implementation Cost above (in dollars)
allocated to each.)

Name of Organizational Unit Cost Center No. WBS Number Allocation of

/ Internal Order Total Costs

1.

2.

3.

4.

TOTAL Funds
 Source of Funding
Indicate what percent of the Total Implementation Cost will be funded from State versus
Federal or private money.
Percent
(Total must equal 100%)
State ___ %
Federal ___ %
Private ___ %

6.5.5 Risk Assessment

(Review the completed Risk Watch List. Provide a copy as an Appendix to this document
and/or reference the file path for shared access to an electronic copy of this document.)
[ ] Risk Assessment is available as an Appendix

6.5.6 Approvals

(Once all previous sections of the Statement of Work (SOW) are completed, the IT Project
Manager reviews the document with the Client, the IT Business Officer and appropriate IT
Managers. The IT Project Manager makes any necessary revisions to the SOW and obtains
the approvals indicated in the table below. Additional approvers may be added to this table.)

(Agency Sponsor approval indicates acceptance of the project's detailed scope, schedule and
budget. Agency Chief Financial Officer approval affirms that project funding information is
correct and that the available budget is sufficient. Approval by the agency Chief Information
Officer and agency Chief Technology Officer affirms that the agency will provide resources
required to meet these terms.)

Approvals

PROJECT ROLE NAME SIGNATURE DATE

Sponsor
 Agency Chief
Financial
Officer

Chief
Information
Chief
Officer
Technology
Officer
Appendix - Supporting Documents
Manager
(Create each of the documents listed below as supporting information to this Statement of Work. DO NOT
insert these documents into this SOW. Provide electronic versions of each of these documents together with this
SOW.)

Detailed Scope Provide a copy of the Requirements Document for the project and /
or reference the file path for shared access to an electronic copy of
these documents.
Project Schedule Provide a copy of the Project Schedule and / or reference the file
path for shared access to an electronic copy of this document.
Project Budget Provide a copy of the Project Budget and / or reference the file path
for shared access to an electronic copy of this document.
Risk Assessment Matrix Provide a copy of the Risk Watch List and / or reference the file
path for shared access to an electronic copy of this document.

Review Questions

21. What is SOW?

22. What is the format of SOW?
23. Explain Sample Report with examples?
24. What is the objective of SOW?

Discussion Questions
Explain the Detailed Scope list with necessary items available in it?

Application Exercises

16. Describe the Project Implementation Cost Responsibilities?

17. What is the need of approval in SOW?
18. What information is available in the appendix of the report?
 Introduction to Project Management Concepts
CHAPTER 7 – Work Breakdown Structure

Learning Objectives

To know about work breakdown structure.

To analyse the purpose of WBS.
To recognise Project Control module.
To explain about the formation of WBS.
To know more about WBS levels.

7.1 Overview

Program, project or job management; to a CEO or a computer system, it's all the same. Are
we hitting our project targets? Are we within budget to date? What's our estimate to
completion? How do earned value and actual value compare? Do we have acceptable data to
obtain prepayments from our customers based on reaching our milestones?

If you're a make-to-stock, make-to-order or engineer-to-order manufacturer, these are

questions you ask in one way or another each and every day. Perhaps, you use terms such as
customer orders or sales orders instead of project orders. They're all the same. They might
define a quantity of valves designed for a major oilfield supply company, various sized
girders for a new skyscraper or a big boat for a movie about a big boat. The resulting end
product has multiple BOMs and your organization has to keep track of almost each and every
part, when it was bought, and when it is due to be sent on to the next station and/or shipped.
Plus, you need to know how much it costs and to which budget it shall be allocated.

If you're an engineer-to-order company, the people running these projects probably report
directly to the CEO. If not, they're typically a rung below. Regardless, if your company has
one project going, it probably has many projects or jobs or customer orders being undertaken
at the same time. This is important because, without having actual, real-time data, you could
have several, not just one, projects going bad at the same time. Here's the kicker &emdash;
you wouldn't even know it until it's too late.

A work breakdown structure is a key project deliverable that organizes the team's work into
manageable sections. The Project Management Body of Knowledge defines the work
breakdown structure as a "deliverable oriented hierarchical decomposition of the work to be
executed by the project team." The work breakdown structure visually defines the scope into
manageable chunks that a project team can understand, as each level of the work breakdown
structure provides further definition and detail. Figure 7.1 depicts a sample work breakdown
structure with three levels defined.

Figure 7.1Work Breakdown Structure

An easy way to think about a work breakdown structure is as an outline or map of the specific
project. A work breakdown structure starts with the project as the top level deliverable and is
further decomposed into sub-deliverables using the following outline hierarchy (Figure 7.2)

Figure 7.2 Work Breakdown Structure Deliverable

The project team creates the project work breakdown structure by identifying the major
functional deliverables and subdividing those deliverables into smaller systems and sub-
deliverables. These sub-deliverables are further decomposed until a single person can be
assigned. At this level, the specific work packages required to produce the sub- deliverable
are identified and grouped together. The work package represents the list of tasks or "to-dos"
to produce the specific unit of work.

From a cost perspective, these work packages are usually grouped and assigned to a specific
department to produce the work. These departments, or cost accounts, are defined in an
organizational breakdown structure and are allocated a budget to produce the specific
deliverables. By integrating the cost accounts from the organizational breakdown structure
and the project's work breakdown structure, the entire organization can track financial
progress in addition to project performance.

The work breakdown structure has a number of benefits in addition to defining and
organizing the project work. A project budget can be allocated to the top levels of the work
breakdown structure, and department budgets can be quickly calculated based on the each
project's work breakdown structure. By allocating time and cost estimates to specific sections
of the work breakdown structure, a project schedule and budget can be quickly developed. As
the project executes, specific sections of the work breakdown structure can be tracked to
identify project cost performance and identify issues and problem areas in the project
organization.

Project work breakdown structures can also be used to identify potential risks in a given
project. If a work breakdown structure has a branch that is not well defined then it represents
a scope definition risk. These risks should be tracked in a project log and reviewed as the
project executes. By integrating the work breakdown structure with an organizational
breakdown structure, the project manager can also identify communication points and
formulate a communication plan across the project organization.

When a project is falling behind, referring the work breakdown structure will quickly identify
the major deliverables impacted by a failing work package or late sub- deliverable. The work
breakdown structure can also be color coded to represent sub- deliverable status. Assigning
colors of red for late, yellow for at risk, green for on-target, and blue for completed
deliverables is an effective way to produce a heat-map of project progress and draw
management's attention to key areas of the work breakdown structure.
The WBS has the following objectives:

Scope: The WBS will aid in the organisation and function of a project’s scope by
providing PM’s with the elements to precisely establish the work that needs to be
done within a particular project.
Organization and Management: By interacting with a WBS a Project Manager can
assign resources and responsibilities. This gives them the control to manage the
project in a way that’s structured to ensure project success.
Verify that all details are covered in a project. This will prevent project change
requests being issued.

The development of the WBS is the most important part of the process. If this stage is done
poorly it will follow through and affect the cost and time of the project. If done correctly and
thoroughly a project should sail through the plan schedule without any changes needing to be
made. The first part of the process is to gather the entire project team and any other
individual who will have a part to play in the project. By gathering a wide range of know-
how and experience at the one time will allow a project manager to get to the smallest of
details within the deliverables of a project.

Once these deliverables have been established they will need to be broken down into
manageable tasks. By dividing the deliverable into smaller tasks will give the project
manager more control and focus over the management of the time and cost associated with
it. In fact the WBS is a foundation for the timeline of projects. Having the work broke down
into manageable sections allows a PM to make a relatively close estimation on the amount of
time required to complete the project. The project breakdown will allow the project manager
to identify the time constraint that should be applied to the tasks. Therefore if a project
manager decides not to go with a WBS they could run a risk of facing project delays. By
having a timeline drawn up it will give the project manager and project team members a
visual aid of what the progress of the project should be at a certain point in time.

7.2 Work Breakdown Structures

Dividing complex projects to simpler and manageable tasks is the process identified as Work
Breakdown Structure. Usually, the project managers use this method for simplifying the
project execution. In WBS, much larger tasks are broken-down to manageable chunks of
work. These chunks can be easily supervised and estimated.
Fig: 7.3

WBS is not restricted to a specific field when it comes to application. This methodology can
be used for any type of project management. WBS is a hierarchical decomposition of the
project into phases, deliverables and work packages. It is a tree structure, which shows a
subdivision of effort required to achieve an objective; for example a program, project, and
contract. In a project or contract, the WBS is developed by starting with the end objective and
successively subdividing it into manageable components in terms of size, duration, and
responsibility (e.g., systems, subsystems, components, tasks, subtasks, and work packages)
which include all steps necessary to achieve the objective.

The work breakdown structure provides a common framework for the natural development of
the overall planning and control of a contract and is the basis for dividing work into definable
increments from which the statement of work can be developed and technical, schedule, cost,
and labor hour reporting can be established.

A work breakdown structure permits summing of subordinate costs for tasks, materials, etc.,
into their successively higher level ―
parent‖ tasks, materials, etc. For each element of the
work breakdown structure, a description of the task to be performed is generated. This
technique is used to define and organize the total scope of a project.

The first step in producing a Project Plan is the creation of the Work Breakdown Structure
(WBS), listing all the phases, activities and tasks that make up the project. A phase is a set
of related activities that comprise a substantial portion of an overall project. You may find it
useful to draw up a table of phases:

Phase Title Phase Description Phase Sequence

List Phase titles (eg: Initiation, Planning, Describe the purpose and key Number each
Execution, Closure and Evaluation). outcomes of each Phase Phase in sequence

An activity is a set of tasks which must be undertaken to complete a portion of a project. You
may find it useful to draw up a table of activities:

Phase Title Activity Title Activity Description Activity Sequence

List the phase that the List the title of Describe the purpose and Number each
Activity corresponds to. each Activity. outcomes of each Activity. Activity in sequence.

A task is an item of work to be completed within a project. You may find it useful to draw up
a table of tasks:

Task Title Task Title Task Description Task Sequence

List the phase that the Task List the title of Describe the purpose and Number each Task
corresponds to. each Task. outcomes of each Task. in sequence.

The above phase, activity and task lists comprise the Work Breakdown Structure (WBS) for
the project. As well as creating the WBS, you must also specify any critical project
milestones.

The WBS is organised around the primary products of the project (or planned outcomes)
instead of the work needed to produce the products (planned actions). Since the planned
outcomes are the desired ends of the project, they form a relatively stable set of categories in
which the costs of the planned actions needed to achieve them can be collected. A well-
designed WBS makes it easy to assign each project activity to one and only one terminal
element of the WBS. In addition to its function in cost accounting, the WBS also helps map
requirements from one level of system specification to another, for example a requirements
cross reference matrix mapping functional requirements to high level or low level design
documents.

Following are a few reasons for creating a WBS in a project.

Accurate and readable project organization.

Accurate assignment of responsibilities to the project team.

 Indicates the project milestones and control points.

Helps to estimate the cost, time, and risk.

Illustrate the project scope, so the stakeholders can have a better understanding of the
same.

WBS is actually common sense reporting that most CEOs attempt to undertake as second
nature. The problem is some tools are needed. The builders of these tools decided to provide
names for them that nobody that uses them would have created.

When you begin a project, you set up milestones. You also allocate a percentage of your
budget for each milestone. As a milestone is reached, you want your project team to show
you that they met their goal in a specific amount of time at a specific cost, hopefully within
budget. If you had budgeted 100,000 to meet this milestone by the due date, you would want
them to bring in this portion of the project by or before that date at 100,000 or less.

Your project team, though, will tell you that they have "earned" the estimated cost of this
portion of the project. If their cost was 100,000 and their budget was 100,000, they will have
earned a value of 100,000 within your time schedule. That's, of course, a scenario for the
perfect project.

Budgeted Cost of Work Performed

Actual Cost of Work Performed
Budgeted Cost of Work Scheduled

These terms know each other on a first-name basis and are interrelated. With them, you can
measure any project's performance. For example, comparing BCWS to BCWP gives you your
schedule variance while the relationship of BCWP to ACWP provides your cost variance.
There are more acronyms but these get the point across. Bottom line &emdash; you can
measure the performance of a project. There's even better news. Much fine software are
available for help.

7.3 Purpose

A work breakdown structure, 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.

There are three reasons to use a WBS in projects.

The first is that is helps more accurately and specifically define and organise the
scope of the total project. The most common way this is done is by using a
hierarchical tree structure. Each level of this structure breaks the project deliverables
or objectives down to more specific and measurable chunks.
The second reason for using a WBS in your projects is to help with assigning
responsibilities, resource allocation, monitoring the project, and controlling the
project. The WBS makes the deliverables more precise and concrete so that the
project team knows exactly what has to be accomplished within each deliverable. This
also allows for better estimating of cost, risk, and time because you can work from the
smaller tasks back up to the level of the entire project.
Finally, it allows you double check all the deliverables' specifics with the stakeholders
and make sure there is nothing missing or overlapping.

WBS lets each department in your organization look at your numbers in the way they want
and need. Take the word "costs." Costs, along with payables and receivables information,
allow your accountant to put together a financial picture of your company that your Board
can review and compare from month-to-month. By product, costs determine where you are
spending your money. Labor costs can be compartmentalized by employee grade.
Department costs show where your greatest investments in assets are located. And, if you're a
contract or job shop manufacturer, you will want many of these costs segregated by customer
or job order. That's a project management need!

Indeed, you want to be able to monitor the actual procurement and production of a project
against an estimate. You would like to sum up material, labor, overhead, subcontract and
other direct charges for each individual project and compare these costs against your total
estimate for the project. Then, you could determine, through any given period, your earned
value. That was the earlier point of the project manager telling you what was earned.

Obtaining the data to provide these calculations is not difficult. A project cost system simply
needs to capture and record costs through the end of each period, plus the budgets for each
cost element plus the BCWP for each period. To do so, each cost charge needs to be stamped
with a time period. And, of course, there shall be a budgeted amount for each cost element for
each time period.

With such information, your project cost system can provide you with a great depth of
management information. Not only can you learn that you spent $65,000 on that valve project
for Detroit, Inc. but you spent that $65,000 in September and had budgeted to spend
$100,000. With this data, you can determine your variances. You're ahead, on or behind
schedule and over, under or on budget. It's a great management tool. How can you employ it?

Perhaps, you're an engineer-to-order firm. You engineer, prototype and run production of
product well in advance of finally shipping production product and would like to receive
prepayments on milestones reached. Using WBS, you will establish budgets &emdash; by
period and cost element &emdash; for subgroups such as software design, mechanical
engineering, electrical prototyping, final assembly and so on. A cost account manager will be
responsible for each.

This is WBS. In this case, we have a 3-level WBS with the top level reporting to the program
manager, (the Detroit, Inc. program), the second level being the individual manager's WBS
(Turbo Valve 2 project) and the sub-department cost account manger level (Tooling) being
the third. In this 3-level WBS, cost accumulation, the budget and the cost performance
measurement shall be available at the lowest level. Each person concerned with the WBS
information shall be able to get what he or she needs without impacting anybody else's data.
Yet, there are all sorts of people in the corporation that don't want their data soiled with time
stamps.

ERP providers have solved this problem. Typically, a Project Control module lets you
associate inventory items, sales orders, work orders, purchase requirements and purchase
orders with each project. With project-oriented MRP, you even have the flexibility to plan by
project or not. Certain items can be planned without regard to projects to increase purchasing
or manufacturing efficiencies. Such an item could be a sub-component, a bolt or screw, used
throughout your company's products. Project Control, though, will control allocation of
material or finished sub-components to any specific projects. Ultimately, each manufacturing
work order and purchase order line will be associated with an individual project.

7.4 The WBS Module

Working in consort with the Project Control module will be the WBS module, providing the
WBS for each project and each multi-level of the project. A WBS program defines the
posting level accounts and the summarization program that rolls up costs from the lowest
level to the higher levels. As you obtain individual contracts or sales orders, you will enter
them into the system. Budget figures &emdash; in both dollars and hours &emdash; will be
entered. From that point on, multiple budgets will be provided &emdash; original, revised
and current. As transactions are processed in other modules, the costs associated will be
posted to the WBS structure automatically.

In most cases, project management software results can't be provided in real-time. Now, you
know why some of your projects went over budget "so fast." In fact, they didn't. You just
didn't know it. When chastised, your project manager truthfully answered that he didn't know
it in time. If he would have, he could have taken immediate measures. You're right to be
angry and he's right to be defensive. Although your project management people have project
management software, it's being fed batched ERP data that needs translation. In other words,
the data required is being collected as described. But, then, it is put on a disk and sent to the
project management team where it is translated into a format useable by their project
management software and, only then, run. By the time the data is turned into information, the
report is typically well over a month old.

The problem is, the WBS modules from the ERP vendors were not formatted to the needs of
the project management software vendors, which provide all the calculations required to
monitor projects. We learned that ERP modules need four architectural capabilities to support
real-time project management &emdash;

Inventories, costs, shop orders, purchase orders, requisitions, receipts and sales orders
shall be maintained by item number as well as by project and WBS account.
Costed transactions, including all material movement and labor transactions, are not
only the basis for Accounting's business as usual general journal entries, but, in real-
time, update the project/WBS cost components of material, labor, overhead,
subcontract and other direct costs and Selling, General, and Administrative which are
used in all ACWP and BCWP calculations.
A cross-reference shall be maintained between the ACWP costed transaction and the
general journal entry.
 ACWP and BCWP costed transactions must be as to the minute for the project
management department as the journal entries emanating from the business as usual
departments are for the general accounting department.

With such a system, as we've now incorporated into our INFIMACS II ERP, on-line project
status in real-time is achieved with proper data. At any time, you can enter a specific
customer and sales order and immediately receive to-the-second status regarding purchase
requisitions, purchase orders, and production work orders that have been established to meet
the requirements of any specific project.

With WBS in real-time, you will now be able to more aggressively manage projects. All
reporting variables will be readily available. Corrective actions can be taken immediately.

7.5 Making Work Breakdown Structure

A work breakdown structure (WBS) is a project management tool designed to capture project
tasks in a visual, organized manner. The WBS was originally developed by the US
Department of Defense, which mandated their use across the DoD. Today work breakdown
structures are widely used for projects of all types, both business and personal.

On the most basic level, you decompose the project scope in order to create the work
breakdown structure. This takes time in beginning, but ultimately it affords the project
manager better control of costs and deadlines, thus saving time. When you use the
decomposition process to create your WBS, you are less prone to adding items that are
outside of the project scope.

A Work Breakdown Structure defines the objectives of a project at all levels of detail. All
levels contain the measurable components that must be produced or achieved in order to
reach the overall objective, the completion and delivery of the product. The work breakdown
structure is hierarchical, as the top objective (Level 1) represents the entire project, while
lower levels break down the project into increasingly detailed component outcomes or parts.

The most important consideration in making a work breakdown structure is to avoid

mirroring either an organizational structure or a functional structure, since these structures are
not outcome-oriented. The defined objectives at all levels must be measurable outcomes and
deliverables, the parts and the entirety of what the customer will receive at project
completion. The work breakdown structure must be strictly built to define products and sub-
products, as well as services that are directly tied to those concrete outcomes.

Figure 7.4Work Breakdown Structure

7.5.1 Work Breakdown Structure Levels

Project Management's first step is creating the work breakdown structure, a step that then
enables subsequent planning of the work processes and schedule for accomplishing the
project. When the work breakdown structure is in place, thoroughly reviewed and finalized,
the structure can then be evaluated to determine the processes needed and the scheduled time
and costs for achieving each of the goals.

The work breakdown structure, though created at the very beginning of the planning process,
needs to be constant during project accomplishment. Work activity schedules will change,
budgeted costs and actual costs will change, but objectives remain constant, barring a
complete revision to the objective and final deliverable.

The determination of project objectives lends itself to a top-down approach, since the primary
objective or end product is the first thing known. Building of the work breakdown structure
starts with Level 1, the top objective, continuing with Levels 2 and below requiring managers
and planners to carefully consider the outcomes that are required at increasingly more distinct
levels of detail to achieve the ultimate objective. Level 2 of the work breakdown structure is
necessarily created before moving down to Level 3, and the thought process should follow in
that manner until the entire work breakdown structure is in place and ready for review.

Project complexity, expected dollar value, and customer expectations for visibility are among
the factors that are considered in determining the number of levels to build into a work
breakdown structure. In turn, the project is managed by different levels of managers, at
higher or lower levels of the work breakdown structure.

After the start of the project, the performance plan framed by the work breakdown structure
moves into project execution. During the execution phase, a Level 3 view provides top
managers with sufficient detail for identifying problem areas. This promotes focusing on the
project at an appropriate level of detail, while avoiding micromanagement tendencies.

Project managers will generally need the work breakdown structure to be broken down below
Level 3, especially on a complex project. Doing so allows leaders at all levels to closely
monitor efforts within their respective spans of control. The bottom level of the work
breakdown structure consists of "work packages", which represent the efforts and objectives
of a small team of individuals who are working on a very specific outcome.

The work packages at the lowest level of detail in the work breakdown structure roll up to
elements that are definable outcomes or completed sub-products, which in turn comprise a
larger part of the final products, which is defined at the top of the work breakdown structure.

Every element of the work breakdown structure will be assigned a schedule and dollar budget
for accomplishment, progress against the objective can be evaluated throughout its period of
performance. Problem areas can be identified and process changes or additional resources can
be applied to correct problems as they are encountered.

Careful consideration of objectives and the building of the work breakdown structure to
identify those objectives during project initiation are essential in the planning and
management process.

7.5.2 Example
The example shown below is a simple, task-oriented WBS that resembles a graphical To Do
list. A To Do list like the example below may work for a wedding party, but in the corporate
world there is more to developing and using a WBS than simply creating an expanded To Do
list.

7.5.2.1 Considerations When Building a Work Breakdown Structure

As you set up your project WBS, think about how you will want to use it later in the project.
For instance, pay close attention to the indents in your WBS because these eventually end up
being the indent structure in your Gantt schedule. Intuitively we gravitate toward developing
task-oriented work breakdown structures because they are easy to understand, and because
we tend to think of a project as a collection of tasks. It usually takes more effort to develop a
deliverable-oriented WBS because they include multiple levels of detail. Up till now, taking
the time to develop a deliverable-oriented WBS may better serve the project, especially if
extensive project management controls are used. Determine whether you want to build a
WBS that is process oriented or product oriented. What’s the difference? If the results you
want from your project can be defined in verbs, then you want a WBS that is process
oriented. If you want a WBS that is built on nouns, then it will be product oriented.
Remember that our brains can simultaneously comprehend only 7 to 9 items at a time. When
a project involves hundreds of tasks, they need to be broken into chunks that we can readily
understand and use. The process of creating a WBS helps break down the project, which
makes it easier to manage – and master. Be sure there is no overlap in scope definition
between two elements of your WBS. Not only would this result in duplication of effort, but
would likely cause confusion regarding responsibility, authority and cost accounting.
.
7.5.2.2 Building Process
Not only do you need the project scope to create your WBS, you need the input from the
project managers and team leaders. Generally, the WBS-building process finds all these
people in a room with plenty of white boards and markers, or pads of paper and sticky notes.
Out of this brainstorm session should come a first draft of the project WBS. It should be one
that will foster ―
buy in‖ because the core project personnel participated in its development.
Creating a quality WBS can take a substantial amount of time, but is usually worth the effort
because of the additional clarity it provides for the project manager.

Review Questions

25. What is the role of Project Management Body of Knowledge?

26. What are the objectives of WBS?
27. Explain Work Breakdown Structure with example?
28. What is make-to-stock and make-to-order refers to?

Discussion Questions
Explain in detail the Work Breakdown Structure?

Application Exercises

19. Describe the purpose of Work Breakdown Structure?

20. What is the role of Project Plan in creating WBS?
21. What information is required to create WBS?
 Introduction to Project Management Concepts
CHAPTER 8 – IT in Projects

Learning Objectives

To know about IT Projects.

To analyse the purpose of IT Projects.
To understand the methodologies of IT Project.
To explain challenges in IT Projects.
To know more about failure of IT Projects.

8.1 Introduction

Project management is the process of applying knowledge, skills, tools and techniques to
activities within a project. Many of the techniques a project manager uses, as well as the
knowledge and experience required to do the work, are similar to those used in managing
organizational units. Frequently, a project manager acts independently of the formal,
functional organization. A project is a set of temporary, non-routine activities, the completion
of which requires combined effort and skills from people with a variety of specializations.

IT project management is a sub-discipline of project management in which information

technology projects are planned, monitored and controlled. Project management is a carefully
planned and organized effort to accomplish a successful project. A project is a one-time effort
that produces a specific result, for example, a building or a major new computer system. This
is in contrast to a program, which is:
1) an ongoing process, such as a quality control program,
2) an activity to manage a series of multiple projects together. In some countries,
the term "program" refers to a software tool and the term "programme" can
mean a TV or radio show.

Like any project, an IT project is a temporary endeavor (with a start date and an end date) to
bring about a specific finalized goal. Here are several examples of IT projects:

Programming computer software, a mobile app, or video game

Designing hardware architecture for a computer platform
 Web development for an online shopping site
Data security on a social network or bank server
Today, because information technology is such a fast-growing industry, even projects that are
not exactly defined as ―
IT‖ are not entirely separate from IT. For instance, a concert is not an
IT project, but the featured band might advertise the event by creating a new website.

Project management includes developing a project plan, which includes defining and
confirming the project goals and objectives, identifying tasks and how goals will be achieved,
quantifying the resources needed, and determining budgets and timelines for completion. It
also includes managing the implementation of the project plan, along with operating regular
'controls' to ensure that there is accurate and objective information on 'performance' relative
to the plan, and the mechanisms to implement recovery actions where necessary.

Projects usually follow major phases or stages such as:

feasibility,
definition,
project planning,
implementation,
evaluation
support
maintenance.

When you retain IT project management service from ICT, experienced IT project managers
will:
Guide your project through the appropriate software development cycle stages.
Prepare budget, schedule, risk avoidance and mitigation, and scope plans for your
project.
Provide regular sponsor and community project status reports.
Ensure other community communiqués are prepared as needed.

8.2 Projects

People who grow up in project-based organisations have a different work experience. From
the age of sixteen when they joined, say, as a bricklayer they were working to a project plan.
The project plan determines when each task will be done. Tasks can be long and complex,
may have unique features, and are most certainly related to other tasks. People who run these
organisations know all about planning. For them the goal isn't so much to answer the phone
within three rings, but to achieve the project goal three years away. At the extremes these are
two very different styles of management.

The trouble is, when you come to do projects in inherently process-based organisations there
is a real opportunity for culture clash. People may observe the resulting friction but not
realise its underlying cultural cause. Asking a senior business manager for two of his best
people full time for a month to define requirements in a project that will deliver in twelve
months' time can provoke the reaction of getting business to run. As seen, no two people
taken off proper job for this project thing as it come back in eleven month's time. People who
have never been involved in a project sometimes don't believe that it is necessary for their
people to be involved so far in advance of implementation. In the process world you make a
decision and tomorrow you're doing it that way. The idea that you must decide things in
detail a year in advance just does not ring true. Beside, his boss has given him no headcount
for extraneous activities like projects.

IT people will tell you that the three things most likely to make projects succeed are planning,
planning and more planning. Whereas business people might tell you that they don't see the
need for all that planning - they in the business just get on with the work and do it. And they
may even see planning as an irritating, initial delaying tactic used by IT people to avoid ever
doing any real work.

So, how do we overcome these cultural challenges? Well, enlightenment is the first step.
People who run businesses are bright people - when it is explained to them what projects are
all about and why they are different, they quickly get the message. But all too often nobody
has taken the trouble to explain what a project sponsor should do, what the systems
development process actually is, why and when the users should be involved and so on.

8.3 Challenges and Changes

After enlightenment comes action a shift towards a more project-based culture. Some
transactions, like holiday insurance, are now completed with no human intervention.
Computers increasingly perform the day to day business processes and consequently business
people are less and less involved in performing the operational tasks. Changing the business
with new products, new processes and new ways will effect the organisations. Projects are the
way change is effected.

In the past a business manager might have managed a number of people all of whom were
performing essentially the same operational task. Now and increasingly, some of the
manager's people will be performing operational tasks but others will be involved in projects
and some doing both concurrently. Those involved in projects are not working for their boss,
they are working for a project manager. The role of the business manager changes: they not
only manage day to day operations but also provide career management for those people
rented out full time or part time to project managers. Servicing the immediate needs of the
business and providing people for projects naturally conflict. The business manager has a
more challenging management job. And they may also be thrust into projects themselves,
even into a project management role, with no previous project experience. Not only are they
expected to swim, they are also expected to show others how to swim! You're a manager -
manage this project.

In the past a company would have had a deep, static management hierarchy designed
principally to manage the operational work being done by large numbers of people at the
bottom. There were clear functional chains of command - you had a boss for whom you
worked. The need now is more for resource pools: a pool of financial skill, of engineering
skill, of legal skill, etc. The people are available to do projects. In the extreme case if there
are no projects they have nothing to do. The company hierarchy does not manage any work, it
manages the people. One-off project hierarchies manage the work. For the next three months
you'll be working on project X working not for me but for the project manager." And when
that project finishes Joe is assigned to another project working for another project manager.
In the extreme case you spend your whole career never doing any work for your boss.

Every year Joe's boss gives him his appraisal based, of course, on the input from project
managers and others. A familiar concept in project-based organisations, but a culture change
for hitherto process-based organisations. If business people do not see working on a project
as part of their "proper job" it is hard to get their commitment.

8.4 Project Culture

Business managers' headcounts must reflect both their operational workload and resources
they will supply to projects. This means an organisation-wide project resource planning
process that determines how much resource from each business area each project will need.
This is an important planning role to be overseen by a business executive. There is a clear
distinction between the resources needed to keep the business running and those the
organisation chooses to invest in projects which will yield future benefits. Many individuals
will be split between these two activities.

Project sponsors must become accountable for projects, including "IT" projects - they must
be more than just a name on a piece of paper. If the project fails, the Board holds the project
sponsor accountable. The sponsor can't just blame IT. In this regime, sponsors become much
more interested in their projects and who is managing them: the sponsor's fate is partly in the
hands of the project manager. The sponsor will do what he can to help the project succeed.

If project management is viewed as an IT discipline it is difficult to get the business fully

engaged in it. Most IT organisations have project management standards. However these are
often integrated with technical IT standards, voluminous and perceived as unnecessarily
bureaucratic. Experienced IT hands don't need to read them. Novice IT people may not
understand them even if they did read them. Business people are often unaware of them or
see them as relating only to IT people.

Project management rules and guidelines must become the property of the business, not the
property of IT. The project management rules would be, say, a ten page booklet (not the 17
volume methodology so beloved by some IT shops) laying down the minimum mandatory
things that must be adhered to on every project. The rules do not include IT technical
standards and should be written in business-friendly language - a simple common sense
"Highway Code" governing all projects. Separate project management guidelines may offer
advice, checklists, useful forms, etc.

The business, not IT, has a (small) project assurance function which: ensures project
management rules are followed; helps project managers adopt best practice; and conducts in-
depth health checks of key projects on behalf of the project sponsors. Project managers never
lie about project status, but they have been known to forget to mention certain things, which
can inadvertently leave the wrong impression in the mind of the sponsor. If they know an
independent review is coming in a couple of months they are more likely to report warts and
all today.

8.5 Business Leadership

Who are the project managers? In the past they would have been IT people. Increasingly
business people manage "IT" projects. The business may even have a pool of people whose
profession is now project manager. They may well be certificated, for example by the Project
Management Institute. They will be called upon to manage the organisation's major projects,
particularly systems development projects.

All business people who become involved in projects (not just the project managers) receive
project management education. However, invite a senior manager to a project management
course and he will see the words "management course" and conclude he does not need
another one of them! The idea that project management is an additional set of management
techniques has to be sold.

The education is not how to use a PC based planning tool or how to do PERT network
analysis. It is not training in the bureaucratic impositions of a complex methodology. It is not
training in how to pass a project management examination. It is training in how projects are
run. It includes an insight into the black art of software development - though the education
reveals it isn't such a black art after all, and that business people are quite capable of taking a
leadership role in it.

The business, including the HR department, understand that when an individual is managing
a project they can have the title "project manager" even though they are not a manager in the
organisation. Similarly the title "project director" can be given to an individual who is not a
Director.

Business people understand that when they are assigned to work on a project, full time or part
time, they are working for the project manager even if the project manager has a lower job
grade than them. The project hierarchy takes precedence over company hierarchies and
seniorities.

8.6 Competitive Advantage

A senior user once said a project is like a train: you start it off then it goes into a long tunnel
and emerges as a quite different train neither where nor when you expected. In his company
IT were the train drivers. The project manager, from the business, must have weekly updates
of status and the sponsor a monthly report of status and outlook to completion. At major
checkpoints the sponsor should be obliged to authorise continuation, in writing, based upon
an updated cost/benefit case: is the project still worth doing?

Business people must see projects as being a part of their job, indeed an interesting and
rewarding part. They understand that projects build the future. They want to be part of that.
Senior managers reward project performance at least as much as performance in running day
to day activities. Eventually business people find it incredible that anyone would propose
they should not be managing and taking leading roles in projects, and find it hard to believe it
was ever so!

Many organisations now have a full project management capability as they can comfortably
work in project mode when the need arises. Others are in transition. Others do not realise
there is a transition to be made.

Whilst running the business operations remains the key focus, senior managers in project-
capable organisations have the ability to manage projects as efficiently and effectively as they
do the business operations. They know that new products are born out of projects and that
running these projects well means getting good quality products to market sooner. They know
that an effective project management capability confers competitive advantage.

8.7 Principles of IT project management

Projects are short-term efforts to create a unique product, service or environment, such as
removing old servers, developing a custom e-commerce site, creating new desktop images or
merging databases. All projects are constrained by three factors: time, cost and scope. For a
project to be successful, these three constraints are called the ―
Triple Constraints of Project
Management‖, and they must be all in equilibrium. If any constraint is out of balance, the
project is heading for disaster.
Like all projects, the IT projects are established through the same phases of project lifecycle:
initiating, planning, executing (monitoring and controlling) and closing. Each phase listed
here contains processes that move the project from the idea to the implementation.

8.7.1 IT project management methodologies

The following are the three principles methodologies for IT project management:

Traditional project management: this applies to any type of IT project – based on technology.
Extreme Programming (XP): this approach is designed especially for software development.
It also uses a software development model that involves users, customers and programmers
during the four interactive phases (planning, coding, designing and testing).
Scrum: this is a final leading approach in IT project management. It named after a rugby
term, also uses iterations of planning, coding, executing and testing software. The Scrum
methodology employs its own vernacular and has some rigid rules about meetings, hitting
milestones and the duration of planning activities.

8.7.2 IT projects failure

According to the Standish Group which tracks IT project success rates; ―

29% of IT projects
conducted in 2004 were completed successfully‖. Bellow is the main reasons that have been
depressing these results of failure:

IT projects fail because they are planed harder. They include the usual project-
management challenges, such as deadlines, budget constraints and too few people to
devote to the project. But they also face unique technology challenges, from
hardware, operating system, network or database woes, to security risks,
interoperability issues, and the changes manufacturers make to their hardware and
software configurations.
Many IT projects fail at the beginning and not at the end, due to a lack of sufficient
planning. An IT company/organisation will first list the number of resources it will
use for the implementation of the project, the type of skills it needs, the kind of people
to be involved during the achievement, and then timing the length for the
accomplishment, test and implement the project deliverables. Otherwise, the project
 will be a mess. The IT organization will never complete it on time, on budget or with
the required functionality, which are three common factors for project success.
Other IT projects fail because they are rushed. This happens because actually many
companies are focused on IT competitive advantages. They doesn’t spend a lot of
time through development strategies and systems implementations, rushing to be the
first with new IT based products or services. However, organizations often feel that to
remain competitive, they must cut costs and maintain business operations, but that
adds to the pressure on a big, expensive project such as an ERP implementation or a
platform upgrade. An IT project with luck of planning techniques, risk strategies and
testing is failed from the beginning.
Finally, some other IT projects fail because their scope is too unwieldy. A project
with large scope can usually be better executed by breaking it down into a series of
smaller that are more manageable. For example, a project to convert all of an
organization's historical records, forms and transactions from paper to an online
digital database can be incredibly complex and time consuming. A series of smaller
projects allow more manageable endeavors, such as first converting the existing
records to digital, and then a second project to use the digital database internally, and
then a third project to bring the database to the Web. These smaller projects can be
completed sequentially and with more flexibility than a large and complicated project.

As all initiations/entrepreneurs, the project also, during its initiation phase, the organisation
should establish the success and failure criteria. An example for the project to be considered
successful, it may have to adhere to certain quality standards, fall within a certain budget,
meet a particular deadline and/or deliver specific functionality.

The organisation may consider another approach of using an indicator such as the "15-15
Rule. This rule states that if a project is more than 15% over budget or 15% off schedule, it
may be likely never recoup the time or cost necessary to be considered successful.

There are also various management techniques that can also help the organisation to identify
whether a project will be a success or a failure. An ―
Earned value management‖ technique is
an example of management technique that allows an organization to measure a project's
completion, schedule variances, create schedule and cost performance indexes, and forecast a
project's likely completion date and financial impact upon completion. If using the Earned
Value Management technique, the organisation can understand that a project is costing so
much money that it is going to produce a quarterly loss, from there, it is easy to make sure
that the project will be unsuccessful.

8.7.3 Ensuring successful projects

To ensure that a project is successful, companies would be required to create or to adapt

standard approaches to manage projects. Therefore, Managers will not wasting time choosing
which ones are resulting smoothly and which are not, when all projects follow the same
processes and approaches, and use the same metrics for measuring project performance. A
standard approach to project management establishes ground rules and expectations for the
project team. It also provides project managers, functional managers and the operational staff
with a common language around project management that develops communication and helps
ensure that everyone is on the same page.

Using a mishmash of project management techniques makes it impossible for an organization

to measure the success of projects. And if organizations can't measure their projects, they
can't determine which processes and methodologies are working and which ones need to be
improved.

8.7.4 Cancellation of Project

Projects are generally canceled for a variety of reasons, though chief, if among them is poor
planning. Cost overruns by more than 15%, late milestones and poor quality are also viable
reasons for canceling projects.

Canceling a project from the beginning will come after the determination of circumstances
that would generate the project cancellation. From there, the organisation will focus on the
cost overruns, time or shitting business conditions. For instance, if the experience of the
organisation is significant or sustained dip in revenue for whatever reason, that organisation
may decide to cancel the project to save money. It might also decides to cancel a project if its
scope has grown or changed so significantly that the project is no longer recognizable or has
morphed into something else.

8.8 Role of offices in IT Projects

Most of the organizations/companies have adopted a project management office (PMO) to
centralize and coordinate all project management activities across the organisation/company.
The project management office establishes a group of rules and expectations on how projects
would be managed by the project manager, the project team and the stakeholders.

Project management Offices also generate all requests for changes to the scope of a project
and provide training, tracking software, project plan templates and process forms to the
project manager and the project team, to ensure that projects proceed smoothly and conclude
successfully. Therefore the project management offices prioritize in some companies, which
projects are going to get done and when. They also determine which resources will work on
which projects just to prevent dispute between departments over resources. The project
management office is often led by a well-versed and experienced project manager and is
staffed with support personnel who relieve the manager of busy work: keeping minutes from
meetings, coordinating project records, communications and meeting with stakeholders.

Project management offices can exist inside or outside of IT departments. Some companies
would like to use one independent project management office for all projects - whether they
are IT initiatives, research and development efforts on new product launches. Project
managers typically report into project management offices. Dedicated project managers are
often part of the project management office’s staff, but employees who are named project
manager for a given initiative are not usually part of this office’s staff because they have
some other day-to-day responsibility in addition to their newfound project-management
responsibility.

The only one disadvantage of project management offices is that they can stuck project
managers' leadership and management strategies by dictating the methodologies that project
managers must use and by making them follow specific procedures on documenting works.

8.9 IT Projects: a Misnomer

Are IT projects characteristically different from other engineering projects? We should stop
calling them IT projects: they are instead major programmes of change. Very few are
specifically IT projects.
The much publicised UK Passport Office project was not a technology failure but to do with
management failures in business processes and change control. The National Health Service
(NHS) IT project is not an IT project but a huge change programme.

Similarly the NHS or any other big organization is not necessarily a single entity running a
unified business change programme with a unified objective and agreed scope.

Indeed, big programmes can highlight that an organization is in fact dysfunctional, in that it is
a group of disparate functions. Perhaps this could be a starting point for major programmes:
clarifying the nature of the organization and the programme.

The aircraft programme was budgeted at £175m and came in at £800m; the Channel Tunnel
costs more than doubled from £4.8bn to £10.9bn; and the Scottish Parliament building costs
rose from £40m to £374m.

8.9.1 Reasons for Project Failure

A review of 1,000 projects by the UK Office of Government Commerce found that

technology was one of the least likely reasons for a project to fail. Programmes fail for
management reasons, not technical reasons.

The OGC found the main reasons for failure to be:

Lack of leadership
Lack of knowledge at the top of the organization about what the technologists are
trying to explain - and lack of knowledge among technologists about what business
users want. This leads to a huge gulf
Poor risk management - not in terms of whether program code is accurate but rather in
terms of whether, for example, unions will accept the proposed changes
Underestimation of the complexity of business process change and human change
Inability to break down programmes into bite-size chunks. Programmes or projects
taking 12-18 months are too long, because things change. There is also a problem that
people might not tell the project that things have changed.
Major programmes often involve some firsts; a lot of firsts can indicate that this could be a
high-risk programme, something the budget and schedule should to take into account. These
firsts need to be thought about early on.

Is this the first time this team has worked together? Is this the first time this activity has been
computerized? Is this the first change programme for this function or group of people? Is it
the first time that this programme team has had to identify stakeholders and get them
committed?

Although IT projects might be renamed as business change programmes, the IT industry must
take responsibility for some factors. Bad practices have become established in drawing up IT
contracts, and these must be addressed.

For example lowest-cost bidding is prevalent. Many suppliers bid low, knowing they can get
back the costs on scope changes and overruns. So accepted practice actually gives incentives
to fail, because that's the only way IT suppliers feel they can make money.

Requirements are often lacking - unlike in big civil engineering programmes such as bridge
building, which have more precise specifications. This again can give suppliers another way
to make money on top of their lowest-cost bids.

8.9.2 Success Factors

So what is needed to make change programmes successful? In complex programmes the

management must come from the very top, because such programmes threaten the entire
organization. So those involved must have the attention of the chief executive, or the
government minister. Clear leadership from the top is especially important if some of the
stakeholders are less than enthusiastic. Stakeholders must be kept engaged throughout,
especially the customers or business users.

The need for hybrid managers who can build communication bridges between technologists
and top management was articulated many years ago and is still best advice. Hybrid
managers are people who can cope with the business, aren't afraid of the technology - to the
extent that they have been there, done that - and have the personality to talk to a wide range
of people, be credible to users and technologists, and get their cooperation.
BCS might have a role here in promoting the development of hybrid managers, who are in
short supply. Programmes need to be broken into smaller and more manageable chunks.
When this is done, people say they now understand what is happening and can cope with it,
especially senior management.

This understanding gives people conviction and commitment. As well as system development
chunks there might be ones covering tasks such as training the users or negotiating with
unions. A framework or architecture is needed to piece the chunks together. These are long
established in civil engineering, and IT should be developing such frameworks architectures
and methods of practice.

The idea of data and systems architecture is relatively new to IT but these are the bedrock of
an organization's technology and their absence can be a reason for project failure. A measure
of an organization's IT maturity and its ability to deliver IT is whether it has an enterprise
data architecture. Clarity of vision of what is to be achieved is needed at the outset. Such
vision also clarifies what the programme is NOT going to do, which is also an important
issue. In addition, vision leads the team to start splitting the work into chunks, because stages
towards the vision are identified.

The business outcomes must be agreed. The overriding factor here is money. Teams can talk
about cutting costs and streamlining processes, but everything must come down to money: if
we do this, with these stakeholders, where will the financial benefit be? It could be increased
revenue, or ideally increased profit, but it must have some true monetary value. Successful
programmes need a real business reason for progressing, not a technology reason.

The stakeholders who are going to benefit financially must be committed, and there must be a
contract of some sort with them, otherwise it will just be seen as an IT project - and you
should forget it. The process at the heart of the programme or project should be simplified if
possible before IT development starts. Practice has shown that this can account for 80 per
cent of the benefit of a programme.

Technology develops quickly but thinks realistically about how fast an organization and its
staff can cope with major change. Identify the technology involved and consider if it is new,
or a first for the organization: this increases the risk and needs to be allowed for at the start.
8.9.3 Working with IT Suppliers

Make sure the people needed are available or can be bought. Hiring consultants might not be
the answer, although this approach might be useful if the programme is a one-off, for
example, introducing a major package such as SAP: not all the implementation skills will be
needed in future. But the user organization must have the programme management skills.

Shared risk and reward contracts can help to build a joint sense of purpose between suppliers
and the customer organization - but if things go wrong the customer is the one that cannot
walk away. If IT suppliers are being contracted in, the client might ask whether they actually
use internally the software and techniques they are proposing.

Does a single supplier have the capacity to handle the entire programme? Are there enough
suppliers big enough to handle major complex programmes? If a big software package is
being taken on, the main options are to accept that one size fits all and change processes to
match the product; or to go for an exact fit. The former is usually more successful; with the
latter option the procurement can often take longer than the implementation or the technology
cycle the organization wants to move to. The budget must reflect all this, and also include a
contingency for inflation, technology changes, and software licence policy changes and so
on.

8.9.4 Managing the Programme

The contract must lay out clearly who has what responsibility to make which decisions, and it
must be managed. Who has to be kept informed? Who's managing the costs? Who knows
what the costs are?

Is there a work breakdown so you know how many analyst-programmers is being used, what
the function points are, what the contract programmers costs are? IT contracts rarely lay out
responsibilities in clear detail.

One view says red, amber and green classifications on progress reports should be avoided,
because they do not show the detail of how much of the budget has been spent or where the
risks are. Programmes and projects need detailed schedules and cost management.
There should be openness about problems, and indeed the odd failure should be allowed,
especially if something is being done for the first time. Management should be frank with
staff if things start to drift.

Projects and programmes should be continuously reviewed and their scope challenged. Is this
still the right thing to be doing? If it is taking more than 12 months, what is changing in the
organization that might affect it?

Are the people changing, especially the sponsors or stakeholders? Are they allowed to
change, these people who were supposed to be the beneficiaries? There could be gateway
reviews or peer reviews but there should also be someone, perhaps independent of the
programme, who can ask telling questions and kill a project or programme if the answers are
not forthcoming.

8.9.4.1 Missing Skills

Much of this suggests that there is currently a lack of management and communication skills.
IT people generally lack good communication skills, and there is a need for focus on
developing these softer skills.

There is also a lack of professionalism among core IT people. This is again largely down to
lack of training, to the extent that people at the coalface do not consider whether they know
what makes a good or bad project or project team.

Furthermore IT people do not get traditional engineering training, covering, for example,
going on site, arguing with suppliers and so on. Such training might produce contracts more
like those in big civil engineering programmes. Civil engineering practices are long
established, and IT could benefit from them.

BCS and other industry, employer and supplier bodies could look at certification of project
managers - and indeed these bodies are starting to explore common ground, with some sort of
certification as a possible ultimate outcome.
Many disciplines and applications cross boundaries, so engineering bodies should not
reinvent the wheel if there is an IT element; similarly, IT bodies should not reinvent the
wheel on soft skills if other organizations already have these covered.

Review Questions

29. What is the role of IT project management?

30. What are the services received from ICT in IT projects?
31. Explain IT Projects and its formulation?
32. What are the Challenges and Changes in IT Projects?

Discussion Questions
Explain Project Culture with respect to IT Projects?

Application Exercises

22. Describe Business Leadership?

23. What is the Principles of IT project management?
24. What could be the reasons for IT projects failure?
 Introduction to Project Management Concepts
CHAPTER 9 – Team Building Process

Learning Objectives

To know about Team building.

To analyse the purpose of Team building.
To understand the idea of Grouping.
To explain challenges of Team.
To know more about Group Behaviour.

9.1 Introduction

Team building is an approach towards enhancing organizational effectiveness and

proficiency. A team is 'a collection of people who interact with each other regularly and are
dependent on each other for the attainment of common goals.' The objective of team
development is the removal of impediments to improving group effectiveness. The key
elements of a team are goal sharing, interdependence, commitment and accountability.

9.1.1 Objectives

9.1.1.1 Team Tasks

To examine the extent and kind of teamwork required and determine the amount of
collaboration and interdependency needed.
To gain a better understanding of each member's role on the team.
To clearly articulate the team's purpose of mission and to foster alignment with and
commitment to its goals and decisions.
To develop new ways to achieve synergy and creativity in the performance of its
tasks.
To expand the team's capacity for dealing with a larger scope of problems as a team.

9.1.1.2 Relationships

To work together to build norms of trust and openness and to reduce feelings of
competition.
 To increase communication among team members about issues that affect the
functioning of the group and the attainment of its goals.
To improve the ability to see conflict as a source of creativity and energy rather than a
destructive intrusion to be avoided or suppressed.
To develop more effective ways of working through problems inherent to the team--at
both the task and interpersonal levels.

9.1.1.3 Organization and Culture

To understand the strengths and weaknesses of the existing culture.

To understand and begin to address the major problems that get in the way of the
company's/unit's success.
To increase the team's ability to communicate and work with other units or work
groups within the company

9.1.1.4 Leadership

To help the team leader develop a clear picture of his or her style and strengths as a
leader.
To help the team leader gain a better understanding of how others see his or her
leadership behavior so that impact on the team and the culture is better appreciated
and managed.
To assist the team leader in exploring, developing, and experimenting with alternative
(and more effective) forms of leadership behavior.
To develop the leadership potential of each team member and, where appropriate,
shift the responsibilities of leadership downward.

9.2 Groups

A clear understanding of groups and their formation and dynamics is essential before
discussing team building and management. 'Group' is defined as consisting of two or more
people who interact and influence one another. According to their numerical size, groups can
be classified as:

dyads means group of two members,

triads means group of three,
small means group of four to nine members
 large means group of ten or more.

9.2.1 Group formation

Important variables which influence group formation include:

Personal characteristics, which include shared beliefs, values, attitudes, security needs
and affiliation needs.
Interests and goals in common.
Influence, since a group can exert more power and influence to get proper attention
and action.
Opportunity for interaction, which helps in developing affinities and relationships.
Other factors are similar functional departments, cooperative physical activities,
intellectual pursuits, emotional needs or protection, and attention and friendship.

9.2.2 Group dynamics

Understanding group dynamics is essential for a manager in order to encourage effective

team-work. Group dynamics can be understood by exploring:

how group members are influenced

factors in helping, cooperating and competing
the way group cohesion relates to satisfaction and productivity of group members
maintaining external linkages
how to make task groups more effective.

9.2.3 Group influence

The process of influence and obedience in groups is important for group dynamics. How
people influence each other in a group is the process of group influence. This process prevails
in all types of human interaction and interdependence. Obedience or conformity involves
direct influence of the group on the behaviour of individuals such that their behaviour outside
the group will be different.

9.2.4 Behaviour

People differ in their vulnerability to pressures, yet most people can be influenced to behave
in a particular manner. Compliance, identification, internalization and social facilitation are
some of the important factors which could play a crucial role in influencing people to behave
differently.

Compliance is when people agree in spite of their own beliefs and preferences. This is
obedience.
Identification refers to agreements when people respect or are attracted to others.
Internalization refers to the change in behaviour manifested when people accept
requests or orders because either they are consistent with their own beliefs and values
or they expect the desired behaviour to be rewarding to them.
Social facilitation occurs as a result of the influence exerted by the mere presence of
someone.

9.2.4.1 Helping behaviour

People's penchant to help others differ. Some people care, and are willing to take more risk to
help others. There are several factors that reduce or facilitate helping, and they can be
important to the success of a group or organization.

Cooperation and competition are also crucial for an organization. Cooperation is more than
mere helping: it encompasses giving support to others and contributing time and effort in
situations where people can work together towards the same goals. In competition, people are
more concerned with personal or group interests.

9.2.5 Group cohesion

Group cohesion refers to the degree to which group members are attracted to each other and
to group membership. Cohesiveness brings group members towards a common goal and
creates team spirit. As seen, some of the important factors which can enhance group cohesion
concern:

group formation,
group development,
difficulty of entry,
status congruence,
reward allocation,
success,
stability of membership,
 external threat,
group size.

A manager can boost group cohesion by:

communicating with the subordinates as a group,

emphasizing and promoting competition with other groups,
awarding cooperation,
managing conflict situations within the group,
setting achievement goals for the group rather than for individuals,
treating everyone in the group equitably without favouritism,
encouraging social interaction among group members.

9.2.6 External linkages

A group comprises members representing various areas, skills or backgrounds. Good,

balanced representation can facilitate acceptance of a group's work.

9.3 Encouraging work groups

Group efficiency and effectiveness can be increased by fostering group productivity,

satisfaction, cohesion and learning. This can be achieved by various measures, including:

Treating employees as social beings and not as mere numbers.

Taking care when establishing group size so as to establish neither too small nor too
large a group.
Encouraging group members to select other members whenever possible. This
improves inter-personal relations in the group, which in turn generates cohesion and
cooperation.
Supporting groups to develop and mature. It helps in settling tensions and other
difficulties in the group.
Encouraging group productivity norms in congruence with organizational goals.
Dealing with group situations where cohesion is based on norms that are harmful to
the organization.
Supporting groups to develop good productivity goals. Encouraging participation of
individual members' in the group task so as to avoid the ill effects of social loafing.
Social loafing occurs when in a group an individual does not do his share of work,
 expecting that the work will get done anyway since other members of the group are
working towards the same goal.
Exercising care and discretion in utilizing competition to encourage group
productivity.
Providing groups with opportunities for success.

9.4 Teams

A team can

make important contributions to the development of the organization,

wield strong influence on individual work attitudes and behaviour,
gain the commitment of its members by being participative and consequently
facilitating implementation.

9.4.1 Building a team

The building blocks of effective teams, as identified by Woodcock (1986) are:

clear objectives and agreed goals,

openness and confrontation,
support and trust,
cooperation and conflict,
sound procedures,
appropriate leadership,
regular review,
individual development,
sound inter group relations.

9.4.2 Stages in team building

To make teams efficient and effective, a research manager should use:

managing talents to successfully guide teams through various stages of development,

leading skills, which would kindle team members to achieve their full potential at
every stage of team development.

There are five sequential steps involved in the team building process:
 1) Forming refers to awareness. During this stage, team members are oriented,
become committed, and then accept the goals and programmes.
2) Storming refers to resolution and development of a feeling of belonging.
3) Norming refers to cooperation and collaboration in which communication is
promoted. This results in a feeling of enticement and support.
4) Performing refers to productivity. During this stage problems are solved and
interdependence fostered, which results in achievements.
5) Adjourning refers to separation. This does not occur if the previous four stages
have been successful, with no problems encountered.

9.4.3 Approaches to team building

There are several approaches to team building, with differing degrees of group participation,
self-examination, problem confrontation and goal setting. Any of these approaches can be
used for team development. A manager can also blend and integrate different approaches,
depending upon situational requirements.

9.4.3.1 Goal-setting approach

The goal-setting approach is based on the assumption that a goal influences not only
individual and group behaviour but also direction, coordination and extent of group efforts. If
problems of the group are identified through interviews with group members, they can be
handled by group solutions. Based on these solutions, the group could set goals. Goal setting
creates commitment and a feeling of involvement.

9.4.3.2 The inter-personal approach

Based on the assumption that an inter-personally congenial team functions more effectively,
the inter-personal approach encourages 'sharing of feelings, psychological support for one
another, and non-evaluative communication' among team members. Cooperation and better
understanding is obtained by developing mutual trust and confidence among group members.
It helps in creating an environment where conflicts are effectively settled, problems solved
efficiently, and decision making is based on group concordance. This increases the
effectiveness and productivity of the team.

9.4.3.3 The managerial grid model

The managerial grid approach aims at productive and cohesive team-work. It involves four
steps. The first step is evaluation. Every team member evaluates their personal contribution
and performance as well as that of others in the group. This process helps each member to
identify what they are doing or not doing to make the team effective. In the second step, the
understanding of group members concerning the team's functioning is deliberated and
examined so as to identify the problems faced by the team. The third step is to eliminate
unacceptable individual and team practices and to replace them with new behaviour and
performance goals. The fourth step involves trying out new styles of team-work and
individual behaviour to overcome problems being faced at that time. If these steps are
successful, the usefulness of the new approaches is proven and will provide the group
members with a model of how they can work together.

9.4.3.4 Role model

The role model concept is based on the assumption that 'role is a set of behaviour which an
individual in a particular organizational position feels obliged to perform and which
individuals in other organizational positions expect that person to perform'. Thus, a team is a
chain of overlapping roles. Behaviour in a group can be understood in the context of how
individuals understand their roles. If group members correctly perceive their role and the
roles of other members, conflict and vagueness can be eliminated and efficiency increased.
Many types of role and clarification meetings are used for developing effective teams.

9.4.4 Components of team building

There are three interlocking components in team building. They are:

Developing the individual Individuals come to groups with their own needs. They
work in groups to accomplish group tasks while simultaneously expecting that group
membership will fulfill some of their individual needs.
Task achievement This is the need to achieve something. It is the task on which the
group is working.
Building and maintaining the team The need to develop and sustain working
relationships among members is necessary for the accomplishing of group tasks. This
is the maintenance need of the group.

9.4.5 Team management

There are two approaches to managing a team effectively. One is the traditional approach,
based on an authoritarian style. The other is a democratic or participative approach.

The authoritarian style of team management relies on the manager being in full command.
Involvement of group members in decision making is discouraged. The democratic or
participative style of team management encourages group members to talk, express their
opinions, and involves them in the decision making process and in problem solving. Through
this process, group results are optimized.

By relying more on task and achievement-orientation, an authoritarian-style manager can

perhaps ensure obedience without motivation and involvement, but that would not generate
the best performance in the long term, whereas a participative style usually promotes that. To
promote team-work, a manager should act as an educator or a facilitator rather than as a
dictator or autocratic boss.

9.4.6 Team meetings

As per the invention, it was seen that developing a team meeting structure, consist of six
sequential steps:

a) Follow-up: Every team meeting should conclude with some plan of action to
implement the decisions made. Similarly, every team meeting should start by
objectively reviewing progress in implementing the decisions approved in previous
meetings. Follow-up action is necessary when planning and reviewing.
b) Review of performance data: The next step is to evaluate progress in team performance
since the last meeting. This is done to ensure that the team is moving in the right
direction.
c) Reinforcement: After reviewing the implementation or performance, a manager has to
provide reinforcement. Obviously, positive reinforcements are given to those who have
contributed to progress and performed well. Negative reinforcement is for those who
fell short in their performance. In the team setting, positive reinforcement is effective
in encouraging the good performer to continued with good, or even improved,
performance. Simultaneously, it also motivates slow performers towards better efforts
in the hope of receiving positive reinforcement later on, when they have improved their
performance. A manager should use negative reinforcement only after exhausting other
means. Initially, negative reinforcement should be mild so as not to demotivate poor
performers. The aim should be to motivate towards better performance. As observed:
 behaviour resulting from positive reinforcement tends to continue, persist or
even increase,

behaviour that is re-motivated by negative consequences tends to deplete,

good behaviour which is not reinforced in any manner tends to decline over
time.

d) Problem solving: During team meetings, appropriate reinforcement aims at solving

problems so as to make group members more productive. An imaginative and creative
problem-solving approach is crucial to good team performance. It provides an
opportunity for positive interactions between team members and is helpful in
increasing team productivity.
e) Planning action: The next step in the team meeting process is to formulate an action
plan and assign specific responsibilities to individual members of the group.
f) Communicating: The last step of a team meeting is a brief discussion about the group's
current and future concerns and progress. It strengthens team spirit. It simultaneously
reassures team members that they are working jointly to achieve common goals.

9.4.7 Improving team efficiency

Some useful ways to improve team efficiency are considered below:

(i) Influence the evolution of effective norms which a team adopts, and depending on
managerial style, a manager can achieve this by defining standards, focusing on setting goals
with the group, reinforcing goals when they are met, and recognizing good performance.
Some important considerations in setting norms are noted below.
The atmosphere in the group should be informal and relaxed.
There should be provision for ample discussion regarding tasks, with each member
participating in the discussion and expressing their views.
Objectives should be clearly formulated and understood, and accepted by group
members
Members should listen to each other. They should be able to freely express their ideas
and opinions, including those relating to group performance.
Disagreements should be acknowledged and settled, rather than subdued.
Most decisions should be arrived at through some form of concordance.
Criticism should be frequent, but seldom personal.
 Responsibilities should be assigned clearly and without ambivalence.
The team leader should not overshadow the team, and there should be no power
struggle within the group.
The group should be aware of its operation.

(ii) Improve the efficiency of the team, and a manager can do this by efficiently organizing
the work and securing the means necessary, including appropriate technology, resources, and
supporting facilities.

(iii) Ensure high skill levels.

(iv) Ensure that pay, promotions and recognitions are related to team performance. The
manager thus demonstrates to subordinates the value of team-work and the value attached to
the contribution of individuals in team-work.

(v) Provide intrinsic rewards, such as challenging work, clear responsibilities and autonomy
in influencing work methods. The manager should ensure not only that jobs synchronize with
the interests of individual members, but also that they find the job easier in a team setting.
For effective intrinsic group rewards, managers should define tasks completely, purposely
and explicitly. A task should have an identifiable end point. Each group member should have
skills required to complete these tasks. The team should have freedom in deciding on its
working methods, planning and allocation of responsibilities to individual members.

9.4.8 Team building in agricultural research organizations

Increasing specialization in every field has led to the need for a multidisciplinary approach in
research. This necessitates pooling of experience and knowledge of various fields to foster
creativity and efficiency in a research team. Agricultural research organizations consist of a
number of groups. These groups are important because they provide a stimulus for creativity
and innovation. Through synergic effects, they help in tackling multidimensional and
complex research problems which require collaborative inputs from several disciplines. Team
research also puts limited resources to optimal use. It can result in total solutions covering
different dimensions.

Teams can be constituted either vertically or horizontally. Vertically formed teams are based
on fields of production. Horizontal teams comprise departments based on disciplines. The
size and skills of a team should be based on the problem to be solved and its magnitude. A
research manager has to consider the relative merits and drawbacks of alternative approaches
in forming the team so as to provide the required capabilities for realizing the goals set by the
organization.

The research manager has a crucial role in facilitating smooth, effective and efficient
functioning of the team which includes highly skilled scientists. The manager has to satisfy
both individual and organizational needs through appropriate managerial interventions and
reinforcements. The effective and efficient functioning of a team can be facilitated if the
objectives of the team are jointly decided and tasks clearly specified. In research
organizations, human factors play a proportionally greater role than in other organizations. A
research organization can be effective only if the special human needs of scientists are
satisfied.

In general in agricultural research organizations, it is desirable to attain a suitable blend of

both vertical and horizontal elements in teams. Examples of discipline-based horizontal teams
are:

soil chemistry,
soil physics,
soil pedology,
crop genetics
plant breeding,
plant physiology,
plant pathology,
irrigation and salinity,
animal physiology,
agricultural engineering,
agricultural economics,
food technology
entomology

Teams based on production lines are:

field crops,
vegetable crops,
horticulture,
 forestry,
animal husbandry
poultry

In some organizations, team building may influence individual freedom and creativity, but
not so in an agricultural research organization, where problem solving generally requires
inputs from various disciplines. Research problems are jointly discussed by those constituting
the team, i.e., the scientists of the various disciplines. On the basis of such discussion, goals
are decided. The individual contribution of each scientist is also discussed and planned.
Every scientist then has the freedom to plan their work independently. However, the
scientists meet periodically to exchange experiences, discuss problems and review progress.

9.5 Techniques

Team building has proven to be extremely useful in the business world where executives
have different thought processes. They have different perspectives of looking towards a
scenario. Due to this, personal ego and attitude can cause clashes among the employees and
executives. This results in unhealthy relations which in turn affects employee performance.
Due to such barriers between team members, the team won't be able to achieve what they are
expected to. In such a situation, team building comes to the rescue.

9.5.1 Concepts

Team building is a kind of bonding of all team members who come from different
backgrounds and have different ways of thinking. It enables a mutual understanding and a
common goal to be created in the minds of all team members. It helps them in increasing
their performance levels and quality, better decision making, problem solving, innovative
thinking, and resolving conflicts.

9.5.2 Good Communication

Communication is certainly a crucial factor in team building. Techniques and activities which
don't involve effective communication are unproductive. It is very important for team
members to communicate with each other to pass on their views and ideas. With effective
communication, every team member comes to know how the other person thinks, what work
does he expect, and what he is capable of. This helps in working efficiently and dividing the
work accordingly among the team members, which promotes proper coordination.
9.5.3 Motivation

Employee motivation is also a significant aspect of getting the best from the employee. Team
building is an effective tool for the management to motivate and encourage employees to
move forward towards the set goals. Motivation enables an employee to think that his
contribution is truly important for the company. It includes building a person's confidence
regarding his work, his team members, and the company goals.

9.5.4 Projects

A good leader or manager would surely be aware of all strategies. There are many ways of
promoting team building, be it at the workplace or on an outing. Team building strategies are
put into practice when either the team has performed well and is expected to continue doing
so, or the team is not giving its best for any specific reason. There are several processes in a
company, and there may arise a need of two or more processes to work for a single project. In
such cases, the leaders arrange some activities which would help the teams communicate and
coordinate with teams from other processes for getting ready for the collective work.

Every employee has different strengths and capabilities, and so roles and responsibilities
should be assigned on that basis. Employees come from various backgrounds, so the
company should take advantage of the diverse mentality in their working processes. Typical
team building techniques normally consist of an outdoor trip with all the members of a team.
In such activities, they play creative and informative games that include communication.
There are also some informal corporate team building activities just to make the employees
feel that it is solely not a formal event.

There are many other team building techniques that can be used by experienced managers to
bond a team together for a common purpose. After all, 'team building for success' is the most
important motto in an organization.

9.6 Roles and Rules

Researcher came up with nine team roles through a study conducted at Henley Management
College. He identified the team roles after observing the behavioral tendencies of individuals
within a group. The team roles consist of three categories:

1. action-oriented roles that include shaper, implementer and completer/finisher roles;

 2. people-oriented roles which include coordinator, team worker and resource
Investigator roles;
3. thought-oriented roles which include plant, monitor-evaluator and specialist roles.

Teams formed on the basis of Belbin's categories are effective in achieving their objectives
because there are no overlapping roles or missing qualities in the team.

9.6.1 Shaper Role

In a team, the shaper role is performed by people who are dynamic and relish challenges.
Rather than quit when faced with challenges, shapers maintain a positive mental attitude and
strive to find the best ways to overcome challenges facing the team. Shapers are extroverts
and possess great interpersonal communication skills and work toward motivating other team
members.

9.6.2 Implementer Role

People who play the implementer role in a team are those who actually get things done in the
team. They are practical, efficient and well-organized. Implementers turn the team's ideas and
thoughts into actual plans. Because of their conservative nature, implementers are rather rigid
and slow to accept change in a team.

9.6.3 Completer/ Finisher Role

Finishers have an eye for detail. In a team, they're regarded as perfectionists because they're
the ones who detect errors or omissions and strive to ensure that the team adheres to
deadlines. They're neat and self-conscious and worry at the slightest sign of a problem.
Finishers also have a problem with delegation; they would rather be overwhelmed than share
their work with others.

9.6.4 Coordinator Role

Coordinators are seen as possessing the traditional team role. They're mature and confident in
nature and possess great listening skill. They guide the activities of the team to what they
identify to be the team's obligations. Coordinators are good at delegating duties, but they may
be manipulative when it comes to directing the team toward what they perceive to be its
goals.
9.6.5 Team worker Role

Team workers are the people who ensure the team remains united. They work toward
resolving conflict or issues affecting the team's dynamics. Team workers are very supportive
of other team members and are thus popular within the team. Team workers are known to be
non-committal during decision making because they don't want to be seen as taking sides:
they put team cohesion ahead of their decision-making abilities.

9.6.6 Resource Investigator Role

Resource investigators are inquisitive and enthusiastic in nature and possess great negotiating
and networking skills. They are extroverts, which makes it easy for others to relate to them.
Through their networking skills, resource investigators develop external contacts and
negotiate for the team's resources. They are quick thinkers and good at getting information
from other people.

9.6.7 Monitor-Evaluator Role

These are the critical thinkers in a team. They're serious minded and cautious in nature.
Rather than rush into decision making, they prefer to critically analyze information before
making any conclusions. Monitor-evaluators lack the energy to motivate other team members
and are deemed to be slow in decision making.

9.6.8 Specialist Role

Workers with expert knowledge in a particular area comprise the specialist role. Their
contribution to the team is limited only to their area of expertise. Their priority is in
maintaining their professional standards. Though they show great pride in their area of
expertise, they show little or no interest in the expertise of others. Because of their expert
knowledge, they're indispensable members of a team.

9.6.9 Plants Role

Plants are innovative members of the team. They come up with original approaches and ideas
that help the team in solving problems or overcoming challenges. Plants are introverts in
nature and possess poor communication skills. Plants prefer to work alone. They react well to
praise but are greatly affected by negative criticism.
9.6.2 Importance

Small and large businesses use teams to accomplish various tasks. Teams are groups of
individuals working collectively toward common objectives. A team role is a tendency to
behave, contribute and interact with others in a particular way, notes management consulting
firm, whose founder identified nine different team roles. Recognizing these roles plays an
important part in team and organizational performance.

Belbin's research found that the difference between team failure and success depends on the
behavior of team members. His research team identified separate clusters of behavior or
roles, such as plants, monitor-evaluators, implementers and coordinators. Plants are highly
creative individuals who can solve problems in unconventional ways. Monitor-evaluators
look at problems and propose alternative solutions in an impartial and objective way.
Implementers know how to get things done efficiently. Coordinators act as leaders, who are
involved in delegating work and focusing the team's objectives.

9.6.2.1 Matched Skills

Recognizing various team roles allows a small-business owner or the human resource
manager in a large company to match job requirements with the appropriate employee skills.
This creates balanced teams. For example, a team with only coordinators and no plants may
not have anyone to propose creative solutions. However, it was found that too many plants
could lead to teams wasting precious time on ideas that have no chance of succeeding.
Companies often have to negotiate contracts and agreements with employees, suppliers and
customers. In an August 2005, it was suggested that a negotiating team should have a clear
leader making the ultimate decisions. Similarly, someone should be crunching the financial
data and another person with expertise in drafting legal contracts.

9.6.2.2 Cohesiveness

Teams tend to work more cohesively if the members recognize their individual roles. In a
June 2011 it was suggested that collective work and mutual commitment, in addition to
cooperation and coordination, allow teams to succeed. As found, the familiarity of team
members with one another also plays an important role in team performance. Higher
familiarity usually leads to better team performance because it allows team members to share
information and engage one another to find constructive solutions to problems.
9.6.2.3 Achieving Objectives

Recognizing team roles is important for achieving stated objectives. In a start-up company,
teams may be limited to a single one, with the founding partners performing the plant,
coordinator and other team roles. The team shares a common purpose, which includes
survival and growth. Hill suggests that without a common purpose, a group cannot become a
team. As the company grows and more teams come into play, it is very important that
company management clarify the roles of the team members and the objectives for each
team.

Review Questions

33. What are the components of team building?

34. What is the meaning of Group cohesion?
35. Explain group influence in details?
36. What are the important variables that influence the group formation?

Discussion Questions
What is team building? How the team is formed? State the different approaches of it?

Application Exercises

25. Describe Group efficiency and effectiveness?

26. What is the prime difference between Team and Group?
27. What according to Hill is the meaning of Team building?
“The lesson content has been compiled from various sources in public domain including but not limited to the
internet for the convenience of the users. The university has no proprietary right on the same.”

Rai Technology University Campus

Dhodballapur Nelmangala Road, SH -74, Off Highway 207, Dhodballapur Taluk, Bangalore - 561204
E-mail: [email protected] | Web: www.raitechuniversity.in