INTRODUCTION

PROJECT DEFINITION
Many people and organizations have defined what a project is, or should be, but probably the
most authoritative definition is that given in ‘Guide to Project Management’. This states that
a project is:
‘A unique set of co-ordinated activities, with definite starting and finishing points, undertaken
by an individual or organization to meet specific objectives within defined schedule, cost and
performance parameters.’
A project is a group of unique, interrelated activities that are planned and executed in a
certain sequence to create a unique product or service, within a specific time frame, budget
and the client’s specifications. Some of the characteristics of the tasks that qualify to be a
project are: uniqueness, specificity of goal, sequence of activities, specified time and
interrelatedness. Projects are carried out under many resource constraints and their success
depends on the ability of the manager to manage these constraints effectively.
Projects are undertaken at all levels of organization. They may involve a single person or
thousands. Their duration ranges from few weeks to more than five years. Projects may
involve a single unit of organization or may cross organizational boundaries, as in joint
ventures and partnering. Projects are critical to the realization of the performing
organization’s business strategy because projects are means by which strategy is
implemented. Examples of project include:
• Developing a new product or service
• Effecting a change in structure, staffing or style of an organization.
• Designing a new transport vehicle
• Developing or acquiring a new or modified information system
• Constructing a building or a facility
• Building a water system for a community in a developing country
• Running a campaign for political office
• Implementing a new business procedure or process
In discussions of project management, it is sometimes useful to make a distinction between
terms such as project, program, task, and work packages. The military, source of most of these
terms, generally uses the term program to refer to an exceptionally large, long-range
objective that is broken down into a set of projects. These projects are divided further into
tasks, which are, in turn, split into work packages that are themselves composed of work
units. But exceptions to this hierarchical nomenclature abound. The Manhattan Project was
a huge “program,” but a “task force” was created to investigate the many potential futures of
a large steel company. In the broadest sense, a project is a specific, finite task to be
accomplished. Whether large- or small-scale or whether long- or short-run is not particularly
relevant. What is relevant is that the project be seen as a unit. There are, however, some
attributes that characterize projects.
There are, however, some attributes that characterize projects.
Importance: The most crucial attribute of a project is that it must be important enough
in the eyes of senior management to justify setting up a special organizational unit outside
the routine structure of the organization. If the rest of the organization senses, or even
suspects, that it is not really that important, the project is generally doomed to fail. The
symptoms of lack of importance are numerous and subtle: no mention of it by top
management, assigning the project to someone of low stature or rank, adding the project
to the responsibilities of someone who is already too overworked, failing to monitor its
progress, failing to see to its resource needs, and so on.
Scope: A project is usually a one-time activity with a well-defined set of desired end
results. (We discuss poorly defi ned, or “quasi-” projects a bit later.) It can be divided into
subtasks that must be accomplished in order to achieve the project goals. The project is
complex enough that the subtasks require careful coordination and control in terms of
timing, precedence, cost, and scope. Often, the project itself must be coordinated with
other projects being car ried out by the same parent organization.
RESOURCES: Projects have limited budgets, both for personnel as well as other resources.
Often the budget is implied rather than detailed, particularly concerning personnel, but it
is strictly limited. The attempt to obtain additional resources (or any resources) leads to
the next attribute—conflict.
Conflict: More than most managers, the PM lives in a world characterized by confl ict.
Projects compete with functional departments for resources and personnel. More serious,
with the growing proliferation of projects, is the project-versus-project confl ict for
resources within multiproject organizations. The members of the project team are in
almost constant conflict for the project’s resources and for leadership roles in solving
project problems. The PM must be expert in conflict resolution, but we will see later that
there are helpful types of conflict. The PM must recognize the difference. The four parties-
at-interest or “stakeholders” (client, parent organization, project team, and the public) in
any project even defi ne success and failure in different ways. The client wants changes,
and the parent organization wants profits, which may be reduced if those changes are
made. Individuals working on projects are often responsible to two bosses at the same
time; these bosses may have different priorities and objectives. Project management is no
place for the timid.
Non Projects and Quasi Projects
If the characteristics listed above defi ne a project, it is appropriate to ask if there are non-
projects. There are. The use of a manufacturing line to produce a flow of standard products
is a non-project. The production of weekly employment reports, the preparation of school
lunches, the delivery of mail, the flight of Delta-1288 from Dallas to Dulles, checking your
e-mail, all are Non projects. While one might argue that each of these activities is, to some
degree, unique, it is not their uniqueness that characterizes them. They are all routine.
They are tasks that are performed over and over again. This is not true of projects. Each
project is a one-time event.
Even the construction of a section of interstate highway is a project. No two miles are alike
and constructing them demands constant adaptation to the differences in terrain and
substructure of the earth on which the roadbed is to be laid. Projects cannot be managed
adequately by the managerial routines used for routine work. In addition to projects and
nonprojects, there are also quasi-projects: “Bill, would you look into this?” “Judy, we need
to fi nish this by Friday’s meeting.” “Can you find out about this before we meet with the
customer?” Most people would consider that they have just been assigned a project,
depending on who “we” and “you’’ is supposed to include. Yet there may be no specific
task identified, no specific budget given, and no specific deadline defi ned. Are they still
projects, and if so, can project management methods be used to manage them? Certainly!
The scope, schedule, and budget have been implied rather than carefully delineated by
the words “this,” “meet,” and “we” (meaning “you”) or “you” (which may mean a group
or team). In such cases, it is best to try to quickly nail down the scope, schedule, and
budget as precisely as possible, but without antagonizing the manager who assigned the
project. You may need to ask for additional help or other resources if the work is needed
soon—is it needed soon? How accurate/thorough/detailed does it need to be? And other
such questions. One common quasi-project in the information systems area is where the
project includes discovery of the scope or requirements of the task itself (and possibly also
the budget and deadline). How can you plan a project when you don’t know the scope
requirements? In this case, the project is, in fact, determining the scope requirements (and
possibly the budget and deadline also). If the entire set of work (including the discovery)
has been assigned to you as a project, then the best approach is to set this determination
as the first “milestone” in the project, at which point the resources, budget, deadline,
capabilities, personnel, and any other matters will be reviewed to determine if they are
sufficient to the new project requirements. Alternatively, the customer may be willing to
pay for the project on a “cost-plus” basis, and call a halt to the effort when the benefits no
longer justify the cost.
/ LIFE CYCLE WITH A FINITE DUE DATE
WHAT IS PROJECT MANAGEMENT?
Project management is a critical skill set in today’s world. A project is defined as a non-routine,
one-time effort limited by time, resources and performance specifications designed to meet
customer needs.
Project management meaning: A project management is a temporary endeavour, having a
defined beginning and objective usually to bring about beneficial change. Project
management is the discipline of planning, organizing, securing, and managing resources to
bring about the successful completion of specific project goals and objectives.
According to PMI, “Project management is an art of application of knowledge, skills, tools and
techniques to project activities in order to meet or exceed stakeholder needs and
expectations.”
Project management is accomplished through the use of the processes such as: initiating,
planning, executing, controlling and closing. The project team manages the work of the
projects and the work typically involves:
• Competing demand for: scope, time, cost, risk and quality
• Stakeholders with differing needs and expectations
• Identified requirements
It is important to note that many of the processes within the project management are
iterative in nature. This is part due to the existence of and the necessity for progressive
elaboration in a project throughout the project life cycle; i.e., the more you know about the
project, the better you are able to manage it.
The next question that can be asked is ‘Why does one need project management?’ What is
the difference between project management and management of any other business or
enterprise?
The answer is that project management is essentially management of change, while running
a functional or ongoing business is managing a continuum or ‘business-as-usual’.
Project management is not applicable to running a factory making sausage pies, but it will be
the right system when there is a requirement to relocate the factory, build an extension, or
produce a different product requiring new machinery, skills, staff training and even marketing
techniques.
Project management has emerged because the characteristics of our contemporary society
demand the development of new methods of management. Of the many forces involved,
three are paramount: (1) the exponential expansion of human knowledge; (2) the growing
demand for a broad range of complex, sophisticated, customized goods and services; and (3)
the evolution of worldwide competitive markets for the production and consumption of
goods and services. All three forces combine to mandate the use of teams to solve problems
that used to be solvable by individuals. These three forces combine to increase greatly the
complexity of goods and services produced plus the complexity of the processes used to
produce them. This, in turn, leads to the need for more sophisticated systems to control both
outcomes and processes.
Forces Fostering Project Management
First, the expansion of knowledge allows an increasing number of academic disciplines to be
used in solving problems associated with the development, production, and distribution of
goods and services.
Second, satisfying the continuing demand for more complex and customized products and
services depends on our ability to make product design an integrated and inherent part of
our production and distribution systems.
Third, worldwide markets force us to include cultural and environmental differences in our
managerial decisions about what, where, when, and how to produce and distribute output.
The requisite knowledge does not reside in any one individual, no matter how well educated
or knowledgeable. Thus, under these conditions, teams are used for making decisions and
taking action. This calls for a high level of coordination and cooperation between groups of
people not particularly used to such interaction. Largely geared to the mass production of
simpler goods, traditional organizational structures and management systems are simply not
adequate to the task. Project management is. The organizational response to the forces noted
above cannot take the form of an instantaneous transformation from the old to the new. To
be successful, the transition must be systematic, but it tends to be slow and tortuous for most
enterprises. Accomplishing organizational change is a natural application of project
management, and many firms have set up projects to implement their goals for strategic and
tactical change.
Another important societal force is the intense competition among institutions, both profit
and not-for-profit, fostered by our economic system resulting in organizational “crusades”
such as “total quality control,” “supply chain management,” and particularly prominent these
days: “Six-sigma*.” The competition that all of these crusades engenders puts extreme
pressure on organizations to make their complex, customized outputs available as quickly as
possible. “Time-to-market” is critical. Responses must come faster, decisions must be made
sooner, and results must occur more quickly. Imagine the communications problems alone.
Information and knowledge are growing explosively, but the time permissible to locate and
use the appropriate knowledge is decreasing.
In addition, these forces operate in a society that assumes that technology can do anything.
The fact is, this assumption is reasonably true, within the bounds of nature’s fundamental
laws. The problem lies not in this assumption so much as in a concomitant assumption that
allows society to ignore both the economic and noneconomic costs associated with
technological progress until some dramatic event focuses our attention on the costs (e.g., the
global financial crisis, the Gulf oil spill). At times, our faith in technology is disturbed by
difficulties and threats arising from its careless implementation, as in the case of industrial
waste, but on the whole we seem remarkably tolerant of technological change. For a case in
point, consider California farm workers who waited more than 20 years to challenge a
University of California research program devoted to the development of labor-saving farm
machinery (Sun, 1984). The acceptance of technological advancement is so strong it took
more than two decades to muster the legal attack. Consider also the easy acceptance of
communication by e-mail and shopping on the Internet.
Finally, the projects we undertake are large and getting larger. The modern advertising
company, for example, advances from blanket print ads to regionally focused television ads
to personally focused Internet ads. As each new capability extends our grasp, it serves as the
base for new demands that force us to extend our reach even farther. Projects increase in size
and complexity because the more we can do, the more we try to do.
 The projects that command the most public attention tend to be large, complex,
multidisciplinary endeavours. Often, such endeavours are both similar to and different from
previous projects with which we may be more or less familiar. Similarities with the past
provide a base from which to start, but the differences imbue every project with considerable
risk. The complexities and multidisciplinary aspects of projects require that many parts be put
together so that the project’s objectives—deliverables, time (or schedule), and cost—are
met.
PROJECT MANAGEMENT AND THE PROJECT MANAGER
The Functional Manager versus the Project Manager:
• It is immediately apparent therefore that there is a fundamental difference between
project management and functional or line management where the purpose of
management is to continue the ongoing operation with as little disruption (or change)
as possible. This is reflected in the characteristics of the two types of managers. While
the project manager thrives on and is proactive to change, the line manager is reactive
to change and hates disruption.
• functional manager in charge of one of a firm’s functional departments such as
marketing, engineering, or finance (see Figure 3-1). Such department heads are usually
specialists in the areas they manage. Being specialists, they are analytically oriented
and they know something of the details of each operation for which they are
responsible. When a technically difficult task is required of their departments, they
know how to analyze and attack it. As functional managers, they are administratively
responsible for deciding how something will be done, who will do it, and what
resources will be devoted to accomplish the task.
• A PM generally starts his or her career as a specialist in some fi eld who is blithely
informed by a senior manager that he or she is being promoted to the position of
Project Manager on the Whizbang Project. The PM must now metamorphose from
technical caterpillar into generalist butterfl y. Therefore, what is required is an ability
to put many pieces of a task together to form a coherent whole—that is, the project
manager should be more skilled at synthesis, whereas the functional manager should
be more skilled at analysis. The functional manager uses the analytic approach and the
PM uses the systems approach.
The analytic method focuses on breaking the components of a system into smaller and
smaller elements. We are not saying that this is wrong, it is merely inadequate for
understanding a complex system. Regardless of the dissector’s skill or the degree to
which, say, a frog is dissected, the dissection allows only a partial understanding of the
total animal “frog.” The systems approach maintains that to understand a component, we
must understand the system of which the component is a part. And to understand the
system, we must understand the environment (or larger system) of which it is a part.
Adoption of the systems approach is crucial for the project manager. Consider, if you will,
the problem of managing a project devoted to the development of software that will
create and maintain a database, and to undertake this task without knowing anything
about the decision support system in which the database will be used, or the operating
system of the computers that will contain the DSS, or the purposes for which the
information in the database will be used, and so forth.
Our comparison between the PM and the functional manager reveals another crucial
difference between the two. The functional manager is a direct, technical supervisor. The
project manager is a facilitator and generalist. These simple statements, while true, are
misleading. Both require specialized technical knowledge. The functional manager’s
knowledge must be in the technology of the process being managed. The PM should be
competent in the science of project management (Sahlin, 1998; Zimmerer et al., 1998),
but this is not sufficient. In our opinion, there is strong evidence that the PM should be
both generalist and facilitator and have a reason ably high level of technical competence
in the science of the project.
Three major questions face PMs in their task of synthesis: What needs to be done, when
must it be done (if the project is not to be late), and how are the resources required to do
the job to be obtained? In spite of the fact that the PM is responsible for the project, the
func tional managers will probably make some of the fundamental and critical project
decisions. For example, they usually select the people who will actually do the work
required to carry out the project. They may also develop the technological design
detailing how some tasks will be accomplished. And they frequently infl uence the precise
deployment of the project’s resources.
This separation of powers between functional and project managers, which may aid in
the successful completion of the project, is also a source of considerable “discomfort” for
both. Note here that the PM is responsible for organizing, staffi ng, budgeting, directing,
planning, and controlling the project. In other words, the PM “manages” it, but the
functional managers may affect the choice of technology to be used by the project and
the specific individuals who will do the work. (It is not uncommon, however, for the PM
to negotiate with functional managers about the assignment of special individuals to carry
out certain project work.) Arguments about the logic or illogic of such an arrangement
will fall on deaf ears. The PM cannot allow the functional manager to usurp control of the
project. If this happens, work on the project is likely to become secondary to the work of
the functional group and the project will suffer. But the functional manager cannot allow
the PM to take over authority for technical decisions in the functional area or to control
the assignment of functional area personnel.
At times, a senior manager (often the PM’s immediate superior) will, in effect, take over
the PM’s job by exercising extremely close supervision over every action the PM takes, or
will actually tell the PM precisely what to do. All of the powers normally delegated to the
PM are withdrawn and the PM’s boss runs the project. This condition is known as
micromanagement. It stamps out any creativity or initiative from the PM or project
workers, frustrates almost everyone connected with the project, and generally ensures
mediocre performance, if not failure. To be frank, we do not know how to cure or prevent
micromanagement. It is practiced by individuals who have so little trust in their co-
workers that they must control everything. Our considered advice to PMs who are
micromanaged is to request a transfer. At the other end of the spectrum, the relationship
between the PM, the functional managers, the project team, and the PM’s superior may
be characterized as “collegial,” and the organization may be populated by talented people.
In such organizations conflict is minimized, cooperation is the norm, no one is terribly
concerned with who gets the credit, and the likelihood of success is high. We will have
more to say later in this chapter and in other chapters about building and maintaining
teams. Effective teams tend to operate in a collegial mode. It is worth noting, however,
that collegiality without talent leads to failure—even if the project team smiles a lot while
failing.
 PROJECT MGMT FUNCTIONAL MGMT
Project management is the process of Functional management is managing the
initiating, planning, executing, controlling,
routing activities in the organization relating
and closing the work of a project to achieveto various functions such as production,
a specific objective. sales, and marketing, finance etc. in order to
achieve the overall objective of the
organization.
Project management is unique and the Functional management is a continuous and
project is terminated once the objective is repetitive process.
achieved.
Project management is a onetime activity Functional management is an ongoing
with a specified time span. activity.