What is Project Management?

More specifically, what is a project? Its a temporary group activity designed to produce a unique
product, service or result.
A project is temporary in that it has a defined beginning and end in time, and therefore defined
scope and resources. And a project is unique in that it is not a routine operation, but a specific
set of operations designed to accomplish a singular goal. So a project team often includes people
who dont usually work together sometimes from different organizations and across multiple
geographies. The development of software for an improved business process, the construction of
a building or bridge, the relief effort after a natural disaster, the expansion of sales into a new
geographic market all are projects. And all must be expertly managed to deliver the on-time,
on-budget results, learning and integration that organizations need.
Project management, then, is the application of knowledge, skills and techniques to execute
projects effectively and efficiently. Its a strategic competency for organizations, enabling them
to tie project results to business goals and thus, better compete in their markets.
It has always been practiced informally, but began to emerge as a distinct profession in the mid20th century. PMIs A Guide to the Project Management Body of Knowledge
(PMBOK Guide) identifies its recurring elements:
Project management processes fall into five groups:
Initiating
Planning
Executing
Monitoring and Controlling
Closing
Project management knowledge draws on ten areas:
Integration
Scope
Time
Cost
Quality
Procurement
Human resources
Communications
Risk management
Stakeholder management
All management is concerned with these, of course. But project management brings a
unique focus shaped by the goals, resources and schedule of each project. The value of that
focus is proved by the rapid, worldwide growth of project management:
Small-scale project management is the specific type of project management of small-scale
projects. These projects are characterized by factors such as short duration; low person hours;
small team; size of the budget and the balance between the time committed to delivering the
project itself and the time committed to managing the project. They are otherwise unique; time
delineated and requires the delivery of a final output in the same way as large-scale projects.
Small-scale projects are by far the most common form of project enacted by institutions and
large-scale organizations that may use small projects in order to accomplish a range of smallorder tasks. For SMEs and micro-businesses, especially in the creative industries, the running of
small projects may be an essential component of their core business. Individuals and groups
regularly use small-scale projects as a means to delivering a range of outcomes from organizing
a village fete to building a garden shed.
The balance between process over output is a key factor for consideration when looking at the
effectiveness of applying project management methodologies to smaller projects. Other factors
commonly associated with large-scale project management, for example time, cost and quality,
still apply and broadly there are two approaches that can be taken:
The adoption of a scaled-down version of PRINCE2 offers a flexible and reflexive approach to
small-scale project management and limits the management burden while still enhancing the

process. This methodology enables the project manager to use lean project planning as a
conceptual tool that can be configured to meet the requirements of small-scale projects in a
variety of environments.
AGILE is a risk driven approach that relies on an iterative cycle of review and evaluation. It limits
the 'management overhead' to that which is useful for the project. The process allows for
creative excursions and aims to deliver value outputs over shorter time-scales. The high level of
flexibility in this approach is well suited to creative and experimental project environments.
Quality Management
The 'management overhead' describes the ratio between the effort required to document or
manage a process and the eventual outcome of a project. With large-scale project methodologies
the quality management is an important part of a project's process and aims to provide for
continual improvement and a project output that meets the requirements of the end user. On
small-scale projects it is not always possible to use standard quality management approaches
due to limitations of time, budget and resources. There is still however a need to be creative and
innovative while maintaining quality standards that, especially in the creative industries, maybe
difficult to define or evaluate, and may defy simple categorization. It is important to recognize
that quality is an innate characteristic that we instinctively recognize. We know quality when we
see it but find it hard to say what it is in advance.[2] Insight, intuition and creativity are
indicators of quality that on a small-scale project are perhaps better evaluated on an instinctive
level i.e. is it good enough. Any lightweight, lean or small-scale project management
methodology must scale back process management and documentation to an optimum level. A
level which does not overburden the project with unnecessary administration and does not
commit scarce resources to a quality management approach that constricts the ability to be
creative and innovate. A simple evaluation based on an elaboration of the question is it good
enough may well suffice for the purpose of many small-scale projects.
Creativity, Innovation and Implementation
Innovation equals creativity plus implementation where Creativity is a balance of imagination
and analysis, and implementation is a process of idea selection, development and
commercialization. This suggests there is a requirement for a two phase solution for the
implementation of small-scale projects. The first phase being one of problem definition, analysis,
and critical thinking; followed by a second action or implementation phase where the prime
activity is the application of skills and knowledge to implement the creative idea. The breaking
down of the process of innovation into two fundamental stages offers the possibility for thinking
about small-scale projects as a two stage process. That of innovation and innovation
implementation.
Roles/Responsibilities on Small Projects
The key roles, as with any project, are the sponsor and project manager. As stated previously,
executive support and user involvement are the major contributors towards project success
according to one study. The same study also cited an experienced project manager as another
critical factor. (see Standish Report, 2001):
"Lack of executive support has replaced user involvement as the number one cause of
project failure. Without a staunch project champion with a solid business vision,
projects can drift into a technological or political abyss. Project stakeholders must
create business value by improving customer service, communicating a clear business
plan and delivering a competitive advantage."
It would stand to reason, then, that the mere act of formally designating a project sponsor and
project manager to a small project would contribute to its success. Yet, much project work gets
completed without a formal PM which can often cause projects to be delayed or cancelled. The
same Standish Group study found that for all "successful" projects, 97% of them had a formal
project manager. Of the so-called "challenged" projects in the study, only 79% had
Project Managers assigned. (see Standish Report, 2001).

Example: our company recently completed a major redesign to our web site. It was a
substantial undertaking, and we gave what we thought was good visibility and support.
However, due to budgetary constraints, we had to use a part-time project manager. When
our first project manager got a new job and couldn't continue, we changed project
managers, and again had one part-time. As sponsors, the authors were also busy and were
not exactly "engaged" in the project. It was no wonder the project stalled out, lost
momentum, and was slowly withering away. Finally, we realized the trouble, and engaged
ourselves again. We showed more interest and support for the project, held the project
manager accountable for the project results, and the project got back on track.
Dr. Paul Dorsey writing in the InterNETalia Forum (see Dorsey article, 2003) in his article called
"Top 10 Reasons Why Systems Projects Fail," says "There do seem to be three factors that all
successful projects have in common. Each of these factors is key to any project's success. Each
project can be viewed as a tripod. All three legs must be in place for the tripod to stand sturdily.
In a systems project, these legs or critical success factors consist of the following:
Top management support,
A sound methodology,
Solid technical leadership by someone who has successfully completed a similar project.
Without each of these solidly in place, the tripod will topple and the project will fail." (Dorsey,
2003)
It is obvious, then, that defining clear roles for small projects is as important on small projects as
larger ones. What about other issues that differentiate small and larger projects?

Small vs. Large Projects

If work endeavors are recognized as projects, what differentiates small projects from larger ones?
Here is a summary of some of the ways in which large and small projects differ.
Size Dimension

Medium-Large

Small

Time

Number of example1: 1000 hours <

1000
hours
example2: > 9 months
< 9 months

hours

Budget

Dollars

example1: $100,000 <

example2: $20,000
< $20,000

Risks

Number
or type

example1: "sizable" risks "low-moderate"

example2: any risks
no risks

Stakeholders

Number
or type

example1:
>
2 1
or
2
example2: Director level manager level or below
or above

Visibility

Level

Typically high

$100,000
risks

Often
indistinguishable
from ongoing work

Formality Level Sponsor, Named sponsor, PM, team Absent/informal

PM, team
sponsor/PM/team
1 person project teams
Exhibit 4: Dimensions used to Differentiate Small Projects from Larger Ones
When is Formal Planning Not Appropriate for Small Efforts?
So far we have dealt with the need for formalizing project planning for small projects. To
summarize the major points, research and experience show that formal planning and control is
most appropriate in these cases:
1. For work that requires stakeholder requirements,
2. Unique undertakings (which usually involves stakeholder requirements), and
3. Work that puts an organization at some risk and for which planning would help mitigate
that risk.
One can conclude that if the risks aren't high enough or have enough impact, then the time and
expense of formal planning isn't worth the benefits. Or, project management is not needed if

requirements are not needed, and the work can be performed according to previously gathered
requirements.
Example: if an organization is audited by its Worker's Compensation insurance agency,
the risks inherent in performing the audit aren't high. The risks born of setting up
contractors, hiring employees, etc. have already been expended. So, by the time of the
audit, the risks should be minimal and it's not worth the effort setting up a project plan.
The organization should appropriately respond to the audit and provide the information
called for, but a formal project plan and execution are not appropriate.
Project teams
A group of individuals assembled to perform activities that contribute toward achieving a
common task related goal. Many business operators will put together a project team consisting
of skilled workers from the same or different function areas to work on an important project.
Project Teams and Team Roles
A team is a collection of roles on a project. You can divide the people on a team into two
categories: scheduled members and nonscheduled members. Scheduled team members are
those people for whom you want to track the hours, utilization, and financial impact (costs,
revenue, and margin). Your scheduled team members for a project can also be referred to as the
delivery team. For more information about scheduled team members, see Defining Scheduled
Team Members.
Nonscheduled team members of a project comprise the extended team and include project team
members whose time is not specifically tracked. For more information about nonscheduled team
members, see Defining Nonscheduled Team Members.
Sub teams enable you to classify your people on your project into logical groups. For example,
you may have resources on a project that you can group into consultants, administrative staff,
and engineers, or, you may have people grouped into sub teams for different phases of a project.
For a project, you can enter general staffing information such as the default calendar, role list,
initial team template, and advertisement rules. The role list controls access for the roles that you
can add to your project. The initial team template indicates the name of the team template that
was used to create requirements on the project upon initial project creation.
The advertisement rule controls the visibility of requirements both inside and outside of the
organization. For more information, see Advertisement Rule for a Requirement, Oracle Project
Resource Management User Guide.
Oracle Projects comes seeded with a project manager role, and requires that you designate one
project team member as a project manager. While you can have only one project manager at any
point in time, you can change the project manager role assignment as necessary.
Note: Approved contract projects must have a project manager for the duration of the project. A
project manager is not required for indirect projects or capital projects. You can also define
people as team members in order to facilitate distribution of Projects reports to responsible
parties.
What is the difference between projects and operations?
In any organization, only two aspects of work existon-going operations and projects. Projects
are defined as unique, temporary endeavors with a specific beginning and end. Operations
constitute an organization's on-going, repetitive activities, such as accounting or production.
Since all work and/or efforts performed within an organization are characterized as either
operations or projects, all of the costs of an organization must be distributed to either operations
or projects.

Projects vs. Operations

Projects are initiated by organizations for a variety of reasons, such as to meet a business need,
attain a strategic objective or meet a market demand. The only way organizations can
accomplish any of these goals is by expending resources of the organization over time, for a
cost.
Project Insight, project management software, empowers teams to track project time and
expenses, and/or non-project time.
Definition of Project Controls :
Project Controls can be defined as - Management action, either preplanned to achieve the
desired result or taken as a corrective measure prompted by the monitoring process. Project
controls is mainly concerned with the metrics of the project, such as quantities, time, cost, and
other resources; however, also project revenues and cash flow can be part of the project metrics
under control. Thus, we believe an effective Project Controls process can be applied in a
collaboration of its various sub-disciplines, such as:
1) Planning,

Scheduling & Project Reporting

Scope management;
Project deliverables:
Work breakdown / Cost breakdown structures;
Schedule management;
Schedule forecasting;
Corrective action;
Progress measurement / reporting;
Productivity Analysis & Calculation;

2) Earned Value Analysis & Management

3) Cost Engineering & Estimating

Estimating;

Cost management;

Cost control;

Cost forecasting
4) Change Management & Controls

Change order control;

Trend Analysis;
5) Risk and Delay Claims

Risk Assessment & management;

Delay Claims Quantification

Forensic Schedule Analysis

Put simply, Project Controls encompass the people, processes and tools used to plan, manage
and mitigate cost and schedule issues and any risk events that may impact a project. In other
words, Project control is essentially equivalent to the project management process stripped of its
facilitating sub-processes for safety, quality, organizational, behavioral, and communications
management. Project control may be considered the quantitative resource control subset of the
project management process.
Importance of Project Controls :
The successful performance of a project depends on appropriate planning. The PMBOK Guide
defines the use of 21 processes that relate to planning out of the 39 processes for project

management, (Globerson & Zwikeal 2002). The execution of a project is based on a robust
project plan and can only be achieved through an effective schedule control methodology. The
development of a suitable Project Control system is an important part of the project management
effort (Shtub, Bard & Globerson 2005). Furthermore, it is widely recognised that planning and
monitoring plays a major role as the cause of project failures. Despite the continuous evolution in
the project management field, it appears evident that the traditional approach still shows a lack
of utilisation of Project Controls and there have been a number of articles published to support
the importance of control in the achievement of project objectives. It has been proved time and
again that Project performance can be improved if dedicated Project Controls systems are in
place. An IBC 2000 Project Control Best Practice Study carried out by IPA identified that good
Project Control practices reduce execution schedule slip by 15%. Project Controls cost range from
0.5% to 3% of total project, (including cost accounting), therefore, to break even, Project Control
needs to improve cost effectiveness by around 2%. A sample study carried out by the IBC Cost
Engineering Committee (CEC) in 1999, showed cost improvements for the projects in the study,
was more than 10%. It is noted also that NPV (Net Project Value) also benefits from schedule
improvements. Success factors are based on good Project Control practices, which result in good
cost
and
schedule
outcomes.
"The fact that one failed project can potentially wipe out an entire years profit helps put the
value of Project Controls into perspective."