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 ambitious—challenge 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 well-recognized 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 non-

supportive 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 organization’s 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 organization’s 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 Tucker’s 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 customer’s 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

caller’s 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 customer-

internal 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 product—Design

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. WBS’s 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 structure—design,

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 accounts—under 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 (client’s interest) and tracked horizontally by organization responsibility

(management’s 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 form—columns 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 vendor’s 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 project’s 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 start-and-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 manager’s 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 project’s 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 steps-

Completing 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 following-

the 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

PeopleProject employees, vendor staff, subcontract labour

EquipmentCranes, trucks, backhoes, other heavy equipment or Development, test, and staging servers, CD burners or Recording studio, tape decks, mixers, microphones and speakers

MaterialConcrete, 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 decision-making, 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 decision-makers. 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 agreed-upon 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 we’ve identified during model setup. Normally it’s 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 project’s objective. In this step, the team identifies all of the work to be done. The project’s 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 Planning-

This specifies the in-scope requirements for the project.

Preparing the Work Breakdown Structure-

This specifies the breakdown of the project into tasks and sub-tasks.

Organizational Breakdown Structure-

This 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 resolution-

This 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 includes-

Project 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 Closure-

Did 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 do’s and don’ts 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 team’s 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 don’t 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 don’t 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 team’s 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 you’re 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, it’s up to a dedicated project manager to make sure feature creep doesn’t 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. It’s easy enough for feature creep to happen in strongly defined projects. It’s almost impossible to avoid it when projects aren’t clearly defined. Furthermore, without a guiding vision for a project, stakeholders can muddle a team’s 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 don’t 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 decision-makers. 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 agreed-upon 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 we’ve selected Palisade’s “@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 we’ve identified during model setup. Normally it’s 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 it’s 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 we’d spent all available time on doing one particular task another dependent task should happen only within strictly limited timeframe and that’s 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. We’d tried “What’s 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 option’s 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 customer’s 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 risk’s 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 company’s 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 will determine if all tasks have been taken into account.

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 DataExpected Net Cash Flow

YearProject L Project S

0

1

2

3

($100)

10

60

80

($100)

70

50

20

Considering a Project L:

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.

0 1 2 3

-100.00 10 60 80

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

Year 1

Year 2

Year 3

Year 4

Year 5

Cash Inflows     300

   300   300   300   300

Cash Outflows  – 800

 –150      0    0      0

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 project—always 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

1 $19,000 $19,000

2 $25,000 $44,000

3 $30,000 $74,000

4 $30,000 $104,000

5 $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

1 $19,000 $17,271 $17,271

2 $25,000 $20,650 $37,921

3 $30,000 $22,530 $60,451

4 $30,000 $20,490 $80,941

5 $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 project’s cost.

Project L

Expected Net Cash Flow

YearProject L Project S

0

1

2

3

($100)

10

60

80

($100)

(90)

(30)

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 project’s 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 period’s 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

.

Project L:

8.4718.1%

0 1 2 3

-100.00 10 60 80

18.1%

43.02

48.57

$ 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, don’t 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.)

18.1%

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)

A benefit-cost ratio (BCR) is an indicator, used in the formal discipline of cost-benefit analysis, that attempts to summarize the overall value for money of a project or proposal. A BCR is the ratio of the benefits of a project or proposal, expressed in monetary terms, relative to its costs, also expressed in monetary terms. All benefits and costs should be expressed in discounted present values.

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.

Cost–benefit analysis (CBA), sometimes called benefit–cost 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, cost–utility analysis, economic impact analysis, fiscal impact analysis and Social return on investment(SROI) analysis.

Theory

Cost–benefit 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.

YOU SHOULD REMEMBER

The internal rate of return (IRR) is a popular method in capital budgeting. The IRR is a discount rate that makes the present value of estimated cash flows equal to the initial investment. However, when using the IRR, you should make sure that the calculated IRR is not very different from a realistic reinvestment rate.

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 inconsistency—valuing 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 aversion—the 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 cost–benefit 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.

Cost–benefit 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. Cost–benefit 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 cost–benefit 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 cost–benefit 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).

Cost–benefit 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 cost–benefit 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 cost–benefit 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 cost–benefit 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, cost–benefit 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, cost–benefit 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 cost–benefit 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 cost–benefit 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 peer-reviewed 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 cost–benefit analyses should be treated with caution because they may be highly inaccurate Inaccurate cost–benefit 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 cost–benefit 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 cost–benefit 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 cost–benefit 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 quality-adjusted 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 cost–benefit 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 cost–benefit 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 cost–utility 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. It’s 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 society’s 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 society’s 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 society’s value scale. From society’s 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 cost-

benefit 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 project’s 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

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.

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

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 airport’s vicinity. Landside projects aim at expanding the airport’s 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

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.

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

(1)

where:I : investment costs T: project life∆CSt: change in consumer surplus in year t∆PSt: change in producer surplus in year ti: discount rate

The change in consumer surplus can be estimated with “the rule of a half”:

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

(2)

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:

(3)

where and 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 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:

(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

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

C

D0

Dt

qa qb qc qd

g0

g1

q0

Costs

Benefits

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.

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.

6 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 g1–g0. This value should be interpreted as the average, equal to a half of the interval of time savings. 7 We ignore the trivial case where qb is equal in both cases.

Figure 2. User benefits with administrative rationing of capacity

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.

C

D0

Dt

qb qc qd

g1

g’

g0

q0

Costs

Benefits

Figure 3. User benefits with administrative rationing and congestion

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’)(qe-

qb). 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:

(5)

Given that , and rearranging (5), social surplus can be expressed as:

(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

C

D0

Dt

qb qc qe qd

g1

g’

g0

q0

Costs

Benefits

C’

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.

9 For a formal treatment of this concept see Douglas and Miller (1974).10 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.

Figure 4. Benefits from airside investment

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.

fd’ = c’

c1

fd1

d

ab

Ca

F

1 / ASEUR1 Runway 2 Runways

C

FD

f1 f2f ’

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

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.

Ranking of hours in the year

2,000 4,000 6,000 8,000

Hourly passenger flow

5% of throughput

5% BHR

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)

A B C D E

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 50-60%) 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

13 See, for example, Jorge-Calderón (1997).

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 by runways, taxiways and apron space. As with terminals, the actual hourly capacity of an airport’s 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 delayF: 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:

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 airline’s 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)

Considering only situations where the project will produce significant changes in aircraft operating costs; and

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 aircraft’s cost per block-hour 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)

A—2464.00

B—3595.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 off—all 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. Let’s 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, it’s

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, let’s 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,000-

FC328,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 manager’s 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 bottom-up 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 don’t 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 world’s 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. Sydney’s 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 scaled-down 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 wasn’t able to hand over the land, which meant M & R didn’t 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 project’s 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 project’s 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, it’s 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 project’s 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 project’s 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 don’t exceed the defined budgetary allocation?

Is the proposed project budget compatible with the organization’s 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 organization’s 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 project’s role in the organization’s 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 project’s 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 project’s 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 project’s 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 don’t exceed the defined budgetary allocation?

Is the proposed project budget compatible with the organization’s 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 organization’s 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 project’s role in the organization’s 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 project’s 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 organization’s 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 project’s 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 should-

identify 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 project’s 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 organization’s 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 built—program code and databases—are 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 used-

to 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 documented—this 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 it—for 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 change’s 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.

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

PLANNING

INITIATING

EXECUTINGMONITORING & CONTROLLING

CLOSING

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 organization’s 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 project’s 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 should-

identify 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 project’s 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 organization’s 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 built—program code and databases—are 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 used-

to 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 documented—this 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 it—for 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 change’s 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 manager’s 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, customer’s needs may change, requiring significant design changes mid-way 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. They’re 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 they’re 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 hands-on 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 who’s 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 people’s 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 manager’s 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 won’t 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 manager’s 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 don’t 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 can’t 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 people’s attention positive. A good sense of humour and a playful attitude are often a project manager’s 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 Adair’s 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 decision-making 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 don’t play well with others, and are obnoxious at times. They don’t care about other people’s feelings, and much of the time they don’t 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 project’s 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. It’s essential for the project manager to keep calm, to lead, and to direct the parties to a sensible solution that’s 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 it’s 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 it’s 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 problem—usually 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, you’ll 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 person’s 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 won’t 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, don’t 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 won’t budge, tell them you’ll think it over and then you will make a decision within a day or two—if 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 you’ve made the decision that you have made. In your announcement don’t 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. Don’t 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, you’ll find many different personality types, so it’s 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 don’t 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. They’re so afraid they’ll 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 you’ve 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 someone’s cubicle, telling jokes, and sharing stories around the office. Not only are these types of people great fun, but also they’re great time wasters.Often these folks don’t have enough to do, and so they assume everyone else is under the same workload that they are. Give these people more assignments, and they’ll have less time to kill. If that doesn’t 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, ten-gallon hat, and stunts aren’t 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 don’t care about your project, think the technology sucks, and take their hourly breaks every twenty minutes. Granted, these folks are hard to work with. They’ve 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 can’t 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 don’t 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 can’t! 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 won’t fit into the scope of the testing lab, rely on someone else’s 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 member—at least they shouldn’t. Unfortunately, despite your attempts at befriending, explaining the importance of the project, or keeping team members on track, some people just don’t, or won’t, care. In these instances, you’ll 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 caution—you are dealing with someone’s 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 doesn’t 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, there’s 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 employee’s 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 it’s 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 everyone’s 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 you’ve got more than one person working on your project, you’ve got a team. And if you’ve got a team, you’ve 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 won’t 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 team-building activities, general management skills, reward and recognition systems, collocation, and training.

IMPLEMENTING TEAM BUILDING

Many times, project teams are made up of folks who don’t know each other. They aren’t 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? It’s not. Thousands of projects are started with team members and project managers who don’t know each other and come to a successful completion. How is that done? It’s a result of the project manager’s teambuilding and communication skills.

The project manager’s 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 it’s 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 that’s what we’ll spend our time looking at.

All newly formed teams go through five stages of development: forming, storming, and norming, performing and adjourning. You’ve probably seen this elsewhere, but since these stages are on the exam, you’ll want to memorize them. Let’s take a brief look at each of them.

The Bruce Wayne Tuckman’s five stages of Team Development:

FORMING: This one’s easy. It’s 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 they’re 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 they’re vying for position and control during this stage. They’re 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; they’re 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 team-forming stages start all over again. It doesn’t matter where the team is in the forming process—a 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 team’s accomplishments. Others may be depressed over loss of camaraderie and friendships gained during the project’s 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, you’re creating a lot of energy and looking very busy, but in the end you aren’t making any progress. All the team members need to understand the direction you’re headed and work toward that end. It’s paramount that the team members know and understand the objectives of the project. After all, that’s the reason they’ve 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. It’s 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 you’ve 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 manager’s dream. Investing yourself in team building as well as relationship building, especially when you don’t think you have the time to do so, will bring many benefits.

Here’s 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 don’t just happen by themselves anymore than great teams do. Sure, sometimes you’re 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 “don’t care” attitudes

_ Project work that isn’t 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, it’s 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 self-organization 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 Co-ordinator 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 what’s 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 customer’s 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 devil’s advocate to encourage dissent. Finally, formal team-building sessions may reveal dysfunctional norms and refocus the attention of the team on project objectives.