PONDICHERRY CENTRAL UNIVERSITY

SCHOOL OF MANAGEMENT
DEPARTMENT OF MANAGEMENT STUDIES
I.

MBA II. SEMESTER

Section A
ASSIGNMENT OF TOPICS FOR PRESENTATION
PROJECT MANAGEMENT

1. ABHINAB SONOWAL AS- Define project and explain the characteristics of a Project.
2. ABINANDHAN A- Explain the different types of Projects.
3. AISHWARYAA R - Explain the Objectives of Project Management.
4. ALEX J PATTARA JAMES Importance of Project Management.
5. ARAVINDHAN R- Integrative approach to Project Management.
6. ARUN BALA M - need for Project Portfolio Management.
7. ASHOK R- objectives of Project Portfolio Management.
8. ASHWINI B- challenges of implementing a Project Portfolio Management.
9. BALAJI R- Explain the considerations to be borne in mind while devicing a project
structure.

10. BHASWANI DANA- Explain the different types of Project structures.

11. BLESSON MATHEW THOMAS - Explain the different steps in defining a Project.
12. BOSCO GNANARAJ J-Project Rollup
13. CHANDRASEKHAR NAYAK D - Process Breakdown structure
14. CHARAN TEJA A- Responsibility Matrices.
15. DHAMAL SINGH TOPPO- causes for delay in execution of projects
16. GNANA KUMAR P - steps to be taken during delays.
17. GOUTHAM B - positives and weaknesses of Payback Period method of evaluating
projects.

18. GOWRI C- positives and limitations of Accounting Rate of Return method of

evaluating projects.

19. GYAN PRAKASH - positives and limitations of NPV

20. JAGANNATH T- Positives and negatives of IRR methods of appraising projects.
21. JAWAD MOHAMED AMEER - process of evaluating a project.
22. KANIMOZHI R - Cost Benefit Analysis
23. KARTEEK SANDHI - economic benefits of investing in projects.
24. KARTHICK S- managing and leading of a project.
25. KATYAYANI KRIPONKER K K - social network building for managing the stakeholders
of a project.

26. KAUSHIK RAJA R - Management by Wandering Around.

27. KRISHNA K- qualities of an effective project manager.
28. KRISHNA REDDY MYLARAM - five stages of team development.
29. KUMAR SUSHANT- factors affecting team development in an organisation.
30. MANJU A.THOMAS - pitfalls in team development.
31. MD. AKRAM - various activities performed during Opportunity study of a project.
32. NISHANTH G- preparatory phase of a project.
33. NITHIYANANDAM S- Feasibility study of a project.
34. PARTHIBAN R- process of Feasibility study
35. PRAVIN CUMAR R- reasons for conducting a Feasibility study.
36. PRAVINRAJ N-Case study
37. RAJASIMMAN R - Detailed Study
38. PREETHA A- Technical study.
39. RAJESH KUMAR R - activities involved in Initiation phase of a project.
40. RAKESH RAMACHANDRAN MENON - plans to be prepared during the planning phase
of a project.

41. RANGANATHAN IYER S - process of Managing resources.

42. SARANYA B- importance of managing resources.
43. SATHIYA SORUBAN E - process involved in the Project planning phase.
44. SHAHID KK - key characteristics of Project Planning.
45. SHALINI. P.N. - processes involved in the execution phase of a project.
46. SVETHA K- Explain the information to be furnished by a project review report.
47. TRIDIB KARMAKAR - tasks involved in and the process of project closure phase.
48. UMA M - various types of closing a project.
49. VARSHA MOHAPATRA - Explain the advantages and limitations of PERT.
50. VISHAKHA TAYDE - advantages and limitations of CPM.
51. AISWARYALAKSHMI JC - positives and limitations of crashing a project.
52. ANTUVANE S - process of CPM.
53. ARUN KUMAR P - process of PERT.
54. DHANYA P- Distinguish between Resource Levelling and Resource Allocation.
55. DILIP KUMAR DAS - various approaches to crashing.
56. GOUNDER DHANASHEKAR GANESHAN - Explain the rules for constructing a project
network.

57. RAJEEV RAGAVAN - guidelines FOR crashing.

58. SRINIVASAN G - Explain the various steps of resource leveling.

59. THARANI S- Explain the various steps of resource allocation.

60. CAMALA CANNANE CLAUDINE- Explain the various Causes for time and cost
overruns.

61. BENOIT ALINE POULINE- How can project overruns be overcome?

Section B

1. ABDURASSAK MANARIKKAL M - Define project and explain the characteristics of a

Project.

2. AJAY KASHYAP - Explain the different types of Projects.

3. ALFRED JOHNS J - Explain the Objectives and Importance of Project Management.
4. ANITTI S- Integrative approach to Project Management.
5. ANUSHA G - need for Project Portfolio Management.
6. ARTHI K- objectives of Project Portfolio Management.
7. ARUNKUMAR G- challenges of implementing a Project Portfolio Management.
8. ARVIND S- Explain the considerations to be borne in mind while devicing a project
structure.

9. AYSHWARYA P- Explain the different types of Project structures.

10. BALVINDER SINGH- Explain the different steps in defining a Project.
11. BHUVANESWARI G -Project Rollup
12. BIKASH SAHU - Process Breakdown structure
13. CECILIA LALMUANPUII - Responsibility Matrices.
14. DEODEEP KUMAR - causes for delay in execution of projects and steps to be taken
during delays.

15. FARISHA.K.M. K.M.- positives and weaknesses of Payback Period method of

evaluating projects.

16. GOPU HEMANTH KUMAR REDDY - positives and limitations of Accounting Rate of
Return method of evaluating projects.

17. GUNDIP SINGHA KONSAM K - positives and limitations of NPV

18. HARISH AHIRE UTTAM - Positives and negatives of IRR methods of appraising
projects.

19. IFFAT MASOOD - process of evaluating a project.

20. IYYAPPAN N - Cost Benefit Analysis
21. JOHN. E.P. - economic benefits of investing in projects.
22. JOVITHA J - managing and leading of a project.
23. KALAIYARASI V- social network building for managing the stakeholders of a project.
24. KANIMOZHI A- Management by Wandering Around.
25. KARTHIK K- qualities of an effective project manager.
26. KEERTHIVASAN S- five stages of team development.
27. KUNDAN PRASAD K - factors affecting team development in an organisation.
28. LALHRUAITLUANGA RALTE - pitfalls in team development.

29. MAHENDRA BOHRA - various activities performed during Opportunity study of a

project.

30. MALINI K - preparatory phase of a project.

31. MANAS SINGH - Feasibility study of a project.
32. MANORAJ N- process of Feasibility study
33. MICHI BIDA SIRA - reasons for conducting a Feasibility study.
34. MOUNI SHARON CHINTALA -Case study
35. NANITA DEBBARMA - Detailed Study
36. NIRANJAN TATAVARTI M V R - Technical study.
37. NISHIBANYA MALLIK - activities involved in Initiation phase of a project.
38. PRABHAT KUMAR MATHUR PKM - plans to be prepared during the planning phase of
a project.

39. PRAKASH D- process of Managing resources.

40. RAMYA MAKE - importance of managing resources.
41. RANI RATNA MS.- process involved in the Project planning phase.
42. SAM MOSES AROKIA L - key characteristics of Project Planning.
43. SARANKUMAR R - processes involved in the execution phase of a project.
44. SARANRAJ S - Explain the information to be furnished by a project review report.
45. SIVAKUMAR T - tasks involved in and the process of project closure phase.
46. SRIKANT BERAGATI - various types of closing a project.
47. SUHAIL T- Explain the advantages and limitations of PERT.
48. SUMITHA R- advantages and limitations of CPM.
49. SUSHEEL S- positives and limitations of crashing a project.
50. VIGNESH D- process of CPM.
51. VIVEKANAND- process of PERT.
52. ANAND V- Distinguish between Resource Levelling and Resource Allocation.
53. BHAGYA A- various approaches to crashing.
54. DHASS S- Explain the rules for constructing a project network.
55. LILE SHANTHALL MALLIGAU R - guidelines FOR crashing.
56. SIVARANJINI S - Explain the various steps of resource leveling.
57. SUMIT DAVID TIRKEY - Explain the various steps of resource allocation.
58. SASIDHARAN C - Explain the various Causes for time and cost overruns.
59. JAYABHARATHY M- How can project overruns be overcome?

Unit 1
PROJECT
DEFINITION
A project is a temporary endeavor, having a defined beginning and end (usually constrained by date, but
can be by funding or deliverables), undertaken to meet unique goals and objectives, usually to bring
about beneficial change or added value. The temporary nature of projects stands in contrast to business
as usual (or operations), which are repetitive, permanent or semi-permanent functional work to produce
products or services. In practice, the management of these two systems is often found to be quite
different, and as such requires the development of distinct technical skills and the adoption of separate
management.
Projects are different from standard business operational activities as they are:

Unique in nature. They do not involve repetitive processes. Every project undertaken is different
from the last, whereas operational activities often involve undertaking repetitive (identical)
processes

Have a defined timescale. Projects have a clearly specified start and end date within which the
deliverables must be produced to meet a specified customer requirement

Have an approved budget. Projects are allocated a level of financial expenditure within which the
deliverables must be produced to meet a specified customer requirement

Have limited resources. At the start of a project an agreed amount of labor, equipment and
materials is allocated to the project

Involve an element of risk. Projects entail a level of uncertainty and therefore carry business risk

Achieve beneficial change. The purpose of a project, typically, is to improve an organization

through the implementation of business change.

Project management-Definition
Project management is the discipline of planning, organizing, securing and managing resources to bring
about the successful completion of specific engineering project goals and objectives.
It is sometimes conflated with program management, however technically that is actually a higher level
construction: a group of related and somehow interdependent engineering projects.

Objectives of Project Management

Project management aims to plan, coordinate and control the complex and diverse activities of modern
industrial and commercial projects. All projects are sharing one common characteristic, name the
projection of ideas and activities into new endeavours. The purpose of project management is to foresee
or predict as many uncertainties and problems as possible and to plan, organize and control activities so
that the project is completed successfully in spite of all the risks.

Setting Objectives: The objectives in project management must be specific and should be clearly laid
down. A specific objective increases the chances of leading to a specific outcome. Therefore
objectives shouldn't be vague, such as "to improve customer relations," because they are not
measurable. Objectives should show how successful a project has been, for example "to reduce
customer complaints by 50%" would be a good objective. The measure can be, in some cases, a
simple yes or no answer, for example, "did we reduce the number of customer complaints by
50%?"
While there may be one major project objective, in pursuing it there may be interim project objectives.
In lots of instances, project teams are tasked with achieving a series of objectives in pursuit of the final
objective. In many cases, teams can only proceed in a stair step fashion to achieve the desired outcome.
If they were to proceed in any other manner, they may not be able to develop the skills or insights along
the way that will enable them to progress in a productive manner.
Performance and Quality: The end result of a project must fit the purpose for which it was intended. At
one time, quality was seen as the responsibility of the quality control department. In more recent
years the concept of total quality management has come to the force, with the responsibility for
quality shared by all staff starting from top management to the staff at operational level.
Budget: The project must be completed without exceeding the authorized expenditure. Financial sources
are not always inexhaustible and a project might be abandoned altogether if the funds run out
before completion. If it happens, the money and effort invested in the project would be forfeited
and written off. In the extreme cases, the project contractor could face ruin. Hence, proper
attention is to be paid to the cost budges and financial management.
Time of completion: Actual progress has to match the planned progress. All the significant stages of the
project must take place on later than their specified dates and completed on or before their
respective latest completion times so that the entire project is completed on or before the planned
finish date. The timescale objective is highly important because late completion of the project is
not very likely to please the project sponsors.

Challenges to Project Management

The primary challenge of project management is to achieve all of the project goals and objectives while
honoring the preconceived constraints. Typical constraints are scope, time, and budget. The secondary
and more ambitiouschallenge is to optimize the allocation and integrate the inputs necessary to meet
pre-defined objectives.

CLASSIFICATION
The classification of projects is presented in two different ways as presented below:

Project classification based on product versus nature of work.

Project classification based on application areas.

These are explained in the following sections.

Project classification based on product versus nature of work: Before classifying these projects, certain
terminologies are presented below.
Tangible Product: A tangible product is one in which the primary value is in the physical artifact (entity).
It is the value of the artifact that distinguishes it from other products. A new express highway is a wellrecognized example of this type of product.

Intangible product: An intangible product is one in which the value is in its intellectual property
(content). Although there is some physical result, this is not the essence of the product. The essential
feature is new information and its physical aspect is only a vehicle for its conveyance and
transformation. Software is an example of this category.
Craft work: Craft work is the work that has been done before, essentially requiring repetitive
effort/training. It is an activity that fundamentally repeats a previous activity, can be improved through
repetition and conforms to the learning curve phenomena. Some examples of this type are assembling a
four wheeler, repairing a two wheeler etc.
Intellect work: Intellect work is the work that requires substantial creative effort/education. It has not
been done before. It is exploratory in nature and it will likely require iteration. It requires new ideas and
imagination. This is the result of brain power. Some examples are developing new theory, new product,
new process, new invention, etc.
Now, the projects can be classified into four types with respect to the parings of the types of product and
types of work as mentioned below,
Tangible-craft project: A tangible-craft project involves the creation of a physical artifact that results
from craftwork that is essentially repetitive in nature. The work is subject to linear logic and
learning curves in the pursuit of satisfactory productivity in the building of the artifact. These
projects are usually costly, but the resources are predictable and controllable.
Tangible-intellect project: A tangible-intellect project involves the creation and assembly of a new piece
of hardware or other material product. It is something that has not been done before. It is
typically a subject to linear logic, but requires iterations to achieve the ultimate goal. This project
may be costly and the resources required are not very predictable. An example of this type of
project is a new windmill to generate power.
Intangible-craft project: An intangible-craft project does involve the assembly of a physical entity, but
the value of the product is in its content and not in the article itself. The project likely involves
copying and updating from a previous version. There should be no need for iterations as the
previous version should provide the basis for learning. Linear logic is not required and resource
requirements are predictable. Examples of this type are: annual plant maintenance shut down or
conducting national election.
Intangible-intellect project: An intangible-intellect project requires a non-repetitive, creative effort to
develop new intellectual property. No linear logic is involved, but iterations will be needed
before satisfactory completion. These projects are probably relatively less costly, but the
resources are highly unpredictable simply because brainwork is involved and they have never
been done before. Some examples of this type are propounding a new theory or writing a book.
Project classification based on application areas.
This kind of project can be classified into the following type.

Construction type projects: The construction type of project produces artifacts, which means a useful or
decorative man-made object. The value generated by the project is embedded in the artifact. The
artifact may be a complex system with human and mechanical components. Some examples of
construction projects are IT Park, automobile industry, laying express highway, etc.
Research project : The research projects produce knowledge. The knowledge may be formally
represented as models, patterns or patents, empirical equations, etc. The knowledge is generally
embedded in a working process or artifact. Some examples of research projects are business
modeling, economic model, hybrid variety of paddy, complex algorithm to manage parallel
computers, etc.
Reengineering projects: Reengineering projects will bring a change in an existing system or process.
Some examples of reengineering projects are issuing voter ID cards to the citizens, computerized
land records, improved production processes, etc.
Procurement projects: A procurement project produces a contractually-based business relationship with a
selected supplier for a defined product or service on a fixed specification and/or a defined
specification process.
Some examples are, outsourcing a specific construction project or a research project, outsourcing
business functions, like payroll processing, recruitment of executives, etc.
Business implementation projects: This type of project produces an operationally effective process. The
value generated by the project is embedded in the process. The value generated by the project is
embedded in the process. Some examples of this type of projects are implementation of ERP
software in an automobile company, installing e-commerce system for a chain of stores, etc.

IMPORTANCE OF PROJECT MANAGEMENT

Some of the prime advantages of having a good project management team for a company are as follows.
Excellent product quality: Consumers generally look for low cost and high quality, while purchasing a
product. Maintaining a high standard of excellence in developing quality products earns the
company goodwill amongst its customers. How can a project management team help in improving
the quality of a product? The project management plans the allocated budget, resources and testing
methods that keep the pace of production high, both qualitatively and quantitatively. The project
management team can also undertake six sigma training programs that enhance the quality of the
products.
Adequate communication: Improper communication among employees can lead to misunderstandings
and negatively impact the performance of the firm. A project manager can be a bridge among the
diversified branches of project undertaking. Stakeholders also form a part of the company. They
prefer investing in those companies that deliver projects on time and keep them informed about
updates and progress of the projects. If a client is satisfied with the performance of the firm, it is
likely that it will return with much bigger projects, not to mention huge investments. A project
leader can hold meetings on a daily, weekly or monthly basis and can make sure that everyone is
aware about the project plan and his/her responsibilities, both as an individual and as a team. With
the help of human resource management department, project managers can be more effective in
communicating the expectations of the clients.
Reducing risks: The probability of getting hit by an unwanted or unexpected event has increased
manifold in today's competitive business environment. Why is project management so important?
The project management team can identify the potential risks, take their time to rectify them and
help the company save valuable resources. In case of worst crisis, the project management team
can opt for change management method to attain the desired goals. Team work is a must, when it
comes to visualizing the dangers ahead. Risk management principles can be applied by the project
managers to eliminate risks to a larger extent.

Strategic objectives and goals: Strategic goals are the blueprint of the task undertaken by a company. For
instance, a software company aims to prepare software and related programing codes, whereas an

infrastructure company has a target of constructing dams, bridges and other construction works. A
project management team helps the company in achieving the strategic goals, as it streamlines the
task of a company in taking many important decisions. Strategic planning and strategic thinking
are vital management tools for a project management team.
Once the task is allotted, the project team is responsible for the goal to be finished in the dedicated time.
Innovation is an area in which the project team can invest more and come out with new ideas that can
increase the sale and reputation of the firm. Human resource, financial planning, corporate social
responsibility and physical resources are other facets of strategic goals.
Project management is an essential segment in every organization. Be it, the small scale enterprises or
corporate giants, project management has the power to transform the market standing of a company and
help it soar high in the sky.
Other benefits are
- Successful delivery of the project
- Proven planning and agreement will enable to achieve agreed objectives
- There will be goal clarity and measurement
- The resources will be coordinated which will save costs and time
- The risks will be identified in advance and they will be managed well
- There will be time savings
- There will be cost savings
- The agreed deliverables will be achieved

AN INTEGRATIVE APPROACH
Introduction
As the world becomes more competitive, it is increasingly important to get it right the first time when
managing a project. Piecemeal project management system fails in a number of areas. They often fail to
tie to the overall strategies of the firm. Piecemeal priority systems fail to prioritized project selection and
allot resources to the projects that contribute most to the strategic plan. Piecemeal tools and techniques
fail to be integrated throughout the project life cycle. Piecemeal approaches failed to balance project
management with an organization culture.

Need for Integrative approach

Studies point out that about 30 to 45 percent of software development project fail before completion.
These kinds of projects often incur budget and schedule overruns in excess of 200 percent. Surveys
show failure to integrate project management processes, absence of management support, and a nonsupportive organization culture to be top reasons for projects failing to reach their objectives.

Fortunately many organizations are attempting to address these issues by creating an integrated approach
to project management. At the organizational level, they emphasize developing an integrated project
management process that focuses all efforts toward the strategic plan of the organization. At the
individual level, require project managers to master both project management tools/techniques and the
interpersonal skills necessary to orchestrate successful project completion

Integrative Approaches
For some organization, integrating projects with strategy requires reengineering the entire business
management process. For others, integration means carefully establishing links among the piecemeal
systems already in place to focus on one total system.
Integration in project management directs attention to three key areas.

Integration of projects with the strategic plan of the organization.

Mastering the process of managing actual projects.

Evolution of project-driven organization

Integration of projects with the strategic plan of the organization

Strategic plans are written by one group of managers, projects are selected by another group and projects
are implemented by a third and these independent decisions by different groups of managers create a set
of conditions that leads to conflict, confusion and frequently an unsatisfied customer. Under these
conditions, the resources of the organization are wasted in non-value-added activities/projects
An integrated project management system is one in which all of the parts are interrelated. Any
change in one of the parts will influence the whole. Every organization has a customer they are seeking
to satisfy. The mission, objectives and strategies are set to meet the needs of customer(s). Developing the
mission, objectives and organization strategies is dependent on

1. External environmental factors

2. Internal environmental factors.

And analyzing these factors becomes the first step. See the figure below:
Implementing strategies is the most difficult step and strategies are typically implemented through
projects. Creative minds always propose more projects than there are resources. This means prioritizing
projects so that scarce resources are allocated to the right projects. Once the project has been selected,
the focus should switch to the project management process that sets the stage for how the project will be
implemented or delivered.

Integrated Management of Projects

The Process of Managing Projects:

There are two dimensions within the project management process: technical and sociocultural
The Technical Dimension: the first dimension is the technical side of the management process, which
consists of the formal, disciplined, pure logic parts of the process. The technical side relies on the formal
information system available. This dimension includes planning, scheduling, and controlling projects.
Clear project scope statements should be written to link the project and customer, and to facilitate
planning and control. Creating the deliverable and work breakdown structures facilitates planning and
monitoring the progress of the project. The work breakdown structure serves as a database that links all
levels in the organization, major deliverables, and all work down to the tasks in a work package.
The impacts of project changes should be documented and traceable. So any change in one part of the
project is traceable to the source by the integrated linkages of the system. This integrated information
approach can provide all project managers and the customer with decision information appropriate to
their level and needs. A successful project manager will be well trained in the technical side of managing
projects. See figure below:

The technical and socio-cultural dimensions of the project management process

The Sociocultural Dimension: The second dimension is the sociocultural side of the project management
process. In the contrast with the orderly world of project planning, this dimension involves the much
messier, often contradictory, and paradoxical world of implementation. It centers on creating a
temporary social system within a larger organizational environment to combine the relents of a divergent
set of professional working to complete the project.
Project managers must shape a project culture that stimulates teamwork and high levels of personal
motivation as well as a capacity to quickly identify and resolve problems that threaten project work. This
dimension also involves managing the interface between the project and the external environment.
Project managers have to assess and shape expectations of customers, sustain the political support of top
management, negotiate with their functional counterparts, monitor subcontractors, and so on. Overall the
manager must build a cooperative social network among a divergent set of allies with different
standards, commitments, and perspectives.
Some suggest that the technical dimension represents the science of project management while the
sociocultural dimension represents the art of managing a project. To be successful, managers must be
a master of both. Unfortunately, some project managers become preoccupied with the planning and
technical dimension of project management. Often their first real exposure to project management is
through project management software, and they become infatuated with network charts, Gantt diagrams,
and performance variances and attempt to manager a project from a distance. Conversely, there are other
managers who manage projects by the seat of their pants, relying heavily on the team dynamics and
organizational politics to complete a project. Successful project managers balance their attention to both
the technical and sociocultural dimensions of project management.
Evolution of Project Driven Organizations: Many firms have found it useful to apply project
management maturity models as the foundation for directing and measuring progress toward
integration, developing the skills of project managers, and creating a supportive organization
culture. Project management maturity models have been around for some time for example the
capability maturity model (CMM) was developed in the late 1980s to guide organizations in
implementing concrete best practices of managing software development projects.
Figure below presents a typical schematic of a maturity model. Each level represents an advance in the
use of benchmarked project management best practices.

Capability Maturity Model(CMM)

Following is a short description of each level:

Level one: absence of, or unpredictability in, a process for developing a project plan that
includes cost, time and performance.

Level two: repeatable processes used primarily on large mission-critical projects

Level three: well-defined processes that are integrated with organization processes.

Level four: highest level with seamless, integrated, holistic project systems and processes that
includes strategic decisions that take into account project selection, plan, performance, and
lessons learned.

Lever five: continuous improvement by archiving and using lessons learned to improve project
management execution

Our best guess estimate is that most companies are in the throes of moving form level two to level three
and that less that 10 percent of those firms that actively practice project management are at level four or
five.

PROJECT PORTFOLIO MANAGEMENT

Introduction
Portfolio management is a system which ensures that projects are aligned with strategic goals and
prioritized appropriately. Portfolio management provides information to make better business decisions.
Since there are usually more projects competing for resources than are available, it is important to
follow a logical and defined process for selecting the projects to implement. Design of a project
portfolio system should include classification of a project, selection criteria depending upon
classification, sources of proposals, evaluating proposals and managing the portfolio of projects.

Project portfolio management:

An increasing number of organizations are using, what is referred to as, project portfolio management
(PPM) as a means of selecting the right projects and then using project management techniques as the

means for delivering the outcomes in the form of benefits to the performing private or not-for-profit
organization.
PPM is a term used by project managers and project management (PM) organizations, (or PMO's), to
describe methods for analyzing and collectively managing a group of current or proposed projects based
on numerous key characteristics.

Objective of PPM
The fundamental objective of PPM is to determine the optimal mix and sequencing of proposed projects
to best achieve the organization's overall goals - typically expressed in terms of hard economic
measures, business strategy goals, or technical strategy goals - while honoring constraints imposed by
management or external real-world factors. Typical attributes of projects being analyzed in a PPM
process include each project's total expected cost, consumption of scarce resources (human or otherwise)
expected timeline and schedule of investment, expected nature, magnitude and timing of benefits to be
realized, and relationship or inter-dependencies with other projects in the portfolio.

Challenges of Implementing PPM

The key challenge to implementing an effective PPM process is typically securing the mandate to do so.
Many organizations are culturally inured to an informal method of making project investment decisions,
which can be compared to political processes observable in the U.S. legislature. However this approach
to making project investment decisions has led many organizations to unsatisfactory results, and created
demand for a more methodical and transparent decision making process. That demand has in turn
created a commercial marketplace for tools and systems which facilitate such a process. Some
commercial vendors of PPM software emphasize their products' ability to treat projects as part of an
overall investment portfolio. PPM advocates see it as a shift away from one-off, ad hoc approaches to
project investment decision making. Most PPM tools and methods attempt to establish a set of values,
techniques and technologies that enable visibility, standardization, measurement and process
improvement. PPM tools attempt to enable organizations to manage the continuous flow of projects
from concept to completion.
Treating a set of projects as a portfolio would be, in most cases, an improvement on the ad hoc, one-off
analysis of individual project proposals. The relationship between PPM techniques and existing
investment analysis methods is a matter of debate. While many are represented as "rigorous" and
"quantitative", few PPM tools attempt to incorporate established financial portfolio optimization
methods like modern portfolio theory or Applied Information Economics, which have been applied to
project portfolios, including even non-financial issues.

The Need
Implementation of projects without a strong priority system linked to strategy creates problems. Few of
these problems maybe the implementation gap, organization politics, resource conflicts, multitasking,
etc. A project portfolio system can go a long way to reduce or even eliminate the impact of the above

mentioned problems. Hence, the need for a project portfolio system arises. Each of the problems are
discussed briefly below.
The Implementation Gap: In organizations with short product life cycles, it is interesting to note that
frequently participation in strategic planning and implementation includes participants from all
levels within the organization. However in most of the remaining product and service
organizations, top management formulates strategy and leaves implementation to functional
managers. Within these broad constraints, more detailed strategies and objectives are developed
by the functional managers. The fact that these objectives and strategies are made independently
at different levels by functional groups within the organization hierarchy causes manifold
problems. Some symptoms of organizations struggling with strategy disconnect and unclear
priorities are presented here.
Conflicts frequently occur among functional managers and cause lack of trust.
Frequent meetings are called to establish or renegotiate priorities.
People frequently shift from one project to another, depending on current priority. Employees are
confused about which project is important.
People are working on multiple projects and feel insufficient.
Resources are not adequate.
Because clear linkages do not exist, the organizational environment becomes dysfunctional, confused
and ripe for ineffective implementation of organization strategy and thus, of projects. Thus, the
implementation gap refers to lack of understanding and consensus of organization strategy among top
and middle-level managers.
Organization Politics: Politics exist in every organization and can have a significant influence on which
projects receive funding and high priority. This is especially true when the criteria and process
for selecting projects are ill-defined and not aligned with the mission of the firm. Project
selection maybe based not so much on facts and sound reasoning, but rather on the
persuasiveness and power of people advocating projects. The term sacred cow is often used to
denote a project that a powerful, high-ranking official is advocating. Having a project sponsor
can also play a significant role in the selection and successful implementation of product
innovation projects. Project sponsors are typically high ranking managers who endorse and lend
technical support for the completion of a specific project. They are instrumental in winning
approval and in protecting the project during the critical development stage. Many would argue
that politics and project management should not mix. A more proactive response is that projects
and politics invariably mix and that effective project managers recognize that any significant
project has political ramifications. Likewise, top management needs to develop a system for
identifying and selecting projects that reduces the impact of internal politics and fosters the
selection of the best projects for achieving the mission and strategy of the firm.
Resource Conflicts and Multitasking: Most project organizations exist in a multi project environment.
This environment creates the problems of project interdependency and the need to share
resources. The problems of sharing resources and scheduling resources across projects grow
exponentially as the number of projects rises. In multi project environments the stakes are higher
and the benefits or penalties for good or bad resource scheduling become even more significant
than in most single projects.
Resource sharing also leads to multitasking. Multitasking involves starting and stopping work on one
task to go and work on another project, and then returning to the work on the original task. People
working on several tasks concurrently are far less efficient, especially where conceptual or physical

shutdown and startup are significant. Multitasking adds to delays and costs. Changing priorities
exacerbate the multitasking problems even more.
The number of small and large projects in a portfolio almost always exceeds the available resources.
This capacity overload inevitably leads to confusion and inefficient use of scarce organizational
resources.
The presence of an implementation gap, of power politics and of multitasking adds to the problem of
which projects are allocated resources first. Employee morale and confidence suffer because it is
difficult to make sense of an ambiguous system. A multi project organization environment faces major
problems without a priority system that is clearly linked to the strategic plan.
Hence, what is needed is an effective Project Portfolio Management System.

PROJECT MANAGEMENT STRUCTURE

A project management system provides a framework for launching and implementing project activities
within a parent organization. A good system appropriately balances the needs of both the parent
organization and the project by defining the interface between the project and the parent organization in
terms of authority, allocation of resources and eventual integration of project outcomes into mainstream
operations.

Project Structure Types:

The different ways in which projects can be organized are as follows:
Organizing projects within the Functional Organization
One approach to organizing projects is to simply manage them within the existing functional hierarchy
of the organization. Once management decides to implement a project, the different segments of the
project are delegated to the respective functional units with each unit responsible for completing its
segment of the project. This method is also commonly used when, given the nature of the project, one
functional area plays a dominant role in completing the project or has a dominant interest in the success
of the project.

Organizing projects as Dedicated Teams

Projects can also be organized by creating independent project teams. These teams operate as separate
units from the rest of the parent organization. Usually a full-time project manager is designated to pull
together a core group of specialists who work full time on the project. The interface between the parent
organization and the project teams will vary. In some cases, the parent organization prescribes
administrative and financial control procedures over the project. In other cases, firms allow the project
manager maximum freedom to get the project done, given the resources originally assigned to it.

Organizing projects within a matrix arrangement

Matrix management is a hybrid organizational form in which a horizontal project management structure
is overlaid on the normal functional hierarchy. In a matrix system, there are usually two chains of
command, one along functional lines and the other along project lines. Instead of delegating segments of
a project to different units or creating an autonomous team, project participants report simultaneously to
both functional and project managers. This structure is designed to optimally utilize resources by having
individuals work on multiple projects as well as being capable of performing normal functional duties.
Organizing projects within Network Organizations
Corporate downsizing and cost control have combined to produce what we call network organizations.
In theory, it is an alliance of several organizations for the purpose of creating products or services for
customers. The key organizing principle is that, instead of doing everything in-house, a firm can
outsource key activities to other businesses with the requisite competencies.

Organizational structure consists of activities such as task allocation, coordination and supervision,
which are directed towards the achievement of organizational aims. It can also be considered as the
viewing glass or perspective through which individuals see their organization and its environment. Many
organizations have hierarchical structures, but not all. Organizations are a variant of clustered entities.

An organization can be structured in many different ways, depending on their objectives. The structure
of an organization will determine the modes in which it operates and performs. Organizational structure
allows the expressed allocation of responsibilities for different functions and processes to different
entities. Organizational structure affects organizational action in two big ways. First, it provides the
foundation on which standard operating procedures and routines rest. Second, it determines which
individuals get to participate in which decision-making processes, and thus to what extent their views
shape the organizations actions.
Considerations For Devising A Structure For Project:
The Project Management Office (PMO) is widely recognized as one of the most effective business
practices used by successful organizations.
To ensure the success of your project office, take the time now to look at your organization, and match
the right PMO structure with your organizations culture and goals.
Organization Considerations:
At the organization level, the first question that needs to be asked is How important is the project
management to the success of the firm? What percentage of core work involves projects? If over 75% of
work involves projects, then an organization should consider a fully projectized organization. If an
organization has both standard products and projects, then a matrix arrangement would appear to be
appropriate. If an organization has very few projects, then a less formal arrangement is required.
Temporary task forces could be created on an as-needed basis and the organization could outsource
project work.
A second key question is resource availability. Matrix evolved out of the necessity to share
resources across multiple projects and functional domains while at the same time creating legitimate
project leadership. For organizations that cannot afford to tie up critical personnel on individual projects,
a matrix system would appear to be appropriate. An alternative would be to create a dedicated team but
outsource project work when resources are not available internally.
Considering the first two questions, an organization needs to assess current practices and what
changes are needed to be more effectively manage projects. A strong, project matrix is not installed
overnight. The shift toward a greater emphasis on projects has a host of political implications that need
to be worked through, requiring time and strong leadership. For example, we have observed many
companies that make the transition from a functional organization begin with a weak, functional matrix.
This is due in part to resistance by functional and department managers toward transferring authority to
project managers. With time, these matrix structures eventually evolve into a project matrix. Many
organizations have created Project Management Offices to support project management efforts.
Project considerations:
At the project level, the question is how much autonomy the project needs in order to be successfully
completed. Hobbs and Menard identify seven factors that should influence the choice of project
management structure:
1. Size of project
2. Strategic importance

3. Novelty and need for innovation

4. Need for integration (number of departments involved)
5. Environmental complexity (number of external interfaces)
6. Budget and time constraints
7. Stability of resource requirements
The higher the levels of these seven factors, the more autonomy and authority the project
manager and project team need to be successful. This translates into using either a dedicated project
team or a project matrix structure. For example, these structures should be used for large projects that
are strategically critical and are new to the company, thus requiring much innovation. These structures
would also be appropriate for complex, multidisciplinary projects that require input from many
departments, as well as for projects that require constant contact with consumers to assess their
expectations. Dedicated project teams should also be used for urgent projects in which the nature of the
work requires people working steadily from beginning to end.

STEPS IN DEFINING THE PROJECT

One of the best ways to meet the needs of the customer and major project stakeholders is to use an
integrated project planning and control system that requires selective information. Project managers who
manage a single, small project can plan and schedule the project tasks without a formal planning and
information system. However, when project managers must manage several small projects or a large,
complex project, they quickly reach a threshold where they can no longer cope with the level of detail.
This chapter describes a disciplined, structured method for selectively collecting information to use
through all phases of the project life cycle, to meet the needs of all stakeholders (e.g ., customer, project
manager), and to measure performance against the strategic plan of the organization. The method
suggested is a selective outline of the project called the work breakdowns structure (WBS). The early
stages of developing the outline serve to ensure that all tasks are identified and that participants in the
project have an understanding of what is to done.
Once the outline and its details are defined, an integrated information system can be developed to
schedule work and allocate budgets. This baseline information is later used for control.
The five generic steps provide a structured approach for collecting the project information that is
necessary for planning, scheduling, and controlling the project. These steps and the development of
project networks found in the next chapters all take places concurrently, and several iterations are
typically required to developed dates and budgets that can be used for control of the project. The old
saying, We can control only what we have planned, is true; therefore, defining the project is the first
step.
Step 1: Defining the Project Scope
Defining the project scope sets the stage for developing a project plan. Project scope is a definition of
the end result or mission of your project a product or service for your client or customer. The primary

purpose is to define as clearly as possible the deliverable(s) for the end user and to focus project plans.
As fundamental and essential as scope definition appears, it is frequently overlooked by project leaders
of well- managed, large corporations.
Research clearly shows that a poorly defined scope or mission is the most frequently mentioned barrier
to project success. Smith and Tuckers Study of a large petroleum refinery plant project found that poor
scope definition for major segments of the project had the greatest negative impact on cost and schedule.
Pinto and Slevin found that a clear mission statement is a predictor of more than 50 percent of project
success in the concept, planning, and execution stages of the project. Ashley et al., found outstanding,
successful projects exhibit clear scope and work definitions. A survey by Posner found lack of clear
goals as a major problem mentioned by more than 60 percent of project manager respondents. In a large
study of more than 1400 project managers in the United states and Canada, Gobeli and Larson found
that approximately 50 percent of the planning problems relate to unclear definition of scope and goals.
These studies suggest a strong correlation between project success and clear scope definition. The scope
document directs focus on the project purpose throughout the life of the project for the customer and
project participants.
The scope should be developed under the direction of the project manager and customer. The project
manager is responsible for seeing that there is agreement with the owner on project objectives,
deliverables at each stage of the project, technical requirements, and so forth. For example, a deliverable
in the early stage might be specifications; for the second stage, three prototypes for production; for the
third, a sufficient quantity to introduce to market; and finally, marketing promotion and training.
Your project scope definition is a document that will be published and used by the project owner and
project participants for planning and measuring project success. Scope describes what you expect to
deliver to your customer when the project is complete. Your project scope should define the results to be
achieved in specific, tangible and measurable terms.

Employing a Project Scope Checklist:

Clearly, project scope is the keystone interlocking all elements of a project plan. To ensure that scope
definition is complete, you may wish to use the following checklist:
Project Scope Checklist
Project objectives
Deliverables
Milestones
Technical requirements
Limits and exclusions
Reviews with customer
Project objectives. The first step of project scope definition is to define the major objectives to meet
your customers need(s). For example, as a result of extensive market research a computer software

company decides to develop a program that automatically translates verbal sentences in English to
Russian. The project should be completed within 3 years at a cost not to exceed $1.5 million.
Deliverables. The next step is to define major deliverables- the expected outputs over the life of the
project, For example, deliverables in the early design phase of a project might be a list of specifications.
In the second phase deliverables could be software coding and be final tests and approved software.
Deliverables typically include time, quantity and cost estimates.
Milestones. A milestone is a significant event in a project that occurs at a point in time. The milestone
schedule shows only major segments of work; it represents first, rough-cut estimates of time, cost, and
resources for the project. The organizational units may be internal or external- for example, companies
may rely on consultants to randomly test a new drug.
Technical requirements. More frequently than not, a product or service will have technical requirement
to ensure proper performance. For example is the ability of 911 emergency systems to identity the
callers phone number and location.
Limits and exclusions. The limits of scope should be defined. Failure to define limits can lead to false
expectations and to expending resources and time on the wrong problem. Examples include: data will be
collected by client, not the contractor; a house here will be built, but no landscaping or security devices;
software will be installed, but no training given.
Reviews with customer. Completion of the scope checklist ends with a review with your customerinternal or external. The main concern here is the understanding and agreement of expectations. Is the
customer getting what he or she desires in deliverables? Does the project definition identify key
accomplishments, budgets, timing, and performance requirements? Are questions of limits and
exclusions covered? Clear communication in all these issues is imperative to avoid claims or
misunderstanding.
The Six points above constitute a generic scope checklist. Different industries and companies will
develop unique checklists and templates to fit their needs and specific kinds of projects. Many
companies engaged in contracted work refer to scope statements as statements of work (SOW ). Other
organizations use the term project charter. However project charter has different meanings in the world
of project management. One meaning is above that might include such items as risk limits, customer
needs, spending limits and even team composition. A second meaning, which dates back to the original
use of the word charter , is a document that is used to legitimize the authority of the project manager
to initiate and lead the project. This may take the form of a simple announcement that the project has
been approved by top management has approved the project and Jane Doe is in charge, In other cases it
may include a scope statement with a statement of the business case(why the project is important) and a
priority ranking. In either case, authority is transferred to the project manager not only formally by the
charter, but also informally by the stature of the sponsors of the project.
In summary, close liaison with your customer is necessary to develop a project definition that meets all
the requirements of the customer. Clear scope definition ensures you will know when a change in scope
occurs. A clear project scope definition is the primary prerequisite for development of your work
breakdown structure. Scope definition provides an administrative plan that is used to develop your

operational plan. Scope definition should be as brief as possible but complete; one or two pages are
typical for small projects.
Step 2: Establishing Project Priorities
Quality and the ultimate success of a project are traditionally defined as meeting and/or exceeding the
expectations of the customer and/or upper management in terms of cost, time, and performance of the
project. The interrelationship among these criteria varies. For eg. Sometime it is necessary to
compromise the performance and scope of the project to get the project done quickly or less
expensively. Often, the longer a project takes, the more expensive it becomes. However, a positive
correlation between cost and schedule may not always be true. Sometimes project costs can be reduced
by using cheaper, less efficient labor or equipment that extends the duration of the project.
One of the primary jobs of a project manager is to manage the trade-offs among time, cost, and
performance. To do so, project managers must define and understand the nature of the priorities of the
project. They need to have a candid discussion with the project customer and upper management to
establish the relative importance of each criterion. One technique that is useful for this purpose is
completing a priority matric for the project that identifies which criterion is constrained, which should
be enhanced, and which can be accepted:
Constrain: the original parameter is fixed. The project must meet the completion date, specification and
scope of the project or budget.
Enhance: Given the scope of the project, which criterion should be optimized? In case of time and cost,
this usually means taking advantage of opportunities either to reduce costs or shorten the schedule.
Conversely, with regard to performance, enhancing means adding value to the project.

Project Management Trade-off:

Project Priority Matrix

Accept: For which criterion is it tolerable not to meet the original parameter? When trade-offs have to be
made, is it permissible for the schedule to slip, to reduce the scope and performance of the project, or to
go over budget?
Figure above displays the priority matrix for the development of a new high speed modem. Since time to
market is important to sales, the project manager is instructed to take advantage of every opportunity to
reduce completion time. In doing so, going over cost is acceptable, though not desirable. At the same
time, the original performance specifications for the modem as well as reliability standards cannot be
compromised.
Priority varies from project to project. For example, for many software projects time to market is critical
and companies like Microsoft may defer original scope requirements to later versions in order to get to
the market first. Alternatively, for special event projects (conferences, parades, tournaments) time is

constrained once the date has been announced, and if the budget is tight, the project manager will
compromise the scope of the project in order to complete the project on time.
Some would argue that all there criteria are always constrained and that good project managers should
seek to optimize each criterion. If everything goes well on a project and no major problems or setbacks
are encountered, their argument may be valid. However, this situation is rare and project managers are
often forced to make tough decisions that benefit one criterion while compromising the other two. The
purpose of this exercise is to define and agree on what the priorities and constraints of the project are so
that when push comes to shove, the right decisions are made.
There are likely to be natural limits to the extent managers can constrain, optimize or accept any one
criterion. It may be acceptable for project to slip 1 month behind schedule but no further or to exceed the
planned $20000. Likewise, it may be desirable to finish a project 1 month early, but after that cost
conservation should be the primary goal. Some project managers document these limits as part of
creating the priority matrix.
In summary, developing a decision priority matrix for a project is useful exercise. It provides a forum for
clearly establishing priorities with customers and top management so as to create shared expectations
and to avoid misunderstandings. The priority information is essential to the planning process, where
adjustments can be made in the scope, schedule, and budget allocation. Finally, the matrix provides a
basis for monitoring and evaluating progress so that appropriate corrective action can be taken. Still, one
caveat must be mentioned: during the course of a project, priorities may change. The customer may
suddenly need the project completed 1 month sooner, or new directives from the top management may
emphasize cost saving initiatives. The project manager needs to be vigilant in order to anticipate and
confirm changes in priorities and make appropriate adjustments.
Step 3: Creating the Work Breakdown Structure
Once the scope and deliverables have been identified, the work of the project can be successively
subdivided into smaller and smaller work elements. The outcome of this hierarchical process is called
the work breakdown structure (WBS). The WBS is a map of the project. Use of a WBS helps to assure
project managers that all products and work elements are identified, to integrate the project with current
organization, and to establish a basis for control. Basically, the WBS is an outline of the project with
different levels of detail. The figure shows the major groupings commonly used in the field to develop a
hierarchical WBS.

Hierarchical Breakdown for WBS

The WBS begins with the project as the final deliverable. Major project work deliverables/systems are
identified first; then the sub deliverables necessary to accomplish the larger deliverables are defined. The
process is repeated until the deliverable details are small enough to be manageable and one person can
be responsible. This sub deliverable is further divided into work packages. Because the lowest sub
deliverable usually includes several work packages, the work packages are grouped by type of work
for example, hardware, programming, and testing. These groupings within a subdeliverable are called
cost accounts, this groupings facilitates a system for monitoring project progress by work and
responsibility.
The hierarchical structure later provides management with a database for planning, executing,
monitoring, and controlling the work of the project. In addition, the hierarchical structure provides
management with information appropriate to each level. For example, top management deals primarily
with major deliverables, while first-line supervisors deal with smaller subdeliverables and work
packages.

How a WBS helps the project manager?

The WBS defines all the elements of the project in a hierarchical framework and establishes their
relationships to the project end item(s). Think of the project as a large work package that is
successively broken down into smaller work package; the total project is the summation of all
the smaller work packages. This hierarchical structure facilitates evaluation of cost, time, and
technical performance at all levels in the organization over the life of the project.

While WBS is developed, organizational units and individuals are assigned responsibility for
accomplishment of work packages. This integrates the work and the organization. In practice,
the process is sometimes called OBS, the organization breakdown structure, which will be
discussed later in the chapter.

WBS makes it possible to plan, schedule, and budget. It gives a framework for tracking cost and
work performance. Use of the structure provides the opportunity to rollup (sum) the budget

and actual costs of the smaller work packages into larger work elements so that performance can
be measured by organizational units and work accomplishment.

The WBS defines communication channels and assists in understanding and coordinating many
parts of the project. The structure shows the work and organizational units responsible and
suggests where written communication should be directed. Problems can be quickly addressed
and coordinated because the structure integrates work and responsibility.

WBS Development
Figure below shows a simplified WBS for development of a new Voice Data Recognition project to be
used by field personal to collect and analyze data. At the top of the chart (level 1) is the project end item
a deliverable product or service. Note how the levels of the structure can represent information for
different levels of management. For example, level 1 information represents the total project objectives
and is useful to top management; levels 2, 3, and 4 are suitable for middle management; and level 5 is
for first-line managers.
Level 2 shows a partial list of deliverables necessary to develop the new productDesign
Specifications, Software Development, Integration, Hardware Installation, and Test.

Work Breakdown Structure

The Software Development deliverable (shaded) has been extended down to level 5 work packages.
Level 4 subdeliverables represent the lowest manageable elements of the project. Each subdeliverables
requires work packages that will be completed by an assigned organizational unit. Each deliverable will
be successively divided in the manner. It is not necessary to divide all elements of the WBS to the same
level.
The lowest level of the WBS is called a work package. Work project are short-duration tasks that have a
definite start and shop point, consume resources, and represent cost. Each work project is a control
point. A work project manager is responsible for seeing that the package is completed on time, within
budget, and according to technical specifications. Practice suggests a work package should not exceed
10 work days or 1 reporting period. If a work package has a duration exceeding 10 days, check or
monitoring points should be established within the fore too much time has passed. Each work package

of the WBS should be as independent of other packages of the project as possible. No work package is
described in more than one subdeliverable of the WBS.
There is an important difference between the last work breakdown subdeliverable and a work package.
Typically, a work breakdown subdeliverable includes the outcomes of more than one work package from
perhaps two or three departments. Therefore, the subdeliverable does not have duration of its own and
does not consume resources or cost money directly. (In a sense, of course, duration for a particular work
breakdown element can be derived from identifying which work package must start first [earliest] and
which package will be the latest to finish; the difference becomes the duration for the subdeliverable.)
The resources and costs for the subdeliverable are simply the summation of the resources and costs for
all the work packages in the work package, costs and resources can ne rolled up into the higher
elements. The higher elements are used to identify the execution stage of the project life cycle. Thus,
the work package is the basic unit used for planning, scheduling, and controlling the project.
To review, each work package in the WBS
Defines work (what).
Identifies time to complete a work package (how long).
Identifies a time-phased budget to complete a work package (cost).
Identifies resources needed to complete a work package (how much).
Identifies a single person responsible for units of work (who).
Identifies monitoring points for measuring progress.
Creating a WBS from scratch can be daunting task. Project managers should take advantage of relevant
examples to facilitate the process. WBSs are products of group efforts. It the project is small, the entire
project team may be involved breaking down the project into its components. For large, complex
projects the people responsible for the major deliverables are likely to meet to establish the first two
levels of deliverables. In turn, further detail would be delegated to the people responsible for the
specific work. Collectively this information would be gathered and integrated into a formal WBS by a
project support person. The final version would be reviewed by the inner echelon of the project team.
Relevant stakeholders (most notably customers) would be consulted to confirm agreement and revise
when appropriate.
Project managers developing their first WBS frequently forget that the structure should be end-item,
output oriented. First attempts often result in a WBS that follows the organization structuredesign,
marketing, production, finance. If a WBS follows the organization structure, the focus will be on the
organization function and processes rather than the project output or deliverables. In addition, a WBS
with a process focus will become an accounting tool that records costs by function rather than a tool for
output management. Every effort should be made to develop a WBS that is output oriented in order to
concentrate on concrete deliverables. Organizational unit responsibility can be tied to the WBS by
grouping the work packages of a deliverable into a cost account while still maintaining the focus on
completing the deliverable. The process is discussed next.
Step 4: Integrating the WBS with the Organization

An integral part of creating the WBS is to define the organizational units responsible for performing the
work. In practices, the outcome of this process is the organization breakdown structure (OBS). The
OBS depicts how the firm has organized to discharge work responsibility. The purposes of the OBS are
to provide a framework to summarize organization unit work performance, to identify organization units
responsible for work packages, and to tie the organizational unit to cost control accounts. Recall, cost
accounts group similar work packages (usually under the purview of a department). The OBS defines
the organization subdeliverables in a hierarchical pattern in successively smaller and smaller units.

Integration of WBS and OBS

Frequently, the traditional organization structure can be used. Even if the project is performed entirely
by a team, it is necessary to break down the team structure for assigning responsibility for budgets, time,
and technical performance.
As in the WBS, the OBS assigns the lowest organizational unit the responsibility for work packages
within a cost account. Herein lies one major strength of using WBS and OBS; they can be integrated as
shown in Figure 4-5. The intersection of work packages and the organizational unit creates a project
control point (cost account) that integrates work and responsibility. The intersection of the WBS and
OBS represents the set of work packages necessary to complete the subdeliverable located immediately
above and the organizational unit on the left responsible for accomplishing the packages at the
intersection. Later we will use the intersection as a cost account of management control of projects. For
example, the department is responsible for the work packages in two cost accountsunder deliverables
Interface Vendor Analysis Software and Voice Recognition. Control can be checked from two directions
outcomes and responsibility. In the execution phase of the project, progress can be tracked vertically
on deliverables (clients interest) and tracked horizontally by organization responsibility (managements
interest). Although it is possible to graphically show an integrated WBS/OBS (e.g., Figure 4-5) for
demonstration purposes, software programs do not draw diagrams as we have shown. The graphic
output requirements for large projects make such graphic descriptions impractical by sheer size alone.

Typical software packages allow project managers to sort by WBS and/or OBS, which simply presents
the information in another formcolumns or lists. See the tables below

Work Packages Sorted by WBS

Work Packages Sorted by OBS

Step 5: Coding the WBS for the Information System
Gaining the maximum usefulness of a breakdown structure depends on a coding system. The codes are
used to define levels and elements in the WBS, organization elements, work packages, and budget and
cost information. The codes allow reports to be consolidated at any level in the structure. The most
commonly used scheme in practice is numeric indention. An example for our Voice Data Recognition
project and the Software Development deliverable in Figure is presented below:

Note the project identification is 1.0. Each successive indention represents a lower element or work
package. Ultimately the numeric scheme reaches down to the work package level, and all tasks and

elements in the structure have an identification code. The cost account is the focal point because all
budgets, work assignments, time, cost, and technical performance come together at this point.
This coding system can be extended to cover large projects. Additional schemes can be added for special
reports. For example, adding a -3 after the code could indicate a site location, an elevation, or a special
account such as labor. Some letters can be used as special identifier, such as M for material or E for
engineers. You are not limited to only 10 subdivisions (0-9); ou can extend each subdivision to large
numbers for example, .1-.99 or .1-.9999. If the project is small, you can use whole numbers. The
following example is from a large, complex project:
3R-237A-P2-3.6
3R identifies the facility, 237A represents elevation and the area, P3 represents pipe two inches wide,
and 33.6 represents the work package number. In practice most organizations are creative in combining
letters and numbers to minimize the length of WBS codes.
PROJECT ROLLUP
Figure shows hypothetical labor costs and work packages for the schematic diagram deliverable of the
Voice Data Recognition project. The intersection of the systems engineering and programming shows
fiver work packages in the cost account with budgets of $18, $12, $10, $13, and $7, which total $60.
Rollup to the programming element (summation of all cost accounts below the element) is $95. The
schematic diagram element that includes all first level elements has a budget of $185. The rollup for the
organizational units operates in a similar fashion. For example, the systems engineering department has
responsibility for the work packages found in interface vendor analysis software, voice recognition, and
programming cost accounts. These accounts each have a labor budget of $15, $15, and $60 respectively,
or a total of $90. The test department has a total budget of $55. Of course the total for the organization
units delivering the schematic diagram element is the same as the total budge of all elements rolled up to
the schematic diagram element. This ability to consolidate and integrate using the rollup process
demonstrates the potential value of the WBS for managing the project. Remember, the units do not have
to be money; the units can be resources, labor hours, materials, time, or any units that contribute to the
completion of deliverables. However at the cost account level the units have to be the same throughout
the structure.

Direct Labor Budget Rollup

PROCESS BREAKDOWN STRUCTURE
The WBS is best suited for design and builds projects that have tangible outcomes, such as an offshore
mining facility or a new car prototype. The project can be decomposed or broken down into major
deliverables, subdeliverables, further subdeliverables, and ultimately to work packages. It is more
difficult to apply WBS to less tangible, process-oriented projects in which the final outcome is a product
of a series of steps or phases. Here the big difference is that the project evolves over time with each
phase affecting the next phase. IT projects typically fall in this category for example, creating an
extranet Web site or an internal software database system. These projects are driven by performance
requirements, not by plans or blueprints. Some practitioners choose to utilize what we refer to as a
Process Breakdown Structure (PBS) instead of the classic WBS.
Figure provides an example of a PBS for a software development project. Instead of being organized
around deliverables, the project is organized around phases. Each of the five major phases can be broken
down into more specific activities until a sufficient level of detail is achieved to communicate what
needs to be done to complete that phase. People can be assigned to specific activities and a
complementary OBS can be created just as is done for the WBS. Deliverables are not ignored but are
defined as outputs required moving to the next phase.

PBS for software development project

Checklists that contain the phase exit requirements are developed to manage project progress. These
checklists provide the means to support phase walk-throughs and reviews. Each phase checklist defines
the exit requirement for a phase. Checklists vary depending upon the project and activities involved but
typically include the following details:

Deliverables needed to exit a phase and begin a new one.

Quality checkpoints to ensure that deliverables are complete and accurate.

Sign-off by all responsible stakeholders to indicate that the phase has been successfully completed and
that the project should move on to the next phase.
As long as exit requirements are firmly established and deliverables for each phase are well-defined, the
PBS provides a suitable alternative to the WBS for projects that involve extensive development work.

RESPONSIBILITY MATRICES
In many cases, the size and scope of the project do not warrant an elaborate WBS or OBS. One tool that
is widely used by project managers and task force leaders of small projects is the responsibility matrix
(RM). The RM (sometimes called a linear responsibility chart) summarizes the tasks to be accomplished
and who is responsible for what on a project. In its simplest form an RM consists of a chart listing all the
project activities and the participants responsible for each activity. For example, Figure illustrates an RM
for a market research study. In this matrix the R is used to identify the committee member who is
responsible for coordinating the efforts of other team members assigned to the task and making sure that
the task is completed. The S is used to identify members of the five-person team who will support and/or
assist the individual responsible. Simple RMs like this one are useful not only for organizing and
assigning responsibilities for small projects but also for subprojects of large, more complex projects.

Responsibility matrix for a Market Research Project

More complex RMs not only identifies individual responsibilities but also clarify critical interfaces
between units and individuals that require coordination.
Responsibility matrices provide a means for all participants in a project to view their responsibilities and
agree on their assignments. They also help clarify the extent or type of authority exercised by each
participant in performing an activity in which two or more parties have overlapping involvement. By
using an RM and by defining authority, responsibility, and communications within its framework, the
relationship between different organizational units and the work content of the project are made clear.

EXTERNAL CAUSES OF DELAY AND INTERNAL CONSTRAINTS

Among all possible inefficiencies of the project, project delays are considered to be of utmost
importance. Hence, in this section, the types of project delays and their causes are presented.
The project delays are classified into internal delays and external delays. These are explained in the
following subsections.
Internal Delays
The causes of internal delays are mainly due to some lapses on the part of the management in controlling
project resources and coordinating the project activities.
The different types of resources that are used in projects are as listed below.

Materials and subassemblies

Equipment

Manpower

Money

Materials and subassemblies

A project will require different types of materials and subassemblies which will be sourced from
different vendors who are located in different places. The fact that the materials are sourced from
different vendors, each vendor will be supplying the materials to different projects of its customers. As a
result, the vendor will set priorities for its customers which will delay the supply of materials and
subassemblies to a customer with low priority. Hence, while fixing a vendor to supply materials and
subassemblies to a project, the project firm should clearly spell out the terms and conditions of
procurement of those items from that vendor, such that the vendor fixes the required priority for smooth
supply of necessary items in time as per the schedule of the project.
If the distance of the vendor from the project firm is maximum, then other reasons for the delays
while shipping items from vendors site to project site are as follows.

Bad road condition

High road traffic

Unforeseen regional problems like, strike, etc.

Environmental calamities, like rain, storm, earthquake, etc.

If the raw materials and subassemblies are imported, then there will be delay due to known reasons I
international shipping, which are as mentioned earlier for indigenous sourcing and clearing the items
from ports.
Equipment
In many projects, several equipment costing lakhs of rupees will be installed. Such equipment
assembled/produced by some supplier firms will have certain lead time to arrive at the site of the project
firm. Like the delay at project site, there will be delays at supplier site while producing the equipment.
Hence, the officials of the project firm should make periodical visit to such supplier firms to monitor the
progress of the order which will keep the suppliers on their toes in fulfilling the orders.

Manpower
Almost all the projects are manpower-intensive projects. The manpower may be classified into technical
and non-technical grades. The non-technical grades can be further divided into skilled, semi-skilled and
unskilled. If we take the example of commissioning of a power plant. The technical and the skilled grade
of non-technical are sourced on permanent basis. The remaining grades of the non-technical category
will sourced on contract or casual basis. But, the number of labors required in such categories will be
very high. The demand for such people may not be uniform throughout the project cycle. So, there will
be a challenge in planning for such people in sufficient numbers during the project cycle. If there is
shortage of people at any stage of the project, due to the precedence constraints amongst the activities,
the progress of the project will be stopped for some time. Once can avoid such problem, if the project
firm has multiple projects. On such reality they can be utilized. By way of using very good resource
leveling techniques applied to multi-projects, such delay can minimized.
Money
It is a vital aspect in any project. The project cycle time may be f several months or few years. To source
all other resources, the project firm has to make timely arrangement for the availability of money in
appropriate quantities, for the following.

Making payment to the suppliers

Payments of project team members salaries

Payment of electricity bills

Payments towards rent for equipment and other accessories hired for the project

There will be some credit limit and also time limit for making payments towards such supplies and
services beyond which the respective supplies and services may not be available which will hamper the
progress of the project. Hence, the project firm should have a detailed capital sourcing plan so that the
total interest paid is minimized and the goodwill from service providers and suppliers is maximized,
which will keep a smooth project progress.

External delays
Several external agencies are involved in sanctioning the project and giving clearance at several stages
of the project. After taking a decision to execute the project, one has to consider the following factors
while selecting the site for the project.
Political stability of the state
Culture of the people in the neighborhood
Availability of water and electricity
Analyzing the tax benefits

Steps To Be Taken During Project Delays

Step 1: Focusing the project team
Step 2: Prioritizing the tasks

Step 3: Reducing the scope of the project

Step 4: Increasing resource
Step 5: Communicating the delay

UNIT 2
OPPORTUNITY STUDY
This preliminary stage allows the parties to study the project request and decide whether the concept is
viable. The purpose of this first stage is to validate the users' request compared to the general objectives
of the organization.
It consists of defining the scope of the project (also known as context), in particular to determine the end
users, i.e., those for whom the work is intended (referred to as targeting or profiling). Thus, at this stage
of the project, it is useful to fit the users into the global considerations.
During the opportunity phase, the general needs of the client must be identified. It is necessary to make
sure that these needs correspond to expectations of all target users and that they take into account the
probable developments in needs.
The opportunity study leads to the drafting of a document called the "scoping note", validated by the
Steering Committee of the project (if applicable, the decision-making bodies, depending on the goal of
the project). Therefore, the scoping note is the deliverable of the opportunity study, which formalizes the
intent of the project.
Once the idea of the project is formalized, the Steering Committee must formalize the assignment of the
project manager and determine the terms and conditions. The assignment (assignment note) is the
document that formalizes the assignment of the project manager.

THE PROJECT LIFE CYCLE

The project manager and project team have one shared goal: to carry out the work of the project for the
purpose of meeting the projects objectives. Every project has beginnings, a middle period during which
activities move the project toward completion, and an ending (either successful or unsuccessful). A
standard project typically has the following four major phases (each with its own agenda of tasks and
issues): initiation, planning, execution, and closure. Taken together, these phases represent the path a
project takes from the beginning to its end and are generally referred to as the project life cycle.
INITIATION PHASE
During the first of these phases, the initiation phase, the project objective or need is identified; this can
be a business problem or opportunity. An appropriate response to the need is documented in a business
case with recommended solution options. A feasibility study is conducted to investigate whether each
option addresses the project objective and a final recommended solution is determined. Issues of
feasibility and justification are addressed.
Once the recommended solution is approved, a project is initiated to deliver the approved solution and a
project manager is appointed. The major deliverables and the participating work groups are identified
and the project team begins to take shape. Approval is then sought by the project manager to move on
the detailed planning phase.
The preparatory phase of a Project:
The term preliminary project is generally used to refer to all preparatory stages necessary for the launch
of the project. Thus, the idea is to precisely define the nature of the project in order to finalize the
contractual documents (preparing for a contract), allowing for a commitment of the contractor and the
client.
The projects launch Phase:
In this phase, the decision to begin the project is formalized.
Opportunity study:

This preliminary stage allows the parties to study the project request and decide whether the concept is
viable. The purpose of this first stage is to validate the users' request compared to the general objectives
of the organization.
It consists of defining the scope of the project (also known as context), in particular to determine the end
users, i.e., those for whom the work is intended (referred to as targeting or profiling). Thus, at this stage
of the project, it is useful to fit the users into the global considerations.
During the opportunity phase, the general needs of the client must be identified. It is necessary to make
sure that these needs correspond to expectations of all target users and that they take into account the
probable developments in needs.
The opportunity study leads to the drafting of a document called the "scoping note", validated by the
Steering Committee of the project (if applicable, the decision-making bodies, depending on the goal of
the project). Therefore, the scoping note is the deliverable of the opportunity study, which formalizes the
intent of the project.
Once the idea of the project is formalized, the Steering Committee must formalize the assignment of the
project manager and determine the terms and conditions. The assignment (assignment note) is the
document that formalizes the assignment of the project manager.
Feasibility study:
The feasibility study seeks to analyze the economic, organizational, and technical feasibility of the
project.
Technical Feasibility Study:
The Technical Feasibility Study assesses the details of how you will deliver a product or service (i.e.,
materials, labor, transportation, where your business will be located, technology needed, etc.). Think of
the technical feasibility study as the logistical or tactical plan of how your business will produce, store,
deliver, and track its products or services.
A technical feasibility study is an excellent tool for trouble-shooting and long-term planning. In some
regards it serves as a flow chart of how your products and services evolve and move through your
business to physically reach your market.
The Technical Feasibility Study Must Support Your Financial Information Do not make the mistake of
trying to entice investors with your staggering growth projections and potential returns on their
investment that only includes income (revenue) to the business. With any increase in revenue there is
always an increase in expenses. Expenses for technical requirements (i.e., materials and labor) should be
noted in the technical feasibility study.
You should also not strictly rely on feasibility study conclusions to impress an investor. An experienced
investor or lending institution will read your entire report and come to their own conclusions. Therefore,
it is critical that the technical and financial data in your study reconcile. If other parts of your feasibility
study shows growth, you will also have to project labor and other costs and the technical ability to
support that growth. The technical component serves as the written explanation of financial data because
if offers you a place to include detailed information about why an expense has been projected high or
low, or why it is even necessary. It demonstrates to potential investors and lenders (and in some cases,
potential clients) that you have thought about the long-term needs your business will have as it grows.
Preparing an Outline for Writing Your Technical Feasibility Study:
The order that you present technical information is not as important as making sure you have all the
components to show how you can run your business. You do not have to include specific financial
information in the technical portion of your feasibility study, but all information in this component must
support your financial data represented elsewhere. Basic things that most businesses need to include in
their technical feasibility study include- Materials, Labor, Transportation or Shipping, Physical Location,
AND Technology
Calculating Material Requirements:

In this section you list the materials you need to produce a product or service, and where you will get
those materials. Include information such as if volume discounts will be available as your business
grows, or if you ever plan to manufacture your own parts at some point in time. Things to include in
your list of materials:
Parts needed to produce a product,
Supplies (glue, nails, etc.), and
Other materials that are involved in producing or manufacturing your product.
You do not need to include actual financial data in this portion of the study but financial data supporting
your narrative assessment should be included in a separate spreadsheet as an attachment.

The Various Components of a Good Feasibility Study: In its simplest form, a Feasibility Study
represents a definition of a problem or opportunity to be studied, an analysis of the current mode of
operation, a definition of requirements, an evaluation of alternatives, and an agreed upon course of
action. As such, the activities for preparing a Feasibility Study are generic in nature and can be applied
to any type of project, be it for systems and software development, making an acquisition, or any other
project.
A good feasibility study involves the following:
The Project Scope: This is used to define the business problem. The scope should be definitive and to
the point; rambling narrative serves no purpose and can actually confuse project participants. It is also
necessary to define the parts of the business affected either directly or indirectly, including project
participants and end-user areas affected by the project. The project sponsor should be identified.
Many projects in the corporate world started without a well-defined project scope. For
example Tierra group Inc. itself though one was formulated after wards for the rest of its life.
Consequently, projects have wandered in and out of their boundaries causing them to produce either far
too much or far too little than what is truly needed.
The Current Analysis: This defines and understands the current method of implementation, such as a
system, a product, etc. From this analysis, it is not uncommon to discover there is actually nothing
wrong with the current system or product other than some misunderstandings regarding it or perhaps it
needs some simple modifications as opposed to a major overhaul. Also, the S and W's of SWOT in the
current approach are identified. In addition, there may be elements of the current system or product that
may be used in its successor thus saving time and money later on. Without such analysis, this may never
be discovered. Avoid the temptation to stop and correct any problems encountered in the current system
at this time. Simply document your findings instead, otherwise you will spend more time unnecessarily
in this stage.
Requirements: - How requirements are defined depends on the object of the project's attention. For
example, how requirements are specified for a product are substantially different than requirements for,
a bridge, or an information system. This is because each of these comprises totally different properties
and, which are defined differently.
The Approach: Represents the recommended solution or course of action to satisfy the requirements.
Here, various alternatives are considered along with an explanation as to why the preferred solution was
selected. In terms of design related projects, it is here where whole rough designs (e.g., "renderings") are
developed in order to determine viability. It is also at this point where the use of existing structures and
commercial alternatives are considered (e.g., "build versus buy" decisions).
Evaluation: Examines the cost effectiveness of the approach selected. This begins with an analysis of the
estimated total cost of the project. In addition to the recommended solution, other alternatives are
estimated in order to offer an economic comparison. For development projects, an estimate of labor and
out-of-pocket expenses is assembled along with a project schedule showing the project path and startand-end dates.
After the total cost of the project has been calculated, a cost and evaluation summary is prepared which
includes such things as a cost/benefit analysis, return on investment, etc.
Review: - All of the preceding elements are then assembled into a Feasibility Study and a formal review
is conducted with all parties involved. The review serves two purposes: to substantiate the thoroughness
and accuracy of the Feasibility Study, and to make a project decision; either approve it, reject it, or ask
that it be revised before making a final decision. If approved, it is very important that all parties sign the
document which expresses their acceptance and commitment to it; it may be a seemingly small gesture,
but signatures carry a lot of weight later on as the project progresses. If the Feasibility Study is rejected,
the reasons for its rejection should be explained and attached to the document.
Four Key Advantages to Feasibility Studies:
Understanding Demand
Assessing Resources

Marketing Feasibility
Marking a Timeline
Four-Step Feasibility Study Method:
Examine the Market
Review Technical Requirements
Explore the Business Model
Look for an Escape Route
The feasibility study outputs the feasibility study report, a report detailing the evaluation
criteria, the study findings, and the recommendations.
Reasons to Do a Feasibility Study
Conducting a feasibility study is a good business practice. If you examine successful
businesses, you will find that they did not go into a new business venture without first thoroughly
examining all of the issues and assessing the probability of business success.
Below are other reasons to conduct a feasibility study.
Gives focus to the project and outline alternatives.
Narrows business alternatives
Identifies new opportunities through the investigative process.
Identifies reasons not to proceed.
Enhances the probability of success by addressing and mitigating factors early on that could affect the
project.
Provides quality information for decision making.
Provides documentation that the business venture was thoroughly investigated.
Helps in securing funding from lending institutions and other monetary sources.
Helps to attract equity investment.
The feasibility study is a critical step in the business assessment process. If properly
conducted, it may be the best investment you ever made.
Feasibility studies:
A feasibility study is created in order to minimize risk and to ascertain the viability of a
project. As soon as it is certain that a specific project could be carried out profitably, it is only then, that
it could be implemented. It is not merely an investigation but at the same time a plan or a framework on
how the operation of a business project shall be accomplished.
A feasibility study contains five major components namely:
marketing study,
technical study,
management study,
financial study
Social desirability.
During marketing study, the researcher must determine if there are sufficient demands for
the product as well the competitive position of the firm in the industry. Sale projection for the project
must also investigate as part of market study.

The manufacturing process, plant size, production schedule, machinery, plant location
and layout, structure, raw materials, utilities and waste disposal is taken into consideration when it
comes to technical study.
Management study involves on how the project shall be managed such as the business
organization including the organization chart and function of each unit management personnel, skills
and numbers of labor required.
In financial study, the researcher should include the assessment of total capital
requirements, break-even outputs, sales and prices, amount of sales required to earn a certain amount of
profit and the cash payback period.
Last but not the least is the social desirability which is measure by economic benefits to
the people living in the community and its vicinities.
No wonder that one of the important steps in business development is a feasibility study.
Feasibility study is used to determine the potential for success of a proposed business venture. The
success of a feasibility study is based on the careful identification and evaluation of all of the important
aspects for business success.
A good feasibility study involves the following.
The Project Scope
The Current Analysis
Requirements
The Approach
Evaluation
Review
Here are rules, processes and tools for project planning and project management.
While project management skills are obviously important for project managers,
interestingly the methods and tools that project managers use can be helpful for everyone.
A 'task' does not necessarily have to be called a 'project' in order for project management
methods to be very useful in its planning and implementation. Even the smallest task can benefit from
the use of a well-chosen project management technique or tool, especially in the planning stage. Any
task that requires some preparation to achieve a successful outcome, will probably be done better by
using a few project management methods somewhere in the process. Project management methods can
help in the planning and managing of all sorts of tasks, especially complex activities.
Project management is chiefly associated with planning and managing change in an
organization, but a project can also be something unrelated to business - even a domestic situation, such
as moving house, or planning a wedding. Project management methods and tools can therefore be useful
far more widely than people assume.
Project management techniques and project planning tools are useful for any tasks in
which different outcomes are possible - where risks of problems and failures exist - and so require
planning and assessing options, and organizing activities and resources to deliver a successful result.
Projects can be various shapes and sizes, from the small and straightforward to extremely large and
highly complex.
In organizations and businesses, project management can be concerned with anything,
particularly introducing or changing things, in any area or function, for example:
people, staffing and management
products and services
materials, manufacturing and production
IT and communications
plant, vehicles, equipment
storage, distribution, logistics

buildings and premises

finance, administration, acquisition and divestment
purchasing
sales, selling, marketing
human resources development and training
customer service and relations
quality, health and safety,
legal and professional
technical, scientific, research and development
new business development
And anything else which needs planning and managing within organizations.
Case studies: the feasibility study leads to imagining various scenarios ("use cases"). Each case
allows for the evaluation of the risks of the project and should be accompanied by a preliminary
statement of the costs and benefits of the scneario. This stage includes a deliverable, the
feasibility file, submitted to the Steering Committee to ensure that each scneario is studied.
Detailed study: The need analysis carried out in the pre-project phase only bears on the major
processes of the project. It is necessary to do a more in-depth study of the needs so that the client
and contractor

can reach an agreement on a contractual document; this is the preliminary

study, also known as the "general design". During the preliminary study,it is essential to make
sure that the needs are expressed in purely functional terms rather than in terms of solutions. The
functional needs analysis thus allows the mparties to bring out the necessary functionalities of
the work. The functional analysis leads to the finalization of a document functionally defining
the need (independently of any technical solution). This document is called the functional
specifications, also known as /design document/. The Specifications allow the client to express
its needs in functional terms, and to clarify the restrictions on the contractor. Thus, the functional
specifications constitute a contractual document between the contractor and the client.
Technical study: The technical study is the phase in which the design is adapted to the technical
architecture used, describing and documenting the functioning of each unit of the software. The
deliverable of the technical study is the Technical Terms of the Contract (TTC) or detailed
specifications. The detailed study may be accompanied by the creation of a mock-up, or
prototype, that allows the users' representatives to confirm that the solution chosen meets their
expectations.

Project management process

Successful project management, for projects large or small, tends to follow the process
outlined below. The same principles, used selectively and appropriately, also apply to smaller tasks.
Agree precise specification for the project - 'Terms of Reference'
Plan the project - time, team, activities, resources, and financials - using suitable project management
tools.
Communicate the project plan to your project team - and to any other interested people and groups.
Agree and delegate project actions.

Manage and motivate - inform, encourage, enable the project team.

Check, measure, monitor, review project progress - adjust project plans, and inform the project team and
others.
Complete project - review and report on project performance; give praise and thanks to the project team.
Project follow-up - train, support, measure and report results and benefits.

Conclusion: It should be remembered that a Feasibility Study is more of a way of thinking as opposed to
a bureaucratic process. For example, what I have just described is essentially the same process we all
follow when purchasing a business franchise, car or a home. As the scope of the project grows, it
becomes more important to document the Feasibility Study particularly if large amounts of money are
involved and/or the criticality of delivery. Not only should the Feasibility Study contain sufficient detail
to carry on to the next succeeding phase in the project, but it should also be used for comparative
analysis when preparing the final Project Audit which analyses what was delivered versus what was
proposed in the Feasibility Study.
Feasibility Studies represent a common sense approach to planning. Frankly, it is just plain good
business to conduct them. However, I have read where some people, consider Feasibility Studies to be a
waste of time.

Phases of Project Life Cycle:

The Project Life Cycle refers to a logical sequence of activities to accomplish the projects goals or
objectives. Regardless of scope or complexity, any project goes through a series of stages during its life.
There is first an Initiation or Birth phase, in which the outputs and critical success factors are defined,
followed by a Planning phase, characterized by breaking down the project into smaller parts/tasks, an
Execution phase, in which the project plan is executed, and lastly a Closure or Exit phase, that marks the
completion of the project.
Project activities must be grouped into phases because by doing so, the project manager and the core
team can efficiently plan and organize resources for each activity, and also objectively measure
achievement of goals and justify their decisions to move ahead, correct, or terminate. It is of great
importance to organize project phases into industry-specific project cycles. Why? Not only because each
industry sector involves specific requirements, tasks, and procedures when it comes to projects, but also
because different have industry sectors had different needs for life cycle management methodology. And
paying close attention to such details is the difference between doing things well and excelling as project
managers.
The phases of project life cycle are:
1) Initiation:
In this first stage, the scope of the project is defined along with the approach to be taken to deliver the
desired outputs. The project manager is appointed and in turn, he selects the team members based on
their skills and experience. The most common tools or methodologies used in the initiation stage are
Project Charter, Business Plan, Project Framework (or Overview), Business Case Justification, and
Milestones Reviews.
Activities involved in this phase are:
Develop a Business Case:
This Business Case will help to 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
A Business Case justifies the start-up of a project. It includes a description of the business problem or
opportunity, the costs and benefits of each alternative solution, and the recommended solution for
approval. A Business Case Template is used whenever the expenditure on a project has to be justified.
Completing a Business Case Template is usually the first step in the Project Life Cycle. Once the
Business Case Template has been completed, it is presented to a Sponsor for approval. The Business
Case is referred to frequently during the project, to determine whether it is currently on track. And at the
end of the project, success is measured against the ability to meet the objectives defined in the Business
Case. So the completion of a Business Case is critical to the success of the project.
Undertake a Feasibility Study:
The best way to find out whether your project is feasible is to complete a Feasibility Study. This process
helps you gain confidence that the solution you need to build can be implemented on time and under
budget. So here's how to do it in 5 simple stepsCompleting a Feasibility Study:
A Feasibility Study needs to be completed as early in the Project Life Cycle as possible. The best time
to complete it is when you have identified a range of different alternative solutions and you need to
know which solution is the most feasible to implement.
Step 1: Research the Business Drivers:
In most cases, your project is being driven by a problem in the business. These problems are called
"business drivers" and you need to have a clear understanding of what they are, as part of your
Feasibility Study. For instance, the business driver might be that an IT system is outdated and is causing
customer complaints, or that two businesses need to merge because of an acquisition. Regardless of the
business driver, you need to get to the bottom of it so you fully understand the reasons why the project
has been kicked off.
Find out why the business driver is important to the business, and why it's critical that the project
delivers a solution to it within a specified timeframe. Then find out what the impact will be to the
business, if the project slips.
Step 2: Confirm the Alternative Solutions:
Now you have a clear understanding of the business problem that the project addresses, you need to
understand the alternative solutions available. If it's an IT system that is outdated, then your alternative
solutions might include redeveloping the existing system, replacing it or merging it with another system.
Only with a clear understanding of the alternative solutions to the business problem, can you progress
with the Feasibility Study.
Step 3: Determine the Feasibility:
You now need to identify the feasibility of each solution. The question to ask of each alternative
solution is "can we deliver it on time and under budget?" To answer this question, you need to use a
variety of methods to assess the feasibility of each solution. Here are some examples of ways you can
assess feasibility:
Research: Perform online research to see if other companies have implemented the same solutions and
how they got on.
Prototyping: Identify the part of the solution that has the highest risk, and then build a sample of it to see
if it's possible to create.

Time-boxing: Complete some of the tasks in your project plan and measure how long it took vs.
planned. If you delivered it on time, then you know that your planning is quite accurate.
Step 4: Choose a Preferred Solution:
With the feasibility of each alternative solution known, the next step is to select a preferred solution to
be delivered by your project. Choose the solution that; is most feasible to implement, has the lowest risk,
and you have the highest confidence of delivering.
You've now chosen a solution to a known business problem, and you have a high degree of confidence
that you can deliver that solution on time and under budget, as part of the project.
Step 5: Reassess at a lower level:
It's now time to take your chosen solution and reassess its feasibility at a lower level. List all of the
tasks that are needed to complete the solution. Then run those tasks by your team to see how long they
think it will take to complete them. Add all of the tasks and timeframes to a project plan to see if you can
do it all within the project deadline. Then ask your team to identify the highest risk tasks and get them to
investigate them further to check that they are achievable. Use the techniques in Step 3 to give you a
very high degree of confidence that it's practically achievable. Then document all of the results in a
Feasibility Study report.
Establish the Project Charter:
Project Charter 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.
A Project Charter outlines the purpose of the project, the way the project will be structured and how it
will be successfully implemented. The Project Charter describes the project vision, objectives, scope and
deliverables, as well as the Stakeholders, roles and responsibilities. The Project Charter is also known as
a "Terms of Reference" or "Project Definition Report".
"Every time you start a new project, you should complete a Project Charter template. The Project
Charter defines the vision and boundaries for the project, as well as the high level roadmap. In addition,
the Project Charter also defines the scope of the project, within which the deliverables are produced.
With a well defined Project Charter, the Project Manager has a clear project roadmap for success.
Appoint the Project Team
Set up the Project Office: This Project Office 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.
The Project Office Checklist lists everything you need to do, to set up a Project Management Office. A
Project Management Office is the physical premises within which project staff (e.g. the Project Manager
and support staff) reside. The Project Office also contains the communications infrastructure and
technologies required to support the project. The project Office must cater to the followingthe Project Office premises must be fit for purpose,
sufficient equipment must be available,
all the roles, standards and processes must be in place within the Project Management Office
environment.
Perform Phase Review:
Project Review 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 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
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.

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 of
"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.
As soon as the project team believes they have completed a particular project phase, a project review
should be undertaken. There will usually be at least three project reviews during the project life cycle: at
the end of the Initiation, Planning and Execution project phases.

MANAGING PROJECT RESOURCES FLOW

A successful Project Manager must effectively manage the resources assigned to the project. This
includes the labour hours of the designers, the builders, the testers and the inspectors on the project
team. It also includes managing any labour subcontracts. However, managing project resources
frequently involves more than people management. The project manager must also manage the
equipment used for the project and the material needed by the people and equipment assigned to the
project
People
Project employees, vendor staff, subcontract labour
Equipment
Cranes, trucks, backhoes, other heavy equipment or
Development, test, and staging servers, CD burners or
Recording studio, tape decks, mixers, microphones and speakers
Material
Concrete, pipe, rebar, insulation or
CD blanks, computers, jewel cases, instruction manuals
Managing the people resources means having the right people, with the right skills and the proper tools,
in the right quantity at the right time. It also means ensuring that they know what needs to be done,
when, and how. And it means motivating them to take ownership in the project too. Managing direct
employees normally means managing the senior person in each group of employees assigned to your
project. Remember that these employees also have a line manager to whom they report and from whom
the usually take technical direction. In a matrix management situation, like a project team, your job is to
provide project direction to them. Managing labour subcontracts usually means managing the team lead
for the subcontracted workers, who in turn manages the workers.
The equipment you have to manage as part of your project depends on the nature of the project. A
project to construct a frozen food warehouse would need earth moving equipment, cranes, and cement
trucks. The project management key for equipment is much like for people resources. You have to make
sure you have the right equipment in the right place at the right time and that it has the supplies it needs
to operate properly.
Most projects involve the purchase of material. For a frozen food warehouse, this would be freezers, the
building HVAC machinery and the material handling equipment. The project management issue with
supplies is to make sure the right supplies arrive at the right time (we'll talk about the right price later).
. Time management is critical in successful project management.

Steps in Managing resources

Identify the key resources in your organization.

Key resource is a group of individuals that is probably 5% or less of your total resource pool. The key
resources are those people who have more advanced skills, knowledge or combination of skills and
knowledge that makes them indispensable.
Create a project in any project management scheduling tool which contains only the tasks
assigned to those resources.
Sub-divide the project into sections for each key resource then in each section, add the tasks for
that key resource only.
Resource levels only these tasks until no key resource is overloaded.
Have team leaders manage all other resources around this key resource schedule.
Ways to manage the resources:In a very small organization, this technique is likely to be ineffective because everyone is a key
resource.
Once the plan is created, review all tasks assigned to the key resources with a critical eye to
seeing if any of them could be accomplished by less key resources
Avoid having too many key resources. The more people in this plan, the harder it is to
implement.
Avoid doing the schedule too far into the future. Use a scheduling window that is meaningful to
everyone.
Focus on regular reporting on cost and timeline updates
Share the reports with your team so they are aware of the activities
Share the errors and solutions with your team members
This is a summary of each activity: cost, timeline and resource (people)
The focus is a general point of view and for small projects (under 10k in budget, with 2 to 4
people and at the most 3 weeks in duration)
Managing projects are not easy and with time and experience will get easier.

DEVELOPING A PROJECT PLAN:

A project plan is a model of the process that the project team intends to follow to realize the project
objectives. It brings together a number of important aspects of this process including its scope, timing,
cost, and associated risks.The project plan can be viewed as a type of contract between the project
team members and other stakeholders. It defines the process by which the objectives will be achieved,
and the responsibilities in carrying out this process. Project plans also underpin a number of other key
project management functions including estimating and forecasting, options analysis and decisionmaking, and performance monitoring and control.

DEVELOPMENT OF PROJECT MANAGEMENT PLAN

The Development of Project Management Plan process includes the actions necessary to define,
integrate, and coordinate all subsidiary plans into a project management plan. The project management
plan content will vary depending upon the application area and complexity of the project. This process
results in a project management plan that is updated and revised through the Integrated Change Control
process. The project management plan defines how the project is executed, monitored and controlled,
and closed. The project management plan documents the collection of outputs of the planning processes
of the Planning Process Group and includes:
The project management processes selected by the project management team
The level of implementation of each selected process
The descriptions of the tools and techniques to be used for accomplishing those processes
How the selected processes will be used to manage the specific project, including the dependencies and
interactions among those processes, and the essential inputs and outputs

 How work will be executed to accomplish the project objectives

How changes will be monitored and controlled
How configuration management will be performed
How integrity of the performance measurement baselines will be maintained and used
The need and techniques for communication among stakeholders
The selected project life cycle and, for multi-phase projects, the associated project phases
Key management reviews for content, extent, and timing to facilitate addressing open issues and
pending decisions.
STRATEGIC PLANNING:
In strategic planning, resource allocation is a plan for using available resources, for example human
resources, especially in the near term, to achieve goals for the future. It is the process of allocating
resources among the various projects or business units. The plan has two parts: Firstly, there is the basic
allocation decision and secondly there are contingency mechanisms. The basic allocation decision is the
choice of which items to fund in the plan, and what level of funding it should receive, and which to
leave unfunded: the resources are allocated to some items, not to others. There are two contingency
mechanisms. There is a priority ranking of items excluded from the plan, showing which items to fund if
more resources should become available; and there is a priority ranking of some items included in the
plan, showing which items should be sacrificed if total funding must be reduced.
The main objective is to smooth resources requirements by shifting slack jobs beyond periods of peak
requirements. Some of the methods essentially replicate what a human scheduler would do if he had
enough time; others make use of unusual devices or procedures designed especially for the computer.
They of course depend for their success on the speed and capabilities of electronic computers. Resource
allocation may be decided by using computer programs applied to a specific domain to automatically
and dynamically distribute resources to applicants. It may be considered as a specialized case of
automatic scheduling. This is especially common in electronic devices dedicated to routing and
communication.
Whether you call it a project plan or a project timeline, it is absolutely imperative that you develop and
maintain a document that clearly outlines the project milestones and major activities required to
implement your project. This document needs to include the date each milestone or major activity is to
be completed, and the owner of each. Your project plan also needs to be created at the beginning of the
project, and a baseline version approved by the team as soon as possible.
Although you will probably not know all of the major activities required to implement your project in
the beginning, it is important that you create a draft of the activities you think may need to be tracked
via a formal document. Take some time and really think through what you know about the objective of
your project. Look at some historical data from similar projects. You can even have a few informal
meetings with knowledgeable individuals you can use as a sounding board to make sure you aren't
completely off base. You'll be surprised how good a draft you can develop if you put in a little effort.
With this draft you will be able to speak with subject matter experts (SMEs) and stakeholders to flesh
out the project plan. If you don't make some level of effort to develop a rough draft, you may give a bad
impression which will make it harder for you to obtain the support of the persons you need to implement
the project.
After you have fleshed out your draft with your core team, and some other SMEs that may not be a part
of your team, you should give the document a baseline status. Your timeline / project plan should not
undergo many edits, if any, after it achieves baseline status.
You should document the actual date your project activities are completed. If the actual completion date
differs from your baseline date at any time, you'll still have documented the date it was supposed to be
completed for historical purposes.
It is also a good idea to notate where things are deleted or added, and why. That way you aren't standing
there looking crazy, trying to go through the crevices of your memory, when someone asks you why
something you deleted isn't in the document.

A few key items to include in your timeline are:

A unique ID that your team can reference when giving an update The name of the task
When the task should start
When the task should finish
The actual date the task was completed
Any tasks that need to happen before other tasks can begin
The owner of the task
Percent complete of each task
PROJECT BOTTLENECKS
Hurry up and wait The client wants the project to begin as soon as possible, so you work overtime to
get the scope document, budget, and timeline together. But when you are ready, the client fails to make
its resources information and people available in a timely manner.
Scope creep you work overtime to meet the client's expectations, even though their expectations
included deliverables that weren't part of the original scope discussion. This is especially problematic for
fixed-price contracts.
Endless brainstorming sometimes the client has an idea of what they want you to discover during the
course of a project, and if you don't find it, they want you to try again.
Two departments, one project objective Sometimes, especially at larger companies, you get involved
in a project and you find out that another department is working on a similar project.
Late or no payment some consultants fail to set proper payment expectations with clients, resulting in
an excessively delayed payment.
Planning recommendations: The following planning suggestions can help you better navigate the
process of getting client buy-in at the start of a project.
Identify the project champion: There must be a clear project champion someone at a high level within
the client organization who supports your team. This individual must have enough clout in the
organization to gain access to key people and resources, and to eventually help sell ideas to the decisionmakers. The project champion can help:
Ensure that you have access to client staff and information to prevent bottlenecks that could affect your
project timeline.
Gather feedback on project hypotheses by researching findings and status from within the organization
as a litmus test for how other client executives might react.
Identify any other projects within the organization that have similar objectives. You want to make sure
that the client resources are being used effectively and that any complementary efforts are coordinated.
Establish clear project scope: Most likely, you participated in a thorough proposal and pitch process
before being awarded the contract. Even if you reviewed the project scope during that discussion, it's a
good idea to refine it at the beginning of the project. The following can help you establish a clear project
scope:
Discuss initial hypotheses to test as soon as possible. Some client executives don't like to be surprised by
transformational ideas or assumptions in the final recommendations meeting with their peers. Gain an
understanding of executive response early in the project.
Outline the tasks and deliverables that are and are not covered in the project scope, in order to set client
expectations. Sometimes the client will choose before the project begins to expand the scope after the
out-of-scope issues are communicated.
Clarify format of deliverables. Make sure that the client knows the format of the various deliverables so
that they don't have unrealistic expectations about the level of detail. Also, make certain that the client
has realistic expectations regarding your participation in training and follow-up meetings as well as how
many iterations of a project you will complete before requiring a change order especially in the case
of fixed-price contracts.

Have the client sign off on a scope document at the beginning of a project. Be careful not to make this
process so formal as to put off the client.
Consistently review the original scope as you work through various milestone meetings during the
course of the project.
Clearly outline the project timeline: Consulting projects can take weeks or months to complete. Also,
they are often at the front end of larger operational initiatives, such as technology implementations,
product development, or process reengineering efforts. The following can help you establish a clear
project timeline:
Outline the due dates of key milestones and when you expect to have the project wrapped up. This way,
your client can coordinate your deliverables with other important company events board meetings,
earnings releases, or national sales meetings where they might want to present some of the project
findings.
Include deadlines in your schedule for items that the client must provide to you, so they know their
responsibilities. If they miss deadlines and force your schedule to shift, it will have been clear from the
beginning.
Identify required client and consulting resources and when they will be needed along the project
timeline. You can do this most effectively in terms of full-time equivalents (FTEs).
Make sure there is enough time for your team to complete the necessary research and analysis to make
solid recommendations, while still allowing the client sufficient time to implement those
recommendations.
Define how to handle billing issues: Client budgets are often tight, and miscommunication regarding
billing issues can sour an otherwise good client relationship. Up-front and honest communication
regarding all billing-related issues can positively contribute to your client relationship. The following are
some suggestions on how to handle billing issues:
Provide assumptions as to how you arrived at your price, such as the estimated number of hours and
hourly rates that you used as the basis for the project price.
Establish a mechanism for dealing with out-of-scope issues. If your master services agreement allows
for it, and the client wants you to perform additional work, issue change orders that follow an agreedupon format.
Gain a clear understanding of when invoices will be paid and if the client expects any discounts for early
payment, so you aren't surprised when you get the checks.
Clearly communicate how travel, meals, and other expenses will be billed. These expenses can add up,
especially on out-of-town engagements.
Ask for a down payment before the project begins. This shows that the client is committed to the project,
and that it has cleared the appropriate decision-making process that allows you to get paid.
Present your project plan in a kickoff meeting: The relationship between consultant and client is critical
to the ultimate success of the project. If your clients feel that they were not adequately communicated
with, or are surprised or overwhelmed, they might not embrace your recommendations. Presenting your
plan in a project kickoff meeting can earn their immediate trust, which can pay off later. The following
guidelines can help you plan a successful kickoff meeting:
Get the right people in the room. Work with the project champion to ensure that the meeting includes all
the relevant decision-makers so they clearly understand the project's scope, objectives, initial
hypotheses, research plan, and the broader strategic context in which the project exists.
Present the project timeline indicating when key meetings, interviews, and presentations will take place,
as they include the participation of your audience.
Distribute a hard-copy version outlining this timeline as well as the project scope and deliverables. You
can later reference this copy in future conversations. Meeting attendees can also use the copy to
communicate the project's objectives to their peers and subordinates.

Maintain clear communication: Even though consulting projects deal with high-level strategic and
operational issues, at the end of the day they are just projects. As such, it is important for all consultants
to have project management skills and clear communication methods in place. In general, the more
information that can be openly and honestly communicated about the project's scope, budget, and
timeline, the better off both you and your client will be.
STEPS IN PROJECT PLANNING:
The key to a successful project is in the planning. Creating a project plan is the first thing you should do
when undertaking any kind of project. Often project planning is ignored in favour of getting on with the
work. However, many people fail to realise the value of a project plan in saving time, money and many
problems.
Step 1: Project Goals:
A project is successful when the needs of the stakeholders have been met. A stakeholder is anybody
directly, or indirectly impacted by the project. As a first step, it is important to identify the stakeholders
in your project. It is not always easy to identify the stakeholders of a project, particularly those impacted
indirectly. The project sponsor, The customer who receives the deliverables, The users of the project
outputs, The project manager and project team are some Examples of stakeholders.
Once you understand who the stakeholders are, the next step is to find out their needs. The best way to
do this is by conducting stakeholder interviews. Take time during the interviews to draw out the true
needs that create real benefits. Often stakeholders will talk about needs that aren't relevant and don't
deliver benefits. These can be recorded and set as a low priority.
The next step, once you have conducted all the interviews, and have a comprehensive list of needs is to
prioritise them. From the prioritised list, create a set of goals that can be easily measured. A technique
for doing this is to review them against the SMART principle. This way it will be easy to know when a
goal has been achieved.
Once you have established a clear set of goals, they should be recorded in the project plan. It can be
useful to also include the needs and expectations of your stakeholders. This is the most difficult part of
the planning process completed. It's time to move on and look at the project deliverables.
Step 2: Project Deliverables:
create a list of things the project needs to deliver in order to meet those goals. Specify when and how
each item must be delivered.
Add the deliverables to the project plan with an estimated delivery date. More accurate delivery dates
will be established during the scheduling phase, which is next.
Step 3: Project Schedule: Create a list of tasks that need to be carried out for each deliverable identified
For each task identify the following:
The amount of effort (hours or days) required to complete the task.
The resource who will carryout the task.
Once you have established the amount of effort for each task, you can workout the effort required for
each deliverable, and an accurate delivery date. Update your deliverables section with the more accurate
delivery dates.
At this point in the planning, you could choose to use a software package such as Microsoft Project to
create your project schedule. Alternatively, use one of the many free templates available. Input all of the
deliverables, tasks, durations and the resources who will complete each task.
A common problem discovered at this point, is when a project has an imposed delivery deadline from
the sponsor that is not realistic based on your estimates. If you discover that this is the case, you must
contact the sponsor immediately. The options you have in this situation are:
Renegotiate the deadline (project delay).
Employ additional resources (increased cost).

Reduce the scope of the project (less delivered).

Use the project schedule to justify pursuing one of these options.

Step 4: Supporting Plans:

This section deals with plans you should create as part of the planning process. These can be included
directly in the plan.
Human Resource Plan: Identify by name, the individuals and organisations with a leading role in the
project. For each, describe their roles and responsibilities on the project. Next, describe the number and
type of people needed to carry out the project. For each resource detail start dates, estimated duration
and the method you will use for obtaining them.
Create a single sheet containing this information.
Communications Plan: Create a document showing who needs to be kept informed about the project and
how they will receive the information. The most common mechanism is a weekly or monthly progress
report, describing how the project is performing, milestones achieved and work planned for the next
period.
Risk Management Plan: Risk management is an important part of project management. Although often
overlooked, it is important to identify as many risks to your project as possible, and be prepared if
something bad happens. Here are some examples of common project risks:
Time and cost estimates too optimistic.
Customer review and feedback cycle too slow.
Unexpected budget cuts.
Unclear roles and responsibilities.
Stakeholder input is not sought, or their needs are not properly understood.
Stakeholders changing requirements after the project has started.
Stakeholders adding new requirements after the project has started.
Poor communication resulting in misunderstandings, quality problems and rework.
Lack of resource commitment.
Risks can be tracked using a simple risk log. Add each risk you have identified to your risk log; write
down what you will do in the event it occurs, and what you will do to prevent it from occurring. Review
your risk log on a regular basis, adding new risks as they occur during the life of the project. Remember,
when risks are ignored they don't go away.
Remember to update your plan as the project progresses, and measure progress against the plan.

COST AND RESOURCE CONSIDERATIONS IN PROJECT PLANNING:

In many instances you can actually change activity completion times by allocating more resources to it.
How can you decide which activities are the best to give more resources to and how much you should
give?
Key characteristics of project plans: A project plan can be considered to have five key characteristics
that have to be managed:
Scope: defines what will be covered in a project.
Resource: what can be used to meet the scope.

Time: what tasks are to be undertaken and when.

Quality: the spread or deviation allowed from a desired standard.
Risk: defines in advance what may happen to drive the plan off course, and what will be done to recover
the situation.
The sad thing about plans is you cannot have everything immediately. Many people plan using planning
software packages, without realising the trade-offs that must be made. They assume that if they write a
plan down, reality will follow their wishes. Nothing is further from the truth. The point of a plan is to
balance:
The scope, and quality constraint against,
The time and resource constraint, Whileminimising the risks.
Balance Plan: If The scope of a project plan is so large that there is no way the time, resource, and
quality constraints can result in the project delivering, which means there are enormous risks.
To salvage this plan, requires reducing the scope, increasing the time, or resource, or lowering the
quality standard. Any of which will reduce the risk of failure. The key lesson is that plans have to be
balanced within the project constraints if they are to deliver.
Project Planning with Uncertain Activity Times: Generally the distribution of the activity times is
unknown and must be estimated. A typical method of dealing with the situation is to estimate three
activity duration times for each activity, optimistic, most likely and pessimistic. Use these estimates to
estimate a normally distributed activity time:
most optimistic time (a): the probability of completing the activity in less than a is about 1%
most likely time (m): the estimated average time required to complete the activity
most pessimistic time (b): the probability of taking longer than b is about 1%
The activity time is assumed to be normally distributed with mean, te, and variance as follows:
Expected time: te = ( a + 4m + b ) / 6
Variance: var[te] = [ ( b - a) / 6 ]2
Assumptions:
1. Duration of activities along the critical path determine project completion time
2. Duration time of one activity is independent of duration times of all other activities. Using the Central
Limit Theorem, the project completion time is assumed to be normally distributed with the mean equal
to the sum of the activity times on the critical path the variance is equal to the sum of the variances of
the activities on the critical path.
Once the mean and standard deviation of the critical path are known it is possible to calculate the
probability of completing the project in a certain time.
If a project has two critical paths, the critical path with the largest variance should be used to calculate
the probability that the project will be completed within a certain time.
Note - Only considering the critical path makes a very strong assumption. In real situations you should
be aware of the other paths which may become critical. If an activity that is not on the critical path has a
large variance of duration time, it is possible for that activity to become a critical path activity simply
through random occurrences.
Approach to Project Planning: The following situation is very common for a product development
organization. How to rapidly develop an accurate project plan estimate which is critical to the overall
development lifecycle (resources, relation to other projects and dependencies on other deliverables
should be always well defined) and at the same time minimize the time spent performing if-then-else
analysis. Business and technical analysts and project managers have their hands full doing real things
implementing new customer requested functions and working on the next release of the product.

Project Planning Process: The process of planning and assessment consists of the 5 main steps:
Define the Project: During this phase we put together the regular project plan in MS Project with the
main tasks, timeframes and deliverables. The project plan can be
created either manually, or be
generated as the result of other efforts (doing some preliminary use cases or object design or working
with the cost estimate tools).
Identify Uncertainty: In this phase we need to determine:
Which tasks or their inputs in the plan are uncertain
What we know about these uncertainties
What would be the best way to describe these uncertainties
The behaviour and known range of values they might cover.
During this phase we also need to identify what are the most critical results we want to look at, analyse
and optimize as outputs of our plan.
Run simulation: As the result of the Monte Carlo simulation (parameters of this simulation can be
configured as well) we can obtain the ranges and probabilities of all outcomes for the outputs that weve
identified during model setup. Normally its the ranges of the duration for particular phases, or the
project with the most critical dependencies, overall project timeframe, etc.
Establishing Project Parameters: We use our past projects experience and historical knowledge to
define the possible ranges for different tasks and distribution functions. For any distribution function we
can define its fine structure, like average value, standard deviation, etc. There is also another advanced
feature which allows us to add additional custom uncertainties to the selected tasks or group of tasks.

BENEFITS OF PLAN:
It is more likely to lead to success and is more cost effective than a just do it approach.It develops
greater mutual understanding and more commitment to achieving the objectives within the project
team.It provides an early warning system so that problems are identified while there is still time to do
something about them.

KEY ELEMENTS OF THE PLAN:

Products What products must the project deliver? What is the quality requirements associated with the
products?
Activities What activities are needed to deliver the products?
Resources What resources are needed to carry out the activities?
Schedule In what sequence should we carry out the activities? How long will the activities take to
complete? Are the required resources available? How long will the project take overall?
Budget What are the time-phased resource requirements and financial costs? How much will the
project cost overall?
Risks Are we taking unnecessary risks? Is the level of risk exposure commensurate with the risk
appetite? Are there any opportunities that could be exploited?
Assumptions What are the underlying assumptions associated with the plan?

What is the process for developing a plan?

There are four key stages in developing a robust plan:

1. Identify, structure and define the products needed to achieve the project objectives. Break down the
work needed to deliver the products into discrete work packages. Define the responsibilities of the
individuals or teams who will deliver the work packages.
2. Identify the activities and resources needed to deliver the work packages. Construct a schedule that
takes account of the logical dependencies between activities, and the availability of resources.
3. Estimate the quantity of resources and financial costs associated with each work package, and use this
information in conjunction with the schedule to develop time-phased budgets.
4. Identify and analyse the risks associated with each work package.

PLANNING PHASE
The next phase, the planning phase, is where the project solution is further developed in as much detail
as possible and you plan the steps necessary to meet the projects objective. In this step, the team
identifies all of the work to be done. The projects tasks and resource requirements are identified, along
with the strategy for producing them. This is also referred to as scope management. A project plan is
created outlining the activities, tasks, dependencies and timeframes. The project manager coordinates the
preparation of a project budget; by providing cost estimates for the labour, equipment and materials
costs. The budget is used to monitor and control cost expenditures during project execution. Once the
project team has identified the work, prepared the schedule and estimated the costs, the three
fundamental components of the planning process are complete. This is an excellent time to identify and
try to deal with anything that might pose a threat to the successful completion of the project. This is
called risk management. In risk management, high-threat potential problems are identified along with
the action that is to be taken on each high threat potential problem, either to reduce the probability that
the problem will occur or to reduce the impact on the project if it does occur. This is also a good time to
identify all project stakeholders, and to establish a communication plan describing the information
needed and the delivery method to be used to keep the stakeholders informed. Finally, you will want to
document a quality plan; providing quality targets, assurance, and control measures along with an
acceptance plan; listing the criteria to be met to gain customer acceptance. At this point, the project
would have been planned in detail and is ready to be executed.
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. A Project Plan is filled in every time you wish to embark on a new project. A summarized Project
Plan is usually created early in the life cycle, with a detailed Project Plan being created later the
planning phase. The Project Plan is referred to constantly throughout the project. Every day, the Project
Manager will review actual progress against that stated in the Project Plan, to ensure they are still on
track. The Project Plan is therefore the most critical tool a Manager can have to successfully deliver
projects.
The project plan should also include a risk analysis and a definition of a criteria for the successful
completion of each deliverable. The governance process is defined, stake holders identified and
reporting frequency and channels agreed.
The Project Planning Phase follows the Project Initiation Phase and is the most important phase in
project management. The effort spent in planning can save countless hours of confusion and rework in
the subsequent phases. The purpose of the Project Planning Phase is:
Establish Business Requirements.
Establish Cost, Schedule, List of Deliverables and Delivery Dates.
Establish Resource Plan.
Get Management Approval and proceed to next phases.
The basic processes of the Project Planning Phase are:
Scope PlanningThis specifies the in-scope requirements for the project.

Preparing the Work Breakdown StructureThis specifies the breakdown of the project into tasks and sub-tasks.
Organizational Breakdown StructureThis specifies who all in the organization need to be involved and referred for Project Completion.
Procurement Plan:
Procurement Plan helps to procure products and services from external suppliers. It provides you with a
complete project procurement plan template, to help you to quickly and easily create a Procurement Plan
for your business. By planning your procurement carefully, you can ensure that you buy the right
products for your business, at the right price.
This Procurement Plan helps you:
Define your procurement requirements
Identify all of the items you need to procure
Create a sound financial justification for procuring them
List all of the tasks involved in procuring your products
Schedule those tasks by allocating timeframes and resources
Create a robust project procurement process for your business
Procurement Planning is critical if you want to get the most out of your supplier relationships. By using
this Procurement Plan template, you can quickly and easily define your procurement requirements, the
method of procurement and the timeframes for delivery.
A Procurement Plan defines the products and services that you will obtain from external suppliers. A
good Procurement Plan will go one step further by describing the process you will go through to appoint
those suppliers contractually. Whether you are embarking on a project procurement or organizational
procurement planning exercise, the steps will be the same. First, define the items you need to procure.
Next, define the process for acquiring those items. And finally, schedule the timeframes for delivery.
It is advisable to create a Procurement Plan whenever you want to purchase items from suppliers. Using
the Procurement Plan template, you can define the procurement requirements, identify potential
suppliers, contract those suppliers and manage them to ensure delivery. Project Procurement Planning is
critical to the success of any project. This Procurement Plan template helps you to perform these steps
quickly and easily.
Resource Planning:
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. A Resource Plan is created during the Resource Planning phase of the
project. Anyone responsible for Project Resource Management will need to create a comprehensive
Resource Plan, to ensure that all of the resources needed to complete the project are identified. By
implementing proper Resource Planning practices, it also helps you with budgeting and forecasting
project expenditure.
The Resource 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 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
Plan the dates for using or consuming these resources
Identify the amount of resource required per project activity
Create a detailed resource utilization schedule

Project Schedule Development:

This specifies the entire schedule of the activities detailing their sequence of execution.
Budget Planning:
This specifies the budgeted cost to be incurred in the completion of the Project.
Financial Plan:
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. Financial Plan can be used 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.
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.
Whenever you need to ask for money, you need a sound Financial Plan showing how it will be
consumed. For a Project Manager, getting Project Finance is one of the most critical tasks in the project.
Therefore, sound Financial Planning principles must be followed to ensure a positive outcome. Using
this Financial Plan template, you can create a detailed Financial Plan for your project. It will help you
get the Project Finance needed to successfully deliver your project on time.
Communication Planning:
Communication Plan helps to communicate the right information, to the right people, at the right time. It
will also help create a schedule of communications events to ensure that your stakeholders are always
kept properly informed, ensuring their continued buy-in and support.
One can then use this Communication Plan for :
Listing your communications stakeholders
Defining each stakeholders communication needs
Identifying the required communications events
Determining the method and frequency of each event
Allocating resource to communications events
Building a communication event schedule
Monitoring the communications events completed
Gaining feedback on communications events
Improving communications processes

Communication Planning is an important part of any business. Using this template you can create a
comprehensive Communications Plan for your project or team, helping keep your stakeholders properly
informed at all times.
A Communication Plan describes how you intend to communicate the right messages to the right people
at the right time. Within a Communication Plan, the communication goals, stakeholders and strategies,
activities and timeframes are described. A Communication Plan helps you keep everyone informed so
that you can communicate a consistent message to your target audience.
Whenever you have a variety of staff, external suppliers, customers and stakeholders to communicate
with, then you should record your communications formally in a Communication Plan. A clear
Communications Plan is vital to the success of an organization. It is also critical to the success of
projects, as it ensures that all of the staff and stakeholders are kept properly informed of the progress of
a project. The best time to perform Communication Planning is during the start up phase of a project.
This will ensure your Communication Plan includes the tasks needed to communicate effectively
throughout the entire project life cycle.

Quality Plan:
Create a Quality Assurance Plan and Quality Control Plan.
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.
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. Creating a Quality Plan is essential if you want to provide the
customer with confidence that you will produce a solution that meets their needs. The Quality Plan states
everything you're going to do, to ensure the quality of your solution. The first section defines the Quality
targets. The second section sets out a Quality Assurance Plan. And the third section defines a Quality
Control Plan. By using this template, you can create a Quality Management Plan that gives your
customer a high degree of confidence that you will succeed.
Risk Management Planning:
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 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.
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. A Risk Plan should be used anytime that risks need to be carefully managed.
For instance, during the start up of a project a Risk Plan is created to identify and manage the risk
involved with the project delivery. The Risk Plan is referred to frequently throughout the project, to
ensure that all risks are mitigated as quickly as possible. The Risk Plan template helps you identify and
manage your risks, boosting your chances of success.
Configuration Management Planning.
Defines how the various project artifacts will get stored.
Both the basic processes and facilitating processes produces a Project Plan. During this phase, Project
Team is responsible for the following activities:
Project Managers are responsible for developing the Project Plan thus ensuring that all the
project planning requirements are fulfilled.
Functional / Management personnel are responsible ensures that adequate resources are available
for the project.
Acceptance Plan:
This Acceptance Plan helps you to gain the customers acceptance for the deliverables produced by your
project. Creating an Acceptance Plan (or 'Acceptance Test Plan') is an important part of any project, as it
allows the customer to accept the deliverables you have produced for them. By using this acceptance
plan template, you can gain customer acceptance for your deliverables, quickly and efficiently. This
Acceptance Plan template will help you gain acceptance, by:
Creating a full list of all project deliverables
Listing the criteria for gaining customer acceptance
Putting in place, acceptance standards to be met
You can then use this template to create an Acceptance Plan, by:
Identifying the acceptance test methods
Allocating acceptance test resources
Scheduling acceptance reviews with your customer
Gaining your final acceptance of your deliverables
By creating an Acceptance Plan for your projects, you'll boost your chances of success - as you will
constantly produce deliverables which meet your customers requirements. The Acceptance Plan
template helps you to schedule customer acceptance tests to ensure that your deliverables meet your
customers needs, every time.

An Acceptance Plan (also known as an "Acceptance Test Plan") is a schedule of tasks that are required
to gain the customers acceptance that what you have produced is satisfactory. It is more than just a task
list though. An Acceptance Plan is in fact an agreement between you and the customer, stating the
acceptance tasks that will be undertaken at the end of the project to get their final approval. The
Acceptance Plan includes a list of the deliverables, the acceptance test activities, the criteria and
standards to be met, and the plan for their completion.
You should create an Acceptance Plan every time you need to produce a set of deliverables that require
the customer's approval before completion. If the customer needs to approve anything, then you should
agree upfront what actions will be taken to get their approval when the deliverables are complete. By
creating an Acceptance Plan at the start of a project, it will save you time and hassle at the end, as the
acceptance test actions will already have been pre-completed by the customer. Key Stakeholders should
approve the Project Plan before moving to the next phase.
Project Planning is essential for a project's success. Project Planning helps team members to understand
their responsibilities and expectations from them. Project Planning Phase identifies scope, tasks,
schedules, risks, quality and staffing needs.

PROJECT EXECUTION AND CONTROLLING:

During the third phase, the execution phase, the project plan is put into motion and performs the work of
the project. It is important to maintain control and communicate as needed during execution. Progress is
continuously monitored and appropriate adjustments are made and recorded as variances from the
original plan. In any project a project manager will spend most of their time in this step. During project
execution, people are carrying out the tasks and progress information is being reported through regular
team meetings. The project manager uses this information to maintain control over the direction of the
project by measuring the performance of the project activities comparing the results with the project
plan and takes corrective action as needed. The first course of action should always be to bring the
project back on course, i.e., to return it to the original plan. If that cannot happen, the team should record
variations from the original plan and record and publish modifications to the plan. Throughout this step,
project sponsors and other key stakeholders should be kept informed of project status according to the
agreed upon frequency and format. The plan should be updated and published on a regular basis.
Status reports should always emphasize the anticipated end point in terms of cost, schedule and quality
of deliverables. Each project deliverable produced should be reviewed for quality and measured against
the acceptance criteria. Once all of the deliverables have been produced and the customer has accepted
the final solution, the project is ready for closure.

The most important issue in this phase is to ensure project activities are properly executed and
controlled. During the execution phase, the planned solution is implemented to solve the problem
specified in the project's requirements. In product and system development, a design resulting in a
specific set of product requirements is created. This convergence is measured by prototypes, testing, and
reviews. As the execution phase progresses, groups across the organization become more deeply
involved in planning for the final testing, production, and support. The most common tools or
methodologies used in the execution phase are an update of Risk Analysis and Score Cards, in addition
to Business Plan and Milestones Reviews.
This phase ideally starts once the Project Plan has been approved and baselined. Project Execution is
characterized by the actual work on the tasks planned and project Control involves the comparison of the
actual performance with the planned performance and taking appropriate corrective action to get the
desired output. During this phase, Project Team is responsible for the following activities:
Team Members execute the tasks as planned by the Project Manager.

Project Manager is responsible for performance measurement which includes finding variances between
planned and actual work, cost and schedule.
Project manager is responsible for providing Project Status Report to all key stakeholders to provide
visibility.
All Project Key stakeholders are responsible for the review of the metrices and variances.
All Project Key stakeholders are responsible for taking necessary action of the variances thus
determined so as to complet the project within time and budget.
The basic processes of the Project Execution and Control can be:
Project Time Management Process:
This Project Time Management Process describes how to monitor and control time spent within a
project. It describes each of the Time Management procedures step-by-step, explaining how to use
Timesheets and Time Management Logs to record time spent. By using this Time Process, you can
control the amount of time that it takes staff to build deliverables within a project, increasing your
chances of delivering "on time" and to schedule. This Project Time Management process will help you
to:
Put in place a process for recording time within projects
Use Timesheets to monitor the time spent by staff
Identify and resolve time management issues
Keep the Project Plan up-to-date at all times
Lists the key steps taken to manage time within a project
Includes a process diagram, showing when those steps are taken
Describes each of the roles and responsibilities involved
Is pre-completed and ready to use on projects now
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 (or "Time 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.
The best way to see if your project is on track is to record time actually spent vs. time planned to be
spent. The process is called Project Time Management, and it is by far the most effective way to monitor
project progress. The time process allows you to see for every task, whether is has been completed on
time.
This time process also allows you to control time spent by implementing a timesheet approval process.
The facilitating processes during Project Execution and Control can be:
Quality Assurance and Quality Control:
This Quality Management Process will help you to improve the quality of your team deliverables. It also
helps you to implement a Quality Assurance Process, to boost confidence in the quality of your outputs.
By implementing quality management in your organization, you can boost the quality of your
deliverables and achieve total success.

This Quality Management Process will help you to:

Set Quality Targets to be met by your team
Define how those quality targets will be measured
Take the actions needed to measure quality
Identify quality issues and improvements
Report on the overall level of quality achieved
Perform Quality Assurance
Undertake Quality Control
Initiate Quality Improvement
Implement Quality Management

A Quality Management Process is critical process within any business, as it helps you to ensure that the
deliverables produced, actually meet the requirements of your customer. This Quality Management
Process will help you to improve the quality of your deliverables, today.

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.
You should implement a Quality Management Process any time that you want to improve the quality of
your work. Whether you are producing deliverables as part of a project or operational team, an effective
quality management and quality assurance process will be beneficial. By implementing this Quality
Management Process, you can ensure that your team's outputs meet the expectations of your customer.
Change Management Process:
This Change Management process helps you to manage all requests for change within your project. By
putting this change process in place, you'll easily be able to monitor and control the amount of change
that takes place. Within the Change Management Process, each of the key steps for managing change are
included. It also tells you how to implement control change, through change approvals and reviews. By
using this Change Process, you can:
Identify requests for change
Confirm the feasibility of each change
Control the way that change is undertaken
Manage the approval of change
This Change Process is unique, as it:
Provides a template for managing change
Fully describes every step in the change process
Includes a change process diagram, showing you the steps
Defines the responsibilities of change managers
Describes the change review and approval process
Using an effective Change Process is a core function in any team, as change impacts on your ability to
deliver your objectives, therefore increasing costs and putting pressure on delivery timeframes. To
properly control change, this Change Process sets out all of the steps you need to implement, to manage
change effortlessly.
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.
If you work in a team that is subject to change, then you need a Change Process. By implementing a
Change Process, you can track change as it occurs and control the effect it has on your team. A Change
Process helps you monitor the impact of change on the business, to ensure that each change has the
desired outcome.
Risk Management Process:
This Risk Process shows you all of the steps you need to take to implement Risk Management in your
organization. By using this risk process to monitor and control risk, you can ensure you meet your team
objectives. Within this risk process, all of the steps need to mitigate risk are described in detail. This
Risk Process helps you:
Identify critical and non-critical risks
Document each risk in depth by completing Risk Forms
Log all risks and notify management of their severity
Take action to reduce the likelihood of risks occurring
Reduce the impact on your business, should risk eventuate

This Risk Process is different, as it:

Lists all of the risk procedures in depth
Includes a diagram explaining the risk process
Tells you how to identify, monitor and control risks
Helps you mitigate risk through best practice processes
Most teams are subject to constant risk of meeting their objectives. The key to success lies in how you
manage risks, by putting in place a clear Risk Management Process. This process describes the steps
taken to mitigate risk as it occurs, helping you to meet your team goals more easily.
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.
You use a Risk Process whenever your ability to meet your objectives is at risk. Most teams face risks on
a regular basis. By putting in place this Risk Process, you can monitor and control risks, removing all
uncertainty. The Risk Process involves running risk reviews to identify and quantify risks. The risks are
then documented and the Risk Process helps you take action to reduce the likelihood of them occurring.
This Risk Process will help you put in place the right processes for managing risk today.
Performance Monitoring and Review:
This Project Phase Review Form is completed at the end of the Project Planning phase to tell the sponsor
whether the project has achieved its objectives to date. A project management review is completed and
the results are documented on this Project Review Form. This form helps you conduct a Project Phase
review quickly and easily.
This Project Phase Review Form states whether the:
Project is under schedule and within budget
Deliverables have been produced and approved
Risks have been controlled and mitigated
Issues have been resolved
Project is on track
Document the results of your Project Reviews
Clearly communicate the progress of your project to your sponsor
List any risks or issues which have impacted the project
Show your sponsor the deliverables produced to date
Seek approval to proceed to the next project phase
By implementing Project Phase Reviews, you are putting in place the necessary "check-points" to
monitor and control the project, thereby ensuring its success.
A Project Phase Review is completed at the end of each project phase. During this project management
review, the reviewer completes a Phase Review Form describing the progress of the project to date and
recommending whether or not it should continue to the next project phase. If approved, the next project
phase can be commenced.
A Project Phase Review should be undertaken at the end of each project phase. The project review may
be conducted by the Team Manager or an independent person to the project. During the project
management review, any risks and issues should also be recorded. The Project Phase Review Form is
then completed, documenting the outcome of the review, for approval.
Issue Management Process:
Issues Management is the process of identifying and resolving issues in a project or organization. Using
this Issue Management Process, you can identify and resolve issues quickly, before they have an
undesirable impact. Whether you experience staffing, supplier, equipment or other issues, this process
will guide you through the steps towards their speedy resolution.
This Issue Management Process will help you to:
Identify and record issues clearly

Use Issue Forms to document issues properly

Determine the impact of each issue
Prioritize issues and report on their status
Review all issues and decide on a course of action
Take the steps needed to resolve issues quickly
Assign actions to staff to resolve issues
Monitor the outcome of the actions taken
Assign roles and responsibilities for managing issues
Report on the status of issues to management
Your ability to identify and resolve issues as quickly as possible will directly affect the success of your
team. This Issue Management Process will help you achieve this, by describing the steps taken to
resolve issues swiftly and efficiently.

An Issue Process / Issue Management Process:

It 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.
You follow an Issue Process when you encounter issues that need to be resolved quickly. Examples of
issues that are resolved through an Issue Process include; lack of funding, insufficient resources and
tight deadlines. Regardless of the circumstance, this Issue Process helps you get approval to take action
to resolve it immediately.
Cost Control:
This Project Cost Management Process helps you to monitor and report all expenses within a project.
Costs (or "expenses") are recorded by team members, using Expense Forms. These forms are reviewed
and approved by the Project Manager, prior to the expense items being purchased. The project cost
management process steps you through this process, to ensure that all of the costs within your project are
accurately recorded and tracked.
This project cost management process will help you to:
Identify each of the costs within your project
Ensure that expenses are approved before purchasing
Keep a central record of all costs incurred
Control the overall cost of your project
Determine whether your expenses were adequately budgeted
Monitor and control instances of over-spending
Gain special approvals for extra-ordinary expenses
Schedule expense payments and invoice approvals
Keep your project and financial plans up-to-date
To deliver your project under budget, it is essential that you implement a project cost
management process. This process will help you identify, monitor and control costs, at each
phase in the project.
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. If you want to control the way that expenses are incurred, then you need to implement a
Cost Management process. It will help you to control project expenses, ensuring that only expenses
which have been approved, may take place. Using this Cost Management process, you can also keep
your project plan up-to-date with the latest expense information available.

Project Execution and Control Phase has a direct correlation to project progress and stakeholder's
expectations. Even the minor issues, if unnoticed, can cause major impact on cost, schedule and risk and
deviate the project from the Project Plan, thus emphasizing the importance for the Project Execution and
Control Phase.
PROJECT CLOSURE PHASE
In this last stage, the project manager must ensure that the project is brought to its proper completion.
The closure phase is characterized by a written formal project review report containing the following
components:
a formal acceptance of the final product by the client,
Weighted Critical Measurements (matching the initial requirements specified by the client with
the final delivered product),
rewarding the team,
a list of lessons learned,
releasing project resources,
a formal project closure notification to higher management.
The commencement of the Project Closure Phase is determined by the completion of all Project
Objectives and acceptance of the end product by the customer. Project Closure includes the following
tasks:
Documenting the Issues faced in the Project and their resolutionThis helps other projects to plan for such type of issues in the Project Initiation Phase itself.
Administrative Closure
This is the process of preparation of closure documents and process deliverables. This includes the
release and redistribution of the Project Resources.
Development of Project Post Implementation Evaluation Report
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 actioned. 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.The report includesProject Sign-Off
Staffing and Skills
Project Organizational Structure
Schedule Management
Cost Management
Quality Management
Configuration Management
Customer Expectations Management
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
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.

A Project Closure Report should be documented any time that a project is ready for closure. Using this
Project Closure Report, you can to document the actions needed to perform project closure immediately.
This Project Closure Report already includes the sections, tables and practical examples you need, to
save you time.
Lessons Learned: Lessons Learned form an integral part of the Project Closure Phase. It helps answer
the following typical question during Project ClosureDid the delivered product / solution meet the project requirements and objectives?
Was the customer satisfied?
Was Project Schedule Met?
Was the Project completed within Budgeted Cost?
Were the risks identified and mitigated?
What could be done to improve the process?
Post Implementation Review:
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.

Post Implementation Review can be performed 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
A Post Implementation Review, or 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.
Project closure is the final phase of any project. It is just as important as the other project phases of
initiating, planning and monitoring. However, many companies do not pay sufficient attention to this
phase whereas others just do not bother with it at all.Project closure involves preparing a complete and
comprehensive project file that forms a history of the project. This file can be used as historical input for
future projects. Due to the amount of documentation and data entry required, it is often
overlooked.Project Closure Phase is the last phase of the Project Life Cycle. The commencement of the
Project Closure Phase is determined by the completion of all Project Objectives and acceptance of the
end product by the customer. Project closure must be recognized and documented.

Project Closure includes the following tasks:

Release of the resources, both staff and non-staff, and their redistribution and reallocation to other
projects, if needed.
Closure of any financial issues like labour, contract etc.
Collection and Completion of All Project Records.

Archiving of All Project Records.

Documenting the Issues faced in the Project and their resolution. This helps other projects to plan for
such type of issues in the Project Initiation Phase itself.
Recording lessons learned and conducting a session with the project team on the same. This helps in the
productivity improvement of the team and helps identify the dos and donts of the Project.
Celebrate the Project Completion.
The basic process of the Project Closure Phase involves:
Administrative Closure. This is the process of preparation of closure documents and process
deliverables. This includes the release and redistribution of the Project Resources.
Development of Project Post Implementation Evaluation Report.
It includes
Project Sign-Off
Staffing and Skills
Project Organizational Structure
Schedule Management
Cost Management
Quality Management
Configuration Management
Customer Expectations Management
Lessons Learned
The outputs from Project Closure Phase provides as a stepping stone to execute the next projects with
much more efficiency and control.
Benefits of Complete Project Closure
There are many benefits that are derived from closing the project properly. It improves the morale and
confidence of the project team. The team members feel a sense of achievement. Therefore, performance
on future projects can improve.
Customer satisfaction is also increased. The company receives experience in controlling project costs.
Staff members can learn from the project's lessons and they will be able to continually improve the
company's processes.
EARLY PROJECT TERMINATION:
There are many reasons why a project eventually ends. They are
Termination by Extinction.
Termination by Addition.
Termination by Integration.
Termination by Starvation.
Termination by Extinction
These two clear can solutions lead to termination by Extinction.
Project Success:
Project success happens when the project has achieved its objectives & goals and when a new
product is handed over to the client.
Project Failure:
Project failure happens when the project fails to achieve its objectives and goals.

Termination by Addition
May occur when a project has been a success and it is picked by the whole organization or it was
developed in a company and is picked by their parent company.
This may result in key personnel transferred to continue work in a new environment with the
radical overhauls of operating budget and practices to meet new organizational standards.
It is true that some projects which work well in one company do less in a wider settings as a
result of changes in key staff or operational procedures.
Termination by Integration
The project is decomposed into separate areas of functionality which are dispersed.
This may leads to obvious considerations of how the staffs are relocated, necessary training is
achieved, design and manufacturing plans are managed.
Termination by Starvation
Occurs when resources used by a project are slowly moved or incrementally diminished for other
purposes.
It could be that a project has become obsolete but there is a political reason not to be seen to
terminate it by the management.
Any evolution or development progress is frozen on the project which remains on the books in
the form of a lame duck project.

PROJECT CONSTRAINTS
The primary impact of project constraints is the likelihood of delaying the completion of the project.
There are three types of project constraints: technological, resource and physical. The technological
constraints relate to the sequence in which individual project activities must be completed. For example,
in constructing a house, pouring the foundation must occur before building the frame. Resource
constraints relate to the lack of adequate resources which may force parallel activities to be performed in
sequence. The consequence of such a change in network relationships is delay in the completion date of
the project. We will examine the nature of resource constraints in much greater detail in the next section.
Physical constraints are caused by contractual or environmental conditions. For example, due to space
limitations an activity such as painting a wall may have to be performed by only one person. In general,
from a scheduling perspective, projects can be classified as either time constrained or resource
constrained. A project is classified as time constrained in situations where the critical path is delayed and
the addition of resources can bring the project back on schedule and the project completed by the
required date. However, the additional resource usage should be no more than what is absolutely
necessary. The primary focus, for purposes of scheduling, in time constrained projects is resource
utilization. On the other hand, a project is resource constrained if the level of resource availability
cannot be exceeded. In those situations where resources are inadequate, project delay is acceptable, but
the delay should be minimal. The focus of scheduling in these situations is to prioritize and allocate
resources in such a manner that there is minimal project delay. However, it is also important to ensure
that the resource limit is not exceeded and the technical relationships in the project network are not
altered.
RESOURCE CONSTRAINTS
The most important resources that project managers have to plan and manage on day-to-day basis are
people, machines, materials, and working capital. Obviously, if these resources are available in
abundance then the project could be accelerated to achieve shorter project duration. On the other hand, if
these resources are severely limited, then the result more likely will be a delay in the project completion
time. Depending on the type of resources, the costs of providing an abundance of such resources to
accelerate project completion time can be very high. However, if resources are readily available and

excess premiums are not incurred to use them on the project, then project cost should be low, as some
project costs are resource related while others are likely to be time dependent. In general, projects with a
shorter duration are less expensive. The longer the duration of the project, the higher will be overall
project cost due to the increase in fixed costs such as overheads. The reality is that as long as the work
on a project is ongoing it will continue to draw resources into its orbit. Whatever the parameters of the
project, it is unlikely that the relationship between cost and duration is linear. For any particular project,
the decision to place the project on the curve between the point of least duration with its associated
higher resource requirements and a point of increased duration with its associated lower resource
requirements depends on the particular parameters of the project.
When a project plan is first devised it is likely that the plan will identify peaks of resource requirements.
However, given the finite nature of resource availability, it may be impractical to meet such peak
resource needs. Ideally, there should be an even demand for resources over the entire project duration,
with a smooth increase at the beginning of a project and a smooth decrease at the end. Given the limited
nature of resources, thoughtful consideration should be given to the project resource requirements; the
project plan should be refined when necessary so that it is practical. The process of refining the plan to
effectively manage and schedule resources (sometimes referred to as resource modeling) comprises four
major stages: resource definition, resource allocation, resource aggregation, and resource leveling
(which include resource smoothing). In the subsequent sections we will discuss of these major stages.

THE THREE CONSTRAINTS OF PROJECT MANAGEMENT

When the procedure of project management is being used to complete a project, there are certain
constraints that the team must deal with. This is something that is to be expected. The three constraints
of project management are cost, time, and scope. Many people call this the Project Management
Triangle, and each side of the triangle symbolizes one of the constraints. It is impossible to change one
part of this triangle without having an effect on the other sides. Understanding these constraints are
critical for those who wish to be successful with the project management process. As the name suggests,
the time constraint deals with the time necessary to finish a project. To successfully complete a project,
the time constraint should be comprised of a schedule. You should have a specific schedule related to the
time that it will take you to finish the project. However, before you can create a schedule, you must first
sit down and figure out a projected time frame for the project. Once you have figured out the total time it
will take for a project to be completed, you must next break this down into a schedule. There should be a
time frame for completing specific parts of the project, and there should be a time frame that deals with
the completion of components that make up these parts.
The three constraints of project management will almost always be competing with each other. If a team
decides to enlarge the scope of a project, the time will become larger as well, along with the cost. If the
time constraint is tighter, the scope may be reduced, but the costs will remain high. If the team should
decide to tighten the budget, the scope will become smaller but the time will increase. To become skilled
in project management, the project manager and their team must be capable of dealing with these
constraints in a way that will allow them to successfully complete any project that they plan.
Cost is another of the three constraints that you will want to become familiar with. The cost involved
with successfully completing a project is dependent on a number of different elements, and some of
these are material costs, the costs of labor, risk, and machines. The profit must also be analyzed when
one is considering the cost constraint. If you are hiring a consultant who is independent, the cost of your
project will be dependent on how much they charge "per diem." This cost will generally be multiplied by
a calculated quantity. The cost constraint is very important, and it should never be overlooked.
The third constraint of project management is scope. Scope can be defined as the tools and resources
that are needed to achieve the end objective of the team. The scope can also be defined as the goal of the
overall project, what it is supposed to achieve. Perhaps one of the most important aspects of the scope is
the quality of the end product or service that is produced. How much time the team puts into the project
is directly connected to its quality. Some projects will require a longer period of time in order to be
completed properly. Looking at the scope of the project is similar to looking at the big picture of what
you are trying to accomplish.
VISUALIZING PROJECT CONSTRAINTS
Scope, Time, and Cost make up the three corners of the triangle that project management professionals
refer to as project constraints. In an equilateral triangle, all three corners are equal, and projects come
in on time and on budget, while addressing all of the needs originally expressed by project stakeholders.
However, if just one of the corners starts to fall out of line with expectations, the entire project can
become distorted.

PLOTTING PROJECT CONSTRAINTS

Some project management professionals use the project constraints triangle in a different way. Keeping
all three of the angles representing project constraints at a consistent sixty degrees, managers using the
plotting method map the triangle to an X-Y axis. Using this kind of diagram represents projects that do
not change in size, but still undergo changes in scope, time, or cost.
Plotting project constraints can illustrate quickly to managers how small changes in budgets or
timelines can impact the overall quality of a teams work. In the example below, a project suffers from
"feature creep," causing distortion of the project's scope. If project leaders fail to account for the
increased costs of the project, it will simply take team members more time to accomplish all of their
tasks.
CHALLENGES TO PROJECT CONSTRAINTS
Challenge #1: Lack of Accountability
Working without cost as a project constraint might sound like an ideal situation for some project
managers. However, a blank check for a team initiative often results in a lack of accountability for team
members and their leaders. When money is no object, team members tend to buy their way out of
problems instead of focusing on creative solutions. In most cases, oversight from stakeholders usually
arrives very late in the project process and often takes a very negative tone toward the relative return on
investment. To prevent this kind of situation, project managers must hold themselves accountable to
initial budgets, even if higher level managers dont show the same restraint.
Challenge #2: Cost Centers as Commodities
As companies of all sizes try to cut costs, job costing has become a way to gauge the value of internal
human resources in the same way that accountants would track the costs of independent contractors.
Unfortunately, in some organizations, job costing allows department heads to set flexible rates for their
team members that dont always scale on the same cycles as projects. As a result, project managers can
suddenly find themselves with cross-departmental teams that actually cost more than they did when
original budgets were estimated. Strong project leaders can often find ways to offset rising personnel
costs by developing their own profit centers. Sharing research and development tasks with other
projects, increasing the book value of a teams output, and outsourcing some team functions to less
expensive contractors can help leaders keep costs in check.
Challenge #3: Unexpected Budget Cuts
Of course, the worst possible scenarios for project managers include rounds of sudden budget cuts. A
strong project statement with a scope that includes need to have and nice to have goals can act as a
buffer in this kind of situation. Many project managers tasked with keeping projects on track during cost
containment try to identify and eliminate non-critical physical resources before looking at staff cuts.
Some leaders find temporary success by asking team members to cover the duties of positions that have
been left unfilled through attrition. In the worst cases, some internal job duties may be outsourced to
independent contractors. While nobody enjoys making these difficult decisions, strong leaders find ways
to meet project goals, even when suffering through budget cuts.
a) Resource Constraints

Key staff resources will be available only on a part-time basis.

Computer resources will be available on a limited basis.

Key customer resources will be available on a restricted basis.

A significant percentage of the project staff will not be experienced with the technical
environment.

A significant percentage of the project staff will not be experienced with the operating
environment.

The customer has limited staff capable of adequately describing in detail the functional
requirements of the system.

The customer has limited staff capable of adequately describing in detail the operational
requirements of the system.

b) Delivery Constraints

Deliverables submitted for approval will require working days for review.

There is no limit to review and approval cycles.

Equipment order lead times cannot be specified with accuracy.

c) Environmental Constraints

The development or operating environment is new, and no project staff members are familiar
with it.

Key decision-makers are difficult to contact when issues arise.

The project does not have a customer project manager (or executive sponsor, or steering
committee)

The project environment is new and the components have not yet been successfully integrated.

The project depends upon the successful and timely completion of associated projects.

d) Budgetary Constraints

Statistics used in preparing the estimates are unreliable.

Outside consulting requirements cannot be accurately estimated.

e) Functionality Constraints

The scope of the project is unclear.

The project depends upon receiving data from other, external applications.

Challenge #4: Feature Creep

This term from the software development world can easily apply to any project that suddenly finds itself
bloating with requests. Most project managers associate feature creep with conversations that contain the
phrase, while youre in there Most incidences of feature creep actually start with good intentions. A
team member may have discovered a need for a new enhancement, or an element from one portion of
the project may become applicable to the project as a whole.
Regardless of the intent, its up to a dedicated project manager to make sure feature creep doesnt cause
the entire enterprise to derail from its other two project constraints. When time and budget can
accommodate new requests, project managers can graciously agree to them. However, managers who
discover that a simple task could throw a team over budget or off schedule must firmly deny new
features during the implementation phase.
In many cases, project managers can use the parking lot method of logging requests and addressing
them as time and budget permit. At other times, managers must simply refer requestors to the original
project documentation to back up their belief that new features must be put on hold.
Challenge #5: Lack of Clarity
When projects rush through the appraisal and preparation stages of the project cycle, they can suffer a
lack of clarity that will threaten to knock teams far off course. Its easy enough for feature creep to
happen in strongly defined projects. Its almost impossible to avoid it when projects arent clearly
defined. Furthermore, without a guiding vision for a project, stakeholders can muddle a teams progress
by inserting their own ideas and agendas.
The project manager must exercise strong leadership skills in this kind of environment, especially if the
lack of clarity infects team members morale. To prevent sudden changes in the scope of a project, a
strong manager must carefully and accurately document project details from the very beginning of the
project cycle. For project managers picking up a team midstream, taking time to document progress so
far creates an opportunity to reconnect with the original vision that inspired the project in the first place.
Challenge #6: Changing Agendas

In the worst instances where teams violate project constraints, a new set of stakeholders enters the
process during the implementation phase. When new stakeholders dont understand the original intent of
a project, they may demand major changes. Expert project managers use these discussions as an
opportunity to return to the appraisal and presentation stages of the cycle, hopefully to wrangle a new
budget and timeline. Unfortunately, many project managers find themselves leading their teams with
new goals and without any additional time or money.

STRATEGIC PLANNING: In strategic planning, resource allocation is a plan for using available
resources, for example human resources, especially in the near term, to achieve goals for the future. It is
the process of allocating resources among the various projects or business units. The plan has two parts:
Firstly, there is the basic allocation decision and secondly there are contingency mechanisms. The basic
allocation decision is the choice of which items to fund in the plan, and what level of funding it should
receive, and which to leave unfunded: the resources are allocated to some items, not to others. There are
two contingency mechanisms. There is a priority ranking of items excluded from the plan, showing
which items to fund if more resources should become available; and there is a priority ranking of some
items included in the plan, showing which items should be sacrificed if total funding must be reduced.
The main objective is to smooth resources requirements by shifting slack jobs beyond periods of peak
requirements. Some of the methods essentially replicate what a human scheduler would do if he had
enough time; others make use of unusual devices or procedures designed especially for the computer.
They of course depend for their success on the speed and capabilities of electronic computers. Resource
allocation may be decided by using computer programs applied to a specific domain to automatically
and dynamically distribute resources to applicants. It may be considered as a specialized case of
automatic scheduling. This is especially common in electronic devices dedicated to routing and
communication. For example, channel allocation in wireless communication may be decided by a base
transceiver station using an appropriate algorithm. One class of resource allocation algorithms is the
auction class, whereby applicants bid for the best resource(s) according to their balance of "money", as
in a online auction business model.
In one paper on CPU time slice allocation an auction algorithm is compared to proportional share
scheduling.
Developing the Project Plan: Whether you call it a project plan or a project timeline, it is absolutely
imperative that you develop and maintain a document that clearly outlines the project milestones and
major activities required to implement your project. This document needs to include the date each
milestone or major activity is to be completed, and the owner of each. Your project plan also needs to be
created at the beginning of the project, and a baseline version approved by the team as soon as possible.
Although you will probably not know all of the major activities required to implement your project in
the beginning, it is important that you create a draft of the activities you think may need to be tracked
via a formal document. Take some time and really think through what you know about the objective of
your project. Look at some historical data from similar projects. You can even have a few informal
meetings with knowledgeable individuals you can use as a sounding board to make sure you aren't
completely off base. You'll be surprised how good a draft you can develop if you put in a little effort.
With this draft you will be able to speak with subject matter experts (SMEs) and stakeholders to flesh
out the project plan. If you don't make some level of effort to develop a rough draft, you may give a bad
impression which will make it harder for you to obtain the support of the persons you need to implement
the project.
After you have fleshed out your draft with your core team, and some other SMEs that may not be a part
of your team, you should give the document a baseline status. Your timeline / project plan should not
undergo many edits, if any, after it achieves baseline status.
You should document the actual date your project activities are completed. If the actual completion date
differs from your baseline date at anytime, you'll still have documented the date it was supposed to be
completed for historical purposes.
It is also a good idea to notate where things are deleted or added, and why. That way you aren't standing
there looking crazy, trying to go through the crevices of your memory, when someone asks you why
something you deleted isn't in the document.

A few key items to include in your timeline are:

A unique ID that your team can reference when giving an update The name of the task
When the task should start
When the task should finish
The actual date the task was completed
Any tasks that need to happen before other tasks can begin
The owner of the task
Percent complete of each task
Developing project plan: Management consulting projects often drive mission-critical initiatives within
a client organization. They can also consume valuable client resources such as time and money.
Developing project plans at the start of the project that clearly set client expectations regarding scope,
timeline, and budget is critical to ensuring that efforts and hard work pay off, and that potential
hardships are avoided later.
Project bottlenecks
Hurry up and wait The client wants the project to begin as soon as possible, so you work overtime to
get the scope document, budget, and timeline together. But when you are ready, the client fails to make
its resources information and people available in a timely manner.
Scope creep You work overtime to meet the client's expectations, even though their expectations
included deliverables that weren't part of the original scope discussion. This is especially problematic for
fixed-price contracts.
Endless brainstorming Sometimes the client has an idea of what they want you to discover during the
course of a project, and if you don't find it, they want you to try again.
Two departments, one project objective Sometimes, especially at larger companies, you get involved
in a project and you find out that another department is working on a similar project.
Late or no payment Some consultants fail to set proper payment expectations with clients, resulting in
an excessively delayed payment.
Planning recommendations: The following planning suggestions can help you better navigate the
process of getting client buy-in at the start of a project.
Identify the project champion: There must be a clear project champion someone at a high level within
the client organization who supports your team. This individual must have enough clout in the
organization to gain access to key people and resources, and to eventually help sell ideas to the decisionmakers. The project champion can help:
Ensure that you have access to client staff and information to prevent bottlenecks that could affect your
project timeline.
Gather feedback on project hypotheses by researching findings and status from within the organization
as a litmus test for how other client executives might react.
Identify any other projects within the organization that have similar objectives. You want to make sure
that the client resources are being used effectively and that any complementary efforts are coordinated.
Establish clear project scope: Most likely, you participated in a thorough proposal and pitch process
before being awarded the contract. Even if you reviewed the project scope during that discussion, it's a
good idea to refine it at the beginning of the project. The following can help you establish a clear project
scope:
Discuss initial hypotheses to test as soon as possible. Some client executives don't like to be surprised by
transformational ideas or assumptions in the final recommendations meeting with their peers. Gain an
understanding of executive response early in the project.
Outline the tasks and deliverables that are and are not covered in the project scope, in order to set client
expectations. Sometimes the client will choose before the project begins to expand the scope after the
out-of-scope issues are communicated.

Clarify format of deliverables. Make sure that the client knows the format of the various deliverables so
that they don't have unrealistic expectations about the level of detail. Also, make certain that the client
has realistic expectations regarding your participation in training and follow-up meetings as well as how
many iterations of a project you will complete before requiring a change order especially in the case
of fixed-price contracts.
Have the client sign off on a scope document at the beginning of a project. Be careful not to make this
process so formal as to put off the client.
Consistently review the original scope as you work through various milestone meetings during the
course of the project.
Clearly outline the project timeline: Consulting projects can take weeks or months to complete. Also,
they are often at the front end of larger operational initiatives, such as technology implementations,
product development, or process reengineering efforts. The following can help you establish a clear
project timeline:
Outline the due dates of key milestones and when you expect to have the project wrapped up. This way,
your client can coordinate your deliverables with other important company events board meetings,
earnings releases, or national sales meetings where they might want to present some of the project
findings.
Include deadlines in your schedule for items that the client must provide to you, so they know their
responsibilities. If they miss deadlines and force your schedule to shift, it will have been clear from the
beginning.
Identify required client and consulting resources and when they will be needed along the project
timeline. You can do this most effectively in terms of full-time equivalents (FTEs).
Make sure there is enough time for your team to complete the necessary research and analysis to make
solid recommendations, while still allowing the client sufficient time to implement those
recommendations.
Define how to handle billing issues: Client budgets are often tight, and miscommunication regarding
billing issues can sour an otherwise good client relationship. Up-front and honest communication
regarding all billing-related issues can positively contribute to your client relationship. The following are
some suggestions on how to handle billing issues:
Provide assumptions as to how you arrived at your price, such as the estimated number of hours and
hourly rates that you used as the basis for the project price.
Establish a mechanism for dealing with out-of-scope issues. If your master services agreement allows
for it, and the client wants you to perform additional work, issue change orders that follow an agreedupon format.
Gain a clear understanding of when invoices will be paid and if the client expects any discounts for early
payment, so you aren't surprised when you get the checks.
Clearly communicate how travel, meals, and other expenses will be billed. These expenses can add up,
especially on out-of-town engagements.
Ask for a down payment before the project begins. This shows that the client is committed to the project,
and that it has cleared the appropriate decision-making process that allows you to get paid.
Present your project plan in a kickoff meeting: The relationship between consultant and client is critical
to the ultimate success of the project. If your clients feel that they were not adequately communicated
with, or are surprised or overwhelmed, they might not embrace your recommendations. Presenting your
plan in a project kickoff meeting can earn their immediate trust, which can pay off later. The following
guidelines can help you plan a successful kickoff meeting:
Get the right people in the room. Work with the project champion to ensure that the meeting includes all
the relevant decision-makers so they clearly understand the project's scope, objectives, initial
hypotheses, research plan, and the broader strategic context in which the project exists.

Present the project timeline indicating when key meetings, interviews, and presentations will take place,
as they include the participation of your audience.
Distribute a hard-copy version outlining this timeline as well as the project scope and deliverables. You
can later reference this copy in future conversations. Meeting attendees can also use the copy to
communicate the project's objectives to their peers and subordinates.
Maintain clear communication: Even though consulting projects deal with high-level strategic and
operational issues, at the end of the day they are just projects. As such, it is important for all consultants
to have project management skills and clear communication methods in place. In general, the more
information that can be openly and honestly communicated about the project's scope, budget, and
timeline, the better off both you and your client will be.
Steps in Project Planning: The key to a successful project is in the planning. Creating a project plan is
the first thing you should do when undertaking any kind of project. Often project planning is ignored in
favour of getting on with the work. However, many people fail to realise the value of a project plan in
saving time, money and many problems.
Step 1: Project Goals: A project is successful when the needs of the stakeholders have been met. A
stakeholder is anybody directly, or indirectly impacted by the project. As a first step, it is important to
identify the stakeholders in your project. It is not always easy to identify the stakeholders of a project,
particularly those impacted indirectly. The project sponsor, The customer who receives the deliverables,
The users of the project outputs, The project manager and project team are some Examples of
stakeholders.
Once you understand who the stakeholders are, the next step is to find out their needs. The best way to
do this is by conducting stakeholder interviews. Take time during the interviews to draw out the true
needs that create real benefits. Often stakeholders will talk about needs that aren't relevant and don't
deliver benefits. These can be recorded and set as a low priority.
The next step, once you have conducted all the interviews, and have a comprehensive list of needs is to
prioritise them. From the prioritised list, create a set of goals that can be easily measured. A technique
for doing this is to review them against the SMART principle. This way it will be easy to know when a
goal has been achieved.
Once you have established a clear set of goals, they should be recorded in the project plan. It can be
useful to also include the needs and expectations of your stakeholders. This is the most difficult part of
the planning process completed. It's time to move on and look at the project deliverables.
Step 2: Project Deliverables: Using the goals you have defined in step 1, create a list of things the
project needs to deliver in order to meet those goals. Specify when and how each item must be
delivered.
Add the deliverables to the project plan with an estimated delivery date. More accurate delivery dates
will be established during the scheduling phase, which is next.
Step 3: Project Schedule: Create a list of tasks that need to be carried out for each deliverable identified
in step 2. For each task identify the following:
The amount of effort (hours or days) required to complete the task.
The resource who will carryout the task.
Once you have established the amount of effort for each task, you can workout the effort required for
each deliverable, and an accurate delivery date. Update your deliverables section with the more accurate
delivery dates.
At this point in the planning, you could choose to use a software package such as Microsoft Project to
create your project schedule. Alternatively, use one of the many free templates available. Input all of the
deliverables, tasks, durations and the resources who will complete each task.
A common problem discovered at this point, is when a project has an imposed delivery deadline from
the sponsor that is not realistic based on your estimates. If you discover that this is the case, you must
contact the sponsor immediately. The options you have in this situation are:

Renegotiate the deadline (project delay).

Employ additional resources (increased cost).
Reduce the scope of the project (less delivered).
Use the project schedule to justify pursuing one of these options.
Step 4: Supporting Plans: This section deals with plans you should create as part of the planning process.
These can be included directly in the plan.
Human Resource Plan: Identify by name, the individuals and organisations with a leading role in the
project. For each, describe their roles and responsibilities on the project. Next, describe the number and
type of people needed to carryout the project. For each resource detail start dates, estimated duration and
the method you will use for obtaining them.
Create a single sheet containing this information.
Communications Plan: Create a document showing who needs to be kept informed about the project and
how they will receive the information. The most common mechanism is a weekly or monthly progress
report, describing how the project is performing, milestones achieved and work planned for the next
period.
Risk Management Plan: Risk management is an important part of project management. Although often
overlooked, it is important to identify as many risks to your project as possible, and be prepared if
something bad happens. Here are some examples of common project risks:
Time and cost estimates too optimistic.
Customer review and feedback cycle too slow.
Unexpected budget cuts.
Unclear roles and responsibilities.
Stakeholder input is not sought, or their needs are not properly understood.
Stakeholders changing requirements after the project has started.
Stakeholders adding new requirements after the project has started.
Poor communication resulting in misunderstandings, quality problems and rework.
Lack of resource commitment.
Risks can be tracked using a simple risk log. Add each risk you have identified to your risk log; write
down what you will do in the event it occurs, and what you will do to prevent it from occurring. Review
your risk log on a regular basis, adding new risks as they occur during the life of the project. Remember,
when risks are ignored they don't go away.
Remember to update your plan as the project progresses, and measure progress against the plan.

COST AND RESOURCE CONSIDERATIONS IN PROJECT PLANNING: In many instances you can
actually change activity completion times by allocating more resources to it. How can you decide which
activities are the best to give more resources to and how much you should give?
Key characteristics of project plans: A project plan can be considered to have five key characteristics
that have to be managed:
Scope: defines what will be covered in a project.
Resource: what can be used to meet the scope.
Time: what tasks are to be undertaken and when.
Quality: the spread or deviation allowed from a desired standard.

Risk: defines in advance what may happen to drive the plan off course, and what will be done to recover
the situation.
The sad thing about plans is you cannot have everything immediately. Many people plan using planning
software packages, without realising the tradeoffs that must be made. They assume that if they write a
plan down, reality will follow their wishes. Nothing is further from the truth. The point of a plan is to
balance:
The scope, and quality constraint against,
The time and resource constraint, While minimising the risks.
Balance Plan: If The scope of a project plan is so large that there is no way the time, resource, and
quality constraints can result in the project delivering, which means there are enormous risks.
To salvage this plan, requires reducing the scope, increasing the time, or resource, or lowering the
quality standard. Any of which will reduce the risk of failure. The key lesson is that plans have to be
balanced within the project constraints if they are to deliver.
Project Planning with Uncertain Activity Times: Generally the distribution of the activity times is
unknown and must be estimated. A typical method of dealing with the situation is to estimate three
activity duration times for each activity, optimistic, most likely and pessimistic. Use these estimates to
estimate a normally distributed activity time:
most optimistic time (a): the probability of completing the activity in less than a is about 1%
most likely time (m): the estimated average time required to complete the activity
most pessimistic time (b): the probability of taking longer than b is about 1%
The activity time is assumed to be normally distributed with mean, te, and variance as follows:
Expected time: te = ( a + 4m + b ) / 6
Variance: var[te] = [ ( b - a) / 6 ]2
Assumptions:
1. Duration of activities along the critical path determine project completion time
2. Duration time of one activity is independent of duration times of all other activities. Using the Central
Limit Theorem, the project completion time is assumed to be normally distributed with the mean equal
to the sum of the activity times on the critical path the variance is equal to the sum of the variances of
the activities on the critical path.
Once the mean and standard deviation of the critical path are known it is possible to calculate the
probability of completing the project in a certain time.
If a project has two critical paths, the critical path with the largest variance should be used to calculate
the probability that the project will be completed within a certain time.
Note - Only considering the critical path makes a very strong assumption. In real situations you should
be aware of the other paths which may become critical. If an activity that is not on the critical path has a
large variance of duration time, it is possible for that activity to become a critical path activity simply
through random occurrences.
Approach to Project Planning: The following situation is very common for a product development
organization. How to rapidly develop an accurate project plan estimate which is critical to the overall
development lifecycle (resources, relation to other projects and dependencies on other deliverables
should be always well defined) and at the same time minimize the time spent performing if-then-else
analysis. Business and technical analysts and project managers have their hands full doing real things
implementing new customer requested functions and working on the next release of the product.
Project Planning Process: The process of planning and assessment consists of the 5 main steps:

Define the Project: During this phase we put together the regular project plan in MS Project with the
main tasks, timeframes and deliverables. The project plan can be
created either manually, or be
generated as the result of other efforts (doing some preliminary use cases or object design or working
with the cost estimate tools).
Identify Uncertainity: In this phase we need to determine:
Which tasks, or their inputs in the plan are uncertain
What we know about these uncertainties
What would be the best way to describe these uncertainties
The behaviour and known range of values they might cover.
During this phase we also need to identify what are the most critical results we want to look at, analyse
and optimize as outputs of our plan.
Apply the tool and implement the model: From the wide variety of the available packages weve
selected Palisades @Risk for Project (http://www.palisade.com) as our project optimisation tool. We
believe that this tool is a good match for most requirements.
It is:
Integrated with the MS project
Easy to set up the model
Sufficient depth of simulation and outputs
Is easy to use for analysis
A particular tool selection only affects the way an uncertainty model will be applied. The general
approach to problem handling will remain the same.
Run simulation: As the result of the Monte Carlo simulation (parameters of this simulation can be
configured as well) we can obtain the ranges and probabilities of all outcomes for the outputs that weve
identified during model setup. Normally its the ranges of the duration for particular phases, or the
project with the most critical dependencies, overall project timeframe, etc.
Make a decision: Based on the simulation results, and looking at the outputs of the model, we obtain the
information about most critical characteristics of the project. This data serve as the basis for the
following optimisation and corrective actions.
Working with the tool: @Risk is tightly integrated with MS Project and looks as the additional tool set
on the MS project panel (see picture below). By selecting particular project parameters (for example
duration of the task) and clicking on the Define Distribution icon on the @Risk tool bar, we can set
up model characteristics.
The tool is quite flexible in definition of the distribution widows. Out of the box its easy to find
anything from the uniform or normal distribution, up to the more exotic ones.
Establishing Project Parameters: We use our past projects experience and historical knowledge to
define the possible ranges for different tasks and distribution functions. For any distribution function we
can define its fine structure, like average value, standard deviation, etc. There is also another advanced
feature which allows us to add additional custom uncertainties to the selected tasks or group of tasks.
Model outputs are specified in the same manner. Click on the selected cell (for example, finish date or
duration) and specify it as the output. You can see the corresponding notations in the @Risk:Functions
column of the Project.
Creating the Implementation Model: An implemented model could be enhanced by putting additional
conditions (e.g. a @Risk icon with an IF on it, 6 th from the left on the tool bar). For example, we
know that if wed spent all available time on doing one particular task another dependent task should
happen only within strictly limited timeframe and thats exactly what If-Then function of the model is
supposed to take into account.

Project Model Output: After running the simulation, the output window will look like the one presented
below.
You can see the defined outputs of the finish dates for the elaboration and construction phases, as well as
the total duration of the construction phase (as they were defined as the outputs of the model). Results
show quite a significant range in the finish date for the construction phase (overall more than a month
uncertainty in the final date) and we might want to re-evaluate the project setup (sequence and task
dependencies as well as resource allocation).
The simulation data provide answers to the additional questions. For example to give the probability that
the project or its phase will be
finished before the certain date together with providing more granular
information about project dynamics and showing the most critical parameters for the project cycle
(sensitivity analysis)
There are multiple ways to display the graphical representation of the simulation results. This also
makes the analysis tasks easier.
Excel Project Planning Tools: Since we mentioned an Excel based enhancements, its worth saying a few
words about them. Palisade also has another version working for Excel. For these set of add‑ins,
we would import our project plan into an Excel spreadsheet and then use similar logic for setting up a
model with the risks and uncertainties. We could then co the simulation. Wed tried Whats Best from
Lindo Systems, OptiRisk from OptiGroup and they all work in a similar fashion. Recognized
leaders like Solver or Crystal Ball add more functionality and better user interface. As we discussed
above, the general approach will stay the same regardless of the tool being used. There are two other
tools similar to @Risk: Risk + and Pertmaster.
CERTAIN DEFINITIONS
Acceptance Management: The process by which deliverables produced by the project are reviewed and
accepted by the customer as meeting their specific requirements
Acceptance Planning: The process of identifying the milestones, criteria and standards for the
acceptance of project deliverables by the customer
Business Case: A document outlining the justification for the initiation of a project. It includes a
description of the business problem (or opportunity), a list of the available solution options, their
associated costs and benefits and a preferred option for approval
Change Management: The process by which changes to the project scope, deliverables, timescales or
resources are formally defined, evaluated and approved prior to implementation
Communications Management: The process by which formal communications messages are identified,
created, reviewed and communicated within a project
Communications Planning: The process of identifying the type and regularity of information to be
provided to all project stakeholders to keep them informed of the progress of the project
Cost Management: The process by which costs (or expenses) incurred on the project are formally
identified, approved and paid
Deliverable: A quantifiable outcome of the project which results in the partial (or full) achievement of
the project objectives
Dependency: A logical relationship between two or more project activities. The four types of
dependencies include: start-to-finish, start-to-start, finish-to-start, finish-to-finish
Feasibility Study: A document which identifies each of the solution options to a particular business
problem (or opportunity) and assesses the likelihood of each options achieving the desired result
Financial Planning: The process of identifying the financial resources required to undertake the project.
This includes a list of the types of costs to be incurred on the project (e.g. labor, equipment, materials
and administration costs) and a schedule outlining when the respective costs are likely to be incurred

Issue: Events which are currently affecting the ability of the project to produce the required deliverables
Issue Management: The process by which issues are formally identified, communicated, monitored and
resolved
Job Description: A document which describes a particular role and its responsibilities within a project
Milestone: The recognition of an important event within the project, usually the achievement of a key
project deliverable
Procurement Management: The process by which product is actually sourced from a preferred supplier,
including the on-going management of the supplier relationship
Procurement Planning: The process of identifying the products to be sourced externally and the methods
for acquiring them
Product : A good or service which is acquired from an external supplier to assist with the production of a
project deliverable
Project: A unique endeavor to produce a set of deliverables within clearly specified time, cost and
quality constraints
Project Activity: A set of project tasks which usually results in the partial (or full) completion of a
project deliverable
Project Lifecycle: A series of project phases which are undertaken in either sequential or parallel order
Project Management: The skills, tools and management processes required to successfully undertake a
project
Project Office: The physical premises within which Project Administration staff (e.g. the Project
Manager and support staff) reside
Project Phase: A set of project activities and tasks which usually result in the completion of a project
deliverable
Project Plan: A document which lists the phases, activities, tasks, timeframes and resources required to
complete the project
Project Schedule: A series of planned dates within which activities and tasks have to be completed to
achieve project milestones
Project Task: A specific work item to be undertaken which usually results in the partial completion of a
project deliverable
Project Team: A collation of people who report to the Project Manager
Quality: The level of conformance of the final deliverable(s) to the customers requirements
Quality Assurance: The preventative steps taken to eliminate any variances in the quality of the
deliverable produced from the quality targets set
Quality Control: The curative steps taken to eliminate any variances in the quality of the deliverable
produced from the quality targets set
Quality Management: The process by which the quality of the deliverables and management processes is
assured and controlled for the project, using Quality Assurance and Quality Control techniques
Quality Planning: The process of identifying the approach taken to ensure the quality of the deliverables
produced by the project and of the management processes undertaken. This includes a list of the quality
criteria and standards to be achieved as well as the Quality Assurance and Quality Control techniques to
be undertaken
Request for Information: A document which is issued by a project to a wide group of potential suppliers
to enable those suppliers to provide summarized information outlining how they will meet the
procurement requirements of the project

Request for Proposal: A document which is issued by a project to a short-listed group of suppliers to
enable the suppliers to submit a detailed proposal outlining how they will meet the procurement
requirements of the project
Resource: The labor, equipment and materials used to complete the activities in the Project
Resource Planning: The process of identifying the resources required to complete the project. This
includes a list of the types of resources required and a schedule providing the use of and activities
undertaken by each resource
Risk: Any event which is likely to adversely affect the ability of the project to achieve the defined
objectives
Risk Management: The process by which risks to the project (e.g. to the scope, deliverables, timescales
or resources) are formally identified, quantified and managed during the project. The process entails
completing a number of actions to reduce the likelihood of occurrence and the severity of impact of each
risk
Risk Mitigation: A set of actions to be taken to avoid, transfer or mitigate a risk, based on its priority.
This includes the preventative actions to be taken during the project to reduce the likelihood of the risks
occurring as well as the contingent actions to be taken to reduce the impact on the project should the risk
eventuate
Risk Planning: The formulation of a document which outlines the foreseeable project risks and provides
a set of actions to be taken to both prevent the risk from occurring and reduce the impact of the risk
should it eventuate
Scope: The total aggregation of deliverables to be produced by the project
Solution: A set of deliverables which, once combined, solve a particular business problem (or realize a
particular business opportunity)
Stage-Gate: A checkpoint at the end of each project phase to ensure that the project has achieved its
stated objectives and deliverables as planned
Statement of Work: A document which defines the procurement requirements of the project in sufficient
detail to enable potential suppliers to determine if they are able to meet those requirements
Supplier Contract: An agreement between the Project Team and an external supplier for the acquisition
of a defined set of products to meet the procurement requirements of the Project
Tender Document: A formal document included during the tender process which outlines the information
required to provide the Project Team with the confidence that a supplier can meet the procurement needs
of the project. The RFI and RFP are both examples of Tender Documents
Tender Management: The process by which interested suppliers are identified, evaluated and selected for
the supply of products (goods or services) to the project. This process entails formalizing the
procurement requirements and tender documentation, receiving tender responses and selecting a
preferred supplier
Terms of Reference: A document which outlines the purpose of the project, the manner in which the
project will be structured and how it will be successfully implemented
Time Management: The process within which time spent by staff undertaking project tasks is recorded
against the project

Unit III
STEPS IN PROJECT APPRAISSAL
Project appraisal involves six broad steps. A brief description of these steps are as follows:
Forecast the costs and benefit: A capital project involves costs and benefits extending over a
period of time. Typically, costs are incurred in the form of initial cash outlays on fixed assets and
net current assets. Benefits are derived in the form of cash inflows from the operations of the
project over its economic life, plus terminal cash inflow from the liquidation of the project at the
end of its economic life.
Apply suitable investment criteria: The stream of costs and benefits of the project has to be
converted into a measure indicating how worth while is the Project. For this purpose, several
investment criteria are used. They fall into two broad categories: discounted cash flow criteria
and non-discounted cash flow criteria.
Assess the risk of the project: Costs and benefits associated with a capital project are almost
invariably subject to risk. There may be a lot of variability characterizing factors like project
cost, sales quantity, selling price, material cost, energy cost, project life, and salvage value. The
actual values of these variables often turn out to be different from their forecast values. Hence,
you should try to get a handle over how the variability in these factors can affect the
attractiveness of the project.
Estimate the cost of capital: The cost of capital is the discount rate used for evaluating a capital
project. Under appropriate conditions, it is measured as the weighted average cost of different
sources of capital employed for financing the project. The cost of a specific source of finance is
defined as the rate of discount that equates the present value of the expected post tax payments to
that source of finance, with the net funds received from that source.
Value the options: The traditional approach to project appraisal calls for judging a project on the
basis of its net present value, obtained by discounting the project cash flow stream using an
appropriate cost of capital. This approach however, is incomplete as it fails to capture the value
of real options embedded in the project. Hence, the traditional Net Present Value analysis needs
to be expanded to include the value of real options inherent in the project.
Consider the overall corporate perspective: Capital investments in plant, machinery, buildings,
research, facilities, product development, marketing programs, and so on are tangible
expressions of a companys strategy. Hence, capital investment decisions must be evaluated from
the overall perspective of the firm. In such an evaluation, due consideration should be given to
general economic outlook, prospects of industries in which the firm operates, and the
competitive position and core competencies of the firm.

Cost & Schedule Estimates: As previously mentioned the principal measures of a project are cost, time
(schedule) and performance. For a given project one or more of these measures may be constrained. For
LAACES your launch opportunity has a fixed date and you must have a pay load ready by this date.
Initial estimates on cost and schedule are essential to determine if your plan is realistic. Cost and
schedule needs to be monitored throughout the project life-cycle

Factors affecting the estimate of cost:

Task Definition: The completeness of your project definition
taken into account.

will determine if all tasks have been

People Productivity: People do not focus on a task with 100% efficiency. The difference between
calendar time and effort must be considered.
Project Structure: A dedicated project team will be able to focus its effort on completing the project
effectively.
Padding: People may increase estimates to take into account unknown risks and this may force an
unnecessary trade-off.
Culture: What is deemed acceptable behavior by the organization (e.g. padding vs. accuracy) will affect
estimates.
Downtime: Equipment repairs, holidays, vacations, exam schedules can all affect the time estimate.
Categories of estimates
The Macro or Top-Down approach can provide a quick but rough estimate. This is done when the time
and expense of a detailed estimate are an. This Usually occurs during conception stage when a full
design and WBS are not available. However, it requires experienced personnel to do the estimate and it
can be highly inaccurate. A Micro or Bottom-Up approach can provide a fairly accurate estimate, but is
time consuming. It takes into account the project design and a roll-up of WBS elements. It may
require multiple personnel and time to complete. If done properly, a bottom-up estimate can yield
accurate cost and time estimates.
Steps to developing the estimates:
Start with a Macro estimate then refine with a Micro estimate
Develop the general project definition
Perform a macro cost and time estimate
Develop the detailed project definition and WBS
Roll-up the WBS elements as part of a micro estimate
Establish the projectschedules
Reconcile differences between the macro and micro estimates
Scaling: Given a cost for a previous project then an estimate for a new project can be scaled from the
known cost. E.g NASA, at times, uses spacecraft weight to estimate total cost.
Apportion: Given a similar previous project, costs for major subunits of the new project would be
proportional to similar subunits in the previous project.
Weighted Variables: Certain types of projects can be characterized by specific parameters (e.g. number
of inputs, number of detector channels). Historical costs & times for single units of these parameters are
weighted by the numbers required for the new project.
Learning Curve: If the same task is repeated a number of times there will be a cost / time savings
relative to the first time the task is done.
Micro Estimates
Template: Uses historical data to establish detailed costs and schedules for project subunits. A new
project composed of some combination of these subunits can then be quickly estimated.
Ratio: Similar to the Macro ratio method but applied to specific tasks associated with project* subunits.
For example, if it takes 1 day to build & test a particular sensor unit, then an instrument with 10 sensors
would take 2 technicians, 5 days to complete.
WBS Roll-up: Times and costs associated with the lowest level WBS work packages are estimated and
then these are added or rolled-up to yield the costs for higher level units. This method provides the most
accurate estimates at the expense of time devoted to developing the estimate.

Phased Approach: On a phased project, details over the entire life-cycle may not be immediately
available. During the each phase details for the remaining phases are refined, modified or changed. In
this case an alternate approach may be appropriate.
Develop the general project definition
Perform a macro cost and time estimate for all phases
Develop a detailed definition and WBS for the immediate phase
Roll-up the WBS elements as a micro estimate for the immediate phase
Establish a detailed schedule for the immediate phase
Reconcile differences between previous macro & current micro estimates
Refine the macro cost and time estimate for the remaining phases
Refine the schedule for the remaining phases
Repeat items 3-8 just prior to next phases for the entire life-cycleGuidelines for Estimates
Estimates should be done by the person most familiar with the task
If possible obtain estimates from several people and use the variance for risk assessment (lecture
7)
* Multiple estimates should be done independently to avoid
GroupThink (lecture 1)
Base the estimates upon normal conditions.
Use consistent units when estimating task time.
Work package estimates should not include contingencies
Use a separate risk assessment for estimating the effect of abnormal conditions and
contingencies.

Net present value

In finance, the net present value (NPV) or net present worth (NPW) of a time series of cash flows, both
incoming and outgoing, is defined as the sum of the present values (PVs) of the individual cash flows of
the same entity.
In the case when all future cash flows are incoming (such as coupons and principal of a bond) and the
only outflow of cash is the purchase price, the NPV is simply the PV of future cash flows minus the
purchase price (which is its own PV). NPV is a central tool in discounted cash flow (DCF) analysis, and
is a standard method for using the time value of money to appraise long-term projects. Used for capital
budgeting, and widely throughout economics, finance, and accounting, it measures the excess or
shortfall of cash flows, in present value terms, once financing charges are met.
The NPV of a sequence of cash flows takes as input the cash flows and a discount rate or discount curve
and outputs a price; the converse process in DCF analysis - taking a sequence of cash flows and a price
as input and inferring as output a discount rate (the discount rate which would yield the given price as
NPV) - is called the yield, and is more widely used in bond trading.

Formula
Each cash inflow/outflow is discounted back to its present value (PV). Then they are summed. Therefore
NPV is the sum of all terms,

where
t - the time of the cash flow
i - the discount rate (the rate of return that could be earned on an investment in the financial markets
with similar risk.); the opportunity cost of capital
Rt - the net cash flow (the amount of cash, inflow minus outflow) at time t. For educational
purposes, R0 is commonly placed to the left of the sum to emphasize its role as (minus) the investment.
The result of this formula if multiplied with the Annual Net cash in-flows and reduced by Initial Cash
outlay the present value but in case where the cash flows are not equal in amount then the previous

formula will be used to determine the present value of each cash flow separately. Any cash flow within
12 months will not be discounted for NPV purpose.

The discount rate

The rate used to discount future cash flows to the present value is a key variable of this process.
A firm's weighted average cost of capital (after tax) is often used, but many people believe that it is
appropriate to use higher discount rates to adjust for risk or other factors. A variable discount rate with
higher rates applied to cash flows occurring further along the time span might be used to reflect the yield
curve premium for long-term debt.
Another approach to choosing the discount rate factor is to decide the rate which the capital needed for
the project could return if invested in an alternative venture. If, for example, the capital required for
Project A can earn five percent elsewhere, use this discount rate in the NPV calculation to allow a direct
comparison to be made between Project A and the alternative.
Related to this concept is to use the firm's Reinvestment Rate. Reinvestment rate can be defined as the
rate of return for the firm's investments on average. When analyzing projects in a capital constrained
environment, it may be appropriate to use the reinvestment rate rather than the firm's weighted average
cost of capital as the discount factor. It reflects opportunity cost of investment, rather than the possibly
lower cost of capital.
An NPV calculated using variable discount rates (if they are known for the duration of the investment)
better reflects the real situation than one calculated from a constant discount rate for the entire
investment duration. For some professional investors, their investment funds are committed to target a
specified rate of return. In such cases, that rate of return should be selected as the discount rate for the
NPV calculation. In this way, a direct comparison can be made between the profitability of the project
and the desired rate of return.
To some extent, the selection of the discount rate is dependent on the use to which it will be put. If the
intent is simply to determine whether a project will add value to the company, using the firm's weighted
average cost of capital may be appropriate. If trying to decide between alternative investments in order
to maximize the value of the firm, the corporate reinvestment rate would probably be a better choice.
Using variable rates over time, or discounting "guaranteed" cash flows differently from "at risk" cash
flows may be a superior methodology, but is seldom used in practice. Using the discount rate to adjust
for risk is often difficult to do in practice (especially internationally), and is difficult to do well. An
alternative to using discount factor to adjust for risk is to explicitly correct the cash flows for the risk
elements using rNPV or a similar method, then discount at the firm's rate.

NPV in decision making

NPV is an indicator of how much value an investment or project adds to the firm. With a particular
project, if Rt is a positive value, the project is in the status of discounted cash inflow in the time of t.
IfRt is a negative value, the project is in the status of discounted cash outflow in the time of t.
Appropriately risked projects with a positive NPV could be accepted. This does not necessarily mean
that they should be undertaken since NPV at the cost of capital may not account for opportunity
cost, i.e. comparison with other available investments. In financial theory, if there is a choice between
two mutually exclusive alternatives, the one yielding the higher NPV should be selected.

If...

It means...

Then...

NPV
>0

the investment
would add value to
the firm

the project may be accepted

NPV
<0

the investment
would subtract
value from the firm

the project should be rejected

NPV
=0

the investment
would neither gain
nor lose value for
the firm

We should be indifferent in the decision whether to accept

or reject the project. This project adds no monetary value.
Decision should be based on other criteria, e.g. strategic
positioning or other factors not explicitly included in the
calculation.

Basic Data

Expected Net Cash Flow

Project L
Project S

Year
0

($100)

($100)

10

70

60

50

80

20

CFt
n
NPV
t 0 (1 k) t
Considering a Project L:

10

60

3
100.00
80
9.09
49.59
60.11
NPVL = $ 18.79
NPVS = $19.98 If the projects are independent, accept both.
If the projects are mutually exclusive, accept Project S since NPVS > NPVL.
Note: NPV declines as k increases, and NPV rises as k decreases.
Payback period
In capital budgeting refers to the period of time required for the return on an investment to "repay" the
sum of the original investment. For example, a $1000 investment which returned $500 per year would
have a two year payback period. The time value of money is not taken into account. Payback period
intuitively measures how long something takes to "pay for itself." All else being equal, shorter payback
periods are preferable to longer payback periods. Payback period is widely used because of its ease of
use despite the recognized limitations described below.
The term is also widely used in other types of investment areas, often with respect to energy
efficiency technologies, maintenance, upgrades, or other changes. For example, a compact
fluorescentlight bulb may be described as having a payback period of a certain number of years or
operating hours, assuming certain costs. Here, the return to the investment consists of reduced operating
costs. Although primarily a financial term, the concept of a payback period is occasionally extended to

other uses, such as energy payback period (the period of time over which the energy savings of a project
equal the amount of energy expended since project inception); these other terms may not be standardized
or widely used.
Payback period as a tool of analysis is often used because it is easy to apply and easy to understand for
most individuals, regardless of academic training or field of endeavour. When used carefully or to
compare similar investments, it can be quite useful. As a stand-alone tool to compare an investment to
"doing nothing," payback period has no explicit criteria for decision-making (except, perhaps, that the
payback period should be less than infinity).
The payback period is considered a method of analysis with serious limitations and qualifications for its
use, because it does not account for the time value of money, risk, financing or other important
considerations, such as the opportunity cost. Whilst the time value of money can be rectified by applying
a weighted average cost of capital discount, it is generally agreed that this tool for investment decisions
should not be used in isolation. Alternative measures of "return" preferred by economists are net present
value and internal rate of return. An implicit assumption in the use of payback period is that returns to
the investment continue after the payback period. Payback period does not specify any required
comparison to other investments or even to not making an investment.
Payback period is usually expressed in years. Start by calculating Net Cash Flow for each year: Net
Cash Flow Year 1 = Cash Inflow Year 1 - Cash Outflow Year 1. Then Cumulative Cash Flow = (Net
Cash Flow Year 1 + Net Cash Flow Year 2 + Net Cash Flow Year 3 ... etc.) Accumulate by year until
Cumulative Cash Flow is a positive number: that year is the payback year.
To calculate a more exact payback period: Payback Period = Payback Year - 1 + (Unrecovered starting
costs*/Net Cash Flow during Payback Year)
(*)This is the absolute value of the Net Cash Flow the year before the Payback Year; i.e. the remaining
outflows left to recover at the beginning of the Payback Year.
Additional complexity arises when the cash flow changes sign several times; i.e., it contains outflows in
the midst or at the end of the project lifetime. The modified payback period algorithm may be applied
then. First, the sum of all of the cash outflows is calculated. Then the cumulative positive cash flows are
determined for each period. The modified payback period is calculated as the moment in which the
cumulative positive cash flow exceeds the total cash outflow.
The Meaning of Payback Period
Payback Period is a financial metric that answer the question: How long does it take for an investment to
pay for itself? Or, how long does it take for incoming returns to cover costs? Or, put still another way:
How long does it take for the investment to break even?
Like other financial metrics such as internal rate of return (IRR) and return on investment
(ROI), payback period takes essentially an "Investment" view of the action, plan, or scenario and its
estimated cash flow stream. Each of these metrics companies investment costs to investment returns in
one way or another. Payback period is the length of time required for cumulative incoming returns to
equal the cumulative costs of an investment (e.g. purchase of computer software or hardware, training
expenses, or new product development), usually measured in years.
Other things being equal, the investment with the shorter payback period is considered the better
investment. The shorter payback period is preferred because:
The investment costs are recovered sooner and are available again for further use.
A shorter payback period is viewed as less risky. It is usually assumed that the longer the payback
period, the more uncertain are the positive returns. For this reason, payback period is often used as a
measure of risk, or a risk-related criterion that must be met before funds are spent. A company might
decide, for instance, to undertake no major investments or expenditures that have a payback period over,
say, 3 years.
Payback Period Explained With an Example
Payback, Mathematically Speaking
Considerations for Using Payback Period
Payback Period Explained With an Example

As an example, consider a five year investment whose cash flow consequences are summarized in the
table below. The primary data for payback calculation are the expected cash inflows and outflows from
the investment:
Cash Inflows: The investment will bring $300 cash inflow each year, for years 1 - 5.
Cash outflows: The initial cost of the investment is a cash outflow of $800 in year 1, followed by a cost
(outflow) of $150 in year 2. There are no expected costs in years 3 - 5.
From these figures, the analyst creates two sets of cash flow numbers to use for the calculation (the
bottom two rows of the table):
Net Cash Flow. The net of cash inflows and outflows for each year.
Cumulative Cash Flow. The sum of all cash inflows and outflows for all preceding years and the current
year.

Investment Cash
Flow
Cash Inflows

Year 1 Year 2 Year 3 Year 4 Year 5

300 300 300

0

300

300

Cash Outflows

800 150

Net Cash Flow

500 150 300

300

300

Cumulative Cash
Flow

500 350 50

250

550

When does payback occur? Look first to the cumulative cash flow line at the table bottom, and it is clear
that payback occurs sometime in Year 4. We know that payback occurs in Year 4 because cumulative
cash flow is negative at the end of Year 3 and positive at the end of Year 4. But where, precisely, is the
payback event in Year 4? The answer can be seen roughly on a graph, showing the payback event as the
"break even" point in time, when cumulative cash flow crosses from negative to positive:

In reality, payback may occur any time in year 4, at the moment when the cumulative cash flow
becomes 0. However, if the analyst has only annual cash flow data to work with (as in this example) and
no further information about when cash flow appears within year 4, the analyst must assume the year's
cash flows are spread evenly through the year. In this case, payback period has to be estimated by
interpolation. That approach is illustrated here and in the next section. The assumption that cash flow is
spread evenly through the years is represented by the straight lines between year end data points above.
Using the tabled data above, where the payback year is clearly Year 4, payback period can be calculated
(estimated) as follows;

Payback Period = Y + ( A / B ) where

Y = The number of years before final payback year. In the example, Y = 3.0 years.
A = Total remaining to be paid back at the start of the payback year, to bring cumulative cash flow to 0.
In the example, A = $50.
B = Total (net) paid back in the entire payback year. In the example, B = 300.
For the example,
Payback Period = 3+ (50) / (300)
Payback Period = 3 + 1/6 = 3.17 Years
Payback period calculated this way is an estimate, based on interpolation between two period end points
(between the end of Year 3 and the end of Year 4). Interpolation was necessary because we have only
annual cash flow data to work with.
Payback Period, Mathematically Speaking
The "formula" in the previous section is easy to understand because it includes simple verbal
descriptions of the amounts to be added or divided. However, when the analyst attempts to implement
the verbal instructions into a spreadsheet formula for payback, the implementation becomes somewhat
cumbersome. In any case, the spreadsheet programmer needs at least a simple understanding of the
quantities that must be identified and used in calculating payback period.
For this understanding, consider again the cumulative cash flow curve (such as that shown above for the
tabled example), but now focused on the payback year (here, Year 4) and the year before that (Year 3).

The blue line rising from lower left to upper right is cumulative cash flow, graphed as straight line
segments between year end points. With simple principles of plane geometry, it is possible to show that
two ratios in the above figure are equivalent:
| A | / | B | = C / 1.0
This fraction, C, plus the number of whole years before the payback year (Y), is payback
period: Payback Period = Y + C.
To implement the payback period metric in a spreadsheet, the sheet must have access to the individual
annual cash flow figures and the annual cumulative cash flow figures (the last two rows of the table
above). The programmer builds logical tests ( "IF" expressions in Microsoft Excel) to find the first year
of positive cumulative cash flow. Then, with the payback year known, the calculations use annual and
cumulative cash flows from the payback year and the year preceding payback, to calculate the lengths
of line segments A and B from the diagram above. (See Financial Metrics Pro for working examples).
Considerations for Using Payback Period
Payback period is an appealing metric because its interpretation is easily understood. Nevertheless, here
are some points to keep in mind when using payback period:
Payback cannot be calculated if the positive cash inflows do not eventually outweigh the cash outflows.
That is why payback (like IRR) is of little use when used with a pure "costs only" business case or cost
of ownership analysis.
There can be more than one payback period for a given cash flow stream. Payback period examples such
as the one above typically show cumulative cash flow increasing continuously. In real world cash flow
results, however, cumulative cash flow can decrease as well as increase from period to period. When

cumulative cash flow is positive in one period, but negative again in the next, there is more than one
Payback Period point.
Payback period by itself says nothing about cash flows coming after the payback time. One investment
may have a shorter payback period than another, but the latter may go on to greater cumulative cash
flow over time.
Payback calculation ordinarily does not recognize the time value of money (in adiscounting sense) nor
does it reflect money coming in after payback (contrast withdiscounted cash flow and internal rate of
return, above).
What It Measures
How long it will take to earn back the money invested in a project.
Why It Is Important
The straight payback period method is the simplest way of determining the investment potential of a
major project. Expressed in time, it tells a management how many months or years it will take to recover
the original cash cost of the projectalways a vital consideration, and especially so for managements
evaluating several projects at once.
This evaluation becomes even more important if it includes an examination of what the present value of
future revenues will be.
How It Works in Practice
The straight payback period formula is:
Payback period = Cost of project Annual cash revenues
Thus, if a project costs $100,000 and is expected to generate $28,000 annually, the payback period
would be:
100,000 28,000 = 3.57 years
If the revenues generated by the project are expected to vary from year to year, add the revenues
expected for each succeeding year until you arrive at the total cost of the project.
For example, say the revenues expected to be generated by the $100,000 project are:
Year

Revenue

Total

$19,000

$19,000

$25,000

$44,000

$30,000

$74,000

$30,000

$104,000

$30,000

$134,000

Thus, the project would be fully paid for in year 4, since it is in that year that the total revenue reaches
the initial cost of $100,000.
The picture becomes complex when the time value of money principle is introduced into the
calculations. Some experts insist this is essential to determine the most accurate payback period.
Accordingly, present value tables or computers (now the norm) must be used, and the annual revenues
have to be discounted by the applicable interest rate, 10% in this example. Doing so produces
significantly different results:
Year

Revenue

Present value

Total

$19,000

$17,271

$17,271

$25,000

$20,650

$37,921

$30,000

$22,530

$60,451

$30,000

$20,490

$80,941

$30,000

$18,630

$99,571

This method shows that payback would not occur even after five years.
Payback period = Expected number of years required to recover a projects cost.
Project L

Year
0

Expected Net Cash Flow

Project L
Project S
($100)

($100)

10

(90)

60

(30)

80

50

PaybackL = 2 + $30/$80 years

= 2.4 years.
PaybackS = 1.6 years.
Weaknesses of Payback:
Ignores the time value of money. This weakness is eliminated with the discounted payback method.
Ignores cash flows occurring after the payback period.
Tricks of the Trade
Clearly, a main defect of the straight payback period method is that it ignores the time value of
money principle, which, in turn, can produce unrealistic expectations.
A second drawback is that it ignores any benefits generated after the payback period, and thus a project
that would return $1 million after, say, six years might be ranked lower than a project with a three-year
payback that returns only $100,000 thereafter.
Another alternative to calculating by payback period is to develop an internal rate of return.
Under most analyses, projects with shorter payback periods rank higher than those with longer
paybacks, even if the latter promise higher returns. Longer paybacks can be affected by such factors as
market changes, changes in interest rates, and economic shifts. Shorter cash paybacks also enable
companies to recoup an investment sooner and put it to work elsewhere.
Generally, a payback period of three years or less is desirable; if a projects payback period is less than a
year, some contend it should be judged essential.

Inflation impacts the amounts of estimated cash flows. It is often stated as an annual percentage such as
3%. It is taken into account by multiplying the current periods cash flow amount by the expected rate of
inflation to determine an estimate of the next period's cash flows. Different inflation rates are often used
for different costs, such as 2% for maintenance costs, 4% for labor costs, etc. The rate of inflation can be
obtained from economic forecasts or other sources but is ultimately estimated by management.

If inflation is omitted from expected future cash flows, managers may reject acceptable projects. When
inflation is added to future cash flows, the net cash inflows are larger, providing a more realistic
approach to estimating how viable a project is. Using cash flows amounts without inflation factored in
means that the cash flows are smaller than cash flows expected, which in turn causes all four capital
budgeting methods--NPV, IRR, ARR and the payback period method to produce smaller results.
Because the results are smaller, the likelihood of accepting a potential investment is smaller because
fewer investments will meet the company's minimum criteria. As a result, managers will often bypass
good investments.

Soft Benefits in Capital Budgeting

So far we have addressed primarily the financial aspects of capital budgeting. Most decisions involved
some type of touchy-feely considerations known as soft benefits. Ignoring soft benefits may cause
managers to pass up investments that would be beneficial to the company.

Soft benefits are hard to quantify but should still impact the decision making process. Some examples
are:
(1) A company's reputation
(2) Maintaining a competitive advantage
(3) Employee moral

Some managers are evaluated on the amount of short term profits they generate. Some capital budgeting
projects will generate small or negative operating cash flows during the early years and greater positive
impacts on profit during the latter years of a proposed investment's life. Because accepting the capital
budgeting investment causes an initial drop in profits, managers are reluctant to invest and often bypass
investments that in the long-run would benefit the company. Even though a potential investment may
have a positive NPV, an IRR that exceeds the company's required rate of return, or a payback period that
quickly recovers the cash outflow, managers may reject the investment to avoid looking bad for their
annual performance evaluation. These actions are often detrimental to the long-term value of the
company.

A couple of solutions exist. One solution is to bring other factors into the performance evaluation of
managers. Giving managers stock ownership in the company often motivates them to focus on both the
long and short run when making decisions in an effort to add value to the company, i.e., increase owners'
equity through retained earnings.

Accounting rate of return (ARR)

The accounting rate of return (ARR) is a very simple (in fact overly simple) rate of return:
average profit average investment
as a percentage.
Where average means arithmetic mean.
The profit number used is operating profit (usually from a particular project).

The average investment is the book value of assets tied up (in the project). This is important as the profit
figure used is after depreciation and amortisation. The means that value of assets used should also be
after depreciation and amortisation as well.
ARR is most often used internally when selecting projects. It can also be used to measure the
performance of projects and subsidiaries within an organisation. It is rarely used by investors, and
should not be used at all, because:
Cash flows are more important to investors, and ARR is based on numbers that include non-cash items.
ARR does not take into account the time value of money the value of cashflows does not diminish
with time as is the case with NPV and IRR.
It does not adjust for the greater risk to longer term forecasts.
There are better alternatives which are not significantly more difficult to calculate.
The accounting rate of return is conceptually similar to payback period, and its flaws, in particular, are
similar. A very important difference is that it tends to favour higher risk decisions (because future profits
are insufficiently discounted for risk, as well as for time value), whereas use of the payback period leads
to overly conservative decisions.
Because ARR does not take into account the time value of money, and because it is wholly unadjusted
for non-cash items, any method of selecting investments based on it is necessarily seriously flawed. Its
only advantage is that it is very easy to calculate. It is fairly easy to construct (realistic) examples where
it will lead to different choices from NPV, and the NPV led decision is clearly correct.
INTERNAL RATE OF RETURN
CFt
n
IRR :
$0 NPV .
t 0 1 IRR t
Project L:

10

60

3
100.00
18.1%
8.47
80
43.02
48.57

18.1%
18.1%

$ 0.06 $0
IRRL = 18.1%
IRRS = 23.6%
If the projects are independent, accept both because IRR > k.
If the projects are mutually exclusive, accept Project S since IRRS > IRRL.
Note: IRR is independent of the cost of capital.
ADVANTAGES AND DISADVANTAGES OF IRR AND NPV
A number of surveys have shown that, in practice, the IRR method is more popular than the NPV
approach. The reason may be that the IRR is straightforward, but it uses cash flows and recognizes the
time value of money, like the NPV. In other words, while the IRR method is easy and understandable, it
does not have the drawbacks of the ARR and the payback period, both of which ignore the time value of
money.
The main problem with the IRR method is that it often gives unrealistic rates of return. Suppose
the cutoff rate is 11% and the IRR is calculated as 40%. Does this mean that the management should
immediately accept the project because its IRR is 40%. The answer is no! An IRR of 40% assumes that
a firm has the opportunity to reinvest future cash flows at 40%. If past experience and the economy
indicate that 40% is an unrealistic rate for future reinvestments, an IRR of 40% is suspect. Simply

speaking, an IRR of 40% is too good to be true! So unless the calculated IRR is a reasonable rate for
reinvestment of future cash flows, it should not be used as a yardstick to accept or reject a project.
Another problem with the IRR method is that it may give different rates of return. Suppose there
are two discount rates (two IRRs) that make the present value equal to the initial investment. In this
case, which rate should be used for comparison with the cutoff rate? The purpose of this question is not
to resolve the cases where there are different IRRs. The purpose is to let you know that the IRR method,
despite its popularity in the business world, entails more problems than a practitioner may think.

WHY THE NPV AND IRR SOMETIMES SELECT DIFFERENT PROJECTS

When comparing two projects, the use of the NPV and the IRR methods may give different results. A
project selected according to the NPV may be rejected if the IRR method is used.
Suppose there are two alternative projects, X and Y. The initial investment in each project is
$2,500. Project X will provide annual cash flows of $500 for the next 10 years. Project Y has annual
cash flows of $100, $200, $300, $400, $500, $600, $700, $800, $900, and $1,000 in the same period.
Using the trial and error method explained before, you find that the IRR of Project X is 17% and the
IRR of Project Y is around 13%. If you use the IRR, Project X should be preferred because its IRR is
4% more than the IRR of Project Y. But what happens to your decision if the NPV method is used? The
answer is that the decision will change depending on the discount rate you use. For instance, at a 5%
discount rate, Project Y has a higher NPV than X does. But at a discount rate of 8%, Project X is
preferred because of a higher NPV.
The purpose of this numerical example is to illustrate an important distinction: The use of the
IRR always leads to the selection of the same project, whereas project selection using the NPV method
depends on the discount rate chosen.
PROJECT SIZE AND LIFE
There are reasons why the NPV and the IRR are sometimes in conflict: the size and life of the project
being studied are the most common ones. A 10-year project with an initial investment of $100,000 can
hardly be compared with a small 3-year project costing $10,000. Actually, the large project could be
thought of as ten small projects. So if you insist on using the IRR and the NPV methods to compare a
big, long-term project with a small, short-term project, dont be surprised if you get different selection
results. (See the equivalent annual annuity discussed later for a good way to compare projects with
unequal lives.)
WHEN ARE THE NPV AND IRR RELIABLE?

Generally speaking, you can use and rely on both the NPV and the IRR if two conditions are met.
First, if projects are compared using the NPV, a discount rate that fairly reflects the risk of each
project should be chosen. There is no problem if two projects are discounted at two different rates
because one project is riskier than the other. Remember that the result of the NPV is as reliable as the
discount rate that is chosen. If the discount rate is unrealistic, the decision to accept or reject the
project is baseless and unreliable. Second, if the IRR method is used, the project must not be
accepted only because its IRR is very high. Management must ask whether such an impressive IRR
is possible to maintain. In other words, management should look into past records, and existing and
future business, to see whether an opportunity to reinvest cash flows at such a high IRR really exists.
If the firm is convinced that such an IRR is realistic, the project is acceptable. Otherwise, the project
must be reevaluated by the NPV method, using a more realistic discount rate.

Benefit-Cost Ratio (BCR)

YOU SHOULD REMEMBER
A benefit-cost ratio (BCR) is an indicator, used in the formal discipline of cost-benefit analysis, that
The internal
rate of return
is a
popular
in capital
budgeting.
The IRR
is a is
discount
rateof the
attempts
to summarize
the (IRR)
overall
value
for method
money of
a project
or proposal.
A BCR
the ratio
that
makes
the
present
value
of
estimated
cash
flows
equal
to
the
initial
investment.
However,
when
benefits of a project or proposal, expressed in monetary terms, relative to its costs, also expressed in
using the IRR, you should make sure that the calculated IRR is not very different from a realistic
monetary
terms.
All benefits and costs should be expressed in discounted present values.
reinvestment
rate.

Benefit cost ratio (BCR) takes into account the amount of monetary gain realized by performing a
project versus the amount it costs to execute the project. The higher the BCR the better the investment.
General rule of thumb is that if the benefit is higher than the cost the project is a good investment.
Costbenefit analysis (CBA), sometimes called benefitcost analysis (BCA), is a systematic process for
calculating and comparing benefits and costs of a project, decision or government policy (hereafter,
"project"). CBA has two purposes:
To determine if it is a sound investment/decision (justification/feasibility),
To provide a basis for comparing projects. It involves comparing the total expected cost of each option
against the total expected benefits, to see whether the benefits outweigh the costs, and by how much.[1]
CBA is related to, but distinct from cost-effectiveness analysis. In CBA, benefits and costs are expressed
in money terms, and are adjusted for the time value of money, so that all flows of benefits and flows of
project costs over time (which tend to occur at different points in time) are expressed on a common basis
in terms of their "net present value."
Closely related, but slightly different, formal techniques include cost-effectiveness analysis, costutility
analysis, economic impact analysis, fiscal impact analysis and Social return on investment(SROI)
analysis.
Theory
Costbenefit analysis is often used by governments and others, e.g. businesses, to evaluate the
desirability of a given policy. It is an analysis of the expected balance of benefits and costs, including an
account of foregone alternatives and the status quo, helping predict whether the benefits of a policy
outweigh its costs, and by how much (i.e. one can rank alternate policies in terms of the ratio of costs
and benefit Altering the status quo by choosing the lowest cost-benefit ratio can improve pareto
efficiency, in which no alternative policy can improve one group's situation without damaging another.
Generally, accurate cost-benefit analysis identifies choices that increase welfare from
a utilitarian perspective. Otherwise, cost-benefit analysis offers no guarantees of increased economic
efficiency or increases of social welfare; generally positive microeconomic theory is moot when it
comes to evaluating the impact on social welfare of a policy.
Process
The following is a list of steps that comprise a generic cost-benefit analysis.[2]
List alternative projects/programs.
List stakeholders.
Select measurement(s) and measure all cost and benefits elements.
Predict outcome of cost and benefits over relevant time period.
Convert all costs and benefits into a common currency.
Apply discount rate.
Calculate net present value of project options.
Perform sensitivity analysis.
Adopt recommended choice.

Valuation
CBA attempts to measure the positive or negative consequences of a project, which may include:
Effects on users or participants
Effects on non-users or non-participants
Externality effects

Option value or other social benefits

A similar breakdown is employed in environmental analysis of total economic value. Both costs and
benefits can be diverse. Financial costs tend to be most thoroughly represented in cost-benefit analyses
due to relatively abundant market data. The net benefits of a project may incorporate cost savings or
public willingness to pay compensation (implying the public has no legal right to the benefits of the
policy) or willingness to accept compensation (implying the public has a right to the benefits of the
policy) for the welfare change resulting from the policy. The guiding principle of evaluating benefits is
to list all (categories of) parties affected by an intervention and add the (positive or negative) value,
usually monetary, that they ascribe to its effect on their welfare.
The actual compensation an individual would require to have their welfare unchanged by a policy is
inexact at best. Surveys (stated preference techniques) or market behavior (revealed preference
techniques) are often used to estimate the compensation associated with a policy, however survey
respondents often have strong incentives to misreport their true preferences and market behavior does
not provide any information about important non-market welfare impacts.
One controversy is valuing a human life, e.g. when assessing road safety measures or life-saving
medicines. However, this can sometimes be avoided by using the related technique of cost-utility
analysis, in which benefits are expressed in non-monetary units such as quality-adjusted life years. For
example, road safety can be measured in terms of cost per life saved, without formally placing a
financial value on the life. However, such non-monetary metrics have limited usefulness for evaluating
policies with substantially different outcomes. Additionally, many other benefits may accrue from the
policy, and metrics such as 'cost per life saved' may lead to a substantially different ranking of
alternatives than traditional cost-benefit analysis.
Another controversy is valuing the environment, which in the 21st century is typically assessed by
valuing ecosystem services to humans, such as air and water quality and pollution. Monetary values may
also be assigned to other intangible effects such as business reputation, market penetration, or long-term
enterprise strategy alignment.

Time and Discounting

CBA usually tries to put all relevant costs and benefits on a common temporal footing using time value
of money calculations. This is often done by converting the future expected streams of costs and benefits
into a present value amount using a discount rate. Empirical studies and a technical framework[3] suggest
that in reality, people do discount the future like this.
The choice of discount rate is subjective. A smaller rate values future generations equally with the
current generation. Larger rates (e.g. a market rate of return) reflects humans' attraction to time
inconsistencyvaluing money that they receive today more than money they get in the future. The
choice makes a large difference in assessing interventions with long-term effects, such as those
affecting climate change. One issue is the equity premium puzzle, in which long-term returns on equities
may be rather higher than they should be. If so then arguably market rates of return should not be used to
determine a discount rate, as doing so would have the effect of undervaluing the distant future (e.g.
climate change).
Risk and uncertainty
Risk associated with project outcomes is usually handled using probability theory. This can be factored
into the discount rate (to have uncertainty increasing over time), but is usually considered separately.
Particular consideration is often given to risk aversionthe irrational preference for avoiding loss over
achieving gain. Expected return calculations does not account for the detrimental effect of uncertainty.
Uncertainty in CBA parameters (as opposed to risk of project failure etc.) can be evaluated using a
sensitivity analysis, which shows how results respond to parameter changes. Alternatively a more formal
risk analysis can be undertaken using Monte Carlo simulations.

Accuracy
The value of a costbenefit analysis depends on the accuracy of the individual cost and benefit
estimates. Comparative studies indicate that such estimates are often flawed, preventing improvements
inPareto and Kaldor-Hicks efficiency. Causes of these inaccuracies include
Overreliance on data from past projects (often differing markedly in function or size and the skill levels
of the team members)
Use of subjective impressions by assessment team members
Inappropriate use of heuristics to derive money cost of the intangible elements
Confirmation bias among project supporters (looking for reasons to proceed)
Cost-benefit analysis: Cost-benefit analysis is a term that refers both to:
helping to appraise, or assess, the case for a project Project, programme or policy proposal;
an approach to making economic decisions of any kind.
Under both definitions the process involves, whether explicitly or implicitly, weighing the total expected
costs against the total expected benefits of one or more actions in order to choose the best or most
profitable option. The formal process is often referred to as either CBA (Cost-Benefit Analysis) or BCA
(Benefit-Cost Analysis).
Benefits and costs are often expressed in money terms, and are adjusted for the time value of money
</wiki/Time_value_of_money>, so that all flows of benefits and flows of project costs over time (which
tend to occur at different points in time) are expressed on a common basis in terms of their present
value. Closely related, but slightly different, formal techniques include cost-effectiveness analysis,
economic impact analysis, fiscal impact analysis and Social Return on Investment (SROI) analysis. The
latter builds upon the logic of cost-benefit analysis, but differs in that it is explicitly designed to inform
the practical decision-making of enterprise managers and investors focused on optimizing their social
and environmental impacts.
Costbenefit analysis is often used by governments to evaluate the desirability of a given intervention.
It is heavily used in today's government. It is an analysis of the cost effectiveness of different
alternatives in order to see whether the benefits outweigh the costs. The aim is to gauge the efficiency of
the intervention relative to the status quo. The costs and benefits of the impacts of an intervention are
evaluated in terms of the public's willingness to pay for them (benefits) or willingness to pay to avoid
them (costs). Inputs are typically measured in terms of opportunity costs the value in their best
alternative use. The guiding principle is to list all parties affected by an intervention and place a
monetary value of the effect it has on their welfare as it would be valued by them.
The process involves monetary value of initial and ongoing expenses vs. expected return. Constructing
plausible measures of the costs and benefits of specific actions is often very difficult. In practice,
analysts try to estimate costs and benefits either by using survey methods or by drawing inferences from
market behavior. For example, a product manager may compare manufacturing and marketing expenses
with projected sales for a proposed product and decide to produce it only if he expects the revenues to
eventually recoup the costs. Costbenefit analysis attempts to put all relevant costs and benefits on a
common temporal footing. A discount rate is chosen, which is then used to compute all relevant future
costs and benefits in present-value terms. Most commonly, the discount rate used for present-value
calculations is an interest rate taken from financial markets (R.H. Frank 2000). This can be very
controversial; for example, a high discount rate implies a very low value on the welfare of future
generations, which may have a huge impact on the desirability of interventions to help the environment.
Empirical studies suggest that in reality, people's discount rates /do/ decline over time. Because cost
benefit analysis aims to measure the public's true willingness to pay, this feature is typically built into
studies.
During costbenefit analysis, monetary values may also be assigned to less tangible effects such as the
various risks that could contribute to partial or total project failure, such as loss of reputation, market
penetration, or long-term enterprise strategy alignments. This is especially true when governments use
the technique, for instance to decide whether to introduce business regulation build a new road, or offer

a new drug through the state healthcare system. In this case, a value must be put on human life or the
environment, often causing great controversy. For example, the costbenefit principle says that we
should install a guardrail on a dangerous stretch of mountain road if the dollar cost of doing so is less
than the implicit dollar value of the injuries, deaths, and property damage thus prevented (R.H. Frank
2000).
Costbenefit calculations typically involve using time value of money formulas. This is usually done by
converting the future expected streams of costs and benefits into a present value amount.
Application and history: The practice of costbenefit analysis differs between countries and between
sectors (e.g., transport, health) within countries. Some of the main differences include the types of
impacts that are included as costs and benefits within appraisals, the extent to which impacts are
expressed in monetary terms, and differences in the discount rate between countries. Agencies across the
world rely on a basic set of key costbenefit indicators, including the following:
NPV (net present value)
PVB (present value of benefits)
PVC (present value of costs)
BCR (benefit cost ratio)
Net benefit (= PVB - PVC)
NPV/k (where k is the level of funds available)

The concept of CBA dates back to an 1848 article by Dupuit and was formalized in subsequent works by
Alfred Marshall The practical application of CBA was initiated in the US by the Corps of Engineers
after the Federal Navigation Act of 1936 effectively required costbenefit analysis for proposed federal
waterway infrastructure. The Flood Control Act of 1939 was instrumental in establishing CBA as federal
policy. It specified the standard that "the benefits to whomever they accrue [be] in excess of the
estimated costs. Subsequently, costbenefit techniques were applied to the development of highway and
motorway investments in the US and UK in the 1950s and 1960s. An early and often-quoted, more
developed application of the technique was made to London Underground 's Victoria Line. Over the last
40 years, costbenefit techniques have gradually developed to the extent that substantial guidance now
exists on how transport projects should be appraised in many countries around the world. In the UK, the
New Approach to Appraisal (NATA) was introduced by the then Department for Transport, Environment
and the Regions. This brought together costbenefit results with those from detailed environmental
impact assessments </wiki/Environmental_impact_assessment> and presented them in a balanced way.
NATA was first applied to national road schemes in the 1998 Roads Review but subsequently rolled out
to all modes of transport. It is now a cornerstone of transport appraisal in the UK and is maintained and
developed by the Department for Transport.
The EU 'Developing Harmonised European Approaches for Transport Costing and Project Assessment'
(HEATCO) project, part of its Sixth Framework Programme, has reviewed transport appraisal guidance
across EU member states and found that significant differences exist between countries. HEATCO's aim
is to develop guidelines to harmonise transport appraisal practice across the EU.
Transport Canada has also promoted the use of CBA for major transport investments since the issuance
of its Guidebook in 1994. More recent guidance has been provided by the United States Department of
Transportation and several state transportation departments, with discussion of available software tools
for application of CBA in transportation, including HERS, BCA.Net, StatBenCost, CalBC, and
TREDIS.
In the early 1960s, CBA was also extended to assessment of the relative benefits and costs of healthcare
and education in works by Burton Weisbrod. Later, the UnitedStates Department of Health and Human
Services issued its CBA Guidebook.
Accuracy problems: The accuracy of the outcome of a costbenefit analysis depends on how accurately
costs and benefits have been estimated.

A peer-reviewed -study of the accuracy of cost estimates in transportation infrastructure planning found
that for rail projects actual costs turned out to be on average 44.7 percent higher than estimated costs,
and for roads 20.4 percent higher (Flyvbjerg, Holm, and Buhl, 2002). For benefits, another peerreviewed study [15] <http://flyvbjerg.plan.aau.dk/Traffic91PRINTJAPA.pdf> found that actual rail
ridership was on average 51.4 percent lower than estimated ridership; for roads it was found that for half
of all projects estimated traffic was wrong by more than 20percent (Flyvbjerg, Holm, and Buhl, 2005).
Comparative studies indicate that similar inaccuracies apply to fields other than transportation.
These studies indicate that the outcomes of costbenefit analyses should be treated with caution because
they may be highly inaccurate Inaccurate costbenefit analyses likely to lead to inefficient decisions, as
defined by Pareto and Kaldor-Hicks efficiency -Hicks_efficiency. These outcomes (almost always
tending to underestimation /unless significant new approaches are overlooked/) are to be expected
because such estimates:
1. Rely heavily on past like projects (often differing markedly in function or size and certainly in the
skill levels of the team members)
2. Rely heavily on the project's members to identify (/remember/ from their collective past experiences)
the significant cost drivers
3. Rely on very crude heuristics to estimate the money cost of the intangible elements
4. Are unable to completely dispel the usually unconscious biases of the team members (who often have
a vested interest in a decision to go ahead) and the natural psychological tendency to /"think positive"/
(whatever that involves)
Reference class forecasting was developed to increase accuracy in estimates of costs and benefits.
Another challenge to costbenefit analysis comes from determining which costs should be included in
an analysis (the significant cost drivers). This is often controversial because organizations or interest
groups may think that some costs should be included or excluded from a study.
In the case of the Ford Pinto (where, because of design flaws, the Pinto was liable to burst into flames
in a rear-impact collision), the Ford company's decision was not to issue a recall. Ford's costbenefit
analysis had estimated that based on the number of cars in use and the probable accident rate, deaths due
to the design flaw would run about $49.5 million (the amount Ford would pay out of court to settle
wrongful death lawsuits). This was estimated to be less than the cost of issuing a recall ($137.5million).
In the event, Ford overlooked (or considered insignificant) the costs of the negative publicity so
engendered, which turned out to be quite significant (because it led to the recall anyway /and/ to
measurable losses in sales).
In the field of health economics, some analysts think costbenefit analysis can be an inadequate measure
because willingness-to-pay methods of determining the value of human life can be subject to bias
according to income inequity. They support use of variants such as cost-utility analysis and qualityadjusted life year to analyze the effects of health policies.
Use in regulation: Cost-benefit analysis was widely in the United States under the Bush administration
to prevent regulatory initiatives, and there is some debate about whether it is neutral to regulatory
initiatives or whether it anti-regulatory and undervalues human life, health, and the environment. In the
case of environmental and occupational health regulation, it has been argued that if modern cost-benefit
analyses had been applied prospectively to proposed regulations such as removing lead from gasoline,
not turning the Grand Canyon into a hydroelectric dam, and regulating workers' exposure to vinyl
chloride, these regulations would not have been implemented even though they are considered to be
highly successful in retrospect. The Clean Air Act has been cited in retrospective studies as a case where
benefits exceeded costs, but the knowledge of the benefits (attributable largely to the benefits of
reducing particulate pollution) was not available until many years later.
Interest groups may attempt to include or exclude significant costs from an analysis to influence the
outcome.
In the case of the Ford Pinto (where, because of design flaws, the Pinto was liable to burst into flames in
a rear-impact collision), the company's decision was not to issue a recall. Ford's costbenefit analysis
had estimated that based on the number of cars in use and the probable accident rate, deaths due to the

design flaw would cost it about $49.5 million to settle wrongful death lawsuits versus recall costs of
$137.5 million. Ford overlooked (or considered insignificant) the costs of the negative publicity that
would result, which forced a recall and damaged sales.[31]
In health economics, some analysts think costbenefit analysis can be an inadequate measure because
willingness-to-pay methods of determining the value of human life can be influenced by income level.
They support use of variants such as costutility analysis and quality-adjusted life year to analyze the
effects of health policies.
In environmental and occupational health regulation, it has been argued that if modern cost-benefit
analyses had been applied prospectively to decisions such as removing lead from gasoline,
buildingHoover Dam in the Grand Canyon and regulating workers' exposure to vinyl chloride, they
would not have been implemented even though they are considered to be highly successful in retrospect.
[32]
The Clean Air Act has been cited in retrospective studies as a case where benefits exceeded costs, but
the knowledge of the benefits (attributable largely to the benefits of reducing particulate pollution) was
not available until many years later.
Social or National Profitability
Public projects like road, railway, bridge and other transport projects, irrigation, projects, power
projects, etc for which socioeconomic considerations play a significant part, rather than mere
commercial profitability. Such projects are analysis for their net socioeconomic benefits and the
profitability analysis of such projects is known as social or national profitability analysis which is
nothing but the socioeconomic cost benefit analysis done at the national level.
Steps involved in determination of social or national profitability:National/Social profitability analysis takes into account the real cost of direct costs and real benefit of
direct benefits,. For instance, some of the inputs may be subsidized. Only the subsidized prices of input
is what is relevant for assessing commercial profitability. However the national profitability analysis
takes into account the real cost of inputs i.e. cost of input had they not been subsidized. Accordingly the
required adjustment to direct cost of input are made for national profitability analysis.
National/Social profitability analysis takes into account the indirect costs and indirect benefits to the
nation.While a nation bears the indirect, the people of the nation enjoy the indirect benefit. Hence
indirect costs and benefits are given due recognition and accounted for in social cost benefit analysis. It
is however difficult to assess exactly the quantum of indirect costs and indirect benefits. Suppose
construction of a bridge over a river. Its indirect benefits may include improved communication
facilities reduction in transportation costs, reduction in traveling time etc. while the indirect cost may
include acquisition of private land by the state, removal of industrial, commercial, agricultural activities
that prevailed in the land that was acquired disturbance of ecological balance etc.
National/Social profitability analysis can thus be regarded as a refinement over commercial appraisal
taking the hidden factors into account. National/Social profitability analysis is mainly used for
evaluating public investment projects. From the societys standpoint, the project should maximize the
aggregate consumption or the addition to the flow of goods or services in the economy investor looks for
maximization on his individual basis, the societys interest should look for maximization of the total
output of the economy. The need total thus arises to have an analysis done of social costs and social
benefits.
The various inputs required for the project are drawls out of the resources of the economy and
constitutes social costs. And the output of the any of the public project represent social benefits. The
input of goods and services and the outputs should be valued with reference to their relative value to
society.
Commercial or Financial profitability
The national development point of view there are always more projects than there are resources and
hence the necessity to appraise projects for selection. While the obvious choice will be the projects with
higher returns the complexity arises because of the need to appraise projected outcome based on
forecasts in a world of uncertainly, particularly in the context of endemic inflation. In the case of large
projects, particularly public sector projects involving the building up of infrastructure it is essential to
assess the social merits of the investment proposals.

Projects emanate from diverse and dispersed sources, such as individuals firms or institutions, and
government at the state and central levels. In instance where the state government is not the owner of the
business. The traditional yard stick of commercial or financial profitability is used for selection of
projects for implementation. The financial benefits get related to the financial costs of the project and if
there is a net surplus the project merit choice.While the process of selection of individual projects thus
meets the profit criteria of the individual investors or promoters, the combination of choices may not
necessarily result in the most socials profitable allocation of resources. For developing economies this is
the very important factor but it cannot be ignored.
Commercial or financial profitability as the sole deciding factor has two major limitations viz.
Financial or market values seldom match with social values and
What is beneficial to one segment of society may not necessary be so to the entire society.
In financial analysis the market values of input and outputs are reckoned and compared. And since
market distortions are many these values fail to reflect the relative worth on the societys value scale.
From societys stand point, goods and services should be valued in terms of relative contributions to
consumption. In the same manner the social value of resource should be reckoned interns of its
opportunity cost, represented by the output or consumption value that it is capable of yielding in its next
best alternative use.
In a free market economy the dominance of the forces of demand and supply has the effect of the market
prices being kept close to social valuation. In a developing economy however there are several
distortions entering into the market prices and they are far removed from their social valuation. The
distortions arise from the monopolistic status of many large enterprise a system of administered prices in
a controlled economy and from various government policy measures such as taxes, duties, controls and
foreign exchange regulations.
A project may confer considerable good to society that does not get reflected in financial projections
others though financially very rewarding may have some harmful effects on society that the financial
results fail to interpret. These effects that are outside the purview of financial projections are known as
externalities and are essential ingredients in the social profitability computations. The emphasis in social
cost benefit analysis is the import on the whole society and not one segment.
Social Cost Benefits Analysis means to analyze the social cost and total social benefits if we accept any
project. We all know that for completing the big project, we need big investment. In social cost benefit
analysis (SCBA), we see whether return or benefits on this investment are more than its cost from point
of view of society in which we are living.
In public investment, we analyze and compare government expenditure with total benefits to society
through SCBA.
It is also good technique of financial evaluation of a project because we leave that project whose
benefits to society are less than total cost which will to society because all resources are from society.
Problems which can be solved by Social Cost Benefits Analysis
a) Market imperfection :
We will not analyze social cost benefit; we can not find market imperfections. After study of market
rates following factors come in to our knowledge.
i) Rationing factor : It means some of raw material prices are controlled by Govt. So, it may increase our
project cost but its social benefit will go to poor community.
ii) Regulation for providing minimum wage factor: It also affects social cost and benefits of any project.
Because company must have to pay this minimum wages.
iii) Foreign Exchange Regulations factor: Sometime, we have to deal at currency rate which is less than
actual market rate due to regulation on FOREX. So, we should analyze this point also.

b) Externalities :
Externalities are non-cash or benefits which an organization suffer or get if it starts the project. For
example, if govt. makes road near your project plant, you can get this facility without any payment. On
the other side, if any other organization is polluting and spreading diseases, its cost may suffer due to
absence of your employee for going to hospitals.
c) Tax and Subsidies:
Tax is payment on the earning of the project and it will reduce our overall benefits. On the other hand, if
govt. gives us subsidy for operating any project, it will count for our cost benefit analysis.
2nd Problem: What is net benefit to society from a project?
With UNIDO approach, we can evaluate net benefit from any project. Formula is given below

3rd Problem: To Know the Effect of using one more Unit of Resources
With shadow price, we know the effect of using one more unit of resources on the social cost and
benefits. Shadow pricing is relating to decision of project manager. Before accepting the project, we
have to find the price if we have to use extra unit of resources. Suppose, we have to use one more hour
of labor, what will we pay and what will its effect on social benefits.

Case study on cost benefit analysis

1. Introduction
The main issues in the economic evaluation of airport projects are common to all cost-benefit analysis of
major transport investments. The basic comparison of social benefits and costs and the criteria and
procedures to avoid errors and biases are not significantly different: the definition of the base case; the
identification and measurement of relevant effects; the use of appropriate parameter values; and the
prevention of double or triple counting (see for example: Adler, 1987; Mackie and Preston, 1998;
Boardman et al, 1996; and Gramlich, 1990)
Airport investments are centers of thriving retailing activity, and projects with a sound financial
performance might not be considered as good from a broader economic perspective. This paper is
concerned with the cost-benefit analysis of airport infrastructure. The principle underlying the paper is
that airport investments are to be assessed as transport infrastructure improvements aimed at addressing
a demand for transportation. The analysis should therefore focus on the impact of the investment on the
generalized cost of travel for the users and on the costs of supplying the transportation service, including
both airport and airline costs.
The methodology proposed in this paper is aimed to help the practical application of cost-benefit
analysis for a project analyst facing limited availability of data and a short period of time for issuing an
opinion, a situation faced by many analysts in government and international agencies. Also, the political
context within which project appraisal is carried out in practice and the uncertainties it is subject to can
make a quick, low cost assessment valuable. The emphasis is placed in the consistency of decision
criteria across projects as to whether a given project is a good or bad investment, rather than on the
detailed accuracy of the estimates of project returns.

The approach must be workable, meaning both that it must be pragmatic about data availability, and that
it must be consistent with the limited resources usually available for project appraisal. When the full
appraisal option is not possible (a full cost-benefit analysis with surveys of local conditions) the
approach to be followed has to rely on data readily available from the majority of airport operators.
There are significant differences in data availability across promoters of airport projects, and the
methodology should be sufficiently flexible to allow application across projects in order to ensure
consistency of decision making.
This paper does not deal with safety, security or environmental impacts, and it is conceived for
incremental projects. Strategic projects with broader objectives like social and economic cohesion
or national competitiveness with controversial indirect effects are not suitable for conventional costbenefit analysis and are prone to overestimating net social benefits.
The paper does not pretend to measure strategic investments based on the presumed impact of the
investment on the regional economy. Evaluating airport investments in terms of maximizing regional
development would require a comparison of the regional impact of airport investment with investment in
other sectors, such as manufacturing, education or health. In any case, it should be noted that the
economic return of the project provides, in most cases, a good indication of the projects impact on the
regional economy. This is because the willingness to pay for travel reflects the gross economic benefit
generated by the trip.1 Revenues from non-aviation activities - mainly retailing, but also land rental for
other industrial activities, should not be counted as economic benefits resulting from the airport
investment2. However, estimating such revenues is necessary in the appraisal process to estimate the
financial return of the project and to gauge the necessary adjustments to aeronautical charges in the
airport following project implementation.
Sections 2 and 3 provide the theoretical basis for the appraisal framework subsequently proposed.
Section 2 is concerned with the theory of economic evaluation of airport projects, and section 3 with the
theory for the measurement of the various benefits. Sections 4 to 7 are concerned with the practical
application of the framework. Section 4 and 5 address appraisal of landside and airside investments,
respectively. Section 6 deals with the special case of freight transport. Section 7 addresses the
estimation of airport operating costs. Finally, section 8 draws some concluding remarks about the
approach presented.
2. The economic evaluation of airport projects
The economic rationale of public investment decisions concerning whether a project should be
implemented, or which projects should be selected subject to a given budget constraint, requires
identifying and measuring the benefits and costs during the life of the project and calculating the net
present value of this flow of net benefits.
An essential element in evaluating the economic benefits of a project is the definition of the alternative
to the project, the without project scenario. There are two elements in this respect. Firstly, what
would happen to existing infrastructure. In the case of repair projects, which involve bringing existing
infrastructure back into normal operative conditions, the without project scenario would be that no
further investments are made and that the airport will progressively degrade into inoperability. If the
project consists of capacity expansion, then the without project scenario should include all necessary
investments to maintain operative the existing level of capacity.

The second element is the institutional constraints present in the market. These may involve
government, airport or airline policies which would place additional conditions on the definition of the
with project and without project scenarios. For example, faced with runway constraints, an airline
dominating an airport may not want to increase aircraft size and may prefer to let yields rise instead.
There may also be environmental constraints, as when there is a cap on aircraft movements below the
notional capacity of a runway. These constraints are very much project-specific, and the project analyst
must incorporate them into the evaluation exercise accordingly, by making ad hoc adjustments to the
scenarios.
2.1. Economic benefits of airport infrastructure
1

Such gross benefits include indirect effects. The only exception would be where a relevant distortion can be identified in which the
project could have a significant impact. This could then be evaluated using standard cost-benefit analysis methods.
2
This implies that construction and operating costs corresponding to non-aviation activities should be excluded from the economic
evaluation. In many cases non-aviation revenues are transfers, but even when they add value, it is advisable to calculate the project NPV
without the secondary activities. A positive global NPV could hide a bad transport project.

The economic benefits derived from investment in airport infrastructure cannot be identified with the
revenues obtained by the airport authority and retailing firms with commercial operations in the airports.
Airport infrastructure devoted to meet transportation demand can be divided into landside and airside.
Normally, airside involves infrastructure beyond security check points, where only passengers or
authorised personnel can access. Landside involves infrastructure before that. For the purposes of this
paper, airside is taken to mean infrastructure to process aircraft; whereas landside would involve
infrastructure to process passengers or cargo. This latter division is more meaningful in the current
context, as it draws the line by type of economic impact, as will be seen further down in the paper.

Airside projects are geared to increase the capacity of the airport to handle aircraft movements. Projects
involve new runways or the widening or lengthening of existing ones; taxiways to increase the capacity
of existing runways; apron space to expand aircraft parking capacity; or aircraft traffic control at the
airport or in the airports vicinity. Landside projects aim at expanding the airports capacity to handle
passenger and freight. Projects could involve expanding capacity of cargo or passenger terminals;
improving access to terminals through parking facilities or rail stations; and enhancing product quality
through increased use of jetways to access aircraft.3 Projects can involve any combination of these items
or, ultimately, the construction of entirely new airports.

The sources of benefits of investing in landside capacity are threefold. Firstly, the avoidance of traffic
being diverted to alternative travel arrangements that impose additional generalised cost of
transportation to the passenger or freight customer. Secondly, by relieving congestion in terminals,
passenger or freight process - or throughput - time is reduced, hence contributing further to a decrease in
the generalised cost of travel. And thirdly, in the case of investing on contact stands (i.e. those equipped
with jetways) in passenger terminals, comfort to passengers is increased by avoiding bus trips or walks
to and from remote aircraft stands.

Investment on the airside will produce two potential benefits. First, enhanced airside capacity will
enable an increase in the frequency of departure and range of routes from the airport. This will yield the
benefit of reducing the frequency delay,4 as well as potentially the trip duration, both of which
contributing to a reduction in the generalised cost of transport. Second, airside investments may speed
the processing time for aircraft, reducing operating costs to airlines.

The benefits derived from airside and landside projects can be summarized into four categories: first,
reductions in travel, access and waiting time; secondly, improvements in service reliability and
predictability; thirdly, reduction in operating costs; and finally, increases in traffic.
Regarding reduction in travel, access and waiting time, infrastructure investments may lead to faster or
more frequent services, or to alleviate congestion, or to generate some network effects. The final effects
translate into lower generalized cost of travel.
When capacity is not enough to match demand at a given level of prices, it may happen that investment
in additional capacity would not alleviate congestion, but accommodate latent demand for that particular
airport, which was previously served at a less convenient alternative. This is the concept of scarcity
(Starkie, 1988; Nash and Samson, 1999) useful to account for the important fact of ex ante matching of
supply and demand through administrative procedures.
Scarcity applies to transport infrastructure with non-random entry and where the different operators have
access to the system through a coordinated scheme. Theoretically, demand cannot exceed capacity.
3

Jetways are the mobile tube-like corridors which connect an aircraft with the passenger terminal and which enable indoor boarding and
disembarking to passengers. Aircraft parking positions equipped with jetways are known as contact stands, and parking positions requiring
walking or transport by bus are known as remote stands.
4

The frequency delay is the difference in the average passengers preferred departure time and the closest flight departure feasible for the
passenger. Other things being equal, the greater the departure frequency, the lower the frequency delay, and hence the time cost of travel
for the passenger.

Unattended demand at given prices is reflected in scarcity. Nevertheless, with tight schedules, system
overloads due to flight delays generate congestion as the required rescheduling to accommodate the
delayed flights impose changes in departing or arrival times for other flights. Scarcity is possible without
congestion when the airport authority is not charging a market clearing price for the available slots and
the number of slots give enough slack to accommodate timing problems without system overloads.
Investment in transport infrastructure can improve service reliability and predictability and this is
converted in lower generalised costs for travellers or lower operating costs for firms using air transport
services.
Other projects allow the introduction of more efficient technologies or facilitate a better use of those in
use, resulting in a reduction in operating costs (lower cost per seat associated with more efficient
aircrafts, handling equipment, etc.)
Finally, the reduction in costs for passengers and firms could lead to an increase in traffic. This is what it
is known as induced traffic, with two basic types: deviated and generated.
The agents directly affected by these economic benefits are the following: airport users, airlines, firms
operating at the airport or providing services to the airport, airport authority and taxpayers. Other agents
can be affected indirectly through substitutive and complementary cross effects in secondary markets.
The importance of these effects in terms of the economic evaluation of the project depends heavily on
the existence of distortions in the economy and the magnitude of the cross effects5.
2.2. Net Present Value (NPV) of the investment
The NPV of an investment in transport infrastructure can be expressed as
T

NPV I (CS t PS t )(1 i ) t

(1)

t 1

where:
I : investment costs
T: project life
CSt: change in consumer surplus in year t
PSt: change in producer surplus in year t
i: discount rate
The change in consumer surplus can be estimated with the rule of a half:
CS t

1
( g t 0 g t1 )(q t 0 q t1 )
2

(2)

g p

where:
gt0 : generalized cost in year t without the investment
gt1 : generalized cost in year t with the investment
qt0 : airport users in year t without the investment
qt1 : airport users in year t with the investment
p: price per trip inclusive of airport charges, airline ticket, access and egress money costs
: value of total trip time (flying, access, egress and waiting)
The change in producer surplus (for any of the affected producers) is equal to:
PS t pt1 q t1 p t 0 q to C t 0 ( qt 0 ) C t1 (q t1 )

(3)

where Ct 0 ( qt 0 ) and Ct1 ( qt1 ) denote total variable costs without the project and with the project.
Changes in producer surplus require estimating incremental revenues and costs for the airport authority,
for airlines and other companies directly affected by the project. The degree of market power in the
airline industry and other economic activities directly affected by the project will determine who is the
final beneficiary of the cost saving or the increase in frequency or service reliability.
When markets are competitive, producer surplus remains unchanged. Passengers and consumers served
by companies benefiting from the cost reduction will increase their surpluses through lower prices and
5

See the report by Venables and Gasoriek (1998) to the Department of Transport (UK) and the revision of their estimations in chapter four
of the Standing Advisory Committee on Trunk Road Assesment (SACTRA).

higher levels of service. However, this is not always the case with the airport authority which enjoys
some market power by being the only provider of aeronautical services within a given area. Such an
operator, once the project has been implemented, has to set prices above avoidable costs to recover the
investment.
There are two ways of approaching the economic appraisal exercise: the social surplus approach, and the
resource use or resource cost approach. The social surplus approach consists of the direct calculation of
changes in consumer and producer surpluses. This requires identifying changes in prices, costs and
revenues with and without the new airport infrastructure. The alternative approach to estimating the
economic benefit of the project consists in looking at the changes in real resources, ignoring transfers.
Even in the case of positive airport authority surplus it is possible to concentrate in resource costs as
shown below.
So, instead of looking at the changes in social surplus, we focus measurement in real resource costs
changes ignoring revenues from existing traffic. In this approach one should take especial care when
changes in quality occur, and with the treatment of taxes and incremental revenue in generated traffic.
When markets are competitive and incremental revenues equal incremental costs for airlines and other
firms, it is possible to measure the benefits of generated traffic by measuring the savings in resource
costs. In the case of taxes, this shortcut is also feasible as long as there is a general indirect taxation in
the rest of the economy. The net increase in tax paid to the government could be too insignificant to
justify further effort (Abelson and Hensher, 2001).
The resource cost approach does not account for quality changes (e.g. comfort) and additional
measurement should be made to avoid the understatement of user benefits when significant quality
changes are part of the project.
The measurement of benefits and costs requires estimating airport demand for the project life. Let us
assume that the base demand level is known and equal to q0 and the annual growth rate is . The annual
airport demand for airport, assuming no changes in generalised costs is:
Qt q0 (1 ) t

(4)

It is worth noting that Qt is the number of users willing to pay, at the existing price, for the use of the
airport in year t, and qt0 and qt1 in (2) and (3) are the equilibrium quantities in year t without and with the
investment. We assume that the evaluating agency knows the annual demand growth and needs to work
out the equilibrium quantities to estimate the change in social surplus (or resource cost).
3. Identification of benefits from airport infrastructure investment
3.1 Benefits without rationing
Assuming that the market is competitive and leaving aside the measurement of service reliability and
predictability, the economic benefit of the investment can be determined through the reduction in
resource costs. Let us consider a project in airport infrastructure which implies a reduction in total trip
time (1- 0), and assume that prices do not change.
Figure 1. Users benefits
Costs
Benefits
C
Dt
D0
g1
g0

qa

qb

qc

qd

Figure 1 represents the stylized case of this type of investment, in landside infrastructure, which
eventually leads to higher capacity. Generalized costs and willingness to pay for airport services are
measured in the vertical axis and the demand per unit of time (e.g. hour, peak period, day or year) in the
horizontal axis. Initial capacity allows attending a maximum of qa users per period of time at a constant
generalized cost equal to g0. The average generalized cost function C shows that once the critical level qa
is reached, a new increase in traffic is only possible, within existing capacity, at a higher average cost.
Initially the airport demand in a particular period of time has an imperfect substitute (another less
convenient flight, airport or mode of transport) available at a generalized cost of g1, higher than g0)
nevertheless, as demand is D0, all the users willing to pay g0 will be attended. Demand growth is
expected to be equal to and according to (4) the level of demand in the following period is Qt.
Depending on which cost (go or g1) applies, Qt would be fully attended at the project airport (Qt=qd), or
partially at this airport (Qt=qb) with some deviated traffic to second best alternatives (qc-qb) and some
deterred traffic (qd-qc).
The situation with the project is characterized in the figure with the possibility of maintaining go as the
generalized cost when demand has shifted to Dt, Qt =qd. The situation without the project is also with a
level de demand equal to Dt, but with an equilibrium demand quantity of qb < qd.

Once the equilibrium level of demand with and without the project has been determined, we can proceed
to evaluate the economic benefit of the investment project.
Three categories of benefits can be identified in figure 1:
(i) Benefits to existing users (qb)
(ii) Benefits from avoided diversion costs (qc-qb)
(iii) Benefits from generated traffic (qd-qc)
Benefits to current users are equal to (g1-g0)qb, because the maximum number of the airport users (qb) is
now determined by the outside alternative with lower cost than the airport equilibrium with demand D0.
Benefits from avoided diversion costs are equal to (g1-g0)(qc-qb). Passengers in the segment qc-qb will
deviate to less preferred alternatives. The diversion could be in time, when passengers are forced to
change to less convenient departure times, or in mode when the passenger has to use an alternative
airport or mode of transport6.
User benefits from generated traffic are equal to 0.5(g1-g0)(qd-qc). Contemplated from the perspective of
forecasted future demand Qt, this benefit can equivalently be interpreted as deterred traffic avoided
thanks to the investment. It is important to notice that additional benefits (taxes and revenues above
incremental costs) could be associated with deviated and generated traffic.
The previous analysis ignores two important facts: firstly, the existence of administrative rationing and
different generalized cost for existing and deviated travelers; and secondly, the possibility of insufficient
capacity to meet demand during the project lifetime.
3.2 Benefits with rationing
In figure 1 it was assumed that the number of airport users in equilibrium was determined by the
intersection of the average generalized cost function and the generalized cost (g1) of an imperfect
substitute (another less convenient flight, airport or mode of transport) and hence the generalized cost at
the base case was identical for existing and deviated users. This is not usually the case when capacity
rationing applies.
Figure 2 shows the standard case of different generalized costs for existing and diverted users. The
situation with the project is identical to figure 1, but the situation without the project is quite different: qb
is now determined through slot allocation and hence the generalized cost of existing traffic has to be
lower (g) than the second best alternative.

The rule of a half applies equally to diverted as well as generated traffic. In Figure 1 the benefits of diverted traffic is represented by the
difference g1g0. This value should be interpreted as the average, equal to a half of the interval of time savings.

This way, the generalized cost of deviated traffic is higher (or equal in an extreme case) than the
generalized cost of existing traffic. Scarcity without the project results in some deviated traffic to second
best alternatives (qc-qb) and some deterred traffic (qd-qc).
The comparison with and without the project leads to the following benefits:
Benefits to current users are equal to (g- g0)qb, strictly lower than without administrative rationing.
Benefits from avoided diversion costs are equal to (qc-qb) (g1-g0), which are strictly higher than those
reflected in figure 1 as (qc-qb) is now strictly higher7. User benefits from generated traffic are similar.
The comparison between the situations reflected in figures 1 and 2 also shows the interesting possibility
of improving the results without implementing the project when congestion is above the optimal level. A
Pareto improvement results without the project through a rationing of capacity. Another insight from the
comparison of figures 1 and 2 is that the benefits of the airport infrastructure project appear to be
substantially higher in figure 1 than in figure 2, highlighting the importance of a clear definition of the
base case.

We ignore the trivial case where qb is equal in both cases.

Figure 2. User benefits with administrative rationing of capacity

Costs
Benefits
C
Dt
D0
g1
g
g0
0

qb

qc

qd

3.3 Capacity constraint

During the lifetime of the project it might occur that demand in some year t is above the baseline
identified in figure 1 with a generalized cost equal to g0. This is a quite realistic case during a typical
project life of 15 or 20 years.
Figure 3 illustrates a situation during the project life, in which demand Qt cannot be met at a constant
cost g0 but at a higher cost, due to the presence of congestion. This could happen because of
indivisibilities in airport investment. It may be optimal not to invest in additional capacity during some
years, and hence the case represented in figure 3 is compatible with the assumption of perfect
information on demand.

Figure 3. User benefits with administrative rationing and congestion

Costs
Benefits

Dt

D0

g1
g

g0

qb

qc

qe

qd

In this case, benefits from capacity expansion are lower than those described in figure 1. The reduction
in the generalized cost of using the airport is now lower and so is the generated traffic. The generalized
cost for existing traffic remains at g. Benefits come from diversion costs avoided, equal to (g1-g)(qeqb). No deterred traffic exists in this case. Project benefits are definitely lower when supply and demand
conditions are similar to those represented in figure 3: lower demand at equilibrium and smaller cost
reduction.
The graphical analysis shows the user benefits we have to measure to work out whether the investment
is socially profitable: time savings for existing passengers, diversion cost avoided and the consumer
surplus of generated travel.
We have assumed that the economic effects of the investment were limited to user time savings and
therefore leaving the producer surpluses of airport authority, airlines and other firms constant.
Investment in airport infrastructure can change operating costs and revenue of airport authority, airlines
and other firms, so we need to generalize the previous graphical analysis based in the resource cost
approach to the case of a positive airport authority surplus. For simplicity, we keep the assumption that
cost reduction accruing to airlines will finally benefit consumers through lower prices.
Without rationing, from (2) and (3), and disaggregating existing and generated traffic, the change in
social surplus with the project in year t is equal to:
(CS t PS t ) ( g t 0 g t1 ) q 0 ( pt1 pt 0 ) q 0

1
( g t 0 g t1 )(qt1 qt 0 ) pt1 (qt1 qt 0 )
2

(5)

Given that g p , and rearranging (5), social surplus can be expressed as:
1
( t 0 t1 ) q0 [( t 0 t1 ) ( pt1 pt 0 )]q
2

(6)

Following (6) the benefit of the project for current users is equal to total time cost savings. In the case of
generated passengers, only half of that amount should be accounted for, plus the average of ex ante and
ex post airport charge per trip. Time diversion cost savings are treated in (6) as existing traffic
(conditions in figure 1) and the full difference in trip time applies8.
With rationing, condition (6) has to be modified to account for possible differences in time savings
between existing and diverted traffic, as happens to be the case in figures 2 and 3. The conditions
8

See footnote 6

prevailing in figure 2 requires to calculate the first term of (6) twice, one for existing traffic and another
for deviated traffic. With figure (3) the calculus is straightforward as the same time saving apply for all
traffic and no deterred traffic exists.
3.4 Additional considerations for airside investments
An increase in airport capacity in terms of the aircraft movements it can handle has three effects. Firstly,
it enables an increase in the potential passenger and freight capacity. Secondly, it makes it possible to
increase flight frequency, benefiting all passengers traveling through the airport. These benefits result
from the greater choice of departure time, and consist of reductions in the frequency delay, which is
the difference between the passengers preferred departure time and the nearest departure time
available.9 Thirdly, for a given amount of traffic as frequency increases there can be a change in the
average size of aircrafts using the airport. This has implications for airline operating costs because
larger aircraft are, to a certain extent, cheaper to operate on a per seat basis than smaller aircraft10.

For a formal treatment of this concept see Douglas and Miller (1974).
For an empirical analysis of the cost economies of aircraft size see Wei and Hasen (1993). They found that when pilot cost is treated as
endogenous, the cost minimizing aircraft size is smaller. Pilot cost increases with aircraft size and the optimal sizes are smaller than those
resulting exclusively from technical efficiency criteria.
10

Figure 4. Benefits from airside investment

EUR

1 Runway

1 / AS

2 Runways
C

fd1
fd = c
c1

b
d

FD
Ca

f1

f2

Indivisibilities in airport expansions imply that runway capacity cannot increase linearly with traffic. As
a runway handles more passengers, it will eventually have to handle larger aircraft. When a new runway
is built, two effects may bring about reductions in average aircraft size. Firstly, airlines would tend to
compete for time sensitive business travelers by increasing flight frequency, which will tend to take
place with smaller aircraft. Secondly, new airlines will enter the airport, developing new routes, also
normally with smaller aircraft.
Should a new runway not be built, airlines will be forced to operate with bigger aircraft in order to
accommodate growing traffic. Hence, the decision to invest in a new runway will have to consider the
possible trade off between, on the one hand, reduced frequency delay at a higher cost per seat if the
runway is built and, on the other hand, keeping frequency delay constant at a lower cost per seat if the
runway is not built.
This trade-off is illustrated in Figure 4. The left-hand vertical axis measures currency units and the right
hand-side vertical axis the inverse of average aircraft size (AS). The horizontal axis measures departure
frequency. The marginal frequency delay schedule (FD) denotes the inverse relationship between
departure frequency and generalized cost. An increase in the value of time would shift the schedule
upwards.
The marginal airport costs schedule (Ca) denotes constant returns to scale. The marginal total cost
schedule (C) includes both airport and aircraft costs. With respect to the right hand side vertical axis, C
reflects the inverse relationship between departure frequency and aircraft size and, with respect to the
left hand side vertical axis C reflects the direct relationship between departure frequency and unit cost
per seat. When total traffic grows, for a given level of frequency, aircraft size will have to increase,
reducing marginal cost per seat, rotating the C curve downwards, clockwise11.
In the example illustrated in figure 4, runway 1 has a capacity for aircraft movements of f1. Building a
second runway would enable an increase in frequency to f2. At f1 the cost imposed on the passenger by
the frequency delay is fd1, higher than marginal operating costs of c1. Airlines hence have an incentive
to increase frequency at the expense of aircraft size, as passenger willingness to pay for en extra
frequency is higher than the marginal cost associated with reducing aircraft size. Equilibrium would be
reached at point b, where frequency is f and where fd is equal to c.
The benefits of building a new runway, enabling an increase in departure frequency, will be equal to the
area abd. Moreover, the passing of time will bring about two effects: traffic grows, shifting the C
schedule downwards; and the value of time increases with growing income, shifting the FD schedule
11

It is worth to point out that traffic is not constant along the horizontal axis. Increases in departure frequency generate traffic in
themselves because they constitute an improvement in service quality and a decrease in frequency delay. The cost curve C accounts for this
effect. The shift in the C curve would be accounted for only by exogenous changes in traffic such as that caused by population or income
growth.

upwards. These two effects would expand the area abd from all of its three corners, meaning that the
benefit of building a new runway increases with time. The economic returns from investing on a new
runway are determined by the present value of the future stream of benefits as determined by the area
abd in each year, and by the present value of the capital investment required for the new runway. Until
point b exceeds the capacity of runway 2, there will be no benefit from building a third runway.
4. Applied measurement of benefits from investment in airport landside
4.1 Expansion of landside capacity
Airport infrastructure usage experiences marked peaks and troughs, which follow time of day, day of the
week and month of the year patterns. Figure 5 provides an indication of the degree of variability of
capacity requirements placed on airport infrastructure throughout the year. It displays the Flow
Distribution Curve (FDC) for a hypothetical typical airport. The FDC ranks all 8,760 hours of the year
by passenger throughput.
Figure 5. Flow Distribution Curve for a hypothetical airport

Hourly
passeng
er flow

5% of
throughput

5%
BHR

2,00
0

4,00
6,00
8,00
0
0
0
Ranking of hours in the
year

This pattern of demand means that the terminal is underused for a significant portion of time. In
principle, terminal capacity could be increased - and a more economically efficient operation could be
achieved - by flattening the FDC, for instance through pricing policy. Airport charges should differ
between peak and off-peak periods either through a differentiated pricing system or by a market-driven
slot allocation. In practice, almost always a flat charge is applied, increasing the peaks in demand above
efficient levels12.
Terminals are designed to be able to process a target hourly throughput with a given level of service.
The objective is to strike a balance between the need to address traffic peaks, and the need to minimize
unused capacity during throughput troughs. This implies that the terminal needs to supply a level of
service that is acceptable most of the time.
There is not a single criterion to set the hourly throughput target for terminal design. Some alternatives
include:
the Standard Busy Rate, taken to be the thirtieth busiest hour;
the fortieth busiest hour;

12

See Morrison (1987) for a discussion of efficient airport pricing applied to runways.

the 5% Busy Hour Rate, defined as the throughput level which the 5% of passengers traveling during the
busiest hours find as a minimum throughput level in the terminal (see Figure 1, where the area under the
FDC and left of the doted line corresponds to 5% of total traffic); and
measures of the type busiest hour in the second busiest month.

At the target level of throughput, a standard of service is defined. The Airports Council International
(ACI) and the International Air Transport Association (IATA) have defined a scale of service standards,
in terms of space available per occupant at various locations in the terminal. These standards are shown
on Table 1. Trespassing the minimum limits imposed by level E would take the terminal to level F,
considered as system breakdown. It is important to underline that the actual capacity of the terminal
in terms of passenger throughput per hour is determined by the maximum capacity of the weakest
point along the passenger processing chain. So, an otherwise A-level terminal with C-level hold room
standards, can only be expected to be able to handle the amount of passenger throughput under C-level
terminal standards, with a minimum C-level service quality standard.
Table 1. ACI / IATA Level of service space standard (m2/pax)

Check-in queue area

1.8

1.6

1.4

1.2

1.0

Wait/circulate area

2.7

2.3

1.9

1.5

1.0

Hold room

1.4

1.2

1.0

0.8

0.6

Bag claim area*

2.0

1.8

1.6

1.4

1.2

Gov. inspection services

1.4

1.2

1.0

0.8

0.6

Difference to C

35%

18%

0%

-18%

-36%

* Excluding luggage conveyor belt.

Source: ACI / IATA.
The extent to which passenger diversion takes each of its possible forms- diversion in time or in mode
is very much case dependent. It varies according to the shape of the FDC at the airport, passenger
profile in terms of trip purpose, alternative transport means available, and the scheduling practices of
airlines operating at the airport. Estimating diversion at an airport with precision can potentially be a
complex process. In many cases the analyst does not have the required information readily available,
and assembling it would require significant analysis costs.
A workable alternative would be for the analyst to use a set of generic rules that can be adjusted to each
particular project. A general rule of thumb followed in the industry is that a C-level terminal will start
experiencing significant traveller diversion when traffic exceeds design annual throughput capacity by
about a third. As shown in Table 1, this roughly coincides with the average difference in space
requirements between service level C and the lower limit of service level E. In view of this, it would be
possible to take ACI/IATA service standard criterion as a proxy index of spare capacity before diversion
takes place. It could be assumed that all forecasted potential throughput exceeding such a threshold
would experience diversion. The percentage assumed for A-level terminals would be higher (some 5060%) and for E-level designs lower (say, some 5%).
Diversion can be measured in equivalent time terms, and its cost calculated using published value of
time estimates. One approach would be to take an average diversion time for all diverted passengers. It
can be further assumed that all diversion would be equally resource consuming, and hence should be
treated equally. The average time could be set at two hours for both diversion in time and in mode.
Regarding diversion in time, peak periods in airport activity extend for 1 to 2 hours. It is reasonable to
assume that in cases of scarcity, where rationing is necessary, flight schedules would have to be

displaced by 1 to 3 hours, the average being around 2 hours. As for diversion in mode, two hours drive
is deemed a reasonable additional access or egress time to an alternative airport, or longer travelling
time if the trip is carried out on an alternative transport mode. If, for a particular project, circumstances
dictate that such assumptions are unreasonable, the analyst can adjust them accordingly.
This diverted traffic is equal to qc-qb in Figure 2. The two hours worth of passenger time corresponds to
g1-g0 in the vertical axis. This corresponds to the difference in generalised cost with respect to the best
alternative available to diverted traffic, whether to an alternative transport mode or airport (diversion in
mode) or to an alternative, less preferred, departure time from the same airport (diversion in time).
Only when for a specific project circumstances suggest that the overall cost of diversion would be
significantly different for time or mode diversion, and when a reasonably accurate estimate could be
formulated as to what proportions would each diversion take, would there be a case for treating them
differently. The typical case would be when the alternative mode of transport poses a very large time
penalty on the passenger, such as in islands. There the two-hour rule must be substituted by the time the
passenger must invest in traveling on the alternative mode. If this is far too high, such as remote oceanic
islands, then the assumed diversion in time per passenger could be increased.

In estimating future traffic, the analyst will start with existing traffic levels - the only hard evidence
regarding demand available to the analyst - and, as mentioned in Section 3.2, it is very important to
define very clearly what the situation of this existing traffic is regarding generalized cost. Throughput
projections will normally have to be made for 20 to 25 years, and to do this the analyst must follow
long-term air traffic projections, normally supplied in the form of average yearly growth rates. The
critical issue when applying such growth rates to existing traffic is determining any possible changes in
the generalized cost of travel to existing airport users after the project is implemented. If there are
significant changes, then generated traffic might be significant and particular attention must be placed to
its estimation.
Normally, new capacity will be opened before scarcity or congestion becomes serious. If so, existing
traffic at the time of project appraisal will be experiencing a generalized cost of or close to g0 in Figure
2. In this case, throughput on each subsequent year after project implementation can be estimated using
long-term air traffic projections. These projections can be taken to include traffic that in the absence of
the project would have been deviated or deterred. For ease of calculation, when estimating the welfare
loss resulting from the without project scenario, both types of traffic can be treated equivalently and
estimated jointly, as the resulting error will be small compared to the uncertainties regarding long-term
traffic, anyway. It should be noted that this does not mean that the estimation excludes generated traffic,
but only that both deviated and generated are taken to be included in the long-term traffic growth
estimate.
However, if at the time of the appraisal the airport is operating with significant rationing, then existing
traffic would be experiencing a generalized cost akin to g in Figure 2. If so, applying the long-term
traffic growth to the years immediately following the opening of the additional capacity could result in a
substantial underestimate, as the sudden decline in generalized cost of users will bring about significant
generated traffic. The same applies to a situation without rationing but where the project still produces a
lower generalized cost relative to that of existing traffic. An example is when the project attracts new
services by no-frill airlines.

In these cases, generated and deviated should not be estimated jointly. The proposed method to
calculate generated traffic would be to, firstly, estimate the difference in generalized cost between
existing traffic and future traffic at the margin (that is, g1-g0 or g-g0, depending on conditions at the
airport, in Figure 2), and then applying an elasticity of about 1, common in aviation.13
5. Applied measurement of benefits from investment in airport airside
Some projects may yield a disproportionate increase in airside (i.e. aircraft movement) capacity relative
to the increase in landside (i.e. passenger or freight throughput) capacity. Airside capacity is determined
13

See, for example, Jorge-Caldern (1997).

by runways, taxiways and apron space. As with terminals, the actual hourly capacity of an airports
airside infrastructure is determined by the capacity of the weakest of these three levels. The exception
being a possible partial substitutability between taxiways and apron space, in that the latter can handle
virtual queues until taxiways are decongested. Investment aimed at alleviating an airside bottleneck
could trigger large increases in the ability of the airport to handle aircraft movements.
Improvements in departure frequency can be valued in terms of changes in frequency delay.14 Whereas
studies explicitly using frequency delay are rare, the most widely quoted estimates of a delay function is
that by Douglas and Miller (1974), as follows:
Fd = 92(F-.456)
where:
Fd: frequency delay
F: departure frequency
Douglas and Miller (1974) acknowledge that the actual delay is affected by scheduling practices, not
picked in the formula. However, they underline that the value of the formula does not reside in
estimating absolute values of delay, but rather in estimating changes in delay, and that for this latter
purpose chances of estimation bias are lower. Changes in delay are governed by the estimated elasticity
of 0.456.
Changes in average frequency delay can be computed by referring to the average departure frequency
per route in the airport, a figure that should be readily available for most airport operators, including
those with poor data resources. The extent to which frequency delay changes over time will depend on
how fast departure frequency increases. As a rule for a simplified type of project appraisal, it can be
assumed that if movement capacity increases in line with passenger capacity, average aircraft size should
remain the same. Frequency should then increase in line with traffic. In practice there could be more
than proportionate increases in frequency during the first few years following project implementation, as
airlines rush to secure runway slots. The rule reflects a long-run equilibrium.
If the increase in aircraft movement capacity were to be lesser than the increase in passenger capacity,
then aircraft size would increase in the long run. Changes in aircraft size would bring about changes in
operating costs, as larger aircraft are cheaper to operate on a per seat basis than smaller aircraft. The
average cost per seat per trip for a mid-size aircraft, such as the Airbus A-320 is 51.15 Aircraft cost per
seat is related to aircraft size by an elasticity in the region of 0.5.16 The impact of a change in average
aircraft size on operating costs could be made by applying the 0.5 elasticity to cost per seat values
based on the 51 benchmark figure.
An additional element to take into account regarding investments on the airside is the impact that
changes in aircraft operating procedures have on costs. To the extent that there is a significant change in
airline operating costs as a result of the project, these should be included as a welfare change. Changes
in aircraft operating costs could result from various sources, including changes in approach traffic
patterns, ground taxiing requirements and turnaround times allowed by the new facilities. Each project
will have different impacts on these factors. A common denominator for these factors can be to convert
them into time savings and then translating them into a total cost figure through data on costs per aircraft
block-hour. A workable way of including these factors into the project appraisal exercise would then be:
Considering only situations where the project will produce significant changes in aircraft operating
costs; and

14

Note that the additional runway capacity could also be used to open a new route. However, this can also be considered an increase in
frequency starting from zero departures. The effect for the passenger could be considered the same as an increase in the frequency of an
existing route: should the passenger wish to depart at the time of the new flight it saves him/her from either altering the departure time or
from spending waiting time in an intermediate connecting airport.
15

The actual average cost per block hour in an airport will depend on the aircraft mix serving the airport, the average route length flown by
such aircraft, as well as on the non-aircraft operating costs of an airline that can differ significantly by the airlines country of origin. The
calculation can potentially become tedious and inefficient. The figure quoted was calculated from 1999 US data from The Airline Monitor.
16

A constant elasticity is to be used as an approximation, in the absence of more detailed data.. The actual elasticity will vary somewhat
with aircraft size itself, as well as with route length. New empirical evidence of this relationship can be found in Wei and Hasen (1993)

using an average figure for cost per block-hour which can be easily adjustable in situations where the
aircraft operations differ significantly from the average.
The suggested approach is to use the A-320 benchmark mentioned above. The aircrafts cost per blockhour is estimated at EUR 2,530. Adjustments for airports with a significantly different aircraft profile
such as in projects on regional airports would be made following the 0.5 elasticity of operating costs
with respect to aircraft size already mentioned.
As in all other aspects of the practical framework here proposed, the analyst should be aware of
institutional constraints facing the airport and its users which may condition the with project and
without project scenarios. In the case of airside investments, one key concern is the extent to which it
is realistic to expect an increase in aircraft size. In highly competitive markets, particularly in
competition between hubs, airlines may demand more runways as a way to compete on frequency. To
the extent that one airline is constrained in terms of number of runways and other competitors are not,
forcing that one airline only to increase aircraft size may distort competition in the airline market.
Moreover, the airline may go on to develop a second hub in another alternative airport instead of
increasing aircraft size. So, in the case of a project consisting of building a new runway, the analyst may
adjust its without project scenario by capping the extent to which the airline would increase the size of
its aircraft below what would be technically feasible.
6. The treatment of airfreight
The European air freight market is very competitive. Operators compete on price and quality, normally
with very narrow operating margins. Freight is less speed demanding and more flexible regarding
traveling times than passengers. Also, aviation carries goods with a relatively high value to weight ratio,
where transport costs are a relatively low proportion of the final price of the good. These characteristics
encourage competition in two ways: First, it widens the catchment area of the various freight terminals
relative to passenger catchment areas. Second, it enables more inter-modal competition than in the
passenger sector.
Hence, demand is little dependent on a single project, as capacity constraints in one network node can be
overcome relatively easily by channeling freight flows through other nodes. Under these circumstances,
the benefits of the project would stem from the lower operating costs resulting from it. Given that an
independent operator can take the price as given, such benefits would be the gain in producer surplus
resulting from the project, that is, the financial internal rate of return.
In cases where demand is largely dependent on the project, as in a remote island, then the project could
bring about significant savings in diversion costs. An estimate of such costs should then be made, and
treated in an analogous manner to diversion costs for passengers.
These considerations apply to both landside and airside projects. In the case of landside projects, issues
are the same as for the passenger sector: terminal capacity determines potential throughput. However,
regarding airside projects, the aircraft size versus frequency of departure trade-off does not normally
apply. Freighter flights can normally operate at off-peak times, so that runway slot availability is
normally a non-issue, and hence there are no benefits of increasing the number of runways. Instead, the
critical issue is the technical characteristics of the runway, as this determines whether large freighter
aircraft can operate from the airport. When there is no sufficient belly-hold space on passenger aircraft
and alternative means of transport are very expensive, large freighter aircraft reduce significantly the
costs of carrying freight. In such cases, investments to upgrade a runway to accommodate such aircraft
could be justified economically.
8. Conclusions
Conducting a thorough cost benefit analysis of airport investment projects can be a very resource
consuming exercise. An accurate estimation of the returns from an investment can require carrying out
surveys of local demand conditions and the formulation of detailed hypotheses about the future
evolution of traffic and airline operations. Nonetheless, it should be noted, even a full appraisal exercise
will render the evaluation subject to significant uncertainties.

Sometimes, project analysts do not need to have precise estimates of the expected returns of a project
and instead need to find out simply whether the project is good or bad, whether the project should
go ahead or not, or indeed whether it is a borderline case that merits a closer look. For arriving at these
types of conclusions, conducting a full economic evaluation might itself be not economically justified.
Instead, the emphasis should be placed on comparability across projects with widely differing data
availability, in order to ensure consistency in decision-making, rather than on the accuracy of the results.
This paper has proposed one possible way (indeed, not the only one) in which such a back of an
envelope answer can be provided. This is done by drawing on rules of thumb generally accepted in the
aviation industry, and applying them to the standard cost-benefit analysis framework.
The approach is itself flexible and requires judgment by the analyst, as assumptions can be altered for a
specific project when there is a good case for doing so. We believe that, whereas the approach makes a
large degree of generalizations and would not substitute a full cost benefit analysis where necessary and
feasible, it still has a role to play among applied economists. It is useful in conditions of very limited
analyst time, research budget, available information, and where quick decisions must be made for a large
number of projects, a condition which many professionals face in practice.

Resource leveling: Resource leveling is a project management technique used to examine unbalanced
use of resources (usually people or equipment) over time, and for resolving over-allocations or conflicts.
When performing project planning activities, the manager will attempt to schedule certain tasks
simultaneously. When more resources such as machines or people are needed than are available, or
perhaps a specific person is needed in both tasks, the tasks will have to be rescheduled concurrently or
even sequentially to manage the constraint. Project planning resource leveling is the process of resolving
these conflicts. It can also be used to balance the workload of primary resources over the course of the
project[s], usually at the expense of one of the traditional triple constraints (time, cost, scope).
When using specially designed project software, leveling typically means resolving conflicts or over
allocations in the project plan by allowing the software to calculate delays and update tasks
automatically. Project management software leveling requires delaying tasks until resources are
available. In more complex environments, resources could be allocated across multiple, concurrent
projects thus requiring the process of resource leveling to be performed at company level. In either
definition, leveling could result in a later project finish date if the tasks affected are in the critical path.
Resource Leveling is also useful in the world of maintenance management. Many organizations have
maintenance backlogs. These backlogs consist of work orders. In a "planned state" these work orders
have estimates such as 2 electricians for 8 hours. These work orders have other attributes such as report
date, priority, asset operational requirements, and safety concerns. These same organizations have a need
to create weekly schedules. Resource-leveling can take the "work demand" and balance it against the
resource pool availability for the given week. The goal is to create this weekly schedule in advance of
performing the work. Without resource-leveling the organization (planner, scheduler, supervisor) is most
likely performing subjective selection. For the most part, when it comes to maintenance scheduling,
there are very few logic ties and therefore no need to calculate critical path and total float.
Resource allocation: Resource allocation is used to assign the available resources in an economic way. It
is part of resource management. In project management, resource allocation is the scheduling of
activities and the resources required by those activities while taking into consideration both the resource
availability and the project time.
Project Evaluation and Review Technique: PERT is a model for project management designed to
analyze and represent the tasks involved in completing a given project. It is commonly used in
conjunction with the critical path method or CPM.
PERT is a method to analyze the involved tasks in completing a given project, especially the time
needed to complete each task, and identifying the minimum time needed to complete the total project.
PERT was developed primarily to simplify the planning and scheduling of large and complex projects. It
was developed by Bill Pocockof Booz Allen Hamilton and Gordon Perhson of the U.S. Navy Special
Projects Office in 1957 to support the U.S. Navy's Polaris nuclear submarine project. It was able to
incorporate uncertainty by making it possible to schedule a project while not knowing precisely the
details and durations of all the activities. It is more of an event-oriented technique rather than start- and
completion-oriented, and is used more in projects where time, rather than cost, is the major factor. It is
applied to very large-scale, one-time, complex, non-routine infrastructure and Research and
Development projects. An example of this was for the 1968 Winter Olympics in Grenoble which applied
PERT from 1965 until the opening of the 1968 Games. This project model was the first of its kind, a
revival for scientific management, founded by Frederick Taylor (Taylorism) and later refined by Henry
Ford (Fordism). DuPont corporation's critical path method was invented at roughly the same time as
PERT. A PERT chart is a tool that facilitates decision making; The first draft of a PERT chart will
number its events sequentially in 10s (10, 20, 30, etc.) to allow the later insertion of additional events.
Two consecutive events in a PERT chart are linked by activities, which are conventionally represented as
arrows (see the diagram above). The events are presented in a logical sequence and no activity can
commence until its immediately preceding event is completed. The planner decides which milestones
should be PERT events and also decides their proper sequence.
A PERT chart may have multiple pages with many sub-tasks.
PERT is valuable to manage where multiple tasks are occurring simultaneously to reduce redundancy.

PERT event: a point that marks the start or completion of one or more activities. It consumes no time
and uses no resources. When it marks the completion of one or more tasks, it is not reached (does not
occur) until all of the activities leading to that event have been completed.
predecessor event: an event that immediately precedes some other event without any other events
intervening. An event can have multiple predecessor events and can be the predecessor of multiple
events.
successor event: an event that immediately follows some other event without any other intervening
events. An event can have multiple successor events and can be the successor of multiple events.
PERT activity: the actual performance of a task which consumes time and requires resources (such as
labor, materials, space, machinery). It can be understood as representing the time, effort, and resources
required to move from one event to another. A PERT activity cannot be performed until the predecessor
event has occurred.
Optimistic time (O): the minimum possible time required to accomplish a task, assuming everything
proceeds better than is normally expected
Pessimistic time (P): the maximum possible time required to accomplish a task, assuming everything
goes wrong (but excluding major catastrophes).
Most likely time (M): the best estimate of the time required to accomplish a task, assuming everything
proceeds as normal.
Expected time (TE): the best estimate of the time required to accomplish a task, assuming everything
proceeds as normal (the implication being that the expected time is the average time the task would
require if the task were repeated on a number of occasions over an extended period of time).
TE = (O + 4M + P) 6
Float or Slack is the amount of time that a task in a project network can be delayed without causing a
delay - Subsequent tasks (free float) or Project Completion (total float)
Critical Path: the longest possible continuous pathway taken from the initial event to the terminal event.
It determines the total calendar time required for the project; and, therefore, any time delays along the
critical path will delay the reaching of the terminal event by at least the same amount.
Critical Activity: An activity that has total float equal to zero. Activity with zero float does not mean it is
on the critical path.
Lead time: the time by which a predecessor event must be completed in order to allow sufficient time for
the activities that must elapse before a specific PERT event reaches completion.
Lag time: the earliest time by which a successor event can follow a specific PERT event.
Slack: the slack of an event is a measure of the excess time and resources available in achieving this
event. Positive slack would indicate ahead of schedule; negative slack would indicate behind schedule;
and zero slack would indicate on schedule.
Fast tracking: performing more critical activities in parallel
Crashing critical path: Shortening duration of critical activities
The first step to scheduling the project is to determine the tasks that the project requires and the order in
which they must be completed. The order may be easy to record for some tasks (e.g. When building a
house, the land must be graded before the foundation can be laid) while difficult for others (There are
two areas that need to be graded, but there are only enough bulldozers to do one). Additionally, the time
estimates usually reflect the normal, non-rushed time. Many times, the time required to execute the task
can be reduced for an additional cost or a reduction in the quality.
In the following example there are seven tasks, labeled A through G. Some tasks can be done
concurrently (A and B) while others cannot be done until their predecessor task is complete (C cannot
begin until A is complete). Additionally, each task has three time estimates: the optimistic time estimate

(O), the most likely or normal time estimate (M), and the pessimistic time estimate (P). The expected
time (TE) is computed using the formula (O + 4M + P) 6.
ActivityPredecessorTime estimatesExpected time
Opt. (O)Normal (M)Pess. (P)
A2464.00
B3595.33
CA4575.17
DA46106.33
EB, C4575.17
FD3484.50
GE3585.17

Once this step is complete, one can draw a Gantt chart or a network diagram.
A Gantt chart created using Microsoft Project (MSP). Note (1) the critical path is in red, (2) the slack
is the black lines connected to non-critical activities, (3) since Saturday and Sunday are not work days
and are thus excluded from the schedule, some bars on the Gantt chart are longer if they cut through a
weekend.
A Gantt chart created using OmniPlan. Note (1) the critical path is highlighted, (2) the slack is not
specifically indicated on task 5 (d), though it can be observed on tasks 3 and 7 (b and f), (3) since
weekends are indicated by a thin vertical line, and take up no additional space on the work calendar, bars
on the Gantt chart are not longer or shorter when they do or don't carry over a weekend.
A network diagram can be created by hand or by using diagram software. There are two types of
network diagrams, activity on arrow (AOA) and activity on node (AON). Activity on node diagrams are
generally easier to create and interpret. To create an AON diagram, it is recommended (but not required)
to start with a node named start. This "activity" has a duration of zero (0). Then you draw each activity
that does not have a predecessor activity (a and b in this example) and connect them with an arrow from
start to each node. Next, since both c and d list a as a predecessor activity, their nodes are drawn with
arrows coming from a. Activity e is listed with b and c as predecessor activities, so node e is drawn with
arrows coming from both b and c, signifying that e cannot begin until both b and c have been completed.
Activity f has d as a predecessor activity, so an arrow is drawn connecting the activities. Likewise, an
arrow is drawn from e to g. Since there are no activities that come after f or g, it is recommended (but
again not required) to connect them to a node labeled finish.
A network diagram created using Microsoft Project (MSP). Note the critical path is in red. A node like
this one (from Microsoft Visio) can be used to display the activity name, duration, ES, EF, LS, LF, and
slack.By itself, the network diagram pictured above does not give much more information than a Gantt
chart; however, it can be expanded to display more information. The most common information shown
is:
The activity name
The normal duration time
The early start time (ES)
The early finish time (EF)
The late start time (LS)
The late finish time (LF)
The slack

In order to determine this information it is assumed that the activities and normal duration times are
given. The first step is to determine the ES and EF. The ES is defined as the maximum EF of all
predecessor activities, unless the activity in question is the first activity, for which the ES is zero (0). The
EF is the ES plus the task duration (EF = ES + duration). The ES for start is zero since it is the first
activity. Since the duration is zero, the EF is also zero. This EF is used as the ES for a and b.
The ES for a is zero. The duration (4 work days) is added to the ES to get an EF of four. This EF is used
as the ES for c and d.
The ES for b is zero. The duration (5.33 work days) is added to the ES to get an EF of 5.33.
The ES for c is four. The duration (5.17 work days) is added to the ES to get an EF of 9.17.
The ES for d is four. The duration (6.33 work days) is added to the ES to get an EF of 10.33. This EF is
used as the ES for f. The ES for e is the greatest EF of its predecessor activities (b and c). Since b has an
EF of 5.33 and c has an EF of 9.17, the ES of e is 9.17. The duration (5.17 work days) is added to the ES
to get an EF of 14.34. This EF is used as the ES for g.
The ES for f is 10.33. The duration (4.5 work days) is added to the ES to get an EF of 14.83.
The ES for g is 14.34. The duration (5.17 work days) is added to the ES to get an EF of 19.51.
The ES for finish is the greatest EF of its predecessor activities (f and g).
Since f has an EF of 14.83 and g has an EF of 19.51, the ES of finish is 19.51. Finish is a milestone (and
therefore has a duration of zero), so the EF is also 19.51.
Barring any unforeseen events, the project should take 19.51 work days to complete. The next step is to
determine the late start (LS) and late finish (LF) of each activity. This will eventually show if there are
activities that have slack. The LF is defined as the minimum LS of all successor activities, unless the
activity is the last activity, for which the LF equals the EF. The LS is the LF minus the task duration (LS
= LF - duration).
The LF for finish is equal to the EF (19.51 work days) since it is the last activity in the project. Since the
duration is zero, the LS is also 19.51 work days. This will be used as the LF for f and g.
The LF for g is 19.51 work days. The duration (5.17 work days) is subtracted from the LF to get an LS
of 14.34 work days. This will be used as the LF for e.
The LF for f is 19.51 work days. The duration (4.5 work days) is subtracted from the LF to get an LS of
15.01 work days. This will be used as the LF for d.
The LF for e is 14.34 work days. The duration (5.17 work days) is subtracted from the LF to get an LS
of 9.17 work days. This will be used as the LF for b and c.
The LF for d is 15.01 work days. The duration (6.33 work days) is subtracted from the LF to get an LS
of 8.68 work days.
The LF for c is 9.17 work days. The duration (5.17 work days) is subtracted from the LF to get an LS of
4 work days.
The LF for b is 9.17 work days. The duration (5.33 work days) is subtracted from the LF to get an LS of
3.84 work days.
The LF for a is the minimum LS of its successor activities. Since c has an LS of 4 work days and d has
an LS of 8.68 work days, the LF for a is 4 work days.
The duration (4 work days) is subtracted from the LF to get an LS of 0 work days.
The LF for start is the minimum LS of its successor activities. Since a has an LS of 0 work days and b
has an LS of 3.84 work days, the LS is 0 work days.
The next step is to determine the critical path and if any activities have slack. The critical path is the path
that takes the longest to complete. To determine the path times, add the task durations for all available
paths. Activities that have slack can be delayed without changing the overall time of the project. Slack is
computed in one of two ways, slack = LF - EF or slack = LS - ES. Activities that are on the critical path

have a slack of zero (0). The duration of path adf is 14.83 work days. The duration of path aceg is 19.51
work days.
The duration of path beg is 15.67 work days.
The critical path is aceg and the critical time is 19.51 work days. It is important to note that there can be
more than one critical path (in a project more complex than this example) or that the critical path can
change. For example, let's say that activities d and f take their pessimistic (b) times to complete instead
of their expected (TE) times. The critical path is now adf and the critical time is 22 work days. On the
other hand, if activity c can be reduced to one work day, the path time for aceg is reduced to 15.34 work
days, which is slightly less than the time of the new critical path, beg (15.67 work days).
Assuming these scenarios do not happen, the slack for each activity can now be determined.
Start and finish are milestones and by definition have no duration, therefore they can have no slack (0
work days).
The activities on the critical path by definition have a slack of zero;
however, it is always a good idea to check the math anyway when drawing by hand.
LFa - EFa = 4 - 4 = 0
LFc - EFc = 9.17 - 9.17 = 0
LFe - EFe = 14.34 - 14.34 = 0
LFg - EFg = 19.51 - 19.51 = 0
Activity b has an LF of 9.17 and an EF of 5.33, so the slack is 3.84 work days.
Activity d has an LF of 15.01 and an EF of 10.33, so the slack is 4.68 work days.
Activity f has an LF of 19.51 and an EF of 14.83, so the slack is 4.68 work days.
Therefore, activity b can be delayed almost 4 work days without delaying the project. Likewise, activity
d or activity f can be delayed 4.68 work days without delaying the project (alternatively, d and f can be
delayed 2.34 work days each).
A completed network diagram created using Microsoft Visio. Note the critical path is in red.

Steps in the PERT Planning Process: PERT planning involves the following steps:
Identify the specific activities and milestones.
Determine the proper sequence of the activities.
Construct a network diagram.
Estimate the time required for each activity.
Determine the critical path.
Update the PERT chart as the project progresses.
1. Identify Activities and Milestones: The activities are the tasks required to complete the project. The
milestones are the events marking the beginning and end of one or more activities. It is helpful to list the
tasks in a table that in later steps can be expanded to include information on sequence and duration.
2. Determine Activity Sequence: This step may be combined with the activity identification step since
the activity sequence is evident for some tasks. Other tasks may require more analysis to determine the
exact order in which they must be performed.
3. Construct the Network Diagram: Using the activity sequence information, a network diagram can be
drawn showing the sequence of the serial and parallel activities. For the original activity-on-arc model,
the activities are depicted by arrowed lines and milestones are depicted by circles or "bubbles". If done
manually, several drafts may be required to correctly portray the relationships among activities.
Software packages simplify this step by automatically converting tabular activity information into a
network diagram.

4. Estimate Activity Times: Weeks are a commonly used unit of time for activity completion, but any
consistent unit of time can be used. A distinguishing feature of PERT is its ability to deal with
uncertainty in activity completion times. For each activity, the model usually includes three time
estimates:
Optimistic time - generally the shortest time in which the activity can be completed. It is common
practice to specify optimistic times to be three standard deviations from the mean so that there is
approximately a 1% chance that the activity will be completed within the optimistic time.
Most likely time - the completion time having the highest probability. Note that this time is different
from the expected time.
Pessimistic time - the longest time that an activity might require. Three standard deviations from the
mean is commonly used for the pessimistic time.
PERT assumes a beta probability distribution for the time estimates. For a beta distribution, the expected
time for each activity can be approximated using the following weighted average:
Expected time = ( Optimistic + 4 x Most likely + Pessimistic ) / 6
This expected time may be displayed on the network diagram.
To calculate the variance for each activity completion time, if three standard deviation times were
selected for the optimistic and pessimistic times, then there are six standard deviations between them, so
the variance is given by:
[ ( Pessimistic - Optimistic ) / 6 ]2
5. Determine the Critical Path: The critical path is determined by adding the times for the activities in
each sequence and determining the longest path in the project. The critical path determines the total
calendar time required for the project. If activities outside the critical path speed up or slow down
(within limits), the total project time does not change. The amount of time that a non-critical path
activity can be delayed without delaying the project is referred to as slack time. If the critical path is not
immediately obvious, it may be helpful to determine the following four quantities for each activity:
ES - Earliest Start time
EF - Earliest Finish time
LS - Latest Start time
LF - Latest Finish time
These times are calculated using the expected time for the relevant activities. The earliest start and finish
times of each activity are determined by working forward through the network and determining the
earliest time at which an activity can start and finish considering its predecessor activities. The latest
start and finish times are the latest times that an activity can start and finish without delaying the project.
LS and LF are found by working backward through the network. The difference in the latest and earliest
finish of each activity is that activity's slack. The critical path then is the path through the network in
which none of the activities have slack.
The variance in the project completion time can be calculated by summing the variances in the
completion times of the activities in the critical path. Given this variance, one can calculate the
probability that the project will be completed by a certain date assuming a normal probability
distribution for the critical path. The normal distribution assumption holds if the number of activities in
the path is large enough for the central limit theorem to be applied.
Since the critical path determines the completion date of the project, the project can be accelerated by
adding the resources required to decrease the time for the activities in the critical path. Such a shortening
of the project sometimes is referred to as project crashing.
Update as Project Progresses: Make adjustments in the PERT chart as the project progresses. As
the project unfolds, the estimated times can be replaced with actual times. In cases where there

are delays, additional resources may be needed to stay on schedule and the PERT chart may be
modified to reflect the new situation.
ADVANTAGES OF PERT
PERT is useful because it provides the following information:
Expected project completion time.
Probability of completion before a specified date.
The critical path activities that directly impact the completion time.
The activities that have slack time and that can lend resources to critical path activities.
Activity start and end dates.
PERT chart explicitly defines and makes visible dependencies (precedence relationships)
between the WBS elements
PERT facilitates identification of the critical path and makes this visible
PERT facilitates identification of early start, late start, and slack for each activity,
PERT provides for potentially reduced project duration due to better understanding of
dependencies leading to improved overlapping of activities and tasks where feasible.
The large amount of project data can be organized & presented in diagram for use in decision
making.
The three time estimate process is useful in identifying difficulties as well as more effective
interrelated processes. When utilizing the latest computer applications to PERT networks,
managers have additional benefits with which to plan.
Use of what is termed the management-by-exception principle, whereby data accumulated and
analyzed by various means can be applied to the planning and execution of a major project.
When managers have used PERT in integrated project management, experience gained is
reapplied to future projects, especially in developing bids for project estimates. When
appropriate costing techniques are implemented with PERT networking, the project sponsors
realize significant financial benefits.
The PERT/cost system was developed to gain tighter control over actual costs of any project.
PERT\cost relates actual costs to project costs. Job cost estimates are established from an activity
or a group of activities on the basis of a time network. Labor and nonlabor estimates are
developed for the network targeting the control of time and costs and identifying potential areas
where time and cost can be traded offall aimed at more effective, efficient project
management.
As with all aspects of business, the Internet has become a powerful tool with respect to PERT.
Managers can now locate PERT applications on the World Wide Web and apply them directly to
the appropriate manufacturing project. In most instances, PERT diagrams are available that
eliminate the estimating process and make PERT a more useful and convenient tool.
Clearly PERT is a manufacturing-based project planning and scheduling network. In many
instances, managers have attempted to apply PERT principles to other types of projects,
including hospital planning for such issues as costs and social security, educational planning and
development, various accounting functions, and even real estate development.
Disadvantages: The following are some of PERT's weaknesses:

There can be potentially hundreds or thousands of activities and individual dependency

relationships
The network charts tend to be large and unwieldy requiring several pages to print and requiring
special size paper
The lack of a timeframe on most PERT/CPM charts makes it harder to show status although
colours can help (e.g., specific colour for completed nodes)
When the PERT/CPM charts become unwieldy, they are no longer used to manage the project.
Uncertainty in project scheduling-During project execution, however, a real-life project will
never execute exactly as it was planned due to uncertainty. It can be ambiguity resulting from

subjective estimates that are prone to human errors or it can be variability arising from
unexpected events or risks. And Project Evaluation and Review Technique (PERT) may provide
inaccurate information about the project completion time for main reason uncertainty. This
inaccuracy is large enough to render such estimates as not helpful.
One possibility to maximize solution robustness is to include safety in the baseline schedule in order to
absorb the anticipated disruptions. This is called proactive scheduling. A pure proactive scheduling is an
utopia, incorporating safety in a baseline schedule that allows to cope with every possible disruption
would lead to a baseline schedule with a very large make-span. A second approach, reactive scheduling,
consists of defining a procedure to react to disruptions that cannot be absorbed by the baseline schedule.
The activity time estimates are somewhat subjective and depend on judgement.
In cases where there is little experience in performing an activity, the numbers may be only a
guess. In other cases, if the person or group performing the activity estimates the time there may
be bias in the estimate.
Even if the activity times are well-estimated, PERT assumes a beta distribution for these time
estimates, but the actual distribution may be different.
Even if the beta distribution assumption holds, PERT assumes that the probability distribution of
the project completion time is the same as the that of the critical path. Because other paths can
become the critical path if their associated activities are delayed, PERT consistently
underestimates the expected project completion time.
The underestimation of the project completion time due to alternate paths becoming critical is
perhaps the most serious of these issues. To overcome this limitation, Monte Carlo simulations
can be performed on the network to eliminate this optimistic bias in the expected project
completion time.
A vital aspect of PERT is the formula used for the calculation of expected project time. The project
reads:
where T = expected completion time,
A = optimistic estimate,
M = most likely estimate,
B = pessimistic estimate.
Applying real numbers to the PERT formula, the result is as follows, where A (optimistic time) = 7
weeks; M (most likely time) = 11 weeks; B (pessimistic time) = 15 weeks:
(or T, expected completion time)
Once the expected time is computed, the critical path is established. The PERT network considers all
potential variables, thus quantifying the scheduling and planning of the project. In a comprehensive view
of PERT, it becomes clear that despite the fact that some steps of the process are independent, the next
step will depend on the successful completion of prior steps.
Another key to PERT is to analyze and revise the data owing to a constant state of flux. Factors
influencing project management take many forms, including personnel, materials, equipment and
facilities, utilities, and environmental conditions. For example, absenteeism, sickness, vacations, and
even strikes can affect personnel supply, or sudden changes in climatic conditions (snow, flooding from
rains, etc.) may have an environmental impact. Various methods have been established to adjust the
PERT network in order to allow for unpredictable situations. In recent years, computers have provided
one major means of network analysis and revision, especially on larger projects. Computers are
significantly useful for computations of the critical path and slack time. Smaller networks can generally
be managed with manual computations and are usually developed, evaluated, and revised without great
difficulty.

The basic difference in PERT and CPM is in how the diagrams are drawn. In PERT, events are placed in
circles (or rectangles) to emphasize a point in time. Tasks are indicated by the lines connecting the
network of events. In CPM the emphasis is on the tasks, which are placed in circles. The circles are then
connected with lines to indicate the relationship between the tasks. CPM use has become more
widespread than the use of PERT applications.
PERT has advantages as well as disadvantages, but time has seemingly not diminished its applicability.
Planning a major network reveals potential problem areas and interdependent events that are not so
obvious in conventional project development methods.
Critical path method
The CPM is a mathematically based algorithm for scheduling a set of project activities. It is an important
tool for effective project management.
History: The CPM is a project modeling technique developed in the late 1950s by Morgan R. Walker of
DuPont and James E. Kelley, Jr. of Remington Rand. Kelley and Walker related their memories of the
development of CPM in 1989. Kelley attributed the term "critical path" to the developers of the Program
Evaluation and Review Technique which was developed at about the same time by Booz Allen Hamilton
and the US Navy. The precursors of what came to be known as Critical Path were developed and put
into practice by DuPont between 1940 and 1943 and contributed to the success of the Manhattan Project.
CPM is commonly used with all forms of projects, including construction, aerospace and defense,
software development, research projects, product development, engineering, and plant maintenance,
among others. Any project with interdependent activities can apply this method of mathematical
analysis. Although the original CPM program and approach is no longer used, the term is generally
applied to any approach used to analyze a project network logic diagram.
Basic technique: The essential technique for using CPM is to construct a model of the project that
includes the following:
A list of all activities required to complete the project (typically categorized within a work
breakdown structure),
The time (duration) that each activity will take to completion, and
The dependencies between the activities
Using these values, CPM calculates the longest path of planned activities to the end of the project, and
the earliest and latest that each activity can start and finish without making the project longer. This
process determines which activities are "critical" (i.e., on the longest path) and which have "total float"
(i.e., can be delayed without making the project longer). In project management, a critical path is the
sequence of project network activities which add up to the longest overall duration. This determines the
shortest time possible to complete the project. Any delay of an activity on the critical path directly
impacts the planned project completion date (i.e. there is no float on the critical path). A project can have
several, parallel, near critical paths. An additional parallel path through the network with the total
durations shorter than the critical path is called a sub-critical or non-critical path.
These results allow managers to prioritize activities for the effective management of project completion,
and to shorten the planned critical path of a project by pruning critical path activities, by "fast tracking"
(i.e., performing more activities in parallel), and/or by "crashing the critical path" (i.e., shortening the
durations of critical path activities by adding resources).
Originally, the critical path method considered only logical dependencies between terminal elements.
Since then, it has been expanded to allow for the inclusion of resources related to each activity, through
processes called activity-based resource assignments and resource leveling. A resource-leveled schedule
may include delays due to resource bottlenecks (i.e., unavailability of a resource at the required time),
and may cause a previously shorter path to become the longest or most "resource critical" path. A related
concept is called the critical chain, which attempts to protect activity and project durations from
unforeseen delays due to resource constraints.
Since project schedules change on a regular basis, CPM allows continuous monitoring of the schedule,
allows the project manager to track the critical activities, and alerts the project manager to the possibility
that non-critical activities may be delayed beyond their total float, thus creating a new critical path and

delaying project completion. In addition, the method can easily incorporate the concepts of stochastic
predictions, using the Program Evaluation and Review Technique (PERT) and event chain methodology.
Currently, there are several software solutions available in industry that use the CPM method of
scheduling. Ironically, the method currently used by most project management software is actually based
on a manual calculation approach developed by Fondahl of Stanford University.
A schedule generated using critical path techniques often is not realised precisely, as estimations are
used to calculate times: if one mistake is made, the results of the analysis may change. This could cause
an upset in the implementation of a project if the estimates are blindly believed, and if changes are not
addressed promptly. However, the structure of critical path analysis is such that the variance from the
original schedule caused by any change can be measured, and its impact either ameliorated or adjusted
for.
Indeed, an important element of project postmortem analysis is the As Built Critical Path (ABCP),
which analyzes the specific causes and impacts of changes between the planned schedule and eventual
schedule as actually implemented.
CPM: In 1957, DuPont developed a project management method designed to address the challenge of
shutting down chemical plants for maintenance and then restarting the plants once the maintenance had
been completed. Given the complexity of the process, they developed the CPM for managing such
projects. CPM provides the following benefits:
Provides a graphical view of the project.
Predicts the time required to complete the project.
Shows which activities are critical to maintaining the schedule and which are not.
CPM models the activities and events of a project as a network. Activities are depicted as nodes on the
network and events that signify the beginning or ending of activities are depicted as arcs or lines
between the nodes.
Steps in CPM Project Planning
Specify the individual activities.
Determine the sequence of those activities.
Draw a network diagram.
Estimate the completion time for each activity.
Identify the critical path (longest path through the network)
Update the CPM diagram as the project progresses.
1. Specify the Individual Activities: From the work breakdown structure, a listing can be made of all the
activities in the project. This listing can be used as the basis for adding sequence and duration
information in later steps.
2. Determine the Sequence of the Activities: Some activities are dependent on the completion of others.
A listing of the immediate predecessors of each activity is useful for constructing the CPM network
diagram.
3. Draw the Network Diagram: Once the activities and their sequencing have been defined, the CPM
diagram can be drawn. CPM originally was developed as an activity on node (AON) network, but some
project planners prefer to specify the activities on the arcs.
4. Estimate Activity Completion Time: The time required to complete each activity can be estimated
using past experience or the estimates of knowledgeable persons. CPM is a deterministic model that
does not take into account variation in the completion time, so only one number is used for an activity's
time estimate.
5. Identify the Critical Path: The critical path is the longest-duration path through the network. The
significance of the critical path is that the activities that lie on it cannot be delayed without delaying the
project. Because of its impact on the entire project, critical path analysis is an important aspect of project

planning. The critical path can be identified by determining the following four parameters for each
activity:
ES - earliest start time: the earliest time at which the activity can start given that its precedent activities
must be completed first.
EF - earliest finish time, equal to the earliest start time for the activity plus the time required to complete
the activity.
LF - latest finish time: the latest time at which the activity can be completed without delaying the
project.
LS - latest start time, equal to the latest finish time minus the time required to complete the activity.
The slack time for an activity is the time between its earliest and latest start time, or between its earliest
and latest finish time. Slack is the amount of time that an activity can be delayed past its earliest start or
earliest finish without delaying the project.
The critical path is the path through the project network in which none of the activities have slack, that
is, the path for which ES=LS and EF=LF for all activities in the path. A delay in the critical path delays
the project. Similarly, to accelerate the project it is necessary to reduce the total time required for the
activities in the critical path.
6. Update CPM Diagram: As the project progresses, the actual task completion times will be known and
the network diagram can be updated to include this information. A new critical path may emerge, and
structural changes may be made in the network if project requirements change.
Limitations of CPM: CPM was developed for complex but fairly routine projects with minimal
uncertainty in the project completion times. For less routine projects there is more uncertainty in the
completion times, and this uncertainty limits the usefulness of the deterministic CPM model. An
alternative to CPM is the PERT project planning model, which allows a range of durations to be
specified for each activity.
FAST TRACKING AND CRASHING: Tom Mochal cover these two methods of fixing a project
schedule. Project managers should evaluate their schedules on a weekly basis to ensure their project
remains on track. If the project starts to drift, there are a number of techniques that can be used to get
back on schedule. Most of these are not dramatic. However, let's assume that your project starts to slip
dramatically. It may not be possible to get back on track through the typical schedule management
techniques. Lets further assume that the project deadline is fixed and can't change. In this case you may
need to employ more dramatic means. Two techniques to consider are fast tracking and crashing.
Fast tracking: Fast tracking means that you look at activities that are normally done in sequence and
assign them instead partially in parallel. For instance, normally you would not start constructing a
solution until the design was completed. However, if you were fast-tracking, you would start
constructing the solution in areas where you felt the design was pretty solid without waiting for the
entire design to be completed. Fast-tracking always involves risk that could lead to increased cost and
some rework later. For instance, in the example of designing and constructing an application, its
possible that the design might change before it is finalized, and those final changes may result in having
to redo some of the construct work already underway. A good rule of thumb is that sequential activities
can sometimes be fast-tracked by up to 33%. In other words, if you're fast-tracking, you can start the
second of two sequential activities when the first activity is 66% complete. There is risk involved.
However, this seems to be a level of fast-tracking risk that is normally acceptable.
Crashing: Adding more resources to a project to shorten its duration is called "crashing". "Crashing" the
schedule means to throw additional resources to the critical path without necessarily getting the highest
level of efficiency. For instance, lets say one person was working on a ten-day activity on the critical
path. If you were really desperate to shorten this timeframe, you might add a second resource to this
activity. In fact, the resource may not have all the right skills and he might work five days just to reduce
the overall time by two days. On the surface, the prior tradeoff might not make sense. After all, why
would you have a person work five days just to reduce an activity by two days? It's not efficient.
However, can you imagine a project that was so important that you were willing to make this kind of
tradeoff? Think about the YR2K projects. When the end of 1999 was rolling around, many companies
were throwing resources onto projects; desperate to get them completed on time. They were fast-

tracking. Additional resources may come from within the project team, or they may be loaned
temporarily from outside the team.
One of the goals of crashing the schedule is to minimize the incremental cost. However, in exchange for
completing some work ahead of schedule, crashing usually always leads to some additional incremental
cost to the project. If you're willing and able to spend more to accelerate the schedule, fast-tracking may
be a viable option for you.
But adding resources to a project is often the least dependable way to shorten duration. What's more, it
almost always costs more and generates far more work for the project manager.
The damage that crashing can do: As any pregnant woman knows, you can't add more resources to a
pregnancy to get it over with in five months instead of nine. Truth be told, adding resources to a project
stands as much chance of increasing duration as it does shortening it.
New resources aren't familiar with the tasks at hand and are less productive than current team members.
And who guides the new members up the learning curve? Usually the experienced, most productive
members of the project team, who could be working themselves to get the tasks finished.
At times, the extra hands are often only tangentially qualified for the work. They might do their best, but
the world's foremost neurosurgeons won't help if you need HTML programmers. Even if the new
resources have the right skills, they might not be of the same caliber as the current team members. Either
way, the quality on the project might slip.
Time is money: When you crash a project, you hope to trade off time for money. The project spends
more money to (with luck) deliver in less time. And this can still make economic sense in the long run.
For example, high-tech gadgets grow obsolete at an alarming pace, so getting the goods to market
sooner can mean an increase in profit, which more than makes up for the crashing cost.
Still, why throw money away? You don't have to spend $100,000 to shorten the schedule by 12 weeks, if
you determine that eight weeks and only $50,000 will do. As you'll see, the more you crash a project, the
more expensive the crashes become. By crashing the most cost-effective tasks first, you can pull the
schedule in for the lowest possible cost.
At the scene of the crash: The critical path is the place to look when you want to shorten a schedule. By
definition, the critical path is the sequence of tasks that is nothing but back-to-back work, with no slack,
which you can subtract to reduce the duration. Shortening the Build Ship Infrastructure task won't do
anything to shorten the overall project duration. Because the Build Improbability Drive task is longer, it
determines when the Assemble Components task starts, regardless of how little time it takes to build the
ship.
The tasks on the critical path are the only ones that can shorten the duration of a project.
Cost-effective crash techniques: Crashing the project isn't as simple as finding all the tasks on the critical
path and wildly assigning resources to them. Some tasks cost more per week to crash than others.
Figure 2 shows a crash table that uses the cost of crashing a task and the number of weeks it reduces the
schedule to calculate the crash cost per week.
From your Microsoft Office Project Professional 2003 schedule, you can export the tasks on the critical
path, their durations, and their original costs. Then, by importing that information onto a Microsoft
Office Excel 2003 worksheet, you can calculate the crash cost per week for each task. Sorting the tasks
by the crash cost per week quickly shows you the least costly tasks for crashing.
This worksheet is sorted by using three columns. Column A identifies the tasks on the critical path, so
the sort begins by separating the critical path tasks from the rest of the schedule. Then, the Crash Cost
per Week column is sorted in ascending order to find the least costly tasks. Finally, the Crash Duration
column is sorted in descending order to find the cheapest tasks that shorten the schedule the most. By
looking for the largest reduction at the lowest price, you crash the fewest tasks.
By sorting critical path tasks by using the crash cost per week, you can find the most cost-effective tasks
to crash.

Here's how this example plays out. The Build Improbability Drive task costs $10 million for every week
that you cut from the schedule. Therefore, it will cost $50 million to reduce the schedule by five weeks.
Build Improbability Drive engineers are, well, pretty improbable to come by, so hiring a second one for
the project comes at a steep price. On the other hand, if you start by crashing the least costly task,
Assemble Components, you can shorten the schedule by four weeks for only $4 million.
Crashing a task can change the critical path on the project, even adding a task to the critical path that
wasn't there before. For example, if you reduced the Build Improbability Drive task to less than 40
weeks, the status of the Build Ship Infrastructure task would be elevated to the critical path. To
accurately evaluate your crash decisions, you should review the critical path after every task crash.
If you look closely at the worksheet you'll notice that the Build Ship Infrastructure task and the Test
Improbability Drive task cost less per week to crash than the Build Improbability Drive task. Why aren't
they crashed earlier? The answer lies in the Crash Result column. These two tasks aren't on the critical
path. Although crashing those tasks costs money, their shorter durations don't shorten the overall project
schedule one bit.
Figure 3 illustrates the benefit of crashing the least costly tasks first. As you can see, the initial
reductions shorten the schedule significantly without much of an increase in overall cost. But, as you dig
deeper for more reductions, each additional week comes at a higher and higher price.
Additional reductions in duration come at increasingly higher prices.
Creating a crash table: Crash tables are simple to create. Here are the basic steps that you must perform:
Export the work package tasks (ID and Task Name fields), the original duration (Duration field), and the
original cost (Original Cost field) from your Project Professional 2003 schedule, and open that file in
Excel 2003.
You must calculate the potential crash duration for each critical path task and the cost to crash each task.
On the Excel worksheet, add a column to calculate crash reduction, which is how many weeks you can
crash each task. Crash reduction is simply the original duration minus the crash duration.
Add another column to calculate the crash cost per week, which is the crash cost divided by the crash
reduction value.
If the powers-that-be offer to provide more resources to shorten the project schedule, you're better off
recommending other strategies first, such as fast-tracking, which is the partial overlapping of tasks
originally scheduled sequentially. Or you might offer to spend some time optimizing your schedule in
other ways. For example, you can split long tasks into smaller chunks to squeeze more work into shorter
time, reduce lag times between tasks, or reduce the scope to eliminate less important tasks. However, if
adding resources becomes necessary, take the time to crash the right tasks in the right order. You might
not earn a bonus for your fiscal responsibility, but spending money unnecessarily could cost you your
job.
APPROACHES TO CRASHING A PROJECT NETWORK
I. "minimum-time schedule" method:
use the normal times for each activity to determine the critical path
crash every activity from its normal time to its crash time (minimum duration time) - this gives the
minimum-time schedule
If you must make the minimum time but you want to reduce the cost you can uncrash activities that
aren't critical, beginning with those that are most expensive.
II. "minimum cost schedule" method:
use the normal times for each activity to determine the critical path
crash the activity on the critical path that has the lowest cost to crash per unit time, until: the activity
duration time cannot be reduced any further; or another path becomes critical; or the additional costs of
crashing outweigh

savings from crashing

repeat step 2 until the cost of continuing to crash the project is greater than the savings from crashing
when there is more than one critical path, it may be necessary to simultaneously crash an activity on
each path if so, select the activities that give the lowest total cost per unit time
Example 3
ActivityPredecessorsNormal TimeCrash TimeNormal CostCrash CostCrash
Cost/Week
A-4311,00011,700700
BA317,0009,0001000
CA215,0005,600600
DB4314,00016,0002,000
EB, C112,0002,000FC328,70010,0001,300
GE, F4223,00028,0002,500
HD3210,00011,2001,200
Total 80,70093,500

ESTIMATION OF PROJECT COSTS: For many development projects, the bulk of project costs are tied
to staffing. In this case, the best way to estimate project cost is to prepare a detailed project schedule
using Microsoft Project (or a similar tool), and to use the resource management features of that software
to identify the types, quantities, and phasing of different types of labor.
Project cost estimating is usually performed by summing estimates for individual project elements into a
project total. The pieces can vary in size and number from a few large chunks of a project with known
costs to hundreds or thousands of discrete tasks or individual work packages.
Bottom-up estimates are often prepared by contractors to support their proposal bid process. This
involves using a detailed WBS and pricing out each work package making up the project. This method
may be laborious and time consuming, but it can result in a fairly accurate estimate if the work content is
well understood.
Top-down estimates use rules of thumb, parametric models, analogies, or cost estimating relationships
(CERs). CERs based on historical experience can provide data such as the cost to develop a source line
of software or the cost per square foot for a building construction project.
Sometimes project cost goals are a forced-fit to the amount of money available in the budget. This will
require the project manager to initiate a cost estimate to find out if the project is feasible. Adjustments in
scope may be needed so the project can survive.
"Design-to-Cost" is a process where cost goals for development, acquisition, or operations and
maintenance are used as design parameters, along with technical performance, in the systems design
trade-off process. In cases where the absolute value of a dollar threshold needs to be contained, the
project definition, conceptual design, and development can address performance trade-offs to fit the
project within a predetermined cost envelope.
"Cost as the Independent Variable" is an affordability based method for planning project scope. It starts
with a fixed budget and works backwards, through an iterative process of prioritizing and selecting
requirements, to arrive at a project scope achievable within budget constraints. Costs can usually be
estimated with acceptable accuracy by using relevant historical cost data, a well constructed and
documented estimating methodology, and a good understanding of the work content to be performed.

This approach involves putting as much detail into understanding the tasks as possible and generating
assumptions with whatever shreds of knowledge may be available.
If equipment is to be acquired, a recent analogous vendor quote will be helpful. Experience shows,
however, that analogous cost data are often not analogous. For this reason, the cost estimator will want
to determine whether configurations are really similar; changes are anticipated; things like start-up,
installation, and spare parts are included; and if there are costs left out. These same principles apply to
using costs from similar projects or service contracts. Find out what the cost data include and what has
been left out. It is sometimes useful to take available cost data and shape it using size and complexity
factors to estimate costs for analogous, yet distinctly different, project efforts.
If you estimate only the requirements you are sure of, your estimate will usually be low. If your estimate
for the number of source lines of software is uncertain, you may want to add an uncertainty factor to the
estimate (15-35%).
It may be prudent to add a contingency factor to account for expected changes, or to allocate
management reserves to deal with later eventualities. When a cost estimate is done well, the most likely
problems will be: (1) scope left out, (2) not understanding the technical difficulty, and (3) changes.
Cost estimates are done for different reasons, and the purpose of the estimate usually imparts a bias to
the numbers. "Marketing estimates" are likely to be low, while good "budget estimates" are likely to be
high. When judging the accuracy of an estimate, you need to know the source of the estimate and the
purpose for which it was derived. If the estimate was proposed by a project advocate, you may want to
use caution before putting those numbers in your budget.
Cost estimates that hinge on assumptions about staff or asset availabilities or schedule dependencies
outside the managers control should be considered areas of cost risk and managed accordingly.
As a project manager, you need to understand if your cost estimates are sound or if you are buying into
an inevitable cost overrun due to under-estimating. The adverse consequence of a cost estimate that is
too conservative is that it can kill an otherwise viable project by making it look unaffordable.
Good cost estimating requires a supportive environment in the organization. One way to help this is to
develop projects using standard work breakdown structure categories, and then collect actual costs in a
historical cost database. A cost database for software, for instance, could be used to collect data related
to cost per line of code, software sizing algorithms, costs for function points, or cost data from bottomup functional descriptions and tasks.
A well-structured cost estimate can become unmanageable after the third or fourth "what-if" iteration
unless each change is meticulously documented. Even knowing this fact well, experienced cost
estimators are constantly reminded of it when trying to reconstruct or explain cost estimates that were
prepared some months or years back. It seems that one can never document a cost estimate too well or
record assumptions too thoroughly. An aid to this process is using a PC spreadsheet to prepare your
estimate, and then keeping all the important data and adjustment factors visible in cells, rather than
hidden in formulas. If the assumptions, factors, and data sources are not obvious in your cost estimate
documentation, then it is not done yet.
Put assumptions like uncertainty factors, mark-ups, and quantity multipliers in cells and where they can
be accessed globally, then you can do iterations quickly, and your assumptions will be visible for
reviewers and clearly documented for future reference. It is sometimes helpful to document your cost
estimating methodology in a narrative form. This can help with subsequent reviews and audits, and it
can lay the groundwork for developing an enterprise-wide cost estimating methodology.
When you construct a cost estimating spreadsheet with each cost driving factors in a single cell, it can be
used to conduct cost sensitivity analysis. You can vary an uncertain quantitative assumption and the plot
it against the range of results. If total project or product cost is relatively insensitive to a given variable,
it can be left alone. If the project cost is sensitive to an uncertain assumption, specific efforts should be
focused on gathering additional data to lessen that uncertainty.
TIME AND COST OVERRUN
Cost overrun:
A cost overrun, also known as a cost increase or budget overrun, is an
unexpected cost incurred in excess of a budgeted amount due to an under-estimation of the actual cost

during budgeting. Cost overrun should be distinguished from cost escalation, which is used to express an
anticipated growth in a budgeted cost due to factors such as inflation. Cost overrun is common in
infrastructure, building, and technology projects.
Many major construction projects have incurred cost overruns. The Suez Canal cost 20 times as much as
the earliest estimates; even the cost estimate produced the year before construction began
underestimated the project's actual costs by a factor of three. The Sydney Opera House cost 15 times
more than was originally projected, and the Concorde supersonic airplane cost 12 times more than
predicted. When Boston's "Big Dig" tunnel construction project was completed, the project was 275
percent ($11 billion) over budget. The Channel Tunnel between the UK and France had a construction
cost overrun of 80 percent, and a 140-percent financing cost overrun.
Causes
Three types of explanation for cost overrun exist: technical, psychological, and political-economic. All
three explanations can be considered forms of risk. A project's budgeted costs should always include
cost contingency funds to cover risks (other than scope changes imposed on the project).
Technical explanations account for cost overrun in terms of imperfect forecasting techniques, inadequate
data, etc. Psychological explanations account for overrun in terms of optimism bias with forecasters.
Finally, political-economic explanations see overrun as the result of strategic misrepresentation of scope
or budgets.
Calculation of Cost Overrun:
Cost overrun is typically calculated in one of two ways:
As a percentage, namely actual cost minus budgeted cost, in percent of budgeted cost.
As a ratio of actual cost divided by budgeted cost.
For example, if the budget for building a new bridge was $100 million, and the actual cost was $150
million, then the cost overrun may be expressed by the ratio 1.5, or as 50 percent.
A comprehensive study of cost overrun published in the Journal of the American Planning Association in
2002 found that 9 out of ten construction projects had underestimated costs. Overruns of 50 to one
hundred percent were common. Cost underestimation was found in each of 20 nations and five
continents covered by the study, and cost underestimation had not decreased in the 70 years for which
data were available. For IT projects, an industry study by the Standish Group found that the average cost
overrun was 43 percent; 71 percent of projects were over budget, exceeded time estimates, and had
estimated too narrow a scope; and total waste was estimated at $55 billion per year in the US alone.
How to Avoid Cost Overrun in Your IT Outsourcing Strategy: It 'goes without saying that information
technology is a field of activity, where a lot of problems can occur. It 'also where most outsourcing is
happening. This is because the company usually assumes a 'business and do well, but on a big project
there is a need for more activity. So we need to cooperate to ensure that all is well can be formed. In
addition, we may have to employ more qualified. This happens if the deadline is not met or problems
appear in the project. In this case, usually need to outsource. The problem is not easy to successfully
build your strategy on IT outsourcing. Must be true or loss of money can be made. Let's talk about cost
overruns and how they are avoided.
We will begin work on an IT project we have a special budget will outsourcing. When. This budget
includes income and costs required to deliver this project finished. When outsourcing is involved, we
must be very careful. A lot of people do not have, payroll outsourcing, a strategy for outsourcing because
they think all is to think simple. We can easily understand why we believe, because the facts seem
simple to use. We need to set the people to do a task, and we can afford, pay an amount to produce a
profit. Unfortunately, we tend to some facts overrun. First cause the cost is off, outsourcing, when we
think about long, payroll outsourcing, forgotten. A lot of people forget. Most projects have a deadline to
be met. period not to consider non-compliance may lead to cuts in pay or an attack on the entire project.
In our mind, we believe that some time is needed to accomplish a task. The truth may be different in the
sense that more time might be needed. In this case you will agree with renting or more persons or
missing a deadline. Both cases are immediately translated into a loss of money. Also, if your outsourcing
strategy is not working properly to analyze what price you pay for what they are doing the third, you
lose money, and could be faced with cost overruns. A correct understanding of its costs should be

included in the IT outsourcing strategy before even thinking deal with a particular project. The bottom
line is that every error can allow the passing of information technology projects. This is particularly true
if the mix of outsourcing has been added. Since nobody wants to cost overruns, you should invest some
'time to learn to build Properly IT outsourcing strategy in order to avoid problems.
Outsource Method Saved Me Over 500% On My Staffing Costs
Outsourcing can be a very costly and mistake ridden path if you dont have the connections or know the
pitfalls. When we Interviewed the CEO of RentACoder.com we were amazed at how many buyers get
this wrong.
Time overruns: Percentage of projects behind schedule declined from 62% in 1991 to lowest ever to
31.72% in March 2001, to 34.13% in March 2007 and increased again to 52.10%. The increasing trend
of percentage of delayed projects is also due to the same reasons as in case of cost overruns. The
projects in the Highway, Power, and Petroleum, shipping Ports, Telecommunication, Steel, fertilizers
and Railway sectors suffered the most.
Time is the essence of project management, therefore the system of monitoring based on the monitoring
of milestones drawn from the PERT/CPM charts of projects.
Project Cost and Risk Management: Governments and worlds biggest companies continue to invest
heavily in infrastructural development projects to sustain a growing economy and population.
Project cost overruns are experienced all over the globe. Sydneys iconic opera house, in Australia,
retains the world record for the worst overrun. It cost nearly 15 times more than the original estimate
and was completed a decade late. The project which begun in 1957 only completed in 1973 on a scaleddown version. The total cost was A$102 million over budget by A$95 million. According to the July
2010 publication of the Financial Mail, just before the South Africa 2010 World Cup, in building
Greenpoint Stadium, Murray and Roberts, the construction company, had to make up about six months
in delays. This was due to the redesigning of the stadium by the City of Cape Town which added an
extra R500m to the original bill. Costs soared as the company was forced to source specific materials
from overseas for the design changes. To add more salt to the wound, when M & R signed the contract
in February 2007 to deliver the Gautrain project on time, Gauteng government wasnt able to hand over
the land, which meant M & R didnt have access to the site to do design and geological work. Eventually
every piece of land on the 85km stretch was handed over, but 450 days late.
The above cases illustrate the need for excellent project and risk management skills when it comes to
project planning and deliverance. Risk is inevitable when it comes to projects of this nature. The first
step in preventing cost and time overruns is to acknowledge that they are likely. Some of the reasons
projects experience cost and time overruns are as follows:
1. Insufficient skills and resources: A successful project requires a successful project team. There should
be diversity in the background of the team members.
2. Poor Planning: Most projects fail because the requirements are poorly defined and there is no
agreement or prioritisation of tasks to be completed.
3. Lack of understanding about cost drivers: There is need to identify those activities that are more likely
to reduce the projects duration and cost and then establish a contingency plan.
4. Inadequate Information: Past performance alone is not a good predictor of future performance. Data
on which some projects are based is just plain wrong and obsolete.
5. Unforeseen problems: Sometimes people are overconfident about what can be achieved with the
resources available and fail to plan for the worst case scenario.
6. Inadequate checks on estimates and work: Many people make the mistake of using a fixed budget
from the initial planning phase and when macroeconomic conditions change, they fail to take this into
consideration.
7. Poor Project Leadership: This will always lead to poor project direction and management.
8. Political Pressure: the existence of political pressure, vested interests or fear of a lack of approval also
result in cost overruns.

So what should project leaders do to control the costs of a project and avoid overruns?
1. Have a business case: This drives the project and details the costs and benefits to be accrued. In other
words, the business case clearly defines and prioritises the projects requirements.
2. Identify the direct costs and indirect costs: Distinguishing between direct costs and indirect costs
helps identify those costs that are assignable to specific package of activity and those that are not. It also
makes it easier to identify cost drivers.
3. Validate forecasts and estimates: These should be based on adequate information and not biased. In
order to make realistic estimates, its important that you use a range of information sources. Using
reference class forecasting (RCF) helps make comparisons between the project in question and those
of a similar type.
4. Management should be involved: Senior managers should sponsor the project throughout its lifetime
and not only at the start.
5. Be proactive: This involves continually seeking alternative ways to meet deadlines.
6. Consider lower-cost alternatives: This involves sourcing out quality materials from various suppliers
at a lower price. However, avoid poor quality materials just because they are the cheapest on the market.

Project Audit: To follow the objectives and successfully complete a particular project, it is essential to
study the project feasibility process by the method of project audit. You can plan future projects by
learning new dimensions of the existing project.
Conducting an audit is imperative to assess the progress of a project and regular audit sessions ensure
that a projects management is in-sync with the established project objectives. Ideally, an audit process
should have some level of flexibility. The reason - various teams and organizational resources are
involved in the execution of a project and to measure each of them using a standard assessment tool may
not provide the most accurate results. However, the focus should be on not deviating from the purpose of
a project management is an honest assessment of team and individual performances and their ability to
execute assignments to achieve project targets, both short-term and long-term.
A basic checklist that is often used for auditing project management to assess the Project Characteristics
includes verifying the presence of:
Strategic project management tools for organizing and monitoring every facet of a project
Clearly-defined phases and sub-processes through a projects lifecycle
Delegation of responsibilities to ensure that each of the project phase is in agreement with the critical
project objectives
Conducting periodic audits ensures that project-related risks are avoided. Usual risks that hinder project
performance are:
Practices that defy cost-management and make the project economically unfeasible
Non-adherence with the project plan or organizational practices
Inability to keep-up with time-specific deadlines
Over or under-evaluation of availability of resources
Presence of team personnel who are not qualified for the project
Every organization has various project-related processes to be audited. Following are some of processes
and auditing-related queries that are designed to judge their overall performance:
Auditing of Cost-related Processes (Including Financial Planning)
Budget-based-been managed to ensure that they dont exceed the defined budgetary allocation?
Is the proposed project budget compatible with the organizations limitations?

Does the project budget has a scope for bearing contingency or risk-related expenses?
Is there a budgetary review and does it highlight the reasons for budget discrepancies?
Estimation-based:
Has the cost estimation process been clearly-defined and documented?
Was cost estimation conducted in accordance with accounting regulations?
What methods were used for estimating expenditures related to project execution?
Auditing of Strategic Management-based Processes (Including Management of Organizational
Interdependencies)
Has the authority and the level of accountability been properly divided between various organizational
entities like stakeholders, team members and customers?
Does the management use strategic monitoring/evaluation tools like taking remedial actions, periodic
reviews, establishing responsibility delegation and tracking/verification of adherence to guidelines?
Does the project manager have acceptable levels of authority and clearly-defined accountability
instructions?
Is there a system of analyzing past projects and using this information for improving future task-related
performances?
Is there a system to manage project interaction teams like those involved in risk management, project
evaluation communication?
Does the project plan address issues such as reviews, progress reports and does it include the evaluation
of various project interfaces?
Core constituents of project management that are analyzed during an audit:
Time Management
Time schedule development measures
Activity duration analysis in terms, including inter-team dependency
Resource Management
Resource planning and control in terms of:
Allocation of resources, criteria for distribution, analysis of consumption patterns and measures to
control resource abuse
Personnel Management
Allocation of staff and establishment of recruiting policies
Division of responsibilities regarding team development and training needs
Information Management
Policies regarding Preparing and Collecting information
Principles used for Classifying and Distributing information
Methods used for Filing, Updating and Retrieving information
The purpose of the audit is not just analyzing various project and functionalities but also to help the
organization understand the performance of each of them. For this purpose, most audit processes use a
grading system to rank each audited project constituent:
Critically Deficient suggests a serious inability to match project guidelines
Weak unable to entirely comply with project objectives

Satisfactory *basic project management principles are followed but the overall performance has room
for improvement
Good the compatibility with the project goals and effectiveness of management tools, both are
appreciable and committed to project goals
Very Good the process defines ideal project performance and adheres to planning/monitoring
expectations and performs as per project expectations
This is how audit processes become effective based upon such detailed evaluation, better monitoring
and planning measures can be introduced, wherever necessary to ensure that every project-related meet
the organizations objectives.
Project Audit Process
Initial Inquiry: The process of auditing any project starts out with a formal notification being sent to the
project members, informing them of the impending audit. The notification will also inform the project
members of the audit team's objective and what compliance issues the team will be examining. After
sending project members notification of the impending audit, the audit team will schedule and
conduct a face-to-face meeting with the project head and any administrators. The audit team will
examine the project's records and data files ahead of the full audit.
Reporting Schedule: After the formality of the initial inquiry is over, the audit team begins a full-fledged
inquiry into the project. The team will attempt to glean a further idea of how the project is functioning
by going over the project's background documents and conducting interviews with the project head and
the project's sponsor. The audit team will also conduct a series of interviews with members of the
project, mapping out their individual roles in the project, to get a more detailed idea of the project's
hierarchy and the validity of each member's role. During the inquiry and reporting phase of the audit, the
audit team will periodically report its finding back to the project's sponsor. The audit team will also
examine the project members' efficiency in following their set timelines and will record any
inconsistencies in the project's goals and individual project member's performance.
Final Report: After sufficient data has been gleaned from the project's data files and group member
interviews and the audit team has a firm idea of how the project is supposed to be carried out, the audit
team will create a formal draft of its report. After the management team presiding over the audit team
has reviewed the formal report and decided whether to recommend any amendments or further inquires
into the project, the audit team will construct the final draft. The final draft of the audit report will
contain a summary, list background and key issues raised, and provide an assessment of the quality of
the project members' performance in carrying out its said goals.
Project Audit Process
The primary purpose of a project audit is to find the reasons for uncomfortable symptoms in the project,
and answer questions posed by the sponsor or senior manager. These might include:
Am I being told the truth about the current state of the project?
Is the project going to deliver something that meets my requirements?
Is the technical approach being used appropriate?
Should I believe the project plan?
Is the project organised appropriately, and are the project processes being followed optimal?
Is the project following industry best practices?
What should be changed to improve things?
The output of a project audit should be answers to these questions, giving practical and specific advice
on fixing any problems uncovered, and guidance on improving efficiency for the future.
Major Tasks of a Project Audit

1. Evaluate if the project delivered the expected benefits to all stakeholders.

Was the project managed well?
Was the customer satisfied?
2. Assess what was done wrong and what contributed to successes.
3. Identify changes to improve the delivery of future projects.

Project Audit Components

A review of why the project was selected.

A reassessment of the projects role in the organizations priorities.
A check on the organizational culture to ensure it facilitates the type of project being implemented.
An assessment of how well the project team is functioning well and if its is appropriately staffed.
A check on external factors that might change where the project is heading or its importance.
A review of all factors relevant to the project and to managing future projects.
Types of Project Audits
In-process project audits
Allow for corrective changes if conditions have changed and for concentration on project progress
and performance.
Postproject audits
Take a broader and longer-term view of the projects role in the organization and emphasize improving
the management of future projects.

Project Audit: To follow the objectives and successfully complete a particular project, it is essential to
study the project feasibility process by the method of project audit. You can plan future projects by
learning new dimensions of the existing project.
Conducting an audit is imperative to assess the progress of a project and regular audit sessions ensure
that a projects management is in-sync with the established project objectives. Ideally, an audit process
should have some level of flexibility. The reason - various teams and organizational resources are
involved in the execution of a project and to measure each of them using a standard assessment tool may
not provide the most accurate results. However, the focus should be on not deviating from the purpose of
a project management is an honest assessment of team and individual performances and their ability to
execute assignments to achieve project targets, both short-term and long-term.
A basic checklist that is often used for auditing project management to assess the Project Characteristics
includes verifying the presence of:
Strategic project management tools for organizing and monitoring every facet of a project
Clearly-defined phases and sub-processes through a projects lifecycle
Delegation of responsibilities to ensure that each of the project phase is in agreement with the critical
project objectives

Conducting periodic audits ensures that project-related risks are avoided. Usual risks that hinder project
performance are:
Practices that defy cost-management and make the project economically unfeasible
Non-adherence with the project plan or organizational practices
Inability to keep-up with time-specific deadlines
Over or under-evaluation of availability of resources
Presence of team personnel who are not qualified for the project
Every organization has various project-related processes to be audited. Following are some of processes
and auditing-related queries that are designed to judge their overall performance:
Auditing of Cost-related Processes (Including Financial Planning)
Budget-based-been managed to ensure that they dont exceed the defined budgetary allocation?
Is the proposed project budget compatible with the organizations limitations?
Does the project budget has a scope for bearing contingency or risk-related expenses?
Is there a budgetary review and does it highlight the reasons for budget discrepancies?
Estimation-based:
Has the cost estimation process been clearly-defined and documented?
Was cost estimation conducted in accordance with accounting regulations?
What methods were used for estimating expenditures related to project execution?
Auditing of Strategic Management-based Processes (Including Management of Organizational
Interdependencies)
Has the authority and the level of accountability been properly divided between various organizational
entities like stakeholders, team members and customers?
Does the management use strategic monitoring/evaluation tools like taking remedial actions, periodic
reviews, establishing responsibility delegation and tracking/verification of adherence to guidelines?
Does the project manager have acceptable levels of authority and clearly-defined accountability
instructions?
Is there a system of analyzing past projects and using this information for improving future task-related
performances?
Is there a system to manage project interaction teams like those involved in risk management, project
evaluation communication?
Does the project plan address issues such as reviews, progress reports and does it include the evaluation
of various project interfaces?
Core constituents of project management that are analyzed during an audit:
Time Management
Time schedule development measures
Activity duration analysis in terms, including inter-team dependency
Resource Management
Resource planning and control in terms of:
Allocation of resources, criteria for distribution, analysis of consumption patterns and measures to
control resource abuse

Personnel Management
Allocation of staff and establishment of recruiting policies
Division of responsibilities regarding team development and training needs
Information Management
Policies regarding Preparing and Collecting information
Principles used for Classifying and Distributing information
Methods used for Filing, Updating and Retrieving information
The purpose of the audit is not just analyzing various project and functionalities but also to help the
organization understand the performance of each of them. For this purpose, most audit processes use a
grading system to rank each audited project constituent:
Critically Deficient suggests a serious inability to match project guidelines
Weak unable to entirely comply with project objectives
Satisfactory *basic project management principles are followed but the overall performance has room
for improvement
Good the compatibility with the project goals and effectiveness of management tools, both are
appreciable and committed to project goals
Very Good the process defines ideal project performance and adheres to planning/monitoring
expectations and performs as per project expectations
This is how audit processes become effective based upon such detailed evaluation, better monitoring
and planning measures can be introduced, wherever necessary to ensure that every project-related meet
the organizations objectives.
Project Audit Process
Initial Inquiry: The process of auditing any project starts out with a formal notification being sent to the
project members, informing them of the impending audit. The notification will also inform the project
members of the audit team's objective and what compliance issues the team will be examining. After
sending project members notification of the impending audit, the audit team will schedule and
conduct a face-to-face meeting with the project head and any administrators. The audit team will
examine the project's records and data files ahead of the full audit.
Reporting Schedule: After the formality of the initial inquiry is over, the audit team begins a full-fledged
inquiry into the project. The team will attempt to glean a further idea of how the project is functioning
by going over the project's background documents and conducting interviews with the project head and
the project's sponsor. The audit team will also conduct a series of interviews with members of the
project, mapping out their individual roles in the project, to get a more detailed idea of the project's
hierarchy and the validity of each member's role. During the inquiry and reporting phase of the audit, the
audit team will periodically report its finding back to the project's sponsor. The audit team will also
examine the project members' efficiency in following their set timelines and will record any
inconsistencies in the project's goals and individual project member's performance.
Final Report: After sufficient data has been gleaned from the project's data files and group member
interviews and the audit team has a firm idea of how the project is supposed to be carried out, the audit
team will create a formal draft of its report. After the management team presiding over the audit team
has reviewed the formal report and decided whether to recommend any amendments or further inquires
into the project, the audit team will construct the final draft. The final draft of the audit report will
contain a summary, list background and key issues raised, and provide an assessment of the quality of
the project members' performance in carrying out its said goals.
Project Audit Process

The primary purpose of a project audit is to find the reasons for uncomfortable symptoms in the project,
and answer questions posed by the sponsor or senior manager. These might include:
Am I being told the truth about the current state of the project?
Is the project going to deliver something that meets my requirements?
Is the technical approach being used appropriate?
Should I believe the project plan?
Is the project organised appropriately, and are the project processes being followed optimal?
Is the project following industry best practices?
What should be changed to improve things?
The output of a project audit should be answers to these questions, giving practical and specific advice
on fixing any problems uncovered, and guidance on improving efficiency for the future.
Major Tasks of a Project Audit

1. Evaluate if the project delivered the expected benefits to all stakeholders.

Was the project managed well?
Was the customer satisfied?
2. Assess what was done wrong and what contributed to successes.
3. Identify changes to improve the delivery of future projects.

Project Audit Components

A review of why the project was selected.

A reassessment of the projects role in the organizations priorities.
A check on the organizational culture to ensure it facilitates the type of project being implemented.
An assessment of how well the project team is functioning well and if its is appropriately staffed.
A check on external factors that might change where the project is heading or its importance.
A review of all factors relevant to the project and to managing future projects.
Types of Project Audits
In-process project audits
Allow for corrective changes if conditions have changed and for concentration on project progress
and performance.
Postproject audits
Take a broader and longer-term view of the projects role in the organization and emphasize improving
the management of future projects.

PROJECT CONTROL: 5 steps to help you keep a project under control:

Giving priority to the right thing at the right place,
making necessary adjustments in anticipation to change,
analyzing the hours spent and actual work done,
maintaining a record of daily issues and
using software like GANTT, PERT, CPM to know how the project is going on.
Project control systems: Project control is that element of a project that keeps it on-track, on-time and
within budget. Project control begins early in the project with planning and ends late in the project with
post-implementation review, having a thorough involvement of each step in the process. Each project
should be assessed for the appropriate level of control needed: too much control is too time consuming,
too little control is very risky. If project control is not implemented correctly, the cost to the business
should be clarified in terms of errors, fixes, and additional audit fees. Control systems are needed for
cost, risk, quality, communication, time, change, procurement, and human resources. In addition,
auditors should consider how important the projects are to the financial statements, how reliant the
stakeholders are on controls, and how many controls exist. Auditors should review the development
process and procedures for how they are implemented. The process of development and the quality of
the final product may also be assessed if needed or requested. A business may want the auditing firm to
be involved throughout the process to catch problems earlier on so that they can be fixed more easily. An
auditor can serve as a controls consultant as part of the development team or as an independent auditor
as part of an audit.
Businesses sometimes use formal systems development processes. These help assure that systems are
developed successfully. A formal process is more effective in creating strong controls, and auditors
should review this process to confirm that it is well designed and is followed in practice. A good formal
systems development plan outlines:
A strategy to align development with the organizations broader objectives
Standards for new systems
Project management policies for timing and budgeting
Procedures describing the process
Evaluation of quality of change.
PROJECT MONITORING AND CONTROL (PMC): PMC subjects each project to continuous
monitoring in order to determine if, and when, any given project deviates from /planned estimates/. This
process area makes use of Project Planning (PP) and Measurement and Analysis (MA) which are key
processes to understanding whether or not a project is in control.
The purpose of PMC is to provide an understanding of the projects progress so that appropriate
corrective actions can be taken when the projects performance deviates significantly from the plan.
PMC IS A documented plan basis for monitoring activities, communicating status, and taking corrective
action. Progress is primarily determined by comparing actual work product and task attributes, effort,
cost, and schedule to the plan at prescribed milestones or control levels within the project schedule or
work breakdown structure (WBS). Appropriate visibility enables timely corrective action to be taken
when performance deviates significantly from the plan. A deviation is significant if, when left
unresolved, it precludes the project from meeting its objectives.
Monitoring the Project: The project manager monitors the overall project. A phase project manager
monitors his phase. The phase project manager reports to the overall project manager of any risks.
Jointly, phase project managers and overall project manager shouldidentify risks, potential project problems, as early as possible

identify when goals may not be met

identify when constraints may be violated
ensure that contingency plans occur before unrecoverable problems occur
provide and receive project status for the phases and total project.
When there is a significant chance that the goals of the project will not be met, this risk should be
reported to upper management. Also, when the constraints of the project may be violated, specifically,
costs being overrun and schedules significantly slipped, these risks will be reported.
When there are disagreements between the phase project manager and overall project manager, then
resolution will be escalated to the change control board. Lack of resolution there could escalate to upper
management.
Of the identified risks, these can be separated into those that the project managers consider to be
important and those not considered to be important; of these, the important risks can be built into the
schedule. Of these identified important risks, some will be actual problems and contingency plans in the
schedule would be initiated.

Of the identified risks, some will be considered not important. These later may not becomes problems,
as expected, or may indeed become problems.
The other category of problems, unidentified problems, have a higher likelihood of being overlooked. Of
these, some will become problems and others will not.
there are three paths that result in problems:
1.

Those risks that are identified as important and you do nothing about them

2.

Those risks that are identified as unimportant and later change into a high risk

3.

Those you do not identify and later become problems.

Risks in 1. should never become a problem because the project managers would build them into the
schedules. Risks in 2., although probably not built into the schedule, should be recorded and
remembered and periodically revisited by project managers to determine if they are now turning into
problems. Unidentified risks (3.) require constant monitoring by project managers to identify and
resolve.
The most important Project RisksLack of top management commitment to the project
Failure to gain user commitment
Misunderstanding the requirements
Lack of adequate user involvement
Failure to manage end user expectations
Changing scope/objectives
Lack of required knowledge/skills in the project personnel
Lack of frozen requirements
Introduction of new technology
Insufficient/inappropriate staffing
Conflict between user departments

Monitoring Changes to Workflows: Reengineering workflows is not a one shot deal but should
involve ongoing process management and improvement. Once workflows have been implemented, they
should be monitored for actual improvement in business operations and for compliance with business
policies.
Reengineering is imbedded both within human processes implemented in the organization and within
user interfaces. Both should be considered for further (even radical) change once the project is complete.
As in the project reengineering process, the employee should be heavily involved, as reengineering is a
social process in addition to a business and technical process.
Monitoring System Performance: A potential problem when automated systems are involved is the
potential of the systems not being able to handle increased volumes of data in the future. To take care of
this, performance monitoring should be a part of all automated systems that are likely to grow in size,
identifying potential future bottlenecks in the system, including lack of disk space, lack or processing
power, approaching transaction limits, long before they become a problem, so corrective action can be
taken.
This process is very complex because automated systems will grow in size due to systems being
installed incrementally (e.g., they may be installed at a pilot location first) and due to future increases in
number of customers over time. It is also complex because new technology may become available that
handles greater capacity but that will incur additional costs to the organization to implement.

The term project plan is used throughout these practices to refer to the overall plan for controlling the
project. When actual status deviates significantly from the expected values, corrective actions are taken
as appropriate. These actions may require replanning, which may include revising the original plan,
establishing new agreements, or including additional mitigation activities within the current plan.
Related Process Areas: This refer to the Project Planning process area for more information about the
project plan, including how it specifies the appropriate level of project monitoring, the measures used to
monitor progress, and known risks. It refers to the Measurement and Analysis process area for
information about the process of measuring, analyzing, and recording information. Actual performance
and progress of the project are monitored against the project plan.
Monitor Project Planning Parameters: Monitor the actual values of the project planning parameters
against the project plan. Project planning parameters constitute typical indicators of project progress and
performance and include attributes of work products and tasks, cost, effort, and schedule. Attributes of
the work products and tasks include such items as size, complexity, weight, form, fit, or function.
Monitoring typically involves measuring the actual values of project planning parameters, comparing
actual values to the estimates in the plan, and identifying significant deviations. Recording actual values
of the project planning parameters includes recording associated contextual information to help
understand the measures. An analysis of the impact that significant deviations have on determining what
corrective actions to take is handled in the second specific goal and its specific practices in this process
area.
Typical Work Products
Records of project performance
Records of significant deviations
Monitor progress against the schedule.
Progress monitoring typically includes the following:
Periodically measuring the actual completion of activities and milestones
Comparing actual completion of activities and milestones against the schedule documented in the
project plan
Identifying significant deviations from the schedule estimates in the project plan

Monitor the project's cost and expended effort.

Effort and cost monitoring typically includes the following:

Periodically measuring the actual effort and cost expended and staff assigned
Comparing actual effort, costs, staffing, and training to the estimates and budget documented in the
project plan
Identifying significant deviations from the budget in the project plan
Monitor the attributes of the work products and tasks.
Refer to the Project Planning process area for information about the attributes of work products and
tasks.
Monitoring the attributes of the work products and tasks typically includes the following:

Periodically measuring the actual attributes of the work products and tasks, such as size or complexity
(and the changes to the attributes)
Comparing the actual attributes of the work products and tasks (and the changes to the attributes) to the
estimates documented in the project plan
Identifying significant deviations from the estimates in the project plan
Monitor resources provided and used.
Refer to the Project Planning process area for information about planned resources.
Examples of resources include the following:
Physical facilities
Computers, peripherals, and software used in design, manufacturing, testing, and operation
Networks
Security environment
Project staff
Processes
Monitor the knowledge and skills of project personnel.
Refer to the Project Planning process area for information about planning for knowledge and skills
needed to perform the project.
Monitoring the knowledge and skills of the project personnel typically includes the following:

Periodically measuring the acquisition of knowledge and skills by project personnel

Comparing actual training obtained to that documented in the project plan
Identifying significant deviations from estimates in the project plan

Document the significant deviations in the project planning parameters.

Monitor Commitments
Monitor commitments against those identified in the project plan.

Typical Work Products

Records of commitment reviews
Regularly review commitments (both external and internal).
Identify commitments that have not been satisfied or that are at significant risk of not being satisfied.
Document the results of the commitment reviews.
Monitor Project Risks
Monitor risks against those identified in the project plan.
Refer to the Project Planning process area for more information about identifying project risks.
Refer to the Risk Management process area for more information about risk management activities.
Typical Work Products
Records of project risk monitoring
Periodically review the documentation of the risks in the context of the projects current status and
circumstances.
Revise the documentation of the risks, as additional information becomes available, to incorporate
changes.
Communicate risk status to relevant stakeholders.
Examples of risk status include the following:

A change in the probability that the risk occurs

A change in risk priority
Monitor Data Management
Monitor the management of project data against the project plan.
Refer to the Plan for Data Management specific practice in the Project Planning process area for more
information about identifying the types of data that should be managed and how to plan for their
management. Once the plans for the management of project data are made, the management of that data
must be monitored to ensure that those plans are accomplished.
Typical Work Products
Records of data management
Periodically review data management activities against their description in the project plan.
Identify and document significant issues and their impacts.
Document the results of data management activity reviews.
Monitor Stakeholder Involvement
Monitor stakeholder involvement against the project plan.
Refer to the Plan Stakeholder Involvement specific practice in the Project Planning process area for
more information about identifying relevant stakeholders and planning the appropriate involvement with
them. Once the stakeholders are identified and the extent of their involvement within the project is
specified in project planning, that involvement must be monitored to ensure that the appropriate
interactions are occurring.
Typical Work Products
Records of stakeholder involvement

Periodically review the status of stakeholder involvement.

Identify and document significant issues and their impacts.
Document the results of the stakeholder involvement status reviews.
Conduct Progress Reviews
Periodically review the project's progress, performance, and issues.
Progress reviews are reviews on the project to keep stakeholders informed. These project reviews can be
informal reviews and may not be specified explicitly in the project plans.
Documented project review results
Regularly communicate status on assigned activities and work products to relevant stakeholders.
Managers, staff members, customers, end users, suppliers, and other relevant stakeholders within the
organization are included in the reviews as appropriate.
Review the results of collecting and analyzing measures for controlling the project.
Refer to the Measurement and Analysis process area for more information about the process for
measuring and analyzing project performance data.
Identify and document significant issues and deviations from the plan.
Document change requests and problems identified in any of the work products and processes.
Refer to the Configuration Management process area for more information about how changes are
managed.
Document the results of the reviews.
Track change requests and problem reports to closure.
Conduct Milestone Reviews
Review the accomplishments and results of the project at selected project milestones.
Refer to the Project Planning process area for more information about milestone planning.
Milestone reviews are planned during project planning and are typically formal reviews.
Documented milestone review results
Conduct reviews at meaningful points in the project?s schedule, such as the completion of selected
stages, with relevant stakeholders.
Managers, staff members, customers, end users, suppliers, and other relevant stakeholders within the
organization are included in the milestone reviews as appropriate.
Review the commitments, plan, status, and risks of the project.
Identify and document significant issues and their impacts.
Document the results of the review, action items, and decisions.
Track action items to closure.
Manage Corrective Action to Closure
Corrective actions are managed to closure when the project's performance or results deviate significantly
from the plan.
Many product integration problems arise from unknown or uncontrolled aspects of both internal and
external interfaces. Effective management of product component interface requirements, specifications,
and designs helps ensure that implemented interfaces will be complete and compatible.
Analyze Issues

Collect and analyze the issues and determine the corrective actions necessary to address the issues.
List of issues needing corrective actions
Gather issues for analysis.
Issues are collected from reviews and the execution of other processes.
Examples of issues to be gathered include the following:
Issues discovered through performing verification and validation activities
Significant deviations in the project planning parameters from the estimates in the project plan
Commitments (either internal or external) that have not been satisfied
Significant changes in risk status
Data access, collection, privacy, or security issues
Stakeholder representation or involvement issues
Analyze issues to determine need for corrective action.
Refer to the Project Planning process area for information about corrective action criteria. Corrective
action is required when the issue, if left unresolved, may prevent the project from meeting its objectives.
Take Corrective Action
Take corrective action on identified issues.
Typical Work Products
Corrective action plan
Determine and document the appropriate actions needed to address the identified issues.
Refer to the Project Planning process area for more information about the project plan when replanning
is needed.
Examples of potential actions include the following:
Modifying the statement of work
Modifying requirements
Revising estimates and plans
Renegotiating commitments
Adding resources
Changing processes
Revising project risks
Review and get agreement with relevant stakeholders on the actions to be taken.
Negotiate changes to internal and external commitments.
Manage Corrective Action
Manage corrective actions to closure.
Corrective action results
Monitor corrective actions for completion.
Analyze results of corrective actions to determine the effectiveness of the corrective actions.

Determine and document appropriate actions to correct deviations from planned results for corrective
actions.
Lessons learned as a result of taking corrective action can be inputs to planning and risk management
processes.
Generic Practices by Goal: The process supports and enables achievement of the specific goals of the
process area by transforming identifiable input work products to produce identifiable output work
products.
Perform Specific Practices
Perform the specific practices of the project monitoring and control process to develop work products
and provide services to achieve the specific goals of the process area.
Institutionalize a Managed Process
The process is institutionalized as a managed process.
Establish an Organizational Policy*
Establish and maintain an organizational policy for planning and performing the project monitoring and
control process.
Elaboration: This policy establishes organizational expectations for monitoring performance against the
project plan and managing corrective action to closure when actual performance or results deviate
significantly from the plan.
Plan the Process
Establish and maintain the plan for performing the project monitoring and control process.
Elaboration: This plan for performing the project monitoring and control process can be part of (or
referenced by) the project plan, as described in the Project Planning process area.
Provide Resources
Provide adequate resources for performing the project monitoring and control process, developing the
work products, and providing the services of the process.
Elaboration: Examples of resources provided include the following tools:
Cost tracking systems
Effort reporting systems
Action item tracking systems
Project management and scheduling programs
Assign Responsibility
Assign responsibility and authority for performing the process, developing the work products, and
providing the services of the project monitoring and control process.
Train People
Train the people performing or supporting the project monitoring and control process as needed.
Elaboration: Examples of training topics include the following:
Monitoring and control of projects
Risk management
Data management
Manage Configurations

Place designated work products of the project monitoring and control process under appropriate levels of
control.
Project schedules with status
Project measurement data and analysis
Earned value reports
Identify and Involve Relevant Stakeholders
Identify and involve the relevant stakeholders of the project monitoring and control process as planned.
Examples of activities for stakeholder involvement include the following:
Assessing the project against the plan
Reviewing commitments and resolving issues
Reviewing project risks
Reviewing data management activities
Reviewing project progress
Managing corrective actions to closure
Monitor and Control the Process
Monitor and control the project monitoring and control process against the plan for performing the
process and take appropriate corrective action.
Examples of measures and work products used in monitoring and controlling include the following:
Number of open and closed corrective actions
Schedule with status for monthly financial data collection, analysis, and reporting
Number and types of reviews performed
Review schedule (planned versus actual and slipped target dates)
Schedule for collection and analysis of monitoring data
Objectively Evaluate Adherence
Objectively evaluate adherence of the project monitoring and control process against its process
description, standards, and procedures, and address noncompliance.
Examples of activities reviewed include the following:
Monitoring project performance against the project plan
Managing corrective actions to closure
Examples of work products reviewed include the following:
Records of project performance
Project review results
Review Status with Higher Level Management
Review the activities, status, and results of the project monitoring and control process with higher level
management and resolve issues.
Institutionalize a Defined Process
The process is institutionalized as a defined process.
This generic goal's appearance here reflects its location in the continuous representation.

Establish a Defined Process

Establish and maintain the description of a defined project monitoring and control process.
Collect Improvement Information
Collect work products, measures, measurement results, and improvement information derived from
planning and performing the project monitoring and control process to support the future use and
improvement of the organizations processes and process assets.
Examples of work products, measures, measurement results, and improvement information include the
following:
Records of significant deviations
Criteria for what constitutes a deviation
Corrective action results
Institutionalize a Quantitatively Managed Process
The process is institutionalized as a quantitatively managed process.
Establish Quantitative Objectives for the Process
Establish and maintain quantitative objectives for the project monitoring and control process, which
address quality and process performance, based on customer needs and business objectives.
Stabilize Subprocess Performance
Stabilize the performance of one or more subprocesses to determine the ability of the project monitoring
and control process to achieve the established quantitative quality and process-performance objectives.
Institutionalize an Optimizing Process
The process is institutionalized as an optimizing process.
Ensure Continuous Process Improvement
Ensure continuous improvement of the project monitoring and control process in fulfilling the relevant
business objectives of the organization.
Correct Root Causes of Problems*
Identify and correct the root causes of defects and other problems in the project monitoring and control
process.
Actual performance and progress of the project are monitoredagainst the project plan.
Monitor the actual values of the project planning parameters against the project plan.
Monitor commitments against those identified in the project plan.
Monitor risks against those identified in the project plan.
Monitor the management of project data against the project plan.
Monitor stakeholder involvement against the project plan.
Periodically review the project's progress, performance, and issues.
Review the accomplishments and results of the project at selected project milestones.
Corrective actions are managed to closure when the project's performance or results deviate significantly
from the plan.
Collect and analyze the issues and determine the corrective actions necessary to address the issues.
Take corrective action on identified issues.

Manage corrective actions to closure.

Establish and maintain an organizational policy for planning and performing the project monitoring and
control process.
Establish and maintain the plan for performing the project monitoring and control process.
Provide adequate resources for performing the planned process, developing the work products and
providing the services for the project monitoring and control process.
Assign responsibility and authority for performing the process, developing the work products, and
providing the services of the project monitoring and control process.
Train the people performing or supporting the project monitoring and control process as needed.
Place designated work products of the project monitoring and control process under appropriate levels
of configuration management.
Identify and involve the relevant stakeholders of the project monitoring and control process as planned.
Monitor and control the project monitoring and control process against the plan for performing the
process and take appropriate corrective action.
Objectively evaluate adherence of the project monitoring and control process against its process
description, standards, and procedures, and address noncompliance.
Review the activities, status, and results of the project monitoring and control process with management
and resolve issues.
Controlled Documents: Controlled documents may include the following:
organizational objectives, priorities of objectives, strategies and goals
project objectives, priorities of objectives, strategies, goals and constraints
business requirements
workflow requirements
system requirements
organizational business policies
interface plans
functional specifications
internal design documents (programming specifications)
vendor customization specifications
programs and program code
databases and data dictionary
test plans
performance and scalability requirements (a Performance and Adaptability Plan)
user documentation, including descriptions of user interfaces.
Once an automated system has been implemented, then the automated system must be maintained. After
an automated system has been completed and goes into maintenance mode, documents that extend
beyond the project and should be maintained and kept up-to-date are those with an asterisk next to them.
Documentation describes an automated system are functional specifications and internal design
specifications. These documents should also be controlled. Doing so and enforcing that any changes to
the automated system also be recorded in the functional and internal design specifications, provides
control over the automated system.

Technical items from which an automated system can be builtprogram code and databasesare also
controlled. Program code and databases for previous versions of the automated system are also kept in
case a severe problem occurs that requires a changed automated system to be backed out, returning to a
previous version. This process is called the release process or version control.2.4.
Other documents than those listed above are less often controlled during the project, including project
plans, risks and contingency plans because they are likely to change and be updated quite often, but
should only be changed with careful consideration and consultations.
Controlled documents can be usedto control changes that may seriously harm a project
to distinguish an error in the project from a change in the project.
An error is an inconsistency between how an agreement, workflow or automated system is
implemented and how it is documentedthis is either an error in the implementation or in the
documentation. A change is a modification in the way an agreement, workflow or automated system is
implemented when the implementation matches the documentation of itfor a change, both the
agreement, workflow or automated system and the documentation should be changed.
Change Control Board: Questions the change board might ask are the following:
Is the change necessary? When?
What groups are impacted by the change? How will dependencies and schedules be impacted?
Is there are more effective and preferred change to the one that is proposed? Can changes be
consolidated?
How and when can the change be best made with the least negative impact?
Will the change also change the overall project?
After approved: What is the priority of the changes with respect to other approved changes?
If the change would change the overall project or change other phases in the project, then the overall
design will have to be re-visited to determine the changes effect on other phases of the project.
Maintenance of an Automated System: Once a function has been completed in an automated system,
changes must be introduced in a very disciplined fashion. Changes to existing functionality in an
automated system is called maintenance.
A change is proposed by the business group, management or users. A change document describing the
change is written. (A change could result from a change in a business policy.) The change is reviewed
and approved by the change control board or a user group for the automated system.
The change is discussed with the technical development group who will implement the change and the
quality assurance (QA) group who will test the change. The function or functions to be changed are
analyzed by the business group and the changes are incorporated into the function(s), updating the
functional specification(s) describing the functions from an external view.
The development group uses the functional specification to identify the internal changes to the system.
The development group makes changes to the internal design specifications and the interface plan, and
makes changes to a development version of the automated system or interfaces with other development
systems.
QA tests the development version of the automated system and compares the way it works as compared
to the functional specifications. If there are any discrepancies between the automated system and
functional specifications, it is determined whether there is an error in the changed system or in the
functional specifications. The errors are corrected. The automated system is then retested against the
functional specifications.
When no discrepancies are found, user manuals describing the function are updated and any changes to
business policies are recorded. Changes to automated systems are implemented in the healthcare
organization.

Technical documents (program code, data dictionaries, interface descriptions) are updated within release
control, with old versions kept to back out the changes if necessary.
The Release Process: A fully functioning automated system or set of automated systems that is delivered
to the customer is called a *release *[1]. Subsequent releases could fix program errors or introduce
changes in the automated systems. Such a release is created from program code and databases which
together can be used to build or rebuild the automated system.
The release process is also a controlled process. Although new and changed code, databases, etc., should
be heavily tested before the release, unexpected problems sometimes occur just after a release. If the
release fails, the changed code, databases, etc., should be backed out with return to a previous version of
the system (i.e., return to the previous release).
Because the release process generally involves keeping each successive version of the automated
systems, the release process is also referred to as version control.
Control of software changes is called software configuration management. Software configuration
management is the discipline of managing the evolution of large and complex software systems, through
control of different versions of the software, changes back to a previous version, variants of programs,
and cooperation [2].
Variants of a program are two programs that function the same or nearly the same but differ slightly in
some way; for example, two variants work exactly the same, but work under two different operating
systems. Cooperation is allowing multiple developers to work on a program at the same time.

PROJECT CONTROL PROCESS

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

INITIATING
PLANNING

EXECUTING

MONITORING &
CONTROLLING

CLOSING

Major process groups generally include:

Initiation
Planning or development
Production or execution
Monitoring and controlling
Closing

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

Financial analysis of the costs and benefits including a budget

Stakeholder analysis, including users, and support personnel for the project
Project charter including costs, tasks, deliverables, and schedule
PLANNING AND DESIGN
After the initiation stage, the project is planned to an appropriate level of detail. The main purpose is to
plan time, cost and resources adequately to estimate the work needed and to effectively manage risk
during project execution. As with the Initiation process group, a failure to adequately plan greatly
reduces the project's chances of successfully accomplishing its goals.
Project planning generally consists of
Determining how to plan (e.g. By level of detail or rolling wave);
Developing the scope statement;
Selecting the planning team;
Identifying deliverables and creating the work breakdown structure;
Identifying the activities needed to complete those deliverables and networking the activities in their
logical sequence;
Estimating the resource requirements for the activities;
Estimating time and cost for activities;
Developing the schedule;
Developing the budget;
Risk planning;
Gaining formal approval to begin work.
Additional processes, such as planning for communications and for scope management, identifying roles
and responsibilities, determining what to purchase for the project and holding a kick-off meeting are also
generally advisable.
For new product development projects, conceptual design of the operation of the final product may be
performed concurrent with the project planning activities, and may help to inform the planning team
when identifying deliverables and planning activities.
EXECUTING
Executing consists of the processes used to complete the work defined in the project management plan
to accomplish the project's requirements. Execution process involves coordinating people and resources,
as well as integrating and performing the activities of the project in accordance with the project
management plan. The deliverables are produced as outputs from the processes performed as defined in
the project management plan.
MONITORING AND CONTROLLING
Monitoring and controlling consists of those processes performed to observe project execution so that
potential problems can be identified in a timely manner and corrective action can be taken, when
necessary, to control the execution of the project. The key benefit is that project performance is observed
and measured regularly to identify variances from the project management plan.
Monitoring and Controlling includes
Measuring the ongoing project activities ('where we are');
Monitoring the project variables (cost, effort, scope, etc.) against the project management plan and the
project performance baseline (where we should be);

Identify corrective actions to address issues and risks properly (How can we get on track again);
Influencing the factors that could circumvent integrated change control so only approved changes are
implemented
In multi-phase projects, the monitoring and control process also provides feedback between project
phases, in order to implement corrective or preventive actions to bring the project into compliance with
the project management plan.
Project Maintenance is an ongoing process, and it includes
Continuing support of end users
Correction of errors
Updates of the software over time

Monitoring and controlling cycle

In this stage, auditors should pay attention to how effectively and quickly user problems are resolved.
Over the course of any construction project, the work scope may change. Change is a normal and
expected part of the construction process. Changes can be the result of necessary design modifications,
differing site conditions, material availability, contractor-requested changes, value engineering and
impacts from third parties, to name a few. Beyond executing the change in the field, the change normally
needs to be documented to show what was actually constructed. This is referred to as Change
Management. Hence, the owner usually requires a final record to show all changes or, more specifically,
any change that modifies the tangible portions of the finished work. The record is made on the contract
documents usually, but not necessarily limited to, the design drawings. The end product of this effort is
what the industry terms as-built drawings, or more simply, as built. The requirement for providing
them is a norm in construction contracts.
When changes are introduced to the project, the viability of the project has to be re-assessed. It is
important not to lose sight of the initial goals and targets of the projects. When the changes accumulate,
the forecasted result may not justify the original proposed investment in the project.
CLOSING
Closing includes the formal acceptance of the project and the ending thereof. Administrative activities
include the archiving of the files and documenting lessons learned.
This phase consists of:
Project close: Finalize all activities across all of the process groups to formally close the project or a
project phase

Contract closure: Complete and settle each contract (including the resolution of any open items) and
close each contract applicable to the project or project phase.
CONSIDERATION IN CHOOSING THE PROJECT MANAGEMENT STRUCTURE
Organization design is a continuous process. While a simple design is needed for simple strategies,
complex design should be in consonance with the organization requirements, strategy and environment.
The simple centralized and bureaucratic organizational design based on functional departmentation
focuses on work and is thus better suited for getting work done efficiently.
The team or project type of organizational design is appropriate where inputs from several functional
areas are required.
The divisional structure is appropriate if performance and results are to be assessed. Matrix and
adhocratic designs focus on coordination and relationship
No matter what structure your institution chooses, the implementation process itself is the key to the
success of your project office. A champion should be identified to assist in promoting the benefits of
good project management and helping to clear roadblocks to change.

Culturally, most institutions should begin with a less controlling, de-centralized project office, at least
until the staff becomes comfortable working in a matrix-managed environment. A well-defined, effective
project management office can be an important step to greater success for your institution.
STEPS IN PROJECT CONTROL:
Giving priority to the right thing at the right place,
making necessary adjustments in anticipation to change,
analyzing the hours spent and actual work done,
maintaining a record of daily issues and
using software like GANTT, PERT, CPM to know how the project is going on.
Project control systems: Project control is that element of a project that keeps it on-track, on-time and
within budget. Project control begins early in the project with planning and ends late in the project with
post-implementation review, having a thorough involvement of each step in the process. Each project
should be assessed for the appropriate level of control needed: too much control is too time consuming,
too little control is very risky. If project control is not implemented correctly, the cost to the business
should be clarified in terms of errors, fixes, and additional audit fees. Control systems are needed for
cost, risk, quality, communication, time, change, procurement, and human resources. In addition,
auditors should consider how important the projects are to the financial statements, how reliant the
stakeholders are on controls, and how many controls exist. Auditors should review the development
process and procedures for how they are implemented. The process of development and the quality of
the final product may also be assessed if needed or requested. A business may want the auditing firm to
be involved throughout the process to catch problems earlier on so that they can be fixed more easily. An
auditor can serve as a controls consultant as part of the development team or as an independent auditor
as part of an audit.
Businesses sometimes use formal systems development processes. These help assure that systems are
developed successfully. A formal process is more effective in creating strong controls, and auditors
should review this process to confirm that it is well designed and is followed in practice. A good formal
systems development plan outlines:
A strategy to align development with the organizations broader objectives
Standards for new systems
Project management policies for timing and budgeting
Procedures describing the process
Evaluation of quality of change.

PROJECT MONITORING AND CONTROL (PMC): PMC subjects each project to continuous
monitoring in order to determine if, and when, any given project deviates from /planned estimates/. This
process area makes use of Project Planning (PP) and Measurement and Analysis (MA) which are key
processes to understanding whether or not a project is in control.
The purpose of PMC is to provide an understanding of the projects progress so that appropriate
corrective actions can be taken when the projects performance deviates significantly from the plan.
PMC IS A documented plan basis for monitoring activities, communicating status, and taking corrective
action. Progress is primarily determined by comparing actual work product and task attributes, effort,
cost, and schedule to the plan at prescribed milestones or control levels within the project schedule or
work breakdown structure (WBS). Appropriate visibility enables timely corrective action to be taken
when performance deviates significantly from the plan. A deviation is significant if, when left
unresolved, it precludes the project from meeting its objectives.
Monitoring the Project: The project manager monitors the overall project. A phase project manager
monitors his phase. The phase project manager reports to the overall project manager of any risks.
Jointly, phase project managers and overall project manager shouldidentify risks, potential project problems, as early as possible
identify when goals may not be met
identify when constraints may be violated
ensure that contingency plans occur before unrecoverable problems occur
provide and receive project status for the phases and total project.
When there is a significant chance that the goals of the project will not be met, this risk should be
reported to upper management. Also, when the constraints of the project may be violated, specifically,
costs being overrun and schedules significantly slipped, these risks will be reported.
When there are disagreements between the phase project manager and overall project manager, then
resolution will be escalated to the change control board. Lack of resolution there could escalate to upper
management.
Of the identified risks, these can be separated into those that the project managers consider to be
important and those not considered to be important; of these, the important risks can be built into the
schedule. Of these identified important risks, some will be actual problems and contingency plans in the
schedule would be initiated.

Of the identified risks, some will be considered not important. These later may not becomes problems,
as expected, or may indeed become problems.
The other category of problems, unidentified problems, have a higher likelihood of being overlooked. Of
these, some will become problems and others will not.
there are three paths that result in problems:
1.

Those risks that are identified as important and you do nothing about them

2.

Those risks that are identified as unimportant and later change into a high risk

3.

Those you do not identify and later become problems.

Risks in 1. should never become a problem because the project managers would build them into the
schedules. Risks in 2., although probably not built into the schedule, should be recorded and
remembered and periodically revisited by project managers to determine if they are now turning into
problems. Unidentified risks (3.) require constant monitoring by project managers to identify and
resolve.
The most important Project Risks-

Lack of top management commitment to the project

Failure to gain user commitment
Misunderstanding the requirements
Lack of adequate user involvement
Failure to manage end user expectations
Changing scope/objectives
Lack of required knowledge/skills in the project personnel
Lack of frozen requirements
Introduction of new technology
Insufficient/inappropriate staffing
Conflict between user departments
Monitoring Changes to Workflows: Reengineering workflows is not a one shot deal but should
involve ongoing process management and improvement. Once workflows have been implemented, they
should be monitored for actual improvement in business operations and for compliance with business
policies.
Reengineering is imbedded both within human processes implemented in the organization and within
user interfaces. Both should be considered for further (even radical) change once the project is complete.
As in the project reengineering process, the employee should be heavily involved, as reengineering is a
social process in addition to a business and technical process.
Monitoring System Performance: A potential problem when automated systems are involved is the
potential of the systems not being able to handle increased volumes of data in the future. To take care of
this, performance monitoring should be a part of all automated systems that are likely to grow in size,
identifying potential future bottlenecks in the system, including lack of disk space, lack or processing
power, approaching transaction limits, long before they become a problem, so corrective action can be
taken.
This process is very complex because automated systems will grow in size due to systems being
installed incrementally (e.g., they may be installed at a pilot location first) and due to future increases in
number of customers over time. It is also complex because new technology may become available that
handles greater capacity but that will incur additional costs to the organization to implement.

The term project plan is used throughout these practices to refer to the overall plan for controlling the
project. When actual status deviates significantly from the expected values, corrective actions are taken
as appropriate. These actions may require replanning, which may include revising the original plan,
establishing new agreements, or including additional mitigation activities within the current plan.
Related Process Areas: This refer to the Project Planning process area for more information about the
project plan, including how it specifies the appropriate level of project monitoring, the measures used to
monitor progress, and known risks. It refers to the Measurement and Analysis process area for
information about the process of measuring, analyzing, and recording information. Actual performance
and progress of the project are monitored against the project plan.
Monitor Project Planning Parameters: Monitor the actual values of the project planning parameters
against the project plan. Project planning parameters constitute typical indicators of project progress and
performance and include attributes of work products and tasks, cost, effort, and schedule. Attributes of
the work products and tasks include such items as size, complexity, weight, form, fit, or function.
Monitoring typically involves measuring the actual values of project planning parameters, comparing
actual values to the estimates in the plan, and identifying significant deviations. Recording actual values
of the project planning parameters includes recording associated contextual information to help
understand the measures. An analysis of the impact that significant deviations have on determining what

corrective actions to take is handled in the second specific goal and its specific practices in this process
area.
Typical Work Products
Records of project performance
Records of significant deviations
Monitor progress against the schedule.
Progress monitoring typically includes the following:
Periodically measuring the actual completion of activities and milestones
Comparing actual completion of activities and milestones against the schedule documented in the
project plan
Identifying significant deviations from the schedule estimates in the project plan

Monitor the project's cost and expended effort.

Effort and cost monitoring typically includes the following:

Periodically measuring the actual effort and cost expended and staff assigned
Comparing actual effort, costs, staffing, and training to the estimates and budget documented in the
project plan
Identifying significant deviations from the budget in the project plan
Monitor the attributes of the work products and tasks.
Refer to the Project Planning process area for information about the attributes of work products and
tasks.
Monitoring the attributes of the work products and tasks typically includes the following:

Periodically measuring the actual attributes of the work products and tasks, such as size or complexity
(and the changes to the attributes)
Comparing the actual attributes of the work products and tasks (and the changes to the attributes) to the
estimates documented in the project plan
Identifying significant deviations from the estimates in the project plan
Monitor resources provided and used.
Refer to the Project Planning process area for information about planned resources.
Examples of resources include the following:
Physical facilities
Computers, peripherals, and software used in design, manufacturing, testing, and operation
Networks
Security environment
Project staff
Processes

Monitor the knowledge and skills of project personnel.

Refer to the Project Planning process area for information about planning for knowledge and skills
needed to perform the project.
Monitoring the knowledge and skills of the project personnel typically includes the following:

Periodically measuring the acquisition of knowledge and skills by project personnel

Comparing actual training obtained to that documented in the project plan
Identifying significant deviations from estimates in the project plan

Document the significant deviations in the project planning parameters.

Monitor Commitments
Monitor commitments against those identified in the project plan.
Typical Work Products
Records of commitment reviews
Regularly review commitments (both external and internal).
Identify commitments that have not been satisfied or that are at significant risk of not being satisfied.
Document the results of the commitment reviews.
Monitor Project Risks
Monitor risks against those identified in the project plan.
Refer to the Project Planning process area for more information about identifying project risks.
Refer to the Risk Management process area for more information about risk management activities.
Typical Work Products
Records of project risk monitoring
Periodically review the documentation of the risks in the context of the projects current status and
circumstances.
Revise the documentation of the risks, as additional information becomes available, to incorporate
changes.
Communicate risk status to relevant stakeholders.
Examples of risk status include the following:

A change in the probability that the risk occurs

A change in risk priority
Monitor Data Management
Monitor the management of project data against the project plan.
Refer to the Plan for Data Management specific practice in the Project Planning process area for more
information about identifying the types of data that should be managed and how to plan for their
management. Once the plans for the management of project data are made, the management of that data
must be monitored to ensure that those plans are accomplished.

Typical Work Products

Records of data management
Periodically review data management activities against their description in the project plan.
Identify and document significant issues and their impacts.
Document the results of data management activity reviews.
Monitor Stakeholder Involvement
Monitor stakeholder involvement against the project plan.
Refer to the Plan Stakeholder Involvement specific practice in the Project Planning process area for
more information about identifying relevant stakeholders and planning the appropriate involvement with
them. Once the stakeholders are identified and the extent of their involvement within the project is
specified in project planning, that involvement must be monitored to ensure that the appropriate
interactions are occurring.
Typical Work Products
Records of stakeholder involvement
Periodically review the status of stakeholder involvement.
Identify and document significant issues and their impacts.
Document the results of the stakeholder involvement status reviews.
Conduct Progress Reviews
Periodically review the project's progress, performance, and issues.
Progress reviews are reviews on the project to keep stakeholders informed. These project reviews can be
informal reviews and may not be specified explicitly in the project plans.
Documented project review results
Regularly communicate status on assigned activities and work products to relevant stakeholders.
Managers, staff members, customers, end users, suppliers, and other relevant stakeholders within the
organization are included in the reviews as appropriate.
Review the results of collecting and analyzing measures for controlling the project.
Refer to the Measurement and Analysis process area for more information about the process for
measuring and analyzing project performance data.
Identify and document significant issues and deviations from the plan.
Document change requests and problems identified in any of the work products and processes.
Refer to the Configuration Management process area for more information about how changes are
managed.
Document the results of the reviews.
Track change requests and problem reports to closure.
Conduct Milestone Reviews
Review the accomplishments and results of the project at selected project milestones.
Refer to the Project Planning process area for more information about milestone planning.
Milestone reviews are planned during project planning and are typically formal reviews.
Documented milestone review results

Conduct reviews at meaningful points in the project?s schedule, such as the completion of selected
stages, with relevant stakeholders.
Managers, staff members, customers, end users, suppliers, and other relevant stakeholders within the
organization are included in the milestone reviews as appropriate.
Review the commitments, plan, status, and risks of the project.
Identify and document significant issues and their impacts.
Document the results of the review, action items, and decisions.
Track action items to closure.
Manage Corrective Action to Closure
Corrective actions are managed to closure when the project's performance or results deviate significantly
from the plan.
Many product integration problems arise from unknown or uncontrolled aspects of both internal and
external interfaces. Effective management of product component interface requirements, specifications,
and designs helps ensure that implemented interfaces will be complete and compatible.
Analyze Issues
Collect and analyze the issues and determine the corrective actions necessary to address the issues.
List of issues needing corrective actions
Gather issues for analysis.
Issues are collected from reviews and the execution of other processes.
Examples of issues to be gathered include the following:
Issues discovered through performing verification and validation activities
Significant deviations in the project planning parameters from the estimates in the project plan
Commitments (either internal or external) that have not been satisfied
Significant changes in risk status
Data access, collection, privacy, or security issues
Stakeholder representation or involvement issues
Analyze issues to determine need for corrective action.
Refer to the Project Planning process area for information about corrective action criteria. Corrective
action is required when the issue, if left unresolved, may prevent the project from meeting its objectives.
Take Corrective Action
Take corrective action on identified issues.
Typical Work Products
Corrective action plan
Determine and document the appropriate actions needed to address the identified issues.
Refer to the Project Planning process area for more information about the project plan when replanning
is needed.
Examples of potential actions include the following:
Modifying the statement of work
Modifying requirements

Revising estimates and plans

Renegotiating commitments
Adding resources
Changing processes
Revising project risks
Review and get agreement with relevant stakeholders on the actions to be taken.
Negotiate changes to internal and external commitments.
Manage Corrective Action
Manage corrective actions to closure.
Corrective action results
Monitor corrective actions for completion.
Analyze results of corrective actions to determine the effectiveness of the corrective actions.
Determine and document appropriate actions to correct deviations from planned results for corrective
actions.
Lessons learned as a result of taking corrective action can be inputs to planning and risk management
processes.
Generic Practices by Goal: The process supports and enables achievement of the specific goals of the
process area by transforming identifiable input work products to produce identifiable output work
products.
Perform Specific Practices
Perform the specific practices of the project monitoring and control process to develop work products
and provide services to achieve the specific goals of the process area.
Institutionalize a Managed Process
The process is institutionalized as a managed process.
Establish an Organizational Policy*
Establish and maintain an organizational policy for planning and performing the project monitoring and
control process.
Elaboration: This policy establishes organizational expectations for monitoring performance against the
project plan and managing corrective action to closure when actual performance or results deviate
significantly from the plan.
Plan the Process
Establish and maintain the plan for performing the project monitoring and control process.
Elaboration: This plan for performing the project monitoring and control process can be part of (or
referenced by) the project plan, as described in the Project Planning process area.
Provide Resources
Provide adequate resources for performing the project monitoring and control process, developing the
work products, and providing the services of the process.
Elaboration: Examples of resources provided include the following tools:
Cost tracking systems
Effort reporting systems

Action item tracking systems

Project management and scheduling programs
Assign Responsibility
Assign responsibility and authority for performing the process, developing the work products, and
providing the services of the project monitoring and control process.
Train People
Train the people performing or supporting the project monitoring and control process as needed.
Elaboration: Examples of training topics include the following:
Monitoring and control of projects
Risk management
Data management
Manage Configurations
Place designated work products of the project monitoring and control process under appropriate levels of
control.
Project schedules with status
Project measurement data and analysis
Earned value reports
Identify and Involve Relevant Stakeholders
Identify and involve the relevant stakeholders of the project monitoring and control process as planned.
Examples of activities for stakeholder involvement include the following:
Assessing the project against the plan
Reviewing commitments and resolving issues
Reviewing project risks
Reviewing data management activities
Reviewing project progress
Managing corrective actions to closure
Monitor and Control the Process
Monitor and control the project monitoring and control process against the plan for performing the
process and take appropriate corrective action.
Examples of measures and work products used in monitoring and controlling include the following:
Number of open and closed corrective actions
Schedule with status for monthly financial data collection, analysis, and reporting
Number and types of reviews performed
Review schedule (planned versus actual and slipped target dates)
Schedule for collection and analysis of monitoring data
Objectively Evaluate Adherence
Objectively evaluate adherence of the project monitoring and control process against its process
description, standards, and procedures, and address noncompliance.

Examples of activities reviewed include the following:

Monitoring project performance against the project plan
Managing corrective actions to closure
Examples of work products reviewed include the following:
Records of project performance
Project review results
Review Status with Higher Level Management
Review the activities, status, and results of the project monitoring and control process with higher level
management and resolve issues.
Institutionalize a Defined Process
The process is institutionalized as a defined process.
This generic goal's appearance here reflects its location in the continuous representation.
Establish a Defined Process
Establish and maintain the description of a defined project monitoring and control process.
Collect Improvement Information
Collect work products, measures, measurement results, and improvement information derived from
planning and performing the project monitoring and control process to support the future use and
improvement of the organizations processes and process assets.
Examples of work products, measures, measurement results, and improvement information include the
following:
Records of significant deviations
Criteria for what constitutes a deviation
Corrective action results
Institutionalize a Quantitatively Managed Process
The process is institutionalized as a quantitatively managed process.
Establish Quantitative Objectives for the Process
Establish and maintain quantitative objectives for the project monitoring and control process, which
address quality and process performance, based on customer needs and business objectives.
Stabilize Subprocess Performance
Stabilize the performance of one or more subprocesses to determine the ability of the project monitoring
and control process to achieve the established quantitative quality and process-performance objectives.
Institutionalize an Optimizing Process
The process is institutionalized as an optimizing process.
Ensure Continuous Process Improvement
Ensure continuous improvement of the project monitoring and control process in fulfilling the relevant
business objectives of the organization.
Correct Root Causes of Problems*
Identify and correct the root causes of defects and other problems in the project monitoring and control
process.

Actual performance and progress of the project are monitoredagainst the project plan.
Monitor the actual values of the project planning parameters against the project plan.
Monitor commitments against those identified in the project plan.
Monitor risks against those identified in the project plan.
Monitor the management of project data against the project plan.
Monitor stakeholder involvement against the project plan.
Periodically review the project's progress, performance, and issues.
Review the accomplishments and results of the project at selected project milestones.
Corrective actions are managed to closure when the project's performance or results deviate significantly
from the plan.
Collect and analyze the issues and determine the corrective actions necessary to address the issues.
Take corrective action on identified issues.
Manage corrective actions to closure.
Establish and maintain an organizational policy for planning and performing the project monitoring and
control process.
Establish and maintain the plan for performing the project monitoring and control process.
Provide adequate resources for performing the planned process, developing the work products and
providing the services for the project monitoring and control process.
Assign responsibility and authority for performing the process, developing the work products, and
providing the services of the project monitoring and control process.
Train the people performing or supporting the project monitoring and control process as needed.
Place designated work products of the project monitoring and control process under appropriate levels
of configuration management.
Identify and involve the relevant stakeholders of the project monitoring and control process as planned.
Monitor and control the project monitoring and control process against the plan for performing the
process and take appropriate corrective action.
Objectively evaluate adherence of the project monitoring and control process against its process
description, standards, and procedures, and address noncompliance.
Review the activities, status, and results of the project monitoring and control process with management
and resolve issues.
Controlled Documents: Controlled documents may include the following:
organizational objectives, priorities of objectives, strategies and goals
project objectives, priorities of objectives, strategies, goals and constraints
business requirements
workflow requirements
system requirements
organizational business policies
interface plans
functional specifications

internal design documents (programming specifications)

vendor customization specifications
programs and program code
databases and data dictionary
test plans
performance and scalability requirements (a Performance and Adaptability Plan)
user documentation, including descriptions of user interfaces.
Once an automated system has been implemented, then the automated system must be maintained. After
an automated system has been completed and goes into maintenance mode, documents that extend
beyond the project and should be maintained and kept up-to-date are those with an asterisk next to them.
Documentation describes an automated system are functional specifications and internal design
specifications. These documents should also be controlled. Doing so and enforcing that any changes to
the automated system also be recorded in the functional and internal design specifications, provides
control over the automated system.
Technical items from which an automated system can be builtprogram code and databasesare also
controlled. Program code and databases for previous versions of the automated system are also kept in
case a severe problem occurs that requires a changed automated system to be backed out, returning to a
previous version. This process is called the release process or version control.2.4.
Other documents than those listed above are less often controlled during the project, including project
plans, risks and contingency plans because they are likely to change and be updated quite often, but
should only be changed with careful consideration and consultations.
Controlled documents can be usedto control changes that may seriously harm a project
to distinguish an error in the project from a change in the project.
An error is an inconsistency between how an agreement, workflow or automated system is
implemented and how it is documentedthis is either an error in the implementation or in the
documentation. A change is a modification in the way an agreement, workflow or automated system is
implemented when the implementation matches the documentation of itfor a change, both the
agreement, workflow or automated system and the documentation should be changed.
Change Control Board: Questions the change board might ask are the following:
Is the change necessary? When?
What groups are impacted by the change? How will dependencies and schedules be impacted?
Is there are more effective and preferred change to the one that is proposed? Can changes be
consolidated?
How and when can the change be best made with the least negative impact?
Will the change also change the overall project?
After approved: What is the priority of the changes with respect to other approved changes?
If the change would change the overall project or change other phases in the project, then the overall
design will have to be re-visited to determine the changes effect on other phases of the project.
Maintenance of an Automated System: Once a function has been completed in an automated system,
changes must be introduced in a very disciplined fashion. Changes to existing functionality in an
automated system is called maintenance.

A change is proposed by the business group, management or users. A change document describing the
change is written. (A change could result from a change in a business policy.) The change is reviewed
and approved by the change control board or a user group for the automated system.
The change is discussed with the technical development group who will implement the change and the
quality assurance (QA) group who will test the change. The function or functions to be changed are
analyzed by the business group and the changes are incorporated into the function(s), updating the
functional specification(s) describing the functions from an external view.
The development group uses the functional specification to identify the internal changes to the system.
The development group makes changes to the internal design specifications and the interface plan, and
makes changes to a development version of the automated system or interfaces with other development
systems.
QA tests the development version of the automated system and compares the way it works as compared
to the functional specifications. If there are any discrepancies between the automated system and
functional specifications, it is determined whether there is an error in the changed system or in the
functional specifications. The errors are corrected. The automated system is then retested against the
functional specifications.
When no discrepancies are found, user manuals describing the function are updated and any changes to
business policies are recorded. Changes to automated systems are implemented in the healthcare
organization.
Technical documents (program code, data dictionaries, interface descriptions) are updated within release
control, with old versions kept to back out the changes if necessary.

PROJECT MANAGEMENT UNIT-V

management by walking around (MBWA): MBWA is one of the most important ways to build trust and
loyalty within a company. Genuine managers do it to better understand how the business actually
operates and to get to know employees in their natural setting. Genuine managers will pick up on
employee concerns and will be able to see first hand issues that they can deal with immediately. The
workforce is impressed by managers who take them seriously. On the other hand some managers walk
around for effect and simply to be seen. Their attitude is to keep employees on their toes, and to sniff out
deficiencies of any kind that can keep the employees on the defensive. This type of MBWA is
completely destructive to the original concept, yet perpetrators actually believe they are doing the right
thing.
Successful MBWA managers do it as a management style rather than as a program. They WTT (Walk
the Talk) as well as walk around, and after a while are intimately aware of their entire operation, from
drill press to file clerk. These are great people to work for because they really do care about each person,
and they go out of their way to recognize and reward every employee's contribution. They equally
understand the need to take remedial action, including firing people, before a situation festers through
the organization. In other words, staff trusts these managers to be responsive, even when the issue causes
pain. There are examples of large, unionized work places where even the CEO practice WMS (Walk a
Mile in my Shoes) that takes MBWA to a whole new level. These people intentionally set time aside to
actually work on the front line. In one company the CEO schedules one day a month to be part of a work
crew for an entire shift. In another national corporation the VP Operations schedules work time at
different locations. In a three year period he has been hands on at every location in the system. This type
of executive is rare, but their sincerity and determination to understand what life is like for their
employees is strong enough that the unions allow them to perform contract protected tasks.
Genuine MBWA managers take risks, but these are mitigated by their strength of discernment. They
know local employees can take the opportunity to dump on their managers, and local managers can very
easily believe this will happen. Certain situations may need the executive to intervene, but the real
purpose is to experience a day in the life of a warehouse person or a customer service representative.
The genuine MBWA manager is respected and welcomed in the work place. He or she is received as a
colleague rather than as a boss, and productivity in the companies they manage dramatically shows the
benefits of their endeavor.

Project managers: A project manager is a professional in the field of project management. Project
managers can have the responsibility of the planning, execution, and closing of any project, typically
relating to construction industry, engineering, architecture, computing, or telecommunications. Many
other fields in the production engineering and design engineering and heavy industrial also have project
managers. A project manager is the person accountable for accomplishing the stated project objectives.
Key project management responsibilities include creating clear and attainable project objectives,
building the project requirements, and managing the triple constraint for projects, which is cost, time,
and scope. A project manager is often a client representative and has to determine and implement the
exact needs of the client, based on knowledge of the firm they are representing. The ability to adapt to
the various internal procedures of the contracting party, and to form close links with the nominated
representatives, is essential in ensuring that the key issues of cost, time, quality and above all, client
satisfaction, can be realized.

MANAGING VERSUS LEADING

In a perfect world, the project manager would simply implement the project plan and the project would
be completed. The project manager would work with others to formulate a schedule, organise a project
team, keep track of progress and announce what needs to be done next week and then everyone would
charge along. Of course no one lives in a perfect world and really does everything that go according to
the plan. Project participants get testy, they fail to complement each other, other departments are unable

to fulfil their commitments, technical glitches arise and works take longer than expected. The project
managers job is to get the project back on track. A manager expedites certain activities, figures out ways
to solve technical problems, serves as peacemaker when tension arise and makes appropriate trade-offs
among time cost and scope of the project.
However, project managers do more than put out fires and keep the project on track. They also innovate
and adapt to ever changing circumstances. They often have to deviate from what was planned and
introduced significant changes in the project scope and scheduled to respond to unforeseen threats of
opportunities. For example, customers needs may change, requiring significant design changes midway through the project. Competitors may release new products that dictate switching the time, cost, and
scope priorities of the project. Working relationships among project participants may break down,
requiring rejuvenating the project tem. Ultimately, what was planned are expected in the beginning may
be very different from what was accomplished by the end of the project.
Project managers are responsible for integrating assigned resources to complete the project according to
the plan. At the same time they need to initiate changes in plans and schedules as persistent internal
problems make plans un-workable or as unexpected external events require accommodation. In other
words, managers want to keep the project going while making necessary adjustments along the way.
According to Kotter, these two different activities represent the distinction between management and
leadership. Management is about coping with complexity, while leadership is about coping with change.
Good management brings about order and stability by formulating plans and objectives, designing
structures and procedures, monitoring result against plans and taking corrective attention when
necessary. Leadership involves recognising and articulating the need to significantly alter the directions
and operations of the project, aligning the people to new directions and motivating them to work
together to overcome hurdles produced by the change and realise new objectives.
Strong leadership, while usually desirable is not always necessary to success fully complete a project.
Well-defined projects that encounter no significant surprises require little leadership, as might be the
case in constructing a conventional apartments building in which the project manager simply
administrates the project plan. Conversely, the higher the degree of uncertainty encountered on projects,
whether in terms of changes in project scope, technological stalemates, breakdowns in coordination
between people and so forth, the more leadership is required. For example, strong leadership would be
needed for a software development project where the parameters are always changing to meet the
developments in the industry.
It takes a special person to perform both roles well. Some individuals are great visionaries who are good
at exciting people about change too often though these same people lack the discipline or patience to
deal with the day to day drudgeries of managing. Likewise, there are other individuals who are very well
organised and methodical but lack the ability to inspire others. Strong leaders can compensate for their
managerial weakness by having trusted assistants who oversee and manage the details of the project. A
weak leader can likewise, complement his or her strengths by having assistant who are good at sensing
the need to change and rallying project participants. Still, one of the things that make good project
managers so valuable to an organisation is that they have the ability to both manage and lead a project.
In doing-so they recognise the need to manage project interfaces and building a social network that
allows them to find out what needs to be done and obtain the cooperation necessary to achieve it.
GETTING TO LEADERSHIP VERSUS MANAGEMENT
Leaders have a knack for getting others to do what needs done and rallying them around a vision. Good
leaders have committed team members who believe in the vision of the leader. Leaders set direction and
time frames, and have the ability to attract good talent to work for them. Leaders inspire a vision and get
things done through others by garnering loyalty, respect, and cooperation from team members. They set
the course and lead the way. Leaders are usually concerned about the big picture, so to speak. Good
leaders are directive in their approach, but allow for plenty of feedback and input. Good leaders
commonly have strong interpersonal skills and are well respected.
Managers are generally task-oriented, concerned with things like plans, controls, budgets, policies, and
procedures. Theyre generalists with a broad base of planning and organizational skills, and their
primary goal is satisfying stakeholder needs. They also posses motivational skills and the ability to
recognize and reward behaviour

Project managers need to use the traits of both leaders and managers at different times during the
project. On very large projects, a project manager will act more like a leader inspiring the subproject
managers to get on board with the objectives. On small projects, project managers will act more like
managers as theyre responsible for all the planning and coordinating functions.

MANAGING PROJECT STAKEHOLDERS

First time, project managers are eager to implement their own ideas and manage their people
successfully to complete their project. What they soon find out is that project success depends on
cooperation of a wide range of individuals, many whom do not report to them. For example, during the
course of a system integration project, a project manager was surprised by how much time she was
spending negotiating and working with vendors, consultants, technical specialists and other functional
managers.
Too often when new project managers do find time to work directly on the project, they adopt a handson approach to managing the project. They choose this style not because they are power hungry
egomaniacs but because eager to achieve the results. They quickly become frustrated by, how slowly
things operate, the number of people that have to be brought on board and the difficulty of gaining
cooperation. Unfortunately, as this frustration builds, the natural temptation is to exert more pressure and
get more heavily involved in the project. These project managers quickly earn the reputation of micro
managing and begin to lose sight of the real goal they play in guiding a project. Some new managers
never break out of this vicious cycle. Others soon realise that authority does not equal influence and that
being an effective project manager involves managing a much more complex and expensive set of
interfaces than they had previously anticipated. They encounter a web of relationship that requires a
much broader spectrum of influence than they felt was necessary or even possible.
For example, a significant project, whether it involves renovating a bridge, creating a new product or
installing a new information system, will likely involve in one way or another working with a number of
different groups of stakeholders. First, there is a core group of specialties assign to complete the project.
This group is likely to be supplemented at different times by professionals who work on specific
segments of the project. Second, there are the groups of the people within the performing organisations
who are either directly or indirectly involved with the project. The most notable is top management, to
whom the project manager is accountable. There are also other project managers, functional managers
who provide resource and or may be responsible for specific segments of the project and administrative
support service success human resources, finance etc. Depending on the nature of the project there are a
number of different groups outside the organisation that influence the success of the project. The most
important is the customer for which the project is designed.
The project management structure being used will influence the number and degree of external
dependencies that will need to be managed. One advantage of creating a dedicated project tem is that it
reduces dependencies especially within the organisation, because most of the resources are assigned to
the project. Conversely, a functional matrix structure increases dependencies with the result that the
project manger is much more reliant upon functional qualities for work and staff.
The old fashioned view of managing projects emphasised directing and controlling subordinates, the
new perspective emphasises two areas as the most important aspects of the job
Managing project stakeholders
Anticipating change
Project managers need to be able to assuage consensus of customers, sustain support for the project for
higher levels of the organisation, and quickly identify the problems that threaten project work, while at
the same time defend the integrity of the project and the interest of the project participants. Within this
web of relationships, the project manager must find out what needs to be done to achieve the goal for the
project and build a cooperative network to accomplish it. Project managers must do so without the
requisite authority to expect or demand cooperation. This requires sound communication skills, political
savvy and a broad influence base.

SOCIAL NETWORK BUILDING

MAPPING DEPENDENCIES
First step to building a social network is to identify those on whom the project depends on success. The
project manager and his or her key assistants need to ask the following questions,
Whose cooperation will we need?
Whose agreement or approval will we need?
Whose opposition would keep us from accomplishing the project?
It is always better to overestimate rather than under estimate dependencies on too often, otherwise
talented and successful project managers have been de-railed because they were blindsided by some
whos position or power that they had not anticipated. After identifying who you are dependent on, you
are ready to step into their shoes, and see their project from their perspectives. To help you do that
asks yourself the following questions
What differences exist between me and the people on whom I depend? (Goals, Values, Pressures,
Risks)
How these different people do knew the project? (supporters in different antagonists)
What is the current status of the people I depend on?
What sources of influence do I have relative to whose on whom I depend?
Once, you begin this analysis, you can begin to appreciate what others value and what currencies you
are able to offer on the basis on which to build a mutually satisfying relationship. Likewise, you begin to
realise where potential problems lie, relationships in which you have a current debit or n o convertible
currency, furthermore, diagnosing others point of view as well as the basis for their positions will help
you anticipate the reactions and feelings about your decisions and actions. This information is vital for
selecting the appropriate influence strategy and tactics and conducting win-win negotiations.

MANAGEMENT BY WANDERING AROUND

Once you have established who the keep players are that will determine success then you initiate contact
and begin to build a relationship with those players. Building this relationship requires a management
style referred as Management by wandering around to reflect that managers spend the majority of the
time outside their offices. MBWA is somewhat of a misnomer in that there is a purpose or pattern behind
the wandering. Through face to face interactions project managers are able to stay in touch with what is
really going on in the project and build cooperative relationship essential to project success.
Effective project managers initiate contact with key payers to keep abreast of developments, anticipate
potential problems, provide encouragement and re-enforce the objectives and vision of the project. They
are able to intervene to resolve conflicts and prevent stalemates from occurring. In essence, they
manage the project. By staying in touch with the various aspects of the project, they become the focal
point for information on the project. Participant turn to them, to obtain the most current and
comprehensive information about the project, which re-enforces as central role as, project manager.
While a significant amount of their time is devoted to the project team, effective project managers find
the time to regularly interact with more distal stake holders. They keep in touch with suppliers, vendors,
top management and other functional managers. In doing so, they maintain familiarity with different
parties, sustain friendship, discover opportunities to do favours and understand the motives and needs of
others. They remind people of commitment and champion the cause of their project. They also shape
people expectations. Through frequent communication, they alleviate peoples concern about project
dispel rumours, warn people of potential problems and lay the ground work for dealing with setbacks in
more effective manner.
Experienced project managers build relationships before they need them. They initiate contact with the
key stack holders at times when there are no outstanding issues or problems and therefore no anxieties
and suspicions. On the social occasions they engage in small talk and responsive banter. Astute project
managers also seek to make deposit in their relationships with potentially important stake holders. They
are responsive to others request for aid provide supportive counsel and exchange information. In doing
so they are establishing credit in those relationships which will allow them to deal with more serious
problems down the road. When one person views another as pleasant, credible and helpful based on past

contact, he or she is more likely to be responsive to request for help and less confrontational when
problem arise.

MANAGING UPWARD RELATIONS

Research consistently points out that project success is strongly affected by the degree to which the
project has the support of top management. Such support is reflected in appropriate budget,
responsiveness to unexpected needs and clearly signally to others in the organisation, the importance of
cooperation. In most organisations priorities are communicated through normal channels, however,
companies have found it necessary to take less orthodox approaches to signalling priorities. Visible top
management support is not only critical for securing the support of other managers, within an
organisation, but it also a key factor in the projects managers ability to motivate the project team.
Nothing establishes a managers right to lead more than his or her ability to defend. Top win the loyalty
of team members, project managers have to be effective advocates. They have to be able to get top
management to rescind and reasonable demands, provide additional resources and recognise the
accomplishment of team members.
Many of the tensions that arise between upper management and project managers are a result of
differences in perspective. Project managers naturally become absorbed with what is best for their
project. To them, the most important thing in the world is their project. Upper management has a
different set of priorities. They are concerned with what is best for the entire organisation. It is only
natural for this to interest to conflict. Project managers have to cultivate strong ties with upper managers
that are sponsoring the project. As noted earlier these are high ranking officials who championed
approval and funding of the project, as such as the reputations are aligned with the project. Sponsors
also are the ones who defend the project when it is under attack in the upper circles of management.
Project managers should always keep the top management informed of any problems that may cause
embarrassment or disappointment. Project sponsors should be the first to know if costs are beginning to
overrun the budget or a technical glitch is threatening to delay the completion of the project. When
negotiating from a subordinate position for additional funds, resources or extensions project managers
recognise that the timing of the request is critical. Asking for additional budget the day after
disappointing third quarter earnings or reported is going to be much more difficult than making a similar
request four weeks later. Good project managers pick the optimum time to appeal to top management.
Finally, a few project managers admit ignoring chains of command, if they are confident the top
management will reject an important request and that what they want to do will benefit the project, they
do it without asking permission while acknowledging that this is very risky, they claim that bosses
typically wont argue with success.

QUALITIES OF AN EFFECTIVE PROJECT MANAGER

Project management is, at first glance, a misleading discipline in that there is an inherent logic in the
progression from formulating a project scope statement, creating a WBS, developing a network, adding
resources, finalising a plan and managing milestones. However, when it actually comes to implementing
and completing projects, this logic quickly disappears and project managers encounter a much messier
world, filled with inconsistencies and paradoxes. Effective project managers have to be able to deal with
the contradictory nature of the work.
Vision: An effective leader is often described as having a vision of where to go and the ability to
articulate it. Visionaries thrive on change and being able to draw new boundaries. It was once said that a
leader is someone who "lifts us up, gives us a reason for being and gives the vision and spirit to change."
Visionary leaders enable people to feel they have a real stake in the project. They empower people to
experience the vision on their own. According to Bennis "They offer people opportunities to create their
own vision, to explore what the vision will mean to their jobs and lives, and to envision their future as
part of the vision for the organisation." (Bennis, 1997). every project manager should have a vision, a
vision of what he wants the project to be like, a vision of how to get things done and a vision of the near
future of the project. And he needs to be able to convey this vision to his team members. Only when
there is vision is there going to be real involvement on the part of the project manager and thus

involvement on part of the team members. This is when the team members and project manager start
feeling like a part of the organization and not just the project.
Communication skill: The ability to communicate with people at all levels is almost always named as
the second most important leadership skill. Project leadership calls for clear communication about goals,
responsibility, performance, expectations and feedback. There is a great deal of value placed on
openness and directness. The project leader is also the team's link to the larger organisation. The leader
must have the ability to effectively negotiate and use persuasion when necessary to ensure the success of
the team and project. Through effective communication, project leaders support individual and team
achievements by creating explicit guidelines for accomplishing results and for the career advancement
of team members. Without communication the project manager cannot lead. Communication not only
allows for great leadership but also for openness and relativity. Persuasion and negotiation are all a part
of communication and the project managers qualities.
Honesty: call it honesty, integrity or loyalty, the project manager needs to have it all. The project
manager must remember is that his or her actions, and not words, set the modus operandi for the team.
Good leadership demands commitment to, and demonstration of, ethical practices. Creating standards
for ethical behaviour for oneself and living by these standards, as well as rewarding those who
exemplify these practices, are responsibilities of project leaders. Leadership motivated by self-interest
does not serve the well being of the team. Leadership based on integrity represents nothing less than a
set of values others share, behaviour consistent with values and dedication to honesty with self and team
members. In other words the leader "walks the talk" and in the process earns trust.
The actions of the project manager set an example for the rest of the team members. The project
manager is ultimately responsible for setting standards, ethically and otherwise for the rest of the team.
The project manager needs to practice before preaching and to lead by example.
Enthusiasm: Plain and simple, we don't like leaders who are negative - they bring us down. We want
leaders with enthusiasm, with a bounce in their step, with a can-do attitude. We want to believe that we
are part of an invigorating journey - we want to feel alive. We tend to follow people with a can-do
attitude, not those who give us 200 reasons why something can't be done. Enthusiastic leaders are
committed to their goals and express this commitment through optimism. Leadership emerges as
someone expresses such confident commitment to a project that others want to share his or her
optimistic expectations. Enthusiasm is contagious and effective leaders know it.
Passion: a project manager without passion is one that is simple put, lacking dedication. The project
manager has to be passionate about the project; he should have enthusiasm and the right attitude. Only
then will people follow him and respect his decisions, because they need to feel he is doing it for the
project. There needs to be commitment and optimism involved.
Empathy: The words empathy and sympathy are similar, they are, in fact, mutually exclusive. According
to Norman Paul, in sympathy the subject is principally absorbed in his or her own feelings as they are
projected into the object and has little concern for the reality and validity of the object's special
experience. Empathy, on the other hand, presupposes the existence of the object as a separate individual,
entitled to his or her own feelings, ideas and emotional history (Paul, 1970). As one student so
eloquently put it, "It's nice when a project leader acknowledges that we all have a life outside of work."
Compassion: do not mistake empathy or compassion for sympathy. These two words are independent of
each other. Empathy means to understand. A good project manager needs to understand or empathize
with the fact that there is a life outside the work place and that people are not machines without
emotions.
Skill and knowledge: there needs to be some skill and knowledge that the project manager needs to
have. To put it simply, the project manager should know what he is doing and should be able to guide
the rest of the team.
Delegation: the project manager should be able to handle delegation with ease. He should be able to
recognize skills and expertise of his team members and assign or delegate tasks according to those. Also
this shows that the project manager trusts the team in doing tasks. Trust inspires confidence.

Composed: we do not live in a perfect world. There are times when things do not go as expected in such
a case the project needs to maintain his cool and be composed irrespective of the amount pressure he is
under. This shows good leadership and strength in character.
Competence: Simply put, to enlist in another's cause, we must believe that that person knows what he or
she is doing. Leadership competence does not however necessarily refer to the project leader's technical
abilities in the core technology of the business. As project management continues to be recognised as a
field in and of itself, project leaders will be chosen based on their ability to successfully lead others
rather than on technical expertise, as in the past. Having a winning track record is the surest way to be
considered competent. Expertise in leadership skills is another dimension in competence. The ability to
challenge, inspire, enable, model and encourage must be demonstrated if leaders are to be seen as
capable and competent.
Team building: A team builder can best be defined as a strong person who provides the substance that
holds the team together in common purpose toward the right objective. In order for a team to progress
from a group of strangers to a single cohesive unit, the leader must understand the process and dynamics
required for this transformation. He or she must also know the appropriate leadership style to use during
each stage of team development. The leader must also have an understanding of the different team
players styles and how to capitalise on each at the proper time, for the problem at hand.
the project manager should be a team builder. He should be able to hold and pull the team together to
work under different conditions. The team starts as a group of strangers and needs to be made into a core
group of people.
Cool Under Pressure: In a perfect world, projects would be delivered on time, under budget and with no
major problems or obstacles to overcome. But we don't live in a perfect world - projects have problems.
A leader with a hardy attitude will take these problems in stride. When leaders encounter a stressful
event, they consider it interesting, they feel they can influence the outcome and they see it as an
opportunity. "Out of the uncertainty and chaos of change, leaders rise up and articulate a new image of
the future that pulls the project together." (Bennis 1997) And remember - never let them see you sweat.
Problem solver: Although an effective leader is said to share problem-solving responsibilities with the
team, we expect our project leaders to have excellent problem-solving skills themselves. They have a
"fresh, creative response to here-and-now opportunities," and not much concern with how others have
performed them. (Kouzes 1987). an efficient project manager should be capable of solving any and all
problems, either with the team or the project itself.
Controlling Changes: In order to provide stability to the project, project agreements must be recorded,
and any changes to agreements must be evaluated for their effects upon other agreements. These
agreements should thus be recorded in controlled documentation, and when an agreement is changed,
then all other agreements that are based upon that agreement must be reevaluated. In order to control
controlled documents in the project, it is proposed that there be a *change control board* to review
changes. The change control board would include the overall project manager, phase project managers,
representatives of workers, users, the data processing group and business policy management, and
perhaps a change control administration manager to update schedules and provide unbiased advice on
business, technical and administrative decisions. Problems of interest to upper management, such as
budget issues, would be escalated up to them for resolution.
As the project progresses, the responsibilities of the phase managers might be consolidated and the
change control board might grow smaller, eventually just handling maintenance changes rather than
monitoring the project.
When a phase is completed, resulting automated systems should go into maintenance mode. Changes to
an automated system agreed upon by the change control board would be sent to a business group for
design and to a maintenance group for implementation in the automated system. The maintenance group
is often part or all of the group that did the development of the automated system. Once a phase is
implemented, a help desk should take telephone calls from users of an automated system. The help desk
would give advice on the use of the system and report on errors and suggested enhancements to the
maintenance group who would go through the change board for review.
As the automated system matures, a user group might take over the change control board in reviewing
changes.

INNOVATE BUT MAINTAIN STABILITY: Project managers have to put out fires, restore order and
get the project back on track, at the same time they need to be innovative and develop new, better ways
of doing things. Innovations unravel stable routines and spark new disturbances that have to be dealt
with.

SEE THE BIG PICTURE WHILE GETTING YOUR HANDS DIRTY: Project managers have to see the
big picture on how their project fits within their larger strategy of their firm. There are also times when
they must deeply involve in project work and technology. If they dont worry about the details, who
will?

ENCOURAGE INDIVIDUALS BUT EMPHASISE THE TEAM: Project managers have to motivate,
cajole and entice individual performers while at the same time maintain team work. They have to be
careful that they are considered fair and consistent in the treatment of team members while at the same
time treating each member as a special individual.

HANDS-OFF/HANDS-ON: Project managers have to intervene, resolve stalemates, solve technical

problems and insist on different approaches, at the same time they have to recognise when it is
appropriate to sit on the side lines and let other people figure out what to do?

FLEXIBLE BUT FIRM: Project managers have to be adaptable and responsive to events and outcomes
that occur on the project. At the same time to hold the line at times and tough it out when everyone else
want to give up.

TEAM VERSUS ORGANISATIONAL LOYALTIES: Project managers need to forge a unified project
team whose members stimulate one another to extra ordinary performance, but at the same time they
have to counter the excesses of cohesion and the team resistance to outside ideas they have to cultivate
loyalties to both the team and parent organisation.
There are some core traits and skills that can be developed to successfully perform the job, nine of these
traits are noted below,

SYSTEMS THINKER: Project managers must be able to take a holistic rather than a reductionist
approach to projects. Instead of breaking up a project into individual pieces (planning, budget) and
managing it by understanding each part, a systems perspective focuses on trying to understand how
relevant project factors collectively interact to produce project outcomes.

PERSONAL INTEGRITY: Before you can lead and manage others, you have to be able to lead and
manage yourself. Begin by establishing a firm sense of who you are, what you stand for and how you
should behave. This inner strength provides the buoyancy to endure the ups and downs of the project life
cycle and the credibility essential to sustaining the trust of others.

PROACTIVE: Good project managers take action before it is needed to prevent small problems from
escalating into major concerns. They spend their majority of their time working within their sphere of
influence to solve problems and not dwelling on things they have little control over. Project managers
cant be whiners.

HIGH TOLERANCE OF STRESS: Project management is not for the meek. Deadline pressures
technical uncertainties and dealing with variety of difficult, even stubborn professionals can generate a

great deal of stress. People vary in their tolerance of stress, physical exercise a healthy diet and a
supportive home front are necessary to endure rigors of project management.

GENERAL BUSINESS PERSPECTIVE: Because the primary role of the project manager is to integrate
the contributions of different business and technical disciplines, it is important that a manager have a
general grasp of business fundamentals and how the different functional disciplines interact to contribute
to a successful business.

GOOD COMMUNICATOR: This one appears on every list and with good reasoning project managers
have to be able to communicate with a wide variety of individuals. They are not only have to be able to
convey their ideas in an easily 8understandable manner but they must also be empathic listeners capable
of drawing out the true meaning in what others are trying to say to them.

EFFECTIVE TIME MANAGEMENT: Time is a managers scarcest resource, project managers have to
be able to budget the time wisely and quickly adjust the priorities, they need to balance their interaction
so no one feels ignored.

SKILLFUL POLITICIAN: Project managers have to be able to deal effectively with a wide range of
people and win their support and endorsement of their project. They need to be able to sell the virtues of
the project without compromising the truth.

OPTIMIST: Project managers have to display a can-do attitude they have to be able to find rays of
sunlight in a dismal day and keep peoples attention positive. A good sense of humour and a playful
attitude are often a project managers greatest strength.

MANAGING PROJECT TEAMS

The leadership development level of a project manager is important to a successful project. Effective
leadership skills must be used as needed over the project lifecycle. Project managers are responsible for
project delivery and consequently are uniquely placed to make a positive or negative impact. Whilst
understanding project management methodologies, tools and techniques is important, the critical test is
being able to apply them in practice. This is where leadership skills and behaviours become critical -- as
the project manager leads the project team to meet the objectives.

PROJECT MANAGER LEADERSHIP SKILLS

The project manager must continuously develop effective leadership skills and employ them as needed
during the project cycle. The visible expression of leadership skills for the project team and stakeholders
is via leadership behaviours. These leadership behaviours are used as needed when building the project
team as well as during the project lifecycle. The project manager must develop their leadership skills and
use leadership styles and behaviours as needed during the course of a project. Leadership is very much
about getting things done through others and leaders must use a wide array of tools and techniques to fit
the situation and the desired outcome. It is the same for project managers to deliver a successful project.

DEVELOP EFFECTIVE LEADERSHIP SKILLS

Managers must develop effective leadership skills to lead teams and achieve set objectives. Understand
basic leadership styles and action-centred leadership for results. Many business leaders, consultants,
practitioners and academics have written about leadership and being a good leader and that wealth of
material is both a boon and bane. On the one hand information is readily available. On the other hand

there are so many different definitions and interpretations that it can easily become confusing. Since
there is more than one way to be a good leader developing leadership skills is about selecting ideas that
are personally effective.
ACTION-CENTRED LEADERSHIP
John Adairs Action-Centred Leadership provides a simple and straightforward approach that focuses on
task, team and individual. These are usually represented as three overlapping circles of competence. The
leader uses each circle as needed according to circumstance:
1. Achieving the Task
2. Managing the Team
3. Managing Individuals

ACHIEVING THE TASK

Identify vision, purpose, direction and objectives
Develop the plan and individual tasks to achieve the objectives including deliverables, measures and
schedule
Establish roles, accountabilities and success criteria or measures
Identify and allocate resources, people, systems and tools to fulfil the plan
Set quality standards and reporting methods
Control and maintain activities, monitor and manage risks and issues
Review and reassess the plan as needed

MANAGING THE TEAM

Agree on standards of conduct, behaviour and methods of working
Set expectations and objectives for performance, delegation and team working
Understand and work through team development
Anticipate and resolve team issues and disagreements
Assess and change as necessary the skills, experience and personality blend of the team
Identify team development and training needs
Provide feedback on team performance, coordination and collaboration

 Ensure effective internal and external communication

MANAGING INDIVIDUALS

Understand individual strengths and weaknesses, hopes and fears

Assess, assist and support individuals, coach and develop them
Agree, set and track individual performance and development objectives
Give recognition and/or reward when appropriate

COMPLEMENT ACTION-CENTRED LEADERSHIP BY USING LEADERSHIP STYLES

Leadership styles are effectively different ways to interact with individuals and teams to get the job
done. A good leader will use these like a toolkit, using the right tool at the right time:
Autocratic -- tell people what to do, needs to be used sparingly and in the right circumstances
Bureaucratic -- follow rules, using established procedures and processes
Charismatic -- persuade and charm people, lead by motivating people's enthusiasm and drive
Democratic -- invite contributions to decision making and then make final decision
Laissez-Faire -- leave people to get on with it using a very light touch to monitor progress
People-Oriented -- focused on organising, supporting and developing people and managing
relationships
Servant -- meeting the needs of the team, solving their problems or removing barriers
Task-Oriented -- focus on plan, tasks, roles and getting the job done
Transactional -- people are paid to do the work to a set standard
Transformational -- inspire people with shared vision

DEVELOP EFFECTIVE LEADERSHIP SKILLS

Start with something simple - like action-centred leadership and employing various leadership styles
according to situation. Over time a good leader will integrate many different leadership skills, styles and
behaviours into their own leadership qualities and consequently develop effective leadership. Leadership
skills must be complemented by positive leadership behaviours. Anyone can show effective leadership
behaviours but they are essential skills for good leaders.

EFFECTIVE LEADERSHIP BEHAVIOURS

Different leadership studies highlight the importance of effective leadership behaviours for managers at
every level in an organisation. In short, there are commonalities that emerge from this research time and
again, which characterise positive behaviours and negative behaviours. Whilst there may be significant
differences at the detailed level there seems to be a broad consensus of positive leadership behaviours:
Conducts regular, effective meetings to set objectives, allocate tasks and review performance
Effective project planning and management
Identifying the right person for the right role

 Appropriate delegation of responsibility whilst retaining accountability

Consults and includes others in decision-making
Shows an interest in others and responding to their needs whether that is for more information,
guidance, support, personal development, positive feedback or reward and recognition
Takes ownership and shows commitment for solving problems or difficult/sensitive issues
Leads by example, showing a contagious passion and enthusiasm, engaging and motivating others
Direct, clear, open style of communication
Considers impact before action

INEFFECTIVE OR NEGATIVE BEHAVIOURS

Similarly, there is a broad consensus on ineffective or negative leadership behaviours:
Does not demonstrate accountability, commitment or ownership to objectives, tasks or problems
Does not communicate clearly or well
Does not manage, support or develop others very well
Does not provide timely positive feedback as appropriate
Does not recognise or reward contribution
Avoids conflict or difficult problems
Acts before considering impact
Allows poor performance to continue or low quality deliverables to be produced
Becomes emotional, irrational or temperamental
Fails to agree objectives and clarify expectations
Inadequate preparation or planning
Willingness to not mention or conceal important facts about a situation
Focuses on negatives and tends to reduce morale and motivation of others
Is not open to new or alternative ideas

LEADERSHIP SKILLS AND LEADERSHIP BEHAVIOURS

A good leader will develop their leadership skills and work to demonstrate many positive leadership
behaviours and to eliminate all of the negative leadership behaviours. These positive behaviours must be
demonstrated at all times in all situations so that it is simply how the good leader operates. Leadership
development is a continuous process of personal development.
The following project phases are indicated with leadership styles and behaviours as a starting point for
the project manager to consider for their approach with the stakeholders.
PROJECT INITIATION AND SCOPE

Whilst the business case is being developed the project manager is often asked to explore what is
possible and to define a high level plan with an indication of project costs. This is very much about
making a contribution by meeting others' needs and removing their barriers -- servant leadership.
PROJECT PLANNING
Take ownership and a task orientation towards project planning. Engage key stakeholders in a
democratic, participative style to develop effective plans with accurate estimates. Identify the right
people for the right role. Bureaucratically establish the project control mechanisms and the standards for
the project team. Delegate as needed key components of the project such as:
Business change management
Test cycle
Training
Infrastructure deployment

REQUIREMENTS AND ANALYSIS

Manage effective meetings and focus on people-orientation to ensure that awareness, engagement and
positive support is built with a wider set of stakeholders. Consult with others as needed for decisionmaking using autocratic or democratic approaches as needed. Understand the impact of changes and
lead by example with a clear view of the transformation required and engage people with that vision.

BUILD, TEST, DELIVERY AND CLOSURE

Focus on task-orientation and leaving the project team to get things done. Use a laissez-faire approach
but stay in touch and support people as needed. Ensure that multiple tasks, priorities and risks are
effectively managed and clearly communicated. Take a bureaucratic approach to preparation for testing,
deployment and closure, doing each stage properly -- producing the appropriate deliverables at the
desired level of quality.

Team-Building Strategies : A team-building focus can pay off in several ways. As individuals become
more effective in working with other team members, the team becomes more effective. The team can
learn how to examine its own work and progress and identify areas for improvement. Connie Jastremski
recommends that organizations recognize the following trigger points that indicate a need for team
building:
Increased productivity or effectiveness
decreased number of complaints about staff or quality of care
Minimisation of Conflicts among staff members
Clarity about assignments or unclear roles
Properly understood and implemented Decisions
Apathy or interest and involvement among staff members
Effective staff meetings; Good participation in group decisions

Start-up of a new group that needs to develop quickly into a team

High dependency on or negative reactions to the manager
If a team decides to engage in a team-building process, it should be sure to establish objectives for it,
such as:
Write a mission and purpose statement for the team.
Establish roles and responsibilities for team members.
Develop a conflict-management procedure.
Examine and improve the team's problem-solving strategies.
Improve the group's communication skills.
Develop respect, if not actual friendship, among team members.
Managing Team Issues: Without a doubt, people will fight. Fortunately, in most offices,
people
are mature enough to bite their tongues, try to work peacefully, and, as a whole, strive to finish the
project happily and effectively together. Most disagreements in IT project management happen when
two or more people feel very passionate about a particular IT topic. For example, one person believes a
network should be built in a particular order, while another feels it should be constructed from a
different approach. Or two developers on a project get upset with each other about the way an
application is created. Generally, both parties in the argument are good people who just feel strongly
about a certain methodology of their work. Figure 6-5 demonstrates how arguments over technical
implementations take a project off. Arguments take a project off schedule and increase costs.
There are, of course, a fair percentage of contrary and pessimistic people in the world. These people
dont play well with others, and are obnoxious at times. They dont care about other peoples feelings,
and much of the time they dont care about the success of your project.
Unfortunately, you will have to deal with disagreements, troublemakers, and obnoxious people to find a
way to resolve differences and keep the projects momentum. Dealing with Team DisagreementsIn most
projects there will be instances when the project team, management, and other stakeholders disagree on
the progress, decisions, and proposed solutions within the project. Its essential for the project manager
to keep calm, to lead, and to direct the parties to a sensible solution thats best for the project. Seven
reasons for conflict are Schedules, Priorities, Resources, Technical beliefs, Administrative policies and
procedures, Project costs, and Personalities. There are five different approaches to conflict resolution:
Problem solving: This approach confronts the problem head-on and is the preferred method of conflict
resolution. You may consider this approach as confronting. It calls for additional research to find the
best solution for the problem, and is a win-win solution. Problem solving can be used if there is time to
work through and resolve the issue, and it works to build relationships and trust.
Forcing: With this approach, the person with the power makes the decision. The decision made may not
be best for the project, but its fast. As expected, this autocratic approach does little for
team development and is a win-lose solution. Forcing is used when the stakes are high and time is of the
essence, or if relationships are not important.
Compromising: This approach requires both parties to give up something. The decision is a blend of
both sides of the argument. Because neither party really wins, it is considered a lose-lose solution. The
project manager can use this approach when the relationships are equal and its impossible for one party
to win. This approach can also be used to avoid a fight.
Smoothing: This approach smoothes out the conflict by minimizing the perceived size of the problem.
It is a temporary solution but can calm team relations and boisterous discussions. Smoothing may be
acceptable when time is of the essence or any of the proposed solutions will work. This can be
considered a lose-lose situation as no one really wins long-term. The project manager can use smoothing
to emphasize areas of agreement between the stakeholders within a disagreement, minimizing the areas
of conflict. Smoothing is used to maintain relationships and when the issue is not critical.

Withdrawal: This approach is the worst conflict resolution tactic because one side of the argument walks
away from the problemusually in disgust. The conflict is not resolved and it is considered a yield-lose
solution. The approach can be used, however, as a cooling off period, or when the issue is not critical.
Conflict resolution in teams
Team Management Is Not a Democracy: Despite what some feel-good books and inspiring stories would
like to have you believe, project management is not a democracy. Someone has to be in charge, and that
someone is you, the project manager. The success of the project rests on your shoulders, and it is your
job to work with your team members to motivate them to finish the project on schedule. This does not
mean that you have permission to grump around and boss any member of your team. It also does not
mean that you should step in and break up any disagreement between team members. Among the team,
you should allow some discussion and some disagreement.
This is what teams have to do: they have to work things out on their own. Team members have to learn
to work together, to give and take, to compromise. Step back and let the team first work through
disagreements before you step in and settle issues. If you step into the mix too early, then your team
members will run to you at every problem. Teams can make decisions on their own. Ultimately, you are
in charge. If your team members cannot, or will not, work out a solution among themselves, youll be
forced to make a decision. When you find yourself in this situation, there is an approach to working
through the problem.
Here are recommended steps to conflict resolution:
Attention Meet with both parties and explain the purpose of the meeting: to find a solution to the
problem. If the two parties are amicable to each other, this meeting can happen with both parties present.
If the team members detest each other, or the disagreement is a complaint against another team member,
meet with each member in confidence to hear that persons side of the story.
Listen: Ask the team members what the problem is, allow each to speak their case fully without
interrupting, and then ask questions to clarify any of the facts.
Resolve: Often if the meeting takes place with both team members, a resolution will quickly boil to the
surface. Chances are that you wont even have to make a decision. People have a way of suddenly
wanting to work together when a third party listens to their complaints. They both realize how foolish
their actions have been and one, or both, of the team members will cheer up and decide to work together.
Wait: If this is not the case in your meeting, dont make an immediate decision. Tell the team members
how important it is to you, and to the project, that they find a way to work together. Sometimes even this
touch of direction will be enough for the team members to begin compromising. If they still wont
budge, tell them youll think it over and then you will make a decision within a day or twoif the
decision can wait that long. By delaying an immediate decision, you allow the team members to think
about what has happened and you give them another opportunity to resolve the problem.
Act: If the team members will not budge on their positions, then you will have to make a decision. And
then stick to it. If necessary, gather any additional facts, research, and investigations. Based on your
evidence, call the team members into a meeting again and acknowledge both of their positions on the
problem. Then share with them, based on your findings, why youve
made the decision that you
have made. In your announcement dont embarrass the team member who has been put out by your
decision.
If the losing team member wants to argue his point again, stop him. Dont be rude, but stop him. The
team members have both been given the opportunity to plead their case, and once your decision has been
made, your decision should be final.
Dealing with Personalities: In any organization, youll find many different personality types, so its
likely that there are some people in your organization who just grate on your nerves like fingernails on a
chalkboard. These individuals are always happy to share their discontent, their opinion, or their unique
point of view. Unfortunately, you will have to find a way to work with, or around, these people.
Here are some personality types you may encounter and how you can deal with them:

PersonalityAttributesResolution: The Imaginary LeaderThese individuals think they are managing the
project this week and will be running the company next week. You know the type, always first to raise
their hands in school and remind the teacher if she forgot to assign homework. These people really do
want to lead they just dont know how! Give them an opportunity by allowing them to conduct an
occasional team meeting or organize upcoming activities. If you can, try to show them how to lead with
tact instead of their rudeness. The MouseThese individuals are afraid of doing any activity on the project
without explicit directions from you. Theyre so afraid theyll make a disastrous mistake, they require
your guidance on each part of their work.Encourage these types to take charge of their duties. Tell them
that you have confidence in them to do the tasks that youve assigned to them. If they do make a
mistake, work through it with them to build their confidence. Your Favorite Uncle (or Aunt)This persona
is the office clown. Always playing gags, streaming toilet paper around someones cubicle, telling jokes,
and sharing stories around the office. Not only are these types of people great fun, but also theyre great
time wasters.Often these folks dont have enough to do, and so they assume everyone else is under the
same workload that they are. Give these people more assignments, and theyll have less time to kill. If
that doesnt work, politely share with them that their jovial activities are appreciated, but not always
necessary. The CowboyThese people love excitement. They are happy to try anything out (like rebooting
a server mid-morning) just to see what happens. Their experience may be great, but their swagger, tengallon hat, and stunts arent always well thought out. To deal with the Cowboy types, encourage their
enthusiasm but discourage their ability to make on-the-spot decisions without thinking about the results
of their actions. These individuals are generally smart and eager to help, but need a touch more guidance
from you. The PruneThese sourpusses are as much fun as pocket full of thumbtacks. They dont care
about your project, think the technology sucks, and take their hourly breaks every twenty minutes.
Granted, these folks are hard to work with. Theyve got more problems personally than the project you
are managing. You can start by befriending them and then sharing the value of their work on the project
with their superiors. This transfers some responsibility of the work onto those Prunes. And tell them to
smile a little.
Use Experience: The final method for resolving disputes among team members may be the most
effective: experience. When team members approach you with a problem that they just cant seem to
work out between themselves, you have to listen to both sides of the situation. If you have experience
with the problem, then you can make a quick and accurate decision for the team members. But what if
you dont have experience with the technology, and your team members have limited exposure to this
portion of the work? How can you make a wise decision based on the information in front of you? You
cant! You will need to invent some experience. As with any project, you should have a testing lab to test
and retest your design and implementation. Encourage your team members to use the testing lab to try
both sides of the equation to see which solution will be the best. If a testing lab is not available, or the
problem wont fit into the scope of the testing lab, rely on someone elses experience. Assign the team
members the duty of researching the problem and preparing a solution. They can use books, the Internet,
or other professionals who may have encountered a similar problem. Experience is the best teacher.
A method for resolving issues by testing should be implemented.
Disciplining Team Members: No project manager likes the process of disciplining a team memberat
least they shouldnt. Unfortunately, despite your attempts at befriending, explaining the importance of
the project, or keeping team members on track, some people just dont, or wont, care. In these
instances, youll have little choice other than to resort to a method of discipline. Within your
organization, you should already have a process for recording and dealing with disciplinary matters. The
organizational procedures set by human resources or management should be followed before interjecting
your own project team discipline approach. If there is no clear policy on team discipline, you need to
discuss the matter with your project sponsor before the project begins. In the matter of disciplinary
actions, take great cautionyou are dealing with someones career. At the same time, discipline is
required or your own career may be in jeopardy.
As you begin to nudge team members onto the project track, document it. Keep records of instances
where they have fallen off schedule, failed to complete tasks, or have done tasks halfheartedly. This
document of activity should have dates and details on each of the incidents, and it doesnt have to be
known to anyone but you. Hopefully, your problematic team members will turn from their wicked ways
and take your motivation to do their jobs properly. If not, when a threshold is finally crossed, then you
must take action.

Following an Internal Process: Within your organization there should be a set process for how an unruly
employee is dealt with. For some organizations, theres an evolution of a write-up, a second write-up, a
suspension of work, then ultimately a firing. In other organizations, the disciplinary process is less
formal. Whatever the method, you should talk with your project sponsor about the process and involve
her in any disciplinary action. In all instances of disciplinary action, it would be best for you and the
employee to have the project sponsor or the employees immediate manager in the meeting to verify
what has occurred. This not only protects you from any accusations from the disgruntled team member,
but it also protects the team member from your disappointment by having a member of management
present.
Removal from a Project: Depending on each situation, you may discover that the team member cannot
complete the tasks required of him on the project, and removal from the project may be the best solution.
In other instances it could be that the team member refuses to complete the work assigned to him for his
own reasons and is a detriment to the success of the project. Again, removal from the team may be the
most appropriate action. Removing someone from the project requires tact, care, and planning. A
decision should be made between you and the project sponsor. If you feel strongly that this person is not
able to complete the tasks assigned to him, rely on your documentation as your guide. Removal of a
team member from a project may be harsh, but its often required if the project is to succeed.
Of course, when you remove someone from the project, you need to address the matter with the team.
Again, use tact. A disruption in the team can cause internal rumblings that you may never hear about
especially if the project team member that was removed was everyones best friend. You will have
created an instant us- against-them mentality. In other instances, the removal of a troublemaker may
bring cheers and applause. Whatever the reaction, use tact and explain your reasons without
embarrassing or slandering the team member who was removed.
Factors in Teamwork Success: To improve a team's effectiveness, it is first necessary to understand the
factors that impact its performance. Once you understand these factors you can determine when and
what team development is needed.
In order for teams to function effectively they must manage how they work together and how they
interact with the rest of the organization. As a result of his studies, Richard Beckhard ("Optimising Team
Building Efforts", Journal of Contemporary Business, Summer 1972) states that for teams to be effective
they must manage four areas internal to the team: goals, roles, processes and relationships. Further
research has identified a fifth factor of how the team manages its interaction with the organisational
environment. Within these factors is a hierarchy with some factors affecting all of the others. These five
factors become the focus of attention for the manager who wants to raise team performance, because
teams that effectively manage these areas function more effectively than teams that do not.
Environmental Influences - the impact of the organisation and the outside world on team performance.
The organisation creates the context within which the team functions. The policies, procedures and
systems within an organisation can either support or hinder a team's effectiveness. An excellent example
is the impact an organisation's reward system has on teamwork. Organisations typically reward only
individual contribution. Few organizations have found ways to reward teams.
The team is physically distant, not given enough resources to do the job, individuals are not recognized
for team effort.
Goals - what the team is to accomplish: A team exists when members have responsibility for
accomplishing a common goal. An effective team is aware of and manages:
1. The extent to which goals are clear, understood and communicated to all members
2. The amount of ownership of team goals
3. The extent to which goals are defined, quantified and deliverable
4. The extent to which goals are shared or congruent
5. The extent of goal conflict or divergence
Roles - who does what on the team: Do all members understand what they and others are to do to
accomplish the task? Do they know their individual responsibilities and limits of authority? In new

teams time should be spent discussing and defining roles and responsibilities. As the team develops it is
typical for individuals to build expectations and assumptions of others which are seldom recorded
anywhere. These should be discussed and agreed upon.
Conflict may occur as a result of differing expectations among team members. Overlapping roles can
create conflict, especially when two or more team members see themselves as responsible for the same
task.
Responsibilities are poorly defined, there is a power vacuum, members act independently and avoid
responsibility.
Defining roles and responsibilities is critical where people are in a new environment. Basically you take
all the work and divide it up amongst various people. It solves two problems:
Two people trying to do the same job because they think they are responsible. Often leads to aggravation
and a breakdown in working relationships.
Things falling between the cracks. Everyone thought it was someone else who was responsible.
Once defined, they need to be discussed with the team, and adjusted if necessary. Preparing a document
and emailing it to team members does not provide understanding. It needs to be talked through. As the
project progresses, they should be re-visited to ensure they are still current.
Work Processes - how members work together: Once team members know what they are to do and who
is to do it, they must determine how they will work together. Typical considerations are:
Decision making - how will each of the team members participate in decision making.
Communication - what should be communicated within the team, to whom, by what method, when and
how frequently?
Meetings - what is the team trying to accomplish, what subjects are to be covered, who is responsible for
the subject, how will the meeting be conducted, who should attend? Leadership style - the leader and the
team need to agree the best style to meet the situation and the leader should be open to receiving
feedback on their style.
Meetings are unproductive or poorly attended, decision making is dominated by one or two people,
actions taken without planning or communication is one way.
Relationships - the quality of interaction among team members: As team members work together,
relationships often become strained. Members need ways to resolve problems and to assure that a good
working relationship continues. Sometimes relationship problems occur because of a difference in
values or a personality or management style clash. Managers may need to take an active role in soothing
relationships during times of conflict. The more energy that is siphoned off because of bad feelings,
attitudes or strong emotions, the less energy is available for the team's task. Personality conflicts, or
members are defensive or competitive.
Team Culture and Commitment: Commitment of team members to work together effectively to
accomplish the goals of the team is a critical factor in team success. The relationships team members
develop out of this commitment are key in team building and team success.
Team Culture and Context: Clear performance expectations are a critical factor in teamwork success.
Whether your goal is to develop a project team, your departmental team, or a sense of teamwork
company-wide, clear performance expectations support teamwork success. Use clear performance
expectations to help your employees develop accountable, productive, meaningful, participatory
teamwork.
Compensation: A team works well when the members understand what they will be compensated for
their efforts. All Business notes it is best to come up with a compensation plan before assembling the
team. When people have their compensation expectations laid out before they sign an agreement to join
the team, compensation can be removed as an obstacle to effective teamwork. If all team members feel
they are being compensated fairly, that can help lead to maximum productivity.

Deal With Conflict: Rice University Web Services suggests dealing with conflict within a team as it
arises. Conflict tends to throw a team off of its focus, getting it away from its goals and objectives. By
learning to deal with conflict immediately, a team can remain effective at all times.
Project Direction: What is the outcome you are trying to achieve with this project? How will the
organisation be different when the work is successfully completed?
Just because you understand it, does not mean the team does. Get the sponsor to talk to the team about
why the project is being undertaken and how it will change the organisation. In the heat of a project, it is
easy to loose direction.
Managing Workload: It is inevitable that people will be asked to go the extra yard. There needs to be a
balance in how the organisation rewards them. For this reason, flexibility in working hours is a good
suggestion. Some people like to start early and finish late. Others are the opposite. As long as it does not
adversely impact the project, team members may be encouraged to work their own hours. If working
from home makes sense, let people do it.
Extra Rewards: Being appreciated helps maintain your enthusiasm. Get the sponsor to go out of his or
her way to congratulate people. Something as simple as tickets to a movie for the family, or a taxi
voucher to get home late at night makes people feel valued.
Family Support: The pressure and stress of a project does not stop when you walk out the corporate
door. It spills over at home particularly if you are not there much of the time. Telling your partner how
important your work is, is another way of saying Spending time at work is more important than
spending time with you. Do something for the family be it a planning day, picking up the bill for a
visit to a restaurant, or even a letter from the Sponsor thanking the partner for their patience during the
project.
Escalation Path: Problems are bound to arise that are unable to be resolved within the team. They might
require a level of authority beyond that mandated to the team. It may be that the solution causes two
solutions to be put forward that are equally supported. The situation should be foreseen and a plan put in
place to address the problem. It is sort of like a disaster recovery plan. A DR plan is created because, in
the heat of the moment, nobody wants to decide all the things that need to be done. It is better to have a
plan or process to follow rather than have to both invent and implement a plan. So with escalation.
Developing a plan for escalation means there is a clear expectation set that if something cannot be
resolved, we will react in this manner.
An escalation process has two clear benefits:
It ensures problems are addressed quickly because everyone knows what to do
It sets authority levels and people understand who is making decisions
Individual Skills:
Work delegated based on skills and the passion towards that particular task. The lesson is to look for
skills people have, and exploit those skills. Just because they have a particular role, does not mean it
cannot change to utilise their strengths. On the other side of the coin, it might change to avoid their
weaknesses. Hence, strengths and weaknesses of the team members have to be continuously assessed
and roles may be re-delegated if necessary.
Team Interaction: The week may be started with a team meeting that everyone must attend. This meeting
may throw some light on an overview of progress and then the project leader may go around the table
getting everyone to discuss what they have planned for the week. It achieves a number of things:
It makes people focus on their goals for the week. In fact they get into the habit of last thing on Friday,
looking at their work for the following week
It gives them a sense of commitment. They have stated their goals, and next week they will have to
explain why if they were not met
It alerts the project leader about the problems
It enables people to see how the work of other people may be impacted by what they are doing

It brings out issues between different project team members

It is a chance to set action items and follow up the following week.
Team development is a process aimed at improving team performance in any one or all of the five
factors in the team hierarchy. After examining your team's performance in these areas, your role as a
manager is to identify where your focus for team development needs to be.

FIVE STAGE TEAM DEVELOPMENT MODEL

Projects exist to create a unique product or service within a limited time frame. Projects are performed
by people, and most projects require more than one person to perform all of the activities. If youve got
more than one person working on your project, youve got a team. And if youve got a team, youve got
a wide assortment of personalities, skills, needs, and issues in the mix. Couple this with part-time team
members, teams based in functional organizations whose loyalty lies with the functional manager, or
teams based in matrix organizations that report to two different managers and you could have some real
challenges on your hands. Good luck. Okay, I wont leave you hanging like that.

Team Development according to the Guide to the PMBOK, is about creating an open, encouraging
environment for stakeholders to contribute as well as developing your team into an effective,
functioning, coordinated group. Projects are performed by individuals, and the better they work together,
the smoother and the more efficient the execution of the project will be.
Team Development inputs include project staff, project plan, staffing management plan, performance
reports, and external feedback. All of the inputs have been discussed elsewhere with the exception of
external feedback.

External feedback, as it implies, is information relayed to the project team from those outside of the
project team regarding performance expectations. This feedback might come from stakeholders, the
management team, users, customers, etc. The tools and techniques of Team Development include teambuilding activities, general management skills, reward and recognition systems, collocation, and
training.

IMPLEMENTING TEAM BUILDING

Many times, project teams are made up of folks who dont know each other. They arent necessarily
aware of the project objectives and may not even want to be a part of the team. The project manager may
not have worked with the people assigned to the project team before either. Sound like a recipe for
disaster? Its not. Thousands of projects are started with team members and project managers who dont
know each other and come to a successful completion. How is that done? Its a result of the project
managers teambuilding and communication skills.
The project managers job is to bring the team together, get them all headed in the right direction, and
provide motivation, reward, and recognition to keep the team in tip-top shape. This is done using a
variety of teambuilding techniques and exercises. Team building is simply getting a diverse group of
people to work together in the most efficient and effective manner possible. There are entire volumes on
this subject, and its beyond the scope of this book to go into all the team-building possibilities. The
exam tends to focus more on the theories behind team building, so thats what well spend our time
looking at.
All newly formed teams go through five stages of development: forming, storming, and norming,
performing and adjourning. Youve probably seen this elsewhere, but since these stages are on the exam,
youll want to memorize them. Lets take a brief look at each of them.
The Bruce Wayne Tuckmans five stages of Team Development:

FORMING: This ones easy. Its the beginning stage of team formation when all the members are
brought together, introduced, and told the objectives of the project. This is where team members learn
why theyre working together. During this stage, team members tend to be formal and reserved and take
on an all business approach. The project manager must first form the project
team either at the project initiation stage or more likely over a period of time, leading up to the start of
the project. Sometimes this can extend throughout the project's life as a project resource is engaged and
released during specific stages such as testing. This forming stage is characterised by:
Introduction of new team members meeting other team members for the first time
People starting to understand in more detail the project objectives and challenges and their role but
unsure of how well they will work with other team members or their ability to get the job the done
Understanding team relationships and people's authority (position, expertise, personality...)
Project manager often directs or tells people what to do at this stage as the project team orients itself
STORMING: This stage is where the action begins. Team members become confrontational with each
other as theyre vying for position and control during this stage. Theyre working through who is going
to be the top dog and jockeying for status. After the initial optimism and polite engagement of meeting
people for the first time comes the storming stage where people are getting to work together and
potentially finding issues:
Ideas compete for attention or implementation
Disagreement on goals, expectations, roles or responsibilities
People clash over how to do things, the right way to perform tasks or processes and standards to be
used
Individuals may display their real levels of motivation, ability to interact with others or get their job
done
Project manager must lead by example and put out these fires using a variety of techniques appropriate
to each situation. This stage often results in slow project progress
NORMING: Now things begin to calm down. Team members know each other fairly well by now;
theyre comfortable with their position in the team and begin to deal with project problems instead of
people problems. In this stage, they confront the project concerns and problems instead of each other.
Decisions are made jointly at this stage, and team members exhibit affection and familiarity with one
another. Project team rules, acceptable behaviour, role accountabilities and responsibilities are finalised,
processes and standards to be used are established. This norming stage is:
Team starts to become productive and working well together to achieve project objectives
People are listening to each other and building on collective ideas. Meetings are more positive in tone
and focused on outcomes and helping each other to get the job done
Project manager should use a facilitation and participative style to build on nascent teamwork
PERFORMING: Perfection, Well, almost, anyway. This is where great teams end up. This stage is where
the team is productive and effective. The level of trust among team members is high, and great things
are achieved. This is the mature development stage. Different teams progress through these stages at
different rates. When you have to bring new team members on board for whatever reason, the teamforming stages start all over again. It doesnt matter where the team is in the forming processa new
member will start the cycle over again. Project teams are working well together and getting things done.
The performing stage is:
Highly productive with people able to discuss issues and find collective solutions
People are able to rely on others to do their part to get the job and help others when needed
Project team cohesion, optimism and morale is high and with a sense of team identity
Team is task and people oriented

 Project manager can use a delegating style and focus on factors external to the project team and more
on the project objectives, risks and its impact
ADJOURNING: For conventional workgroups performing is the last stage of their development.
However, for project teams there is ma completion phase during this stage the team prepares for its own
disbandment. High performance is no longer a top priority. Instead attention is devoted to wrapping up
the project. Responses of members vary in this stage. Some members are upbeat, basking in the project
teams accomplishments. Others may be depressed over loss of camaraderie and friendships gained
during the projects life. The project comes to a natural conclusion, the project team disperses and in the
adjourning stage it is important to:
Celebrate project success
Team has a sense of closure about the project and meeting its objectives
People feel able to move on to next challenge
Project manager must formally close the project

SITUATIONAL FACTORS AFFECTING TEAM DEVELOPMENT

Experience and research indicate that high-performing project teams are much more likely to develop
under the following conditions
There are 10 or fewer members per team
Members volunteer to serve on the project team
Members serve on the project from beginning to end.
Members are assigned to the project full-time.
Members are part of an organisational culture that fosters cooperation and trust
All relevant functional areas are represented on the team
The project involves a compelling objective
Members are located within conversational distance of each other
In reality, is rare that a project manager is assigned a project that meets all of these conditions. It is
important for project managers and team members to recognise the situational constraints; they are
operating under and do the best they can. It would be naive to believe that every project theme has the
same potential to evolve into a high performing team. Under less than ideal conditions it may be a
struggle just to meet project objectives. Ingenuity, discipline and sensitivity to team dynamics are
essential to maximise the performance of the project team.

TEAM FOCUS
Did you ever watch any of those old pirate movies on late-night TV? Remember the scenes where the
captain went down into the bowels of the ship to check on the teams of rowers? Imagine your project
team members are like those rowing teams. If the members on the left are rowing one way and the
members on the right are rowing another, youre creating a lot of energy and looking very busy, but in
the end you arent making any progress. All the team members need to understand the direction youre
headed and work toward that end. Its paramount that the team members know and understand the
objectives of the project. After all, thats the reason theyve been brought together in the first place.
Keep in mind that people see and hear things from their own perspective. A room full of people
attending a speech will all come away with something a little different because what was said speaks to
their particular situation in life at the time. In other words, their own perceptions filter what they hear.
Its your job as project manager to make certain the team members understand the objectives and their
assignments correctly. Ask them to tell you in their own words what they believe the project objectives
to be. This is a great way to know if youve got everyone on board.

EFFECTIVE TEAM CHARACTERISTICS

Effective teams are typically very energetic teams. Their enthusiasm is contagious, and it feeds on itself.
They generate a lot of creativity and become good problem solvers. Teams like this are every project
managers dream. Investing yourself in team building as well as relationship building, especially when
you dont think you have the time to do so, will bring many benefits.
Heres a sample of the benefits:
_ Better conflict resolution
_ Commitment to the project
_ Commitment to the project team members and project manager
_ High job satisfaction
_ Enhanced communication
_ A sense of belonging and purpose
Dysfunctional teams will typically produce the opposite results of the benefits we just listed.
Dysfunctional teams dont just happen by themselves anymore than great teams do. Sure, sometimes
youre lucky enough to get the right combination of folks together right off the bat. But usually, team
building takes work and dedication on the part of the project manager. Even in the situations where you
do get that dynamite combination of people, they will benefit from team-building exercises and
feedback. Unfortunately, sour attitudes are just as contagious as enthusiasm. Watch for these symptoms
among your team members and take action to correct the situation before the entire team is affected:
_ Lack of motivation or dont care attitudes
_ Project work that isnt satisfying
_ Status meetings that turn into whining sessions
_ Poor communication
_ Lack of respect and lack of trust for the project manager
Keep in mind that no amount of team building will make up for poor project planning or ineffective
project management techniques. Neglecting these things and thinking that your project team is good
enough to make up for the poor planning or poor techniques could spell doom for your project. And
besides that, its not fair to your project team to put them in that position.

Complexities Associated with Project

The Environment: A project environment is usually:
Higher pressure and more stressful than a line role
Less certain
Requires more flexibility
More transient in terms of developing relationships
Requires problem solving and creative skills
People unclear of what their role is
Frustration from constant changes of direction
Loss of perspective. We will never climb the mountain
Lack of availability of key personnel
Splintering of the team into small groups who work independently and at cross purposes to each other
Never enough time to get the work done

Burn out as the project progresses. People being asked to do more and more when their productivity is
falling through overwork.

self-organizing teams : Self-organizing teams are given the freedom to chose their own team goals every
iteration. They also have the freedom to self-assign tasks which leads to higher sense of responsibility
and ownership of tasks and the overall project as compared to manager-led or directed teams that have
tasks assigned to them by their managers. Self-organizing teams are cross-functional and there is more
flexibility across functional areas of expertise which ensures maximum utilization of resources and
better learning through collaboration. Directed teams, on the other hand, focus on specialization which
can be detrimental to collaboration and knowledge-sharing. Finally, self-organizing teams also value
self-reflection and continuous learning while effectively achieving iteration goals which allows them to
not only out-perform themselves but also find better and innovative ways of working. Directed teams,
on the other hand, are focused on meeting deadlines set by their managers and have little incentive to
improve their own ways of working.
Self-organizing teams do not function in isolation and are effected by environmental factors. The two
most important environmental factors include senior management support and customer involvement.
Senior management at the teams' organization must be able to provide freedom to the teams so that they
can self-organize themselves. Customers must support the teams by being actively involved in the
development process through providing regular requirements, clarifications, and feedback as required.
These two are the most important environmental factors that need to be in place to enable selforganization to emerge.
Informal roles that team members adopt in order to help their team self-organize: These are:
1. Mentor that provides initial guidance, understanding, confidence of Agile methods, and encourages
continued adherence to Agile practice. This role is closest to the classic Agile coach role, but as I
mentioned, was also played by senior developers in more mature Agile teams.
2. Co-ordinator that co-ordinates communication and change requests from customers. The co-ordinator
role was present in situations where the customer was physically distanced from the development team
and co-ordinating change requests and communication with the customers was difficult. The Coordinator was played by a developer or business analyst.
3. Translator that translates the customers business language into technical terminology used by the
team and vice-versa, in order to improve communication. This role emerged to address the language gap
that exists between business customers and the technical development team. The Translator could be
played by anyone of the team with good communication skills who can effectively understand and
translate between business and technical languages.
4. Champion that gains the support of senior management to establish pilot teams and to propagate more
self-organizing teams across the organization. The Champion was played by a Agile coach or (senior)
developer.
5. Promoter that secures customer collaboration and involvement to support efficient functioning of
Agile teams and was played by an Agile coach.
6. Terminator that removes team members that hamper team productivity due to their inability to fit into
the Agile way of working. We found the Terminator to be played by the Agile coach.

PROJECT TEAM PITFALLS

High performance project teams can produce dramatic results however like any other good thing there is
a dark side to project teams that managers need to be aware of. In this section we examine more detail
some of the pathologies that the high performing project teams can succumb to and high light what
project managers can do to reduce the likelihood of these problems occurring.
GROUPTHINK: Janis first identified groupthink as a factor that influenced the misguided 1961 Bay of
Pigs invasion of Cuba, his term refers to the tendency of members in highly cohesive groups to lose their
critical evaluative capabilities. This malady appears when pressures for conformity are combined with

an illusion of invincibility to suspend critical discussion of decisions. As a result decisions are made
quickly with little consideration of alternatives; often the practice leads to fiascos that, after the fact,
appeared totally improbable. Some of the symptoms of group think include the following:
ILLUSION OF INVULNERAVILITY: The team feels invincible. It is marked by a high degree of esprit
de corps, and implicit faith in its own wisdom and an inordinate optimism that allows group members to
feel complacent about the quality of the decisions.
WHITEWASH OF CRITICAL THINKING: The group members discuss only a few solutions, ignoring
alternatives; they fail to examine the adverse consequences that could follow their preferred course of
action; and they too quickly dismiss any alternatives that on the surface appear to be unsatisfactory.
NEGATIVE STEREOTYPES OF OUTSIDERS: Good guy, bad guy stereotypes emerge in which the
group considers any outsiders who oppose their decisions as the bad guys, who are perceived as
incompetent and malicious and whose points are unworthy of serious consideration.
DIRECT PRESSURE: When a team member does speak out or question the direction in which the team
is headed, direct pressure is applied to the dissenter. He or she is reminded that speed is important and
that the aim is agreement not argument.
BUREAUCRATIC BYPASS SYNDROME: Project teams are often licensed to get things done without
having to go through normal protocols of the parent organization. Bypassing bureaucratic channels is
appealing and invigorating. However, if bypassing becomes a way of life, it results in the rejection of
bureaucratic policies and procedures, which provide the glue for the overall organization. A team that
operates outside the organization may alienate other workers who are constrained by the norms and
procedures of the organization; eventually, these outside bureaucrats will find ways to put up road
blocks and thwart the project team.
ENTREPRENEURS DISEASE : Project teams can be intoxicating in the same way that start up
ventures are. Such intoxication is exciting and contributes greatly to the success of the team. But abuse
can occur as the team makes decision based on what is best for the project instead of on whats best for
parent organization. The team becomes myopic in its focus and often views the constraints imposed by
the parent organization or something to overcome. When this attitude occurs on developmental project
the team members, enthralled with their accomplishments sometimes quit the parent organisation and
start their own business. While starting a new venture may be good for the project team, it does little for
the parent organization that sponsored and financed the development work.

TEAM SPIRIT BECOMES TEAM INFATUATION: High-performing project teams can be tremendous
source of personal satisfaction. The excitement, chaos, and joy generated by working on a challenging
project can be an invigorating experience. Leavitt and Lipman-Blumen even go so far as to say that the
team members behave like people in love. They become infatuated with the challenge of the project and
the talent around them. This total preoccupation with the project and the project team, while contributing
greatly to the remarkable success of the project, can leave in its wake a string of broken professional and
personal relationships that contribute to burnout and disorientation upon completion of the project.
GOING NATIVE: Going native is a phrase first used by the British Foreign Service during colonial
times to describe agents who assumed the customs, values and prerogatives of their foreign country
assignment, they did so to the point that they were no longing representing the best interest of the
British empire but rather those of the natives . This same phenomenon can occur within the project
teams working abroad or in those who become closely identified with their customers. In essence, the
customers interest takes precedent organizations interests. This change in view point can lead to
excessive scope creep and open defiance of corporate policy and interests.
Dealing with these maladies is problematic because, in most cases, they are a distortion of a good thing,
rather than a simple evil. Awareness is the first step for prevention. The next step is to take pre-emptive
action to reduce the likelihood of these pitfalls occurring. For example, managers can reduce the
isolation of the project team by creating work-related connections outside the project team. These
include interactions naturally occur in a matrix environment where members work on multiple projects
and maintain ties to their home department.

Likewise, the isolation of dedicated project teams can be reduced by the timely involvement of external
specialists. In either case, the active involvement of relevant members of the parent organisation at
project status meetings can help maintain the link between the project and the rest of the organisation. If
the team appears to be suffering from group think, then the project manager can encourage functional
conflict by playing the devils advocate to encourage dissent. Finally, formal team-building sessions may
reveal dysfunctional norms and refocus the attention of the team on project objectives.