MANAGING PROJECTS

MANAGING IT PROJECTS
Sub Code-160
Developed by
Prof. Pradeep Pendse
On behalf of
Prin. L.N. Welingkar Institute of Management Development & Research
!
CONTENTS
Contents
Chapter No. Chapter Name Page No.
1 Projects Overview and Basic Concepts and 3-35

Definitions
2 The PMI Framework 36-56
3 Software Project Lifecycle 57-76
4 Project Planning and Scheduling 77-117
5 Project Risk Management 118-135
6 Project Tracking 136-150
7 Configuration Management 151-161
8 Project Closeout 162-171

Bibliography 172
! !2
PROJECTS OVERVIEW AND BASIC CONCEPTS AND DEFINITIONS
Chapter 1
PROJECTS OVERVIEW AND BASIC
CONCEPTS AND DEFINITIONS
Objectives:
The Objectives of this lesson are to give you an insight into:
What is a project & Why learn project management?

Why do projects fail?
Project Life Cycle.
The peculiar nature of software projects.
Product perspective & work breakdown structure
Project Charter.
Financial evaluation of project proposals.
Project goals, Stakeholders, risks, resources.
Project Costs, planning, execution, tracking.
Structure:
1.1 What is a Project and Why Learn Project Management.

1.2 Why do Projects Fail?
1.3 Project Life Cycle.
1.4 The Peculiar Nature of Software Projects.
1.5 Product Perspective & Work Breakdown Structure.
1.6 Project Charter.
1.7 Financial Evaluation of Project Proposals.
1.8 Project Goals.
1.9 Project Stakeholders.
1.10 Project Risks.
1.11 Project Resources.
1.12 Project Costs.
1.13 Project Planning.
1.14 Project Execution.
1.15 Project Tracking.
1.16 Summary.
1.17 Self Assessment Questions.
! !3
1.1 What is a Project and Why Learn Project Management?
In personal life as well as Corporate life we are frequently engaged in

activities which we tend to call as Projects. Students are given Projects
which are slightly complex assignments. Building a new house or setting up
a new office are all examples of projects.
In the organizational context every person is increasingly being involved in

one or more projects. This could be in the form of shifting the office to a
bigger location, setting up a new branch office, launching a new product or
service etc. It is therefore important that virtually every person working in
an organization be familiar with Project Management as a subject.
While there are many definitions of a project, given below is how the
Project Management Institute the most authoritative source for Project
Management literature defines a project.
A project is a temporary endeavour undertaken to achieve something

Unique.
A project is, therefore, always characterized by one or more of the

following:
It is a One time and non-repetitive activity
Even where it is repetitiveeach product/service delivered is very large in

terms of magnitude, cost, resource mobilization etc for instance, a ship
building yard which makes ships but each ship is so large that it could be
called a project.
There is something which is unique about it which means that each

project has to be planned separately. The differences in the projects from
any other project either in terms of its purpose, goals, stakeholders,
risks, requirements or people involved must be studied carefully and
should reflect in the plan.
A project has a single objective that must be accomplished through the

completion of tasks that are unique and interrelated.
Projects are completed through the deployment of resources.
! !4
Projects have scopes, schedules, and costs and are accomplished within
specific deadlines, budgets, and according to specification.
The one time nature, the size, complexity and uniqueness of the project
necessitates, proper planning and careful execution to ensure success.
While we learn management in general and also understand the nuances of

our specific business domain, we need to learn the specific tools,
techniques and behaviours required for Project Management and combine
the three disciplines to ensure success at Management of projects.
Examples of Projects
Construction of Ships, Aircraft or Space Craft.

Launching a New Product.
Setting up a New Office, a New Branch etc.
Launching a New Quality Management Program in the Company.
Constructing a Building, Bridge, Road etc.
Launching a New Advertising Campaign.
Public Issue of Shares etc.
Conducting a Employee Satisfaction Survey.
Implementing a Performance Management System.
Setting up a Corporate Website or an Intranet.
From the foregoing, it would be obvious that we would come across

Projects in virtually every aspect of business.
What is project management?
Application of:
Knowledge.
Skills.
Tools and techniques.
To project activities to meet or exceed stakeholders expectations while
using resources efficiently and effectively.
Managing a project includes:
Identifying the requirements.
! !5
Establishing clear and achievable objectives.

Balancing the competing demands for quality, scope, time, and cost.
Adapting specifications, plans, and concerns of the stakeholders.
1.2 Why do Projects Fail?
It is common knowledge that many projects seem to fail in some ways. A

project may either
Fail to achieve some or all aspects of its basic purpose.

It is completed in a timeframe which exceeds the planned timeframe.
It is completed in with excessive resources and costs.
It drags to such an extent that the management aborts it midway.
In the field of Information Technology, project failures are very common.

This is, perhaps because of the new and unexplored technology and the
ability of the users and the developers to understand each others
requirements.
In several surveys of projects in various domains, it has been found that

the following are the more important reasons for project failure:
Unclear Project Goals.

Lack of Management Commitment.
Lack of user Involvement and Commitment .
New Technical or Business Area Uncharted Area.
Failure to Grasp Stakeholder Requirements.
As project Managers we must, therefore, attempt to overcome the above

causes of failure.
Some of the important concepts related to Project Management are:
Project Charter Project Purpose and Goals.

Stakeholders.
Project Selection Cost Benefit Analysis of Projects.
Key Assumptions for the Project.
Project Lifecycle.
Project Planning.
Project Risks.
! !6
Work Break Down Structure and Task List.

Estimating Task Duration.
Project Schedule.
Project Costs and Budgets.
Project Organization Functional or Matrix Organization.
Project Tracking.
Project Planning and Review Techniques PERT, CPM, EVA, Critical Chain.
Fast Tracking, Crashing.
Project Change and Configuration Management.
Project Closure.
In the subsequent sections we shall study about each of these separately.
1.3 Project Life Cycle
As we have seen in the examples given above, projects could be of

different types depending on their business domain. For an organization
which wishes to succeed in managing projects in a certain business domain
it should understand the nuances of that business domain, and structure
the project in a broad series of steps which it should follow so as to be able
to manage the project for that domain.
For instance, a software development company should understand the

nuances of the process of developing software and break down the process
into a series of steps such as Analysis, Design, Coding, Implementation so
that several software projects which it handles can be managed by
managing these steps.
These series of steps provide the sequence of tasks necessary to complete

a project. The completion of a step also gives a sense of achievement
also known as a milestone.
Thus Project Life Cycle i.e., series of steps, is a very important concept in
Managing projects. Project Lifecycles are different for each business area.
Many a time there can be alternative Project Lifecycles for different types
of projects even within the same domain.
Thus for example, the Project Life Cycle for Constructing a Building would
look very different from that of a Software project. Equally, within the
software domain itself, the steps required to make a business application
! !7
software could be different from developing software for an embedded

solution or a process control application.
It is therefore necessary that:
We understand the Project Lifecycle for the Business Domain
Select an Appropriate Project Lifecycle within that Domain which best

represents the nature of the project at hand.
Before we proceed, let us understand the nature of software projects.
1.4 The Peculiar Nature of Software Projects
Software unlike many other domains is an area which is very nebulous. It

is many times referred to as a wicked problem i.e.:
It is difficult to define very definitively.

It is difficult to understand when you have arrived at the desired stage of
the software.
It is difficult to test it completely.
! !8
Most of the users find it difficult to understand technology, its potential and
its impact on business. It is this fear which tends to make it difficult for
people to visualize a technology based solution or to use it effectively.
Unfortunately the technical experts use a language of their own which only
makes it difficult to communicate with the users. As a result software
project suffer from a lack of clarity about requirements, the purpose of the
project. This gap only widens as the project progresses until it is too late to
correct the software.
Estimation of complexity, effort and time is another grey area in the IT

world. Most developers have to estimate, based on a very high level
briefing given by customers. Customers themselves are not very clear
about the potential use of IT in their work area. From a technical
standpoint, the designer of any technology based solution requires a
specific technical scope and specification document. Given the fluidity of
the situation the developer does not have such a document from the
customer at the time of estimation.
Apart from the issue of lack of clarity and lack of complete scope definition,
software estimation is in itself a very difficult task. For instance, a simple
inventory system could vary from Raw material, component/Spares, Books
(library), Blood (blood bank), inventory of eyes (eye bank), Steel and
metal products, Tools, Retail store etc. Though the basics of inventory
remains the same, the variation in the transactions, the complexities in
measuring, storing, handling and documenting different types of items
varies substantially. Thus assessing the effort by a mere understanding of
Inventory concepts would be incorrect.
Add to this, the company specific requirement such as maintaining stock of

an item as a single entry in the item master versus maintaining a supplier
wise or batch wise or expiry date wise (as in pharma) or length or quality
wise stock adds to the myriad complications which specific industries and
company practices create.
Other factors such as:
User experience with technology.

Developers experience with a specific technology to be used in the
project.
! !9
Geographical spread of the organization.

Need for integration with older or a variety of other existing applications.
Compatibility with existing technologies or platforms.
Specific security policies.
Etc.
All these factors add to the complexity of the IT project.
Software Design is also subject to ambiguity. For any given requirement, a

wide set of choices of technologies and design options exist. The operating
conditions underwhich the software is expected to work can also vary. For
instance, a Computer based attendance system in a factory would require
the need to keep the smart card badge readers to be placed in heat and
sun near the gate of the factory. While the same application in a office
environment with white collar workers would be more easier to handle.
The design for a software for 10,000 transactions would be very different
from that which faces a lakh transactions.
Technology itself creates a myriad of options. Client server applications

using an interactive language such as Visual Basic would provide different
features as compared to a Java based application, which in turn would
have different features, effort requirements and maintenance challenges as
compared to ASP.Net or JSP.
Features, complexity, effort vary greatly with technology, making it difficult

to estimate.
Production and Productivity in a Software development environment also

varies considerably. Since Software develop-ment is a highly cognitive work
and a highly labour oriented work, the ability to visualize the software,
develop the code and the quality of the resulting product varies greatly and
depends on the people involved, the technical skills, knowledge of business
domains, the development tools available at their disposal and other
factors such as motivation levels etc. Thus for the same size of the project
the productivity can vary drastically from team to team. Availability of re-
useable code, components and tools also impacts the productivity.
! !10
Process Maturity is another aspect. The Capability Maturity Model (CMM)

which was evolved for software organizations essentially believes that
organizations which have a mature software development process are
likely to deliver software of a consistent quality, delivery schedule and
would be able to predictably meet customer needs even in the face of
process and technology changes. A very large number of IT companies in
India have attained the highest level of CMM certification viz. CMM Level 5.
In spite of this, problem as described above still persists. The challenge is
to institutionalize these processes in the face of a highly volatile work
force.
Testing is another area of concern. It is only in recent times that Testing

Validation and Verification have become serious businesses in the IT
industry. As was mentioned above, software is a wicked problem and
therefore it is difficult to assess whether the software has been adequately
tested. It is equally difficult to assess the extent of bugs which may have
remained in the software product.
All these and many more issues continue to make software projects a
challenging field.
1.5 Product Perspective and The Work Break Down

Structure
A project delivers a product or service. A project can be termed as

successful if and only if it delivers that product or service.
It is therefore necessary to keep the product or service in sharp focus. This

implies that we must strive to understand the needs of the customer/user
of the product or service, identify the necessary features and ensure that
these are being built progressively as the project progresses.
A Project, therefore, needs to be planned in such a manner that each

phase of the project leads to the delivery of some of the product/service
functionality.
It is, therefore, necessary to break down the product to be delivered into

broad components, subcomponents and finally elemental pieces which can
then be put together to construct the product/service.
! !11
This breakdown of the delivered product into elemental pieces is known as

a Work Break Down Structure.
To build each piece, subcomponent and component needs the execution of

some steps. These steps are known as Tasks.
These Tasks need to be performed, they need certain resources such as

people material etc to be performed and require certain amount of time.
The sequence of the tasks is also important in many cases. For instance,
we apply paint on the wall after applying plaster on it. Thus there is an
implied sequence of tasks. This is known as task dependency.
The time required for performing the task by a person is the duration of
the task. The duration can often be reduced by putting more people and
other resources, so that the task is performed faster than usual.
In practice, the Work breakdown structure is decided based on a variety of

factors, such as the product components, priority in delivery of various
functions, commercial considerations such as stages defined for payments,
risks associated with various portions of the product etc.
Example of a product work breakdown structure of an aircraft system.
! !12
Level of detail
A question to be answered in determining the duration of activities

necessary to produce a deliverable defined by the WBS is when to stop
dividing work into smaller elements. There are several heuristics or "rules
of thumb" used when determining the appropriate duration of an activity or
group of activities necessary to produce a specific deliverable defined by
the WBS.
The first is the "80 hour rule" which means that no single activity or group
of activities to produce a single deliverable should be more than 80 hours
of effort.
The second rule of thumb is that no activity or series of activities should be

longer than a single reporting period. Thus if the project team is reporting
progress monthly, then no single activity or series of activities should be
longer than one month long.
The last heuristic is the "if it makes sense" rule. Applying this rule of
thumb, one can apply "common sense" when creating the duration of a
single activity or group of activities necessary to produce a deliverable
defined by the WBS.
A work package at the activity level is a task that:
can be realistically and confidently estimated;

makes no sense practically to break down any further;
can be completed in accordance with one of the heuristics defined above;
produces a deliverable which is measurable; and
Forms a unique package of work which can be outsourced or contracted
out.
Example
! !13
The WBS Construction Technique employing the 100% Rule during WBS
construction.
The figure above shows a Work Breakdown Structure construction

technique that demonstrates the 100% Rule and the "progressive
elaboration" technique. At WBS Level 1 it shows 100 units of work as the
total scope of a project to design and build a custom bicycle. At WBS Level
2, the 100 units are divided into seven elements. The number of units
allocated to each element of work can be based on effort or cost; it is not
an estimate of task duration.
The three largest elements of WBS Level 2 are further subdivided at Level
3. The two largest elements at Level 3 each represent only 17% of the
total scope of the project. These larger elements could be further
subdivided using the progressive elaboration technique described above.
WBS design can be supported by software (e.g. a spreadsheet) to allow

automatic rolling up of point values. Estimates of effort or cost can be
developed through discussions among project team members. This
collaborative technique builds greater insight into scope definitions,
! !14
underlying assumptions, and consensus regarding the level of granularity

required to manage the project.
To summarize:
The goal of the project should be accomplished when all tasks in the
WBS are completed.
When major activities are sequential, they typically appear in that order
in the WBS.
The Gantt chart and PERT chart (well discuss later) are graphic forms of
the WBS.
Activity A:
1. Using Internet, collect information on Project Charter.
1.6 Project Charter
A Project Charter is a document which embodies the Project Goals and the
commitment of the Stakeholders to a project and its outcomes. The
Charter is a means of creating a common sense of purpose. The Charter is
a formal statement which includes the following:
A brief statement of purpose of the project.

A statement of scope mentioning such things as the business areas
covered by the project.
The Goals of the Project Business and Solution related.
The key Stakeholders, their needs and expectations.
Priorities for meeting these needs and expectations in case there is a

conflict.
! !15
Key Risks which are foreseeable even at the start of the project.
Project Scope.
Project Schedule.
Project Budget.
Quality Issues.
Resources.
Key assumptions related to the project for instance the client company
shall provide the equipment and office space for the project team or that
project team shall work 5 days a week etc.
A Financial Evaluation of the project this is in terms of cost-benefits of

the proposed project. The success of the project is to be judged by the
achievements of the goals as well as managing the cost-benefit as
outlined in the charter.
Usually the Project Manager is identified at the time of preparing the

Charter so that his ownership of the charter is ensured.
Sponsors Commitment to provide resources.
Sign-off of the charter by all stakeholders, sponsors, management,

Project Management etc to indicate their understanding and willingness
to contribute to the project success.
A well documented and signed off Project Charter provides a good starting
point for a project.
Purpose of Project Charter
Document the project MOV

Define project infrastructure.
Summarise details of project plan.
Define roles and responsibilities.
Show explicit commitment to project.
Set out project control mechanisms.
! !16
1.7 Financial Evaluation of Project Proposals
Managers are continuously faced with several possible projects which are
perhaps equally attractive from a business standpoint. However, resources
whether people or monetary is always limited. Hence the need is to pick up
projects from among the proposals which provide the maximum benefits
for the investments made.
To evaluate a project proposal, managements tend to use one or more of

the following Financial evaluation methods:
Return on Investment (ROI)

Payback Method
Net Present Value Method
Internal Rate of Return Method
A detailed discussion of each of this methods is beyond the scope of this

book an more appropriately covered in a book related to Finance.
However, here is a quick explanation of these methods:
Return on Investments
Any commercial activity requires investments in terms of capital. The

annual outcome expressed as Net profit from doing business with help of
the invested capital is an indication of the return on Investment.
!
Each company has its own criteria for selecting a project. If the usual
returns from business is of the order of 20% for instance the organization
may select a project only if provides an equivalent Return on Investment.
The reason is that it would argue that if the organization were to invest the
same amount in its existing business it would tend to get that 20% return.
Thus, projects which meet this expectation of returns will be taken up for
implementation.
! !17
Payback Method
This is a conceptually simple method to understand and use. If installing a

new machine in the factory at a cost of ` 1 Crore is expected to result in a
higher profit of ` 50 Lakhs per year. This implies that the machine would
payback for its investments within 2 years.
Intangible Benefits
All the above methods help in evaluating the financial attractiveness of a

Project. Indeed many projects in real life are seen as investing for the
future and may not offer immediate returns in a manner that they can be
considered as financially attractive. Many intangible benefits to the
organization, to its, employees or to its business partners such as
customers and suppliers may have to considered before judging a project
proposal. Some of the typical benefits could be:
Customer Lock-In: Customers are so happy with the solution that they do
not wish to switch to another company how can we measure this in
financial terms?
Employee satisfaction.
Ease and convenience of users of a newly implemented system.
Improvement of the companys image in the eyes of the customers.
Increased learning of its employees.
Increased levels of engagement of its employees.
The Project Management team must evaluate these and other benefits of a
project and not merely financial returns while evaluating a project
proposal.
Numerous examples of development projects undertaken by Governments

across the globe prove the value of Intangible Benefits. For instance the
setting up of a Railway service in an hitherto underdeveloped region may
not perse be financial viable and the Government would have to subsidies
the services. However the availability of such transport increases the
movement of goods and people to and fro this region thereby increasing
trade and business. This multiplier effect often gets overlooked at the time
of evaluating the investment and subsidy for such a project.
! !18
Net Present Value Analysis
Net present value (NPV) analysis: method of calculating expected net

monetary gain or loss from project by discounting all expected future
cash inflows & outflows to present point in time.
Projects with positive NPV should be considered if financial value is key

criterion
The higher the NPV, the better
NPV Example
1.8 Project Goals
A project is launched for meeting a specific purpose. We have already seen

that lack of goals or unclear goals is quite often a result for project failure.
It is therefore vital that every project is launched only after clearly
specifying the purpose and goals of the project.
Some examples of a project Goals could be:
! !19
Develop a software solution which will help improve on time delivery of

customer orders from 50% to 90% and Order Cycle time from 30 days to
10 days over the next 2 years.
Manage the Shifting of office to another location in a manner that there

is Zero stoppage in customer services and ease and comfort to
employees.
One point to note about project goals is that there are two parts to these
goals:
It expresses the desired Business Goals or outcomes.

It expresses the derived Technology/solution/product related
expectations.
Many a time Technical Project Managers are willing to accept the latter
aspect of a project goal. Thus, for example if a Leading Bank is planning to
launch a new Web based banking service, it has a business objective to
launch this by a specific date which can beat its competing bank and create
a strategic advantage. To do this would require the development of a
suitable e-banking portal and implement the same well in time so that the
Bank can launch its e-Banking services. The IT Project Manager in such a
case would usually commit himself to the technology aspect of the solution
and not the business side of the goal which is to successfully launch e-
banking services. The IT project Manager will usually take a view that I
shall provide a platform for doing e-banking; the success of e-banking has
to be managed by the Banking Executives.
Increasingly we are faced with such situations and it is only a matter of

time that we realize that the technologist or delivery manager must share
ownership of the complete project goals.
It is, therefore, usual practice that projects in business are usually

sponsored by Business Heads and quite often driven by someone from the
business side as well. This ensures continuous focus on business outcome
and realization of business benefits at the end of the project delivery.
! !20
! !21
1.9 Project Stakeholders
From the foregoing, Business Heads, Business users, the companys

customers are some of those affected by the outcomes of a project. These
categories of people are known as stakeholders of the project.
Stakeholders are people who are either interested in or are directly or
indirectly influenced or affected by the delivery of the project.
Stakeholders therefore tend to have a set of expectations from the project.

These expectations can be in the sense of product/service features, quality
aspects, financial outcomes, conveniences etc.
While some of the Stakeholders tend to benefit by the implementation of a

project some others may have to compromise or may even suffer as a
result of a project. Projects such as, for instance a large dam may generate
power and create a large resource of water for irrigation and other
purposes would tend to provide rich benefits to one set of community. On
the other hand the accumulation of water by the Dam may lead to
submerging several villages and farms gravely affecting another set of
community.
It is therefore necessary to:

Identify who the stakeholders are?
What are their Expectations from the project?
Who are the stakeholders who would lose something due to the project?
What is the impact on them and would they pose any risk to the success
of the project?
What can be done to reduce the impact on these set of stakeholders?

Who are the stakeholders who would benefit by this project?
What would be the benefits?
In case of conflicting requirements between stakeholders, what should be
priority for satisfying different sets of stakeholders?
Stakeholders include:
The project sponsor

The project manager
! !22
The project team
Support staff
Customers
Users
Suppliers
A thorough analysis of stakeholders, their needs, expectations and risks

would help in correctly articulating the Goals of a project.
The Matrix below can be used for conducting a stakeholder analysis:
Stakeholder Relative Expectations Benefit Loss if Any Project Risk

Priority from Project to them to them associated
with these
Stakeholders
Activity B:
2. Using Internet collect information on Project Stakeholders.
1.10 Project Risks
Risks are part of any business and more so in case of projects. Projects as
defined are very large one off and unique endeavours. The magnitude,
the newness of the situation and extraneous factors make projects highly
unpredictable.
It is, therefore, important to identify the risks associated with a project. A

formal Risk Analysis at the start of the project is very helpful. The project
team can then plan for these risks.
! !23
Uncertainty a random chance that something will happen, with no way

to control whether it happens
Risk an uncertain event or condition that could negatively impact

project performance
Each risk has a likelihood, or probability, of occurring and possible

outcomes if it does occur
Risk management in projects involves:
Identifying risks.
Assessing and analyzing the likelihood and impacts of risks.
Trying to reduce the uncertainties (by gathering more information or
making different decisions).
Trying to lessen the impacts of risks.

Developing contingency plans for critical risks.
Monitoring risks as the project progresses.
Risk management consists of 6 sub processes
Risk Management Planning
How to approach and conduct risk management activities
Risk Identification
Qualitative Risk Analysis
Assessing likelihoods and possible outcomes
Quantitative Risk Analysis
Computer simulations; decision tree analysis; etc.
Risk Response Planning

Risk Monitoring and Control
! !24
Examples of typical risks associated with a variety of projects include:
Construction Projects Technical Failures

Availability of key materials such as Steel,
Cement etc or the cost increase of such
material
Software Projects Customer new to technology hence slower
absorption and difficulties in implementation
Developer new to technology risk in
understanding the technology and resulting
bugs in the software etc
New Product Launch Delays in any aspects
Competitor launches identical product before
Shipbuilding Project Delays in Supply of equipment
Labour Strikes etc
Construction of Roads Unexpected rains/storms/ floods
Resistance from local people who may lose
some part of their properties due to acqui-
sition for construction of the road
It is important to assess both the possibilities of each of the risks and their
potential impact on the project time, cost or other aspects such as
operational feasibility etc.
In a customer-supplier relationship, it is vital to have a common

understanding of the risks involved so that should such a situation arise
both parties would already know how the situation would imply and how it
needs to be handled.
Project Risks, however, need a continuous vigil. New risks which had not
been planned for may emerge as much as those which were imagined may
become a reality. It is therefore necessary that the project team remains
alert to any situation which may have an adverse effect on a project.
! !25
1.11 Project Resources
A project to be executed, requires various types of resources. This could

include people resources, material resources, specific tools and equipment
etc.
Planning a project requires due consideration to sourcing and scheduling of

these resources.
Material required for a project, especially if it is imported material may

require a longer lead time for sourcing. Sourcing must therefore be
planned well in advance of the actual requirement of such material.
People resources are vital in most projects. They are also in many cases in
short supply. They also have problems associated with them such
inadequate skill level, absenteeism, low productivity, morale, attrition etc.
Hence planning of people resources is a matter of getting the right person
for the right job at the right time and cost.
While preparing a project schedule a resource schedule also needs to be

prepared.
The purpose of the resource plan is to ensure that the resource

requirement dovetails with the real need for the resource for a specific task
in a project, the correct level of skill and productivity are available for the
duration required.
Resource planning also aims at smoothing the requirement of a resource

type across the project. Thus neither is a resource locked in for a unduly
long duration nor is it allotted work in bursts making it difficult to allocate,
especially from a shared pool of resources.
Each organization also has what is known as a Critical Constraint. Usually

this could be a very large or expensive machine, or a highly skilled person
etc. An expensive welding machine, a Mobile Cement Mixer or a Forklift
crane or a highly skilled Java Programmer could be the examples of such a
critical constraint.
! !26
Planning for these resources amounts to carefully scheduling tasks based

on the delivery considerations + the availability constraints of these key
resources. This is known as Critical Chain scheduling.
Quite often we are faced with exactly the opposite situation i.e. resources
are wasted. For instance the entire team may be waiting because the
clients approval on the requirement or scope of work document is yet to
come or perhaps an important machine has broken down.
Resource optimization and utilization is therefore one of the key aspects of

a project managers tasks.
1.12 Project Costs
A project consists of several tasks. Each task needs resources. Resources

have a cost associated with them. Thus the project costs are sum of the
cost of all the costs associated with each of its tasks. It would also have
several other overhead costs and indirect costs such as the share of the
cost of the salary of the project manager (who may be working for more
than projects at the same time), telephone costs which are perhaps
common for the whole office and not just to one project.
It is usually a practice to prepare Project Budget. The budget has all the
foreseeable heads of costs which the project is likely to incur. There is also
a buffer included in the budget to cover the monetary impact of any risks.
Project Management involves the close monitoring of the costs of a project.

It has been empirically proved through several surveys conducted that
most projects meet with a cost over run which could range from a small
10% to the even a multiple of the original costs.
A project manager must be always aware about the impact of every

decision which he takes on project costs. For instance if he has a review
meeting with 20 of his team members which lasts for 1 full day every
week. This would translate into 20 person days lost per week on review
alone i.e. approx 20 4 = 80 person days per month. Assuming the cost
per work day of a person in this company is ` 1500 the cost of the
meetings would be ` 1,20,000.
! !27
Or for that matter, if he/she delays a particular tasks or delays getting a

sign off on requirements for 1 week for a team of 20 people this would
mean:
1.13 Project Planning
Projects involve one or more of the following:
Large magnitude in terms of time, costs, people, tasks to be performed.
Complex interdependencies between each tasks leading to project

completion.
Risks associated with every element of a project.
A certain degree of uncertainty and newness.
Any human endeavor, for being successful, needs to be planned. Planning,

Directing, Controlling, Coordinating are very basic management concepts.
It is, therefore, necessary that every element of a project must be

planned.
Project planning as an activity covers a very wide range of activities. Some

of the areas which require planning include:
Project Purpose and goals.

Calendar and Schedule.
Work products to be delivered.
Work Break Down Structure which make up the Work Products.
Individual tasks which need to be performed to achieve the Work
products and the purpose.
Risks associated with each tasks and the products and project as a
whole.
Dependencies in each tasks so that the sequence of tasks is as per the

inherent logic thereby focusing attention and resources towards the
correct sequence leading to completion.
! !28
Processes needed and standards required for ensuring good quality of

deliverables.
People Resources such as people of the requisite skills, costs of the right
time.
Material and other resources such as equipment etc required for

production and delivery as required in the project.
Documentation, Training, Implementation activities etc.

Post Implementation activities, warranty etc.
Project Planning is an extremely complex but an extremely important part

of managing a project.
Project Planning is all about Getting in Control i.e. when you know what
is to be done the team as a whole has a better sense of direction and can
give their best. Also to control any activity you need to have a plan in place
with which you can compare.
1.14 Project Execution
Project Execution involves the performance of each of the tasks which form
part of the project. The execution of the project is done with reference to
the Project plan and should result in the creation of the work products or
the services to be rendered.
Execution is in a sense akin to Production. It would involve actioning of

the plan, mobilising the resources every hour/day as per the plan/
schedule, assigning work, tools, equipment and other support information,
guiding and motivating the team to do a good quality work and inspecting
and correcting defects if any so as to deliver completed work products.
The Key terms to note in the context of Project execution are:
Project Plan.
A more detailed schedule (by the hour or day or week etc.).
Work Products.
Design and Drawings and work Instructions.
Tools and other equipment.
Material and other resources.
! !29
Tasks to be performed to achieve the work products.

People assignment to the tasks.
Production and Productivity.
Absenteeism, Breakdowns, Loss of productive time due to any events.
Inspection and control.
Motivating People.
Just as execution without planning makes the project delivery

unpredictable, planning without flawless execution makes the project plan
meaningless. Flawless execution is a matter of rigorous work practices,
discipline and hard work.
1.15 Project Tracking/Review and Oversight
Tracking refers to checking the progress of the project with reference to

the plan. Usually tracking needs to be done very frequently and regularly
throughout the project lifecycle so that the
tasks constituting the project can be controlled on an ongoing basis. It also

gives an opportunity to detect slippage in the project with reference to any
aspect of the plan giving and to take corrective actions.
Project Review is usually done to take an overall assessment of the project

at significant points in a project. A milestone is a significant point in a
project. A milestone could signify the completion of a certain stage in a
project or a certain component/module of the product to be delivered. It
could also at times be defined by the contract.
A review undertaken at a Milestone is generally takes a complete stock of

the project. The review may involve management and sponsors of the
project along with the project team.
Reviews can also have a more specific agenda if there is a reason for such
a focus for the review. For instance, a sudden attrition of key people or a
substantial hike in costs of important inputs or substantial changes in the
product requirements or suspected quality related issues may necessitate a
comprehensive review of one particular aspect of a project in greater
detail.
! !30
The term project oversight is also at times used to denote the process of
continuously monitoring a project.
Project Tracking, Review or Oversight/Monitoring require information about

the project status, specific issues and a forecast about the projects
completion. The quality of the information largely decides the correct
assessment of the status, correct identification of the issues which may be
causing concern with respect to the project and the decisions that follow in
terms of the course of action to take to ensure that the project is back on
its rails.
Just as Planning is a way of getting in control, tracking is a means of

staying in control.
Activity C:
3. Using the Internet collect information on Project Tracking.
1.16 SUMMARY
This chapter deals with overview & basic concepts of project Management
1. Almost any human activity that involves carrying out a non-repetitive

task can be a project. So we are all project managers! We all practice
project management (PM). But there is a big difference between
carrying out a very simple project involving one or two people and one
involving a complex mix of people, organizations and tasks. This has
been true for millennia, but large-scale projects like the Pyramids often
used rather simple control and resource techniques including brute force
to 'motivate' the workforce!
2. The art of planning for the future has always been a human trait. In
essence, a project can be captured on paper with a few simple
elements: a start date, an end date, the tasks that have to be carried
out and when they should be finished, and some idea of the resources
! !31
(people, machines etc) that will be needed during the course of the
project.
3. Reasons for Project failure:
Projects completed late, over-budget, or without meeting the

functionality requirements of your client.
Weak standard processes and techniques used inconsistently by project

managers.
Project management is reactive and not seen as providing value.
The time required to manage projects proactively is not built into the
work plan, since it is considered 'overhead' .
Projects are 'successful' in spite of a lack of planning and project

management, through heavy stress and overtime work throughout the
lifecycle.
Project life cycle is a series of steps necessary to complete a project.

Project life cycles are different for each business area.
Software unlike other Domain is an area which is very nebulous & difficult
to define definitively.
A project delivers a product or services. This breakdown of delivered

product into elemental pieces is known as work breakdown structure.
A project charter is a document, which embodies the project goal & the
commitment of the stakeholders to the project & its outcomes.
To evaluate the project proposal, management tends to use various

financial evaluation methods like ROI, NPV, and Payback etc.
A project is launched with specific goals
Stakeholders are people who are directly or indirectly influenced or

affected by the delivery of the product.
! !32
Prioritise the risks, listing first those, which would cause major problems
and are most likely to happen. This high impact, high probability risks will
clearly need most attention. You may well decide to ignore low probability
low impact risks to avoid cluttering up your risk management process.
Tools which employ risk weighting and which calculate an overall risk score
in an apparently scientific way may add value, but can obscure the fact
that one single risk, which may not even be considered in the tool, can
make the whole project a complete non-starter. Whatever techni-ques you
use to assess, measure and understand the risks - brainstorming,
checklists, tools - remember that the main aim is simply to focus the
attention of those involved in running the project on those things that are
most likely to cause grief or even failure.
A project to be executed requires various types of resources. Planning of

project needs due consideration & scheduling of these resources.
A project consists of various tasks which needs resources. Resources have

cost associated with them.
To others, the Project Plan is simply the schedule that shows who will do
which work tasks and when, and to them Project Planning is the act of
building this schedule.
Here we will use the term Project Planning in this second sense: building
the task-by-task schedule, which we will call the Project Plan.
Tracking and reviewing the actual software accomplis-hments and results

against documented estimates, commitments and plans.
Revising the project plan to reflect actual accomplishments and re-planning

the remaining work to be done and/or taking action to improve the
performance.
Providing visibility into the actual progress so that management can make
corrective actions when project performance deviates significantly from the
original software plans.
! !33
1.17 SELF ASSESSMENT QUESTIONS
1. Explain different methods used for financial evaluation for project

management.
2. What do you understand by work breakdown structure? Illustrate with

examples.
3. What is Importance of Project Charter to stakeholders?
! !34
REFERENCE MATERIAL
Click on the links below to view additional reference material for this
chapter
Summary
PPT
MCQ
Video Lecture - Part 1
! !35
THE PMI FRAMEWORK
Chapter 2
THE PMI FRAMEWORK
Objectives:
The Objectives of this lesson are to give you insight into:
The PMI framework.

Knowledge Areas.
Process view of project management.
Structure:
2.1 The PMI Framework.

2.2 Knowledge Areas.
2.3 Process View of Project Management.
2.4 Summary.
2.5 Self Assessment Questions.
! !36
THE PMI FRAMEWORK
2.1 The PMI Framework
The Project Management Institute, USA is an internationally acclaimed

organization devoted to creation and sharing of knowledge in the area of
Project Management. The Project Management Book of Knowledge
(PMBOK) is a de facto standard on basic knowledge areas and practice of
Project Management. PMI publishes extensive research on Project
management in diverse business domains from construction, engineering,
plant engineering, Software and several other domains. It also offers a
globally recognized Certification programme on Project management which
ensures that a practicing project manager has a specific level of knowledge
about Project Management.
The Project Management Institute (PMI) is an international professional

society for project managers founded in 1969.
PMI has continued to attract and retain members, reporting 2,77,221

members worldwide by August 31, 2008.
There are specific interest groups in many areas, like engineering,

financial services, health care, IT, etc.
Project management research and certification programs continue to

grow.
PMI provides certification as a Project Management Professional (PMP).
A PMP has documented sufficient project experience, agreed to follow a

code of ethics, and passed the PMP exam.
The number of people earning PMP certification is increasing quickly.
2.2 Knowledge Areas
To make it easy to understand the PMBOK divides the entire domain of

Project Management into 9 Knowledge areas. These are:
Project Scope Management.

Project Time Management.
Project Cost Management.
! !37
THE PMI FRAMEWORK
Project Quality Management.

Project Human Resources Management.
Project Communication Management.
Project Risk Management.
Project Procurement Management.
Project Integration Management.
Knowledge areas describe the key competencies that project managers

must develop
4 core knowledge areas lead to specific project objectives (scope,
time, cost, and quality)
4 facilitating knowledge areas are the means through which the
project objectives are achieved (human resources,
communication, risk, and procurement management)
1 knowledge area (project integration management) affects and is
affected by all of the other knowledge areas
All knowledge areas are important!
! !38
THE PMI FRAMEWORK
Project management tools and techniques assist project managers and

their teams in various aspects of project management
Some specific ones include:
Project charter, scope statement, and WBS (scope)
Gantt charts, network diagrams, critical path analysis, critical

chain scheduling (time)
Cost estimates and earned value management (cost)
Super tools are those tools that have high use and high potential for
improving project success, such as:
Software for task scheduling (such as project management

software)
Scope statements
Requirements analyses
Lessons-learned reports
Tools already extensively used that have been found to improve project
importance include:
Progress reports
Kick-off meetings
Gantt charts
Change requests
For each of these knowledge areas it provides a very structured model in

the form of Input, Process and Output. i.e.
What are the inputs required for that knowledge area?
What is the process of transforming input to the output? and

What specific outputs are expected from that knowledge area?
! !39
THE PMI FRAMEWORK
The enclosed diagrams give a snapshot of the PMI framework. The charts
are self explanatory and describe how each knowledge area of a Project
can be managed.
The terms used in the framework are very generic. For instance Project
Scope is a very generic word and not specific to any type of a business
domain. This is what makes the framework very generic and useful for
understanding basic project management principles and processes for
people from various business domains.
To explain how to read each Knowledge area mentioned in the PMI

framework consider the domain of Project Time Management. Project Time
Management involves the identification of various activities to be
performed, understanding their sequence of execution, estimating the
effort and time required for each task and then preparing a schedule for
delivery of the project by laying down the tasks in the sequence.
Each of these processes such as, for instance, estimating the effort of a
task may require a clear understanding of the task, its complexity and
various techniques for effort and time estimate which lead to an estimate
for the task in question.
Each field has its own method of estimation. There are also thumb rules
which are quite often used for estimation effort and time required for a
task. Analogous estimates which depend upon use of available data of
similar tasks performed in the past, mathematical models for estimation
etc are some of the ways to work out an effort and task estimate.
The section on Overview has already introduced most of the knowledge

areas. The PMI framework however provides a useful structure to these
knowledge areas making it easier to understand and relate.
It also delves deeper into each of these knowledge areas and the processes
involved in these knowledge areas as explained above.
It is suggested that readers go through the charts relating to the PMI

framework and understand the input, process and output for each of the
processes within each knowledge areas. It is also recommended that
readers should relate these with their own work area so as to get a better
! !40
THE PMI FRAMEWORK
understanding of these PMI frameworks and its relationship to real life

projects.
PROJECT MANAGEMENT
Project Integration Project Scope Project Time Management
Management
Project Plan Development Initiation Activity Definition
Project Plan Execution Scope Planning Activity Sequencing
Overall Change Control Scope Definition Activity Duration Estimating
Scope Verification Schedule Development
Scope Change Control
Project Cost Management Project Quality Project Human Resource

Management Management
Resource Planning Quality Planning Organization Planning
Cost Estimating Quality Assurance Staff Acquisition
Cost Budgeting Quality Control Team Development
Cost Control
Project Communication Project Risk Management Project Procurement

Management Management
Communications Planning Risk Identification Procurement Planning
Information Distribution Risk Quantification Solicitation Planning
Performance Reporting Risk Response Solicitation

Development
Administrative Closure Risk Response Control Source Selection
Contract Administration
! !41
THE PMI FRAMEWORK
PROJECT INTEGRATION MANAGEMENT

Project Plan Development Project Plan Execution Overall Change Control
1. Inputs 1. Inputs 1. Inputs
(a) Other Planning (a) Project Plan (a) Project Plan

Outputs
(b) Historical Information (b) Supporting Detail (b) Performance Reports
(C) Organizational Policies (c) Organizational (c) Change Requests

Policies
(d) Constraints (d) Corrective Action
(e) Assumptions
2. Tools & Techniques 2. Tools & Techniques 2. Tools & Techniques
(a) Project Planning (a)General Management (a) Change Control

Methodology Skills System
(b) Stakeholder Skills and (b) Product Skills and (b) Configuration
Knowledge Knowledge Management
(C) Project Management (c) Work Authorizatoin ( c) Performance

Information System system Measurement
(d) Status Review (d) Additional Planning

Meetings
(e) Project Management (e) Project Management

Information System Information System
(f) Organizational
Procedures
3. Outputs 3. Outputs 3. Outputs
(a) Project Plan (a) Work Results (a) Project Plan Updates
(b) Supporting Detail (b) Change Requests (b) Corrective Action
(c) Lessons Learned
! !42
THE PMI FRAMEWORK
PROJECT SCOPE MANAGEMENT

Initiation Scope Planning Scope Definition
1. Input 1. Input 1. Input
(a) Product description (a) Product description (a) Scope statement

(b) Strategic plan (b) Project charter (b) Constraints
(c) Project selection criteria (c) Constraints (c) Assumption
(d) Historical information (d) Assumption (d) Other planning outputs
(e) Historical information
(a) Project selection methodes (a) Product analysis (a) Work breakdown
(b) Expert judgment (b) Benefit/cost analysis structure templates
(c) Alternative identification (b) Decomposition
(d) Expert judgment
(a) Project charter (a) Scope statement (a) Work breakdown

(b) Project manager (b) Supporting detail structure
identified/assigned (c) Scope management plan
(c) Constraints
(d) Assumption
Scope Verification Scope Change Control
1. Input 1. Input
(a) Work results (a) Work breakdown structure

(b) Product documentation (b) Performance reports
(c) Change requests
(d) Scope management plan
2. Tools & Techniques 2. Tools & Techniques
(a) Inspection (a) Scope change control

system
(b) Performance measurement
(c) Additional planning
3. Outputs 3. Outputs
(a) Formal acceptance (a) Scope changes

(b) Corrective action
(c) Lesson learned
! !43
THE PMI FRAMEWORK
PROJECT TIME MANAGEMENT

Schedule Control Schedule Development Activity Definition

(a) Project schedule (a) Project network diagram (a) Work breakdown structure
(b) Performance reports (b) Activity duration estimates (b) Scope statement
(c) Change requests (c) Resource requirements (c) Historical information
(d) Schedule management plan (d) Resource pool description (d) Constraints
(e) Calendars (e) Assumption
(f) Constraints
(g) Assumptions
(h) Leads and lags

(a) Schedule change control (a) Mathematical analysis (a) Decomposition
system (b) Duration compression (b) Templates
(b) Performance measurement (c) Simulation
(c) Additional planning (d) Resource levelling heuristics
(d) Project management software

(a) Schedule updates (a) Project schedule (a) Activity List
(b) Corrective action (b) Supporting detail (b) Supporting Detail
(c) Lesson learned (c) Schedule management plan (c) Work breakdown structure
(d) Resource requirement updates updates
Activity Sequencing Activity Duration

Estimating
1. Input 1. Input
(a) Activity list (a) Activity list
(b) Product description (b) Constraints
(c) Mandatory dependencies (c) Assumptions
(d) External dependencies (d) Resource requirement
(e) Constraints
(e) Resource capabilities
(f) Assumptions
(f) Historical information

(a) Precedence diagramming (a) Expert judgement
method (b) Analogous estimating
(b) Arrow diagramming method (c) Simulation
(ADM)
(c) Conditional Diagramming
Methods
(d) Network templates
(a) Project network diagram (a) Activity duration estimates
(b) Activity list updates (b) Basis of estimates
(c) Activity list updates
! !44
THE PMI FRAMEWORK
PROJECT COST MANAGEMENT

Resource Planning Cost Budgeting
1. Input 1. Input
(a) Work breakdown structure (a) Cost estimates

(b) Historical information (b) Work breakdown structure
(c) Scope statement (c) Project Schedule
(d) Resource pool description
(e) Organisational Policies
(a) Expert judgment (a) Cost estimating tools & Techniques

(b) Alternatives identification
(a) Resource requirements (a) Cost baseline
Cost Estimating Cost Control
1. Input 1. Input
(a) Work breakdown structure (a) Cost baseline

(b) Resource requirements (b) Performance reports
(c) Resource Rates (c) Change request
(d) Activity duration estimates (d) Cost management plan
(e) Historical information
(f) Chart of accounts
(a) Analogous estimating (a) Cost change control system

(b) Parametric modulling (b) Performance measurement
(c) Bottom-up estimating (c) Additional planning
(d) Computerised tools (d) Computerised tools
(a) Cost estimates (a) Revise cost estimate

(b) Supporting details (b) Budget updates
(c) Cost management plan (c) Corrective action
(d) Estimate at completion
(e) Lesson learned
! !45
THE PMI FRAMEWORK
PROJECT QUALITY MANAGEMENT

Quality Planning Quality Assurance Quality Control

(a) Quality Policy (a) Quality Management (a) Work Results
(b) Scope Statement Plan (b) Quality management
(c) Product Description (b) Results of Quality Plan
(d) Standards and Control (c) Operational Definitions
Regulations (c) Measurements (d) Checklists
(e) Other Process Outputs (d) Operational Definitions
(a) Benefits/Cost Analysis (a) Quality Planning Tools (a) Inspection

(b) Benchmarking and Techniques (b) Control Charts
(c) Flowcharting (b) Quality Audits (c) Pareto Diagrams
(d) Design of Experiments (d) Statistical Sampling
(e) Flowcharting
(f) Trend Analysis
(a) Quality Management (a) Quality Improvement (a) Quality Improvement

Plan (b) Acceptance Decisions
(b) Operational Definitions (c) Rework
(c) Checklists (d) Completed Checklist
(d) Inputs to Other (e) Process Adjustment
Processes
! !46
THE PMI FRAMEWORK
PROJECT HUMAN RESOURCE MANAGEMENT

Organisational Planning Staff Acquisition Team Development

(a) Project Interfaces (a) Staffing Management (a) Project Staff
(b) Staffing Requirements Plan (b) Project Plan
(c) Constraints (b) Staffing Pool Description (c) Staffing Management
(c) Recruitment Practices Plan
(d) Performance Reports
(e) External Feedback
(a) Templates (a) Negotiations (a) Team Building Activities

(b) Human Resource (b) Pre-assignment (b) General Management
Practices (c) Procurement Skills
(c) Organizational Theory (c) Reward and Recognition
(d) Stakeholder Analysis System
(d) Collocation
(e) Training
(a) Role and Responsibility (a) Project Staff Assigned (a) Performance
Assignments (b) Project Team Directory Improvements
(b) Staffing Management (b) Input to Performance
Plan Appraisals
(c) Organization Chart
(d) Supporting Detail
! !47
THE PMI FRAMEWORK
PROJECT COMMUNICATION MANAGEMENT

Performance Reporting Communications Planning
1. Input 1. Input
(a) Project Plan (a) Communication Requirement
(b) Communication Technology (b) Communications Technology
(c) Constraints (c) Constraints
(d) Assumptions (d) Assumption
(a) Stakeholder Analysis (a) Stakeholder Analysis
(a) Communications Management Plan (a) Communications Management Plan
Administrative Closure Information Distribution
1. Input 1. Input
(a) Performance Measurement (a) Work Results
Documentation (b) Communications Management Plan
(b) Documentation of the Product of the (c) Project Plan
Project
(c) Other Project Records
(a) Performance Reporting Tools and (a) Communication Skills

Techniques (b) Information Retrieval System
(c) Information Distribution System
(a) Project Archives (a) Project Records

(b) Formal Acceptance
(c) Lessons Learned
! !48
THE PMI FRAMEWORK
PROJECT RISK
Risk Response Development Risk Response Control
1. Input 1. Input
(a) Opportunities to Pursue, Threats to (a) Risk Management Plan
Respond to (b) Actual Risk Events
(b) Opportunities to ignore, Threats to Accept (c) Additional Risk Identification

(a) Procurement (a) Workarounds
(b) Contingency Planning (b) Additional Risk Response Development
(c) Alternative Strategies
(d) Insurance
(a) Risk Management Plan (a) Corrective Action
(b) Inputs to Other Processes (b) Updates to Risk Management
(c) Contingency Plans
(d) Reserves
(e) Contractual Agreements
Risk Identification Risk Quantification
1. Input 1. Input
(a) Product Description (a) Stakeholder Risk Tolerances

(b) Other Planning Output (b) Sources of Risk
(c) Historical Information (c) Potential Risk Events
(d) Cost Estimates
(e) Activity Duration Estimates
(a) Checklists (a) Expected Monetary Value

(b) Flowcharting (b) Statistical Sums
(c) Interviewing (c) Simulation
(d) Decision Trees
(e) Expert Judgement
(a) Sources of Risk (a)Opportunities to Pursue, Threats to

(b) Potential Risk Events Respond to
(c) Risk Symptoms (b) Opportunities to Ignore, Threats to
(d) Inputs to Other Processes Accept
! !49
THE PMI FRAMEWORK
PROJECT PROCUREMENT MANAGEMENT

Procurement Planning Solicitation Planning Contract Administration

(a) Scope statment (a) Procurement (a) Contract
(b) Product description (b) Statement (S) of work (b) Work result
(c) Procurement resources (c) Other planning outputs (c) Change requests
(d) Market conditions (d) Seller invoices
(e) Other planning outputs
(f) Constraints
(g) Assumptions
(a) Make or buy analysis (a) Standards forms (a) Contract change control
(b) Expert judgment (b) Expert judgment system
(c) Contract type selection (b) Performance reporting
(c) Payment system
(a) Procurement (a) Procurement Document (a) Correspondance

management plan (b) Evaluation Criteria (b) Contract changes
(b) Statement (S) of work (c) Statement of work (c) Payment Request
updates
Solicitation Source Selection Contract Close- Out

(a) Procurement Document (a) Proposals (a) Contract documentation
(b) Qualified seller list (b) Evaluation Criteria
(c) Organisational policies
(a) Bidders Conferences (a) Contract negotiation (a) Procurement audits

(b) Advertising (b) Weighting system
(c) Independent estimates
(a) Proposals (a) Contract (a) Contract file

(b) Formal acceptance and
closure
! !50
THE PMI FRAMEWORK
Activity A
1. Use the Internet to collect information on PMI framework.
Activity B
2. Using the Internet collect information on Project Scope Management.
Activity C
3. Using the Internet collect information on Project Time Management.
Activity D
4. Using the Internet collect information on Project Quality Management.
2.3 Process View of Project Management
The PMI Framework also presents each of the processes mentioned in the
Knowledge areas in the form of a process view.
PMI considers that managing a project needs a formal process approach.

There are 5 basic processes in Project Management:
! !51
THE PMI FRAMEWORK
Project Initiation
Planning Processes
Execution Processes
Monitoring Processes
Closure Processes
Individual Processes in the Knowledge areas such as for e.g., Identification

of Tasks to be performed, Identification of the correct sequence of these
tasks, estimation of effort and time for each task etc are all examples of
processes within each Knowledge areas.
PMI framework regroups processes from the Knowledge areas into the
above 5 process categories. Thus all processes from various knowledge
areas which having something to do with planning are grouped under
project Planning etc.
Given below is a list of processes under each of the 5 categories:
Also note that these processes are divided into core processes and support
processes within that Process Category. Thus for instance in the Planning
Category Resource Planning is an important core process. However
Organizational Planning at the customer end as well as the service
providers end, the structure, hierarchy, job description etc., are important
support processes.
Process Core Processes Support Processes

Category
Initiating Initiation Initiation
Process
Planning Scope: Quality Planning
Processes
(i) Planning Organizational Planning
(ii)Definition Staff Acquisition
Activity: Communications Planning
! !52
THE PMI FRAMEWORK
(i) Definition Risk Identification

(ii) Sequencing Risk Quantification
(iii) Duration Estimation Risk Response
Development
Cost Estimation
Cost Budgeting
Project Plan Development
Execution Execution Scope Verification
Processes
Quality Assurance
Team Development
Information Distribution
Solicitation
Source Selection
Contract Administration
Controlling Overall Change Control Scope Change Control
Processes
Performance Reporting Schedule Control
Cost Control
Quality Control
Risk Response Control
Close Out Contract Closeout
Processes
Administrative Closure
! !53
THE PMI FRAMEWORK
2.4 SUMMARY
This chapter deals with Project Management Institute (PMI) framework
Project Management Institute (PMI) is devoted to Creation, Sharing of

knowledge in the area of management.
PMI dives entire domain into 9 areas like Scope, Time, Cost Quality,
Human resource, Communication, Risk, Procurement & Integration.
Each of these areas provides a structured model in the form of input,
process, output.
Each of these processes such as for instance estimating the effort of a

task may require a clear understanding of task, its complexity & various
techniques required to complete.
The PMI also presents each of the processes mentioned in the knowledge
areas in the form of process view.
PMI considers that managing a project needs a formal process approach.
! !54
THE PMI FRAMEWORK
2.5 Self Assessment questions
1. What do understand by Project Domain What are 9 areas a project can

be defined?
2. What is structured model of PMI? Illustrate with examples?
3. What do understand by process view of Project Management?
! !55
THE PMI FRAMEWORK
REFERENCE MATERIAL
chapter
Summary
PPT
MCQ
! !56
SOFTWARE PROJECT LIFECYCLE
Chapter 3
Objectives:
The Objectives of this lesson are to give you insight into:
Software Life Cycles

Waterfall Model
Prototype
V shaped Model
Spiral Model
Incremental Model
Rational Unified process
Rational Software Development process
Implication of different lifecycles
Structure:
3.1 Software Life Cycles

3.2 Waterfall Model
3.3 Prototype
3.4 V Shaped Model
3.5 Spiral Model
3.6 Incremental Model
3.7 Rational Unified Process
3.8 Rational Software Development Process
3.9 Implication of Different Lifecycles
3.10 Summary
3.11 Self Assessment Questions
! !57
3.1 Software Life cycles
Purpose:
This International Standard establishes a common framework for

software life cycle processes, with well-defined terminology, that can be
referenced by the software industry. It contains processes, activities, and
tasks that are to be applied during the acquisition of a system that
contains software, a stand-alone software product, and software service
and during the supply, development, operation, and maintenance of
software products. Software includes the software portion of firmware.
This International Standard also provides a process that can be employed

for defining, controlling, and improving software life cycle processes.
Application: Applies to the acquisition of systems and software products

and services, to the supply, development, operation, and maintenance of
software products, and to the software portion of firmware, whether
performed internally or externally to an organization.
The Systems Development Process (Life Cycle)
! !58
Central to all projects is the concept of a lifecycle. A lifecycle is the series

of steps, which need to be taken which leads to the completion of the
project. Software development is a complex process which involves the
following broad steps:
Terms of Reference which initiates the project
A Preliminary Study/Feasibility Study which may lead to a go

ahead for the project
! !59
A Detailed Systems Study which leads to a detailed understanding

about what the present system is, its shortcomings, the business logic
and the transactions involved, the people, roles etc. and purpose of the
system in the context of the organization. The detailed systems study
also includes a phases of Requirements gathering.
A Logical Systems Design which tries to create a conceptual design

of a new system which meets the present day requirements of the users
and the organization, overcomes the limitations of the existing system.
A Physical Design which visualizes the new system in the context of

the real life organization structure, form, the actual process, the
departments involved, equipment used for processing and the location
and other considerations. The physical design of a system gives the
conceptual design a physical form which can be implemented on the
target hardware and for the stated users.
Coding This involves coding of the necessary software programmes.

These are as per the program specifications which are an important
aspect of the physical design. These program specifications mentions the
purpose of the program, the input used, the outputs expected, the
precise logic used for transforming inputs to outputs, the databases
used, the precise controls and checks to be performed etc. The code so
developed has to be tested by the programmer against a set of test
cases which usually represent the real life business situation under which
the program is going to operate. These days apart from the programmer
testing his/her program peers i.e., the programmers colleagues is/are
also asked to test these programmes for functional requirements as well
as for software quality etc.
Integration Testing the individual pieces viz., the programmes have

to work together in order to deliver the complete functionality expected
of a software package. This testing is known as the integration testing
and involves the integration and testing of all the modules and individual
programmes which constitute the software.
Parallel Runs and User Acceptance Testing This test involves

putting the new software system under real life conditions in terms of
data, transactions and actual users. Once the user is satisfied with the
outcome of the system in terms of the processing which it does, other
! !60
performance parameters such as speed, accuracy, etc and the reports

and screens which it has, the user accepts the software. The UAT is done
with life sample data so as to do a reality check on the software.
GoLive Once the user has gained confidence in the system and runs
it parallel with his/her existing systems, he decides to cut off his/her old
system (whether manual or computerized). This switch over is called
Go-Live. This term is more popular in the context of large integrated
applications such as an ERP or a core banking software but could be used
to represent such a condition for any software.
Review This step involves validating whether the software has

achieved the stated purpose in the terms of reference and the
subsequent system study.
The above stages of software development are indicative. Many

practitioners have proposed various steps in a software lifecycles. Further
in a real life software project, there are many more stages apart from the
pure software related steps stated above. Project Charter, Project Planning,
Sizing and procurement of the necessary Hardware and system software,
Intermediate Project reviews, Documentation, Data Conversion,
Codification (i.e. developing codes for various things such as item
numbers, employee numbers etc.,) etc., are all examples of other activities
which are performed as a part of a software project.
List of Activities: This process consists of the following activities:
Process Implementation;
System Requirements Analysis;
System Architectural Design;
Software Requirements Analysis;
Software Architectural Design;
Software Detailed Design;
Software Coding and Testing;
Software Integration;
Software Qualification Testing;
System Integration;
System Qualification Testing;
Software Installation;
Software Acceptance Support;
! !61
The type of stages involved the sequencing of these and the manner in
which the software development proceeds is known as a Software
Lifecycle.
There are various kinds of software Lifecycles. These have evolved with
time and human experience with various situations and various
technologies involved in developing software.
! !62
3.2 Classical Life Cycle/Waterfall Model
This is one of the oldest model for a software lifecycle. This This Model
assumes that the development of software moves from step to step in a
sequential manner. This stepping appears to be like a waterfall. It assumes
that there is no overlap between each
This model assumes that the development of software moves from step to
a waterfall. It assumes that there is no overlap between each stage, nor is
there any backtracking. Thus when we move from analysis to the design
phase it is assumed that the analysis is completed and then we move to
design. There is no possibility of going back from design to analysis.
The advantage of this model is its simplicity. For smaller software projects
where it is easy to grasp the entire requirement, then design and then
! !63
code and implement this offers a simple way of managing the project.
However for larger software projects it is often not possible to study and
grasp all aspects of the requirements and then flow through to design and
implementation. In such cases the Waterfall model is inadequate. In such
projects the requirements of the users are either taken in phases and
implemented or the requirements are evolved over time in the form of a
continuous improvement of the software product. In either case the Water
fall is not representative of the flow of work in these kind of projects.
The Water fall represents the Big Bang approach i.e. we study the entire
requirement, design the entire requirement etc. As explained the Big Bang
approach is not favoured for large projects since it also means higher risk.
Many times a long drawn project also leads to a solution which may
become irrelevant from the users point 2 years down the line when it goes
for implementation. Thus in the present day situation we need a software
lifecycle which can help us quickly deliver solutions and perhaps helps us to
incrementally evolve the solution into a much larger product.
The Water Fall Method does not directly meet this new requirements.
However, at the heart of all even a phased development process as
discussed above, each phase has to flow through a waterfall like lifecycle.
Thus the water fall Model as a concept is still worthwhile to study and apply
in practice as a part of a larger methodology. We will understand this as we
study the other lifecycles.
Activity A:
1. Use an Internet Search engine to collect information on Waterfall Model

for software development.
.
.
Activity B:
2. Use an Internet Search engine to collect information on Prototype
Model for software development.
! !64
3.3 Prototype
The prototype is a mock-up of the final product. In software a prototype

could be in the form of the screens that need to be presented to the user
linked in a way so as to simulate the real software. The benefit of a
prototype are:
It helps the developer as well as the user to visualize how the software
would look like in terms of its interface with the user. The user can check
the use ability and functionality in terms of the fields on the screen the
sequence of the screen etc
A prototype facilitates communication between the user and developer

Once the user sees a prototypes he is able to visualize his/her
requirements better
A prototype is also a means of reducing risk in many complex projects
If the prototype method approach is used along with the extensive use of
generic software Components it is easier to tune the prototype based on
the suggestions of the user and then take it further in to a completed
software. In some cases however this cannot be done and the prototype
has to be then used only as guideline while the actual software has to be
redeveloped
The steps involved in prototyping is iterative. In the sense that a first

prototype is made based on basic requirements expressed. Subsequent
feedback leads to many such iterations which leads to completion of the
project. Thus the lifecycle steps would look quite different and require
different milestones and deliverables.
! !65
3.4 V - Shaped Model
!
The V-Shaped model is an extension of the waterfall model. It involves
matching of an appropriate test phase for each of the stages in the
waterfall model as shown below:
Requirements = System/Functional Testing

High-Level Design = Integration Testing
Detailed Design = Unit Testing
Activity C:
3. Use an Internet Search engine to collect information on Waterfall Model

for software development.
! !66
3.5 Spiral Model
!
The Spiral model combines the benefits of the waterfall Model, the
prototyping methods and is evolutionary in nature.
The software is visualized in the initial prototype after carrying out a proper
risk analysis. Once this level of prototype is accepted, the spiral of
functionality expands into another cycle with its own risk analysis, phase
analysis, and design phases. Thus the software seems to evolve with each
spiral.
! !67
The four quadrants of a spiral:
(i) Planning: Determination of objectives, alternatives and constraints.
(ii)Risk Analysis: Analysis of alternatives and identification/ resolution of

risks.
(iii)Engineering: Development of the next level product.
(iv)Customer Evaluation: Assessment of the results of engineering.
Each iteration involves Four steps:
Evaluate alternatives
Develop deliverables and verify that they are correct
Plan the next iteration
Commit to an approach for the next iteration
The spiral is very useful where the user is and developer are not very clear
about the solution to be evolved.
3.6 Incremental/Iterative Model
The Iterative approach involves growing the same software from a core to
its full functionality.
For example if we were to break up a Sales Branch software into the

following increments:
Take input and Print Invoices
Generate Sales Analysis reports based on the invoice data.

Take input and print Receipts for Payments made by customer.
Generate Account Receivable statements including Aging analysis of
Debtors etc.
The Invoice can update the Stocks and a stock receipt transaction would
create the stock module.
Generate inventory related statements.
! !68
Each of the above increments could be planned, analysed, designed and

implemented in a water fall style. On completion of each increment move
on to the next increment.
Incremental approach to software development involves the breaking up of

the overall software delivery into smaller modules/ deliveries.
The essential difference between the incremental and iterative method is

that iteration improves the existing functionality whereas incremental adds
newer functionality to earlier piece of the software.
Many of the newer methodologies tend to be a mix between Incremental

and Iterative Models.
3.7 Rational Unified Process (RUP)
Rational (now part of IBM) came up with the Rational Unified Process along
with a set of tools to facilitate software lifecycle management.
RUP divides a project into 4 broad phases:
! !69
1. Inception Phase:
Takes about 10% of the effort.
Emphasis on gaining an idea and vision of the product, hence done just
once on the project.
Primarily sequential and non iterative.
Rough estimation of the cost and resources is done.
Important risks are identified and prioritized.
Planning for the Elaboration Phase is done.
2. Elaboration Phase:
Takes about 20% of the effort
Specifies Use cases i.e. gives details of the use cases which need to be
developed. A use case is a series of actions which a user and machine
must take to accomplish a given business task. A use case repres-ents
the dialog/interaction which should take place between a user and
system in achieving a business purpose. Specifying use cases helps in
gaining clarity of the functionality expected as well as the complexity
and estimate of effort and time.
Baseline software architecture is generated Detailed estimation of the

resources and cost is done.
Other tasks in this phase include refining the initial estimates,

reviewing the Software requirement Speci-fication and the use case
model for quality and estimating risks.
3. Construction Phase:

The System is built in a series of iterations and is incremental in
nature.

Refers to the process of developing and testing software.

More of putting the design into action rather than making new design
decisions.
! !70
4. Transition Phase:

Transition is equivalent of implementation in other methodologies.
Although on the face of it RUP may sound like another version of the
Waterfall model it is not so. RUP can be used in an Iterative fashion. Thus
while one set of use cases are being initiated or elaborated another set of
use cases may already be in the construction or transition phases. Thus
there can be overlapped waves of development which leads to the
completion of the software.
The Iterative Model graph shows how the process is structured along
two dimensions
RUP also identifies the core processes which need to be performed through
the lifecycle.
Given below is a mapping between the lifecycle phases and the core
processes which need to be performed during these phases.
Inception Phase: Requirements Management is Dominant
! !71
Elaboration Phase: Requirements and Analysis is Dominant.
Construction Phase: Analysis, Design and Implementation are

Dominant
Transition Phase: Testing and Maintenance Dominant.
Note that there is a provision to perform any of the core workflows in any
stage of RUP, unlike the traditional models.
3.8 RUP Software Development Process Core Processes
Requirements Management: This stage includes 2 parallel phases a

requirement capturing phase and a requirements analysis phase.
Analysis: The specific perspective of the system to be built is captured

here by domain analysis. A series of analysis models (DFDs and ERDs) are
created here. Thus this is more of a functional requirements collection
stage.
Design: This consists of a Preliminary Design and a Detailed Design.
Implementation: This stage consists mainly of coding.
Testing: This stage focuses on the logical internals and the functional
externals of the software, to uncover errors and ensure the desired results.
Deployment/Maintenance
The extensive use of diagramming tools and conceptual models, the use of
Use cases and the fact that all this is amenable to computerization has
made RUP a very popular model among software developers.
3.9 What is the implication of different lifecycles from a

Project Standpoint?
The success of any project depends on the correct choice of the lifecycle.
In the context of IT/Software projects, factors such as:
Users familiarity with technology in general.
Users familiarity with the chosen technology.
The developers knowledge of the business domain, etc affect the choice
of a lifecycle.
! !72
For instance in many of the above situations an evolutionary approach is

useful. The Evolutionary approach would involve a certain set of tasks to be
performed in a certain sequence. Further, evolution requires a gradual
increase in scope and functionality of the software product. This can lead to
unlimited time, effort and cost.
Which is why a concept of timebox is used along with these methods.

Thus the functionality to be delivered in every time box is pre-decided
based on the business priority/need, the risk involved, the size of effort
involved etc. Once the functionality for each time box is fixed it is easy to
judge the effort required and ensure that the required functionality is
indeed delivered by the end of all time-boxes making the project more
controllable.
Life Cycle Processes: This International Standard groups the activities

that may be performed during the life cycle of software into;
Five Primary Processes

Acquisition Process
Supply Process
Development Process
Operation Process
Maintenance Process
Eight Supporting Processes

Documentation Process
Configuration Management Process
Quality Assurance Process
Verification Process
Validation Process
Joint Review Process
Audit Process
Problem Resolution Process
Four Organizational Processes

Management Process: Defines the basic activities of the
management, including project management, related to the
execution of a life cycle process.
! !73
Infrastructure Process: Defines the basic activities for establishing
the underlying structure of a life cycle process.
Improvement Process: Defines the basic activities that an
organization (that is, acquirer, supplier, developer, operator,
maintainer, or the manager of another process) performs for
establishing, measuring, controlling, and improving its life cycle
process.
Training Process: Defines the activities for providing adequately

trained personnel.
3.10 Summary
This Chapter deals with Software project life cycle.
A software system undergoes a several stages in its lifecycle as follows:
Analysis
Design
Implementation
Testing
Maintenance
The Waterfall method suggests that each of above development cycle
should complete before following to next stage
In the Incremental Model, application software is developed stage by
stage in modules
The Spiral model goes through a phase of Analysis, Risk Analysis, design
& coding before moving to next stage
The V Shaped model is extension of waterfall model
The Prototype approach is used for complex applications. Screens are
developed, approved from client & then coding is done
Rational Unified Process (RUP) along with asset of software tools
facilitate software life cycle management
RUP divides a project into 4 phases. Inception, Elaboration, Construction
& transition phase
Maintenance is important phase of SLDC
! !74
1. What do understand by Waterfall model of SLDC? Illustrate with

examples.
2. What do understand by Rational Unified Process Illustrate with

examples?
3. Maintenance is important phase of SLDC Comment.
! !75
REFERENCE MATERIAL
chapter
Summary
PPT
MCQ
! !76
PROJECT PLANNING AND SCHEDULING
Chapter 4
Objectives:
What is project plan, Calendars?

Work break structure, tasks
Task based Estimation
Task dependency
The Gantt chart
Pert/CPM charts
Structure:
4.1 What is a project plan?

4.2 Work Break Down Structure
4.3 Tasks
4.4 Estimating Task Durations
4.5 Object Analysis as a Means of Identifying Functionality and Number of
Programs
4.6 Estimation Techniques
4.7 Task Based Estimation
4.8 Lines of Code Method
4.9 COCOMO Method
4.10 Function Point Estimate
4.11 Overhead Activities
4.12 Task Durations are not Deterministic
4.13 Beta Distribution and Optimistic, Pessimistic and Most Likely Duration
Estimates
4.14 Final Word on Duration Estimates
4.15 Task Dependency
4.16 Graphical Techniques for Plotting the Project Schedule
4.17 The Gantt Chart
4.18 Resource Chart
4.19 PERT/CPM Charts
4.20 Critical Path
! !77
4.21 Project Evaluation Review Technique (PERT)

4.22 Visual Task/Resource Allocation Schedule
4.23 Summary
! !78
4.1 what is a project plan?
IT Planning Process
Project Planning is a very wide ranging term covering various aspects of a

project.
Some of the aspects which are covered include the following:
Project Purpose, Goal and Charter.
Assumptions related to the Project.
Project Calendars.
Choice of Lifecycle, Planning of Quality Processes and quality attributes of

product and processes.
Stakeholders, their needs, requirements, expectations, risks posed by

them.
! !79
Product or service in terms of how the product functions would be

identified and how they would be developed and how would they be
evaluated and accepted.
Major milestones in the project.
A Work Break Down structure, List of tasks.
Estimation of duration for each tasks.
Resources required to carry out the tasks and a plan to source and
allocate these resources.
Outsourcing of Work developing the right kind of business partners who

will deliver the required. subcontracted services reliably and at a time
and cost which gels with the overall project requirements.
Project Schedule indicating what needs to be done, when and by

whom, giving the start date, end date, duration and the dependency with
other tasks.
Identifiable risks and a plan to handle this risk. Supporting Contingency

plans should be the risk actually happen and the responsibility for
executing the contingency plan. Where certain risks, such as for example
attrition or absenteeism can be buffered to certain extent the
necessary buffers should be planned and incorporated in the project plan.
Cost or Budget for the Project indicating the task wise cost estimate
and rolled up to every level in the Work Break Down structure so as to
make it easy for reporting and monitoring.
Organization The Organization structure, roles and responsibilities, the

types of skills required for various tasks, the reporting relationships etc.
The structure at the client/end users end is also to be defined so that
there are equivalent levels for interaction between client and service
provider.
Communication Communication needs to be planned in terms of the

types of information which should be generated by the project
! !80
management office (PMO) and other project team members, to whom

this information should be circulated at what frequency.
MIS The MIS is very vital to monitoring the performance of the project.
The nature of reports, their frequency, circulation etc needs to be
planned so as to ensure that concerned stakeholders are informed about
the progress of the project.
Physical and Technology Infrastructure The space required and the

equipment required for people to work.
The list is only indicative and there are several aspects which need to be
planned some of which are domain specific while some could project
specific. For instance in case of a mass implementation of a software
products across 50 branches of a company for instance, the selection of a
suitable site (i.e. branch) for the pilot or first implementation is also to be
planned. Likewise the physical site where the hardware is to be installed
needs to be planned. However many of these items would form part of the
task list prepared for the project.
We have already discussed some of the above aspects in other sections

viz:
Purpose, Charter, Goals etc.

Risks
Stakeholders
Let us take a closer look at the other common aspects of Project Planning
and understand the various situations which one should expect while
planning these aspects.
Project Calendars:
The Project Calendar ensures that there is a consistent understanding

about each work day for the project.
All date calculations would be with respect to this common calendar.
Organisational Assumptions such as 5 days a week with Saturday and

Sunday.
! !81
Holidays can be marked on this calendar.
In case the project is to be implemented across multiple locations,

multiple location specific calendars would have to be made for each
implementation plan.
In case part of the work is being done at several different locations, the
calendars at each location need to be made assuming the work is
independent leaving some days for synchronizing work across all
locations.
Where the client is located abroad in another time zone date and time
differences need to be considered in the calendars. The calendar can be
local to place where the work is being done. However the dates should be
interpreted for the clients ease of understanding so that he can relate it
to his own work calendar.
A schedule for a project cannot be prepared unless the calendar is first

defined
Project Planning Framework
! !82
Types of Project Plan
Plan Description
Quality plan Describes the quality procedures and standards
that will be used in a project.
Validation plan Describes the approach, resources and schedule
used for system validation.
Configuration Describes the configuration management
management plan procedures and structures to be used.
Maintenance plan Predicts the maintenance requirements of the
system, maintenance costs and effort required.
Staff development Describes how the skills and experience of the
plan. project team members will be developed.
4.2 Work Break Down Structure
The Work Break Down Structure is a break down of the project-product

into a hierarchy of components and sub-components which together would
lead to the completed product. The break up helps in the following ways:
It gives a sense of architecture to the product so that when the project is

under execution, the Project team is able to link the products from one
task to those coming from other tasks thereby leading to a completed
product.
It helps in visualizing the minutest steps or tasks required to be

performed which will lead to project completion
The visualization of tasks makes it easy to estimate the duration of these

tasks, identify the dependency of one task on the other. In effect it
becomes possible to estimate the effort and time required to deliver the
complete product or service.
Visualisation of tasks also makes it easy to identify the kind of skills

required for them. Hence we can calculate the type and quantum of skills
! !83
required across the project. This helps in sourcing of the right skills at
the right time as per the schedule of the project.
Allocation of work and organizing the team also becomes easy. Since
each component of the product is to be developed independently, the
project team can be divided into smaller groups with its own group
leader and can consist of the required skill mix.
The Work Break Down Structure is also drawn up based on the Delivery
priority, i.e., which part of the product of the project should be delivered
first and by when etc. Thus stage wise release can be planned.
Many a times commercial considerations such as stage wise payments

agreed with the customers also serve as a driving motivation for the
WBS. Thus work products which will generate revenue will be released as
per the commercial schedule.
The key to writing a good WBS is to decompose the project goal into
major activities.
Then keep breaking those activities down until you get to the smallest
level of tasks mentioned earlier.
A WBS with too much detail is time consuming to generate and follow.
not enough detail, and you miss important tasks.
Finally allocation of costs to each level and structure of the WBS helps in
monitoring the costs of the project.
If writing this book is considered a project the break up of the book into
sections, chapters and topics helps in organizing the thoughts, planning
releases of one chapter at a time for editing and other further processes.
The organization of the chapters is also customer focused in the sense they
are designed to make it easy for the target reader to understand the flow
and content.
Why Create a WBS?
The WBS helps plan out the process needed to accomplish the project.
! !84
It also helps design the architecture of the project.
It forms the basis for estimating the time and effort needed for the
project.
It establishes a baseline for reporting project status.
Generating a WBS
There are two basic approaches to generating a WBS
Top-down.
Start at the project goal, and keep breaking down activities until you get
to the smallest task needed.
Can use the Team approach (have everyone work on the schedule
together) or
The Sub team approach (agree on level 1 activities, then have

subteams tackle each activity in detail; then check for duplication
and missed tasks).
Bottom-up
Agree on the top level activities using the top-down approach.
Then break into teams and brainstorm all the activities you think are
within that overall activity.
Organize the activities, and check for missed tasks and

redundancies.
Often the top-down approach results in a more complete draft WBS.
Defining a WBS is thus an engineering task as much as it is grounded in

business reality.
! !85
4.3 Tasks
The WBS leads to an identification of individual tasks. For Instance for

constructing a building some of the tasks could be:
Leveling the ground.

Piling (digging deep pits).
Constructing the wire structures for the foundation
Laying the foundation and constructing the plinth
Etc.
It is important to correctly name the task so as to eliminate confusion.
Especially since many a times similar tasks are found at different stages of
the project. For instance laying the slab is a task which will appear for
every floor to be constructed. Hence for large projects it may be a good
idea to number the tasks with a number which is a structured code which
can identify the task to the phase, stage, portion of the WBS etc.
While codifying the tasks apart from unique identification as stated above it
is equally important to be able to quickly identify tasks which are similar in
some way. For instance to extend the above example it should be possible
from the task number or some other identifier to quickly get a list of all
tasks which pertain to placing a cement Slab.
Grouping tasks in this manner would help in identifying common tools,

specifications and skills and other resources which may be required.
4.4 Estimating Task Durations
The next step in working out a project schedule is to estimate the time and
effort required for each tasks forming part of the project. Each task
requires to be performed by a person with a specific skill.
Estimation of task duration and effort can be done in one of the 2 ways:
A ground up estimate where the task is spilt into elemental activities and
the sum of the effort or time duration of each activity gives the effort or
time for the task
! !86
Empirical Models For instance in software a model called Function

Point is used to compute the work content involved in developing a
software based on certain product attributes such as the number of
inputs to software, the number, outputs, number of files accessed etc.
Such models can be developed after studying a vast amount of past
data. These models help in sizing the project or task.
For instance, constructing a 10 feet by 10 feet wall would require the laying
of perhaps 200 bricks of 6 inches each. The time required for laying each
brick could be more reliably and easily estimated. Multiplying this by 200
bricks adding a safety factor to recognize the difference in complexity in
laying a brick at the first layer to the final layer would give the total man
hours required to complete the brick wall.
Once the basic work content is estimated, this could be converted into time
depending upon the number of people who are deployed for the task. Thus
if two people were to be placed for the wall construction, the time required
would be roughly half the time required by the single person.
To estimate how long it would take to write this book, it would be

necessary to break the book into Sections, Chapters, Topics. It would also
help to write the complete Table of Contents and find topics and chapters
which seem to have similar level of complexity and to estimate the number
of pages required for each topic. Thus there could be simple, medium and
complex chapters/topics. A judgement of the man hours required for
writing a simple, medium and/or complex page need to be measured or
estimated. With this elemental estimate it would be possible to compute
the time required to write the book with say 30 simple, 100 medium and
30 difficult pages. The definition of what is simple, medium and difficult will
depend on the domain. For instance in the context of the book it could be
complex diagrams or reference charts etc could constitute a difficult page.
The best strategy for working out the Task Duration estimates is to use the
Principle of Divide and Conquer i.e. break up the task to an elemental
level where the duration or work content can be easily perceived.
Estimation of Effort, Time and Cost in Software Projects:
Each domain has its own way of estimation. Estimation techniques in

software have evolved over time.
! !87
The difficulties in estimation in software arise primarily due to the nature of

software. Elsewhere it was mentioned that software is a wicked problem.
Software defies specific and clear definition, is very difficult to know, when
one has reached it and is very difficult to ensure completeness of testing of
software.
For the same application such as say inventory or accounting, the scope
and size of the software required for a small trading firm to a large
conglomerate varies greatly. Thus for estimating the size of a software
project many more factors beyond the basic functionality needs to be
understood.
4.5 Object Analysis as a Means of Identifying Functionality

and Number of Programs
In order to break down a customer requirement into software programs

one of the best ways is to apply object analysis. In this we assume that
any process or business is an object which responds to a wide variety of
business events. The purpose of designing a software is to ensure that the
software helps to organization in providing an appropriate response to any
given business event.
Thus for instance some of the events in a typical sales system could be:
A customer seeks information about products offered, prices, delivery

etc.
A customer negotiates various items such as price, delivery etc.
A customer places an order.
An order needs to be fulfilled over the next 6 months as per delivery
schedule given by the customer.
The first 3 months delivery schedule is firm, which the next 3 months
delivery schedule would be notified later.
Customer changes the delivery schedule.
Customer changes the overall quantity required i.e., either increases it
or decreases it.
Customer needs to cancel the order (perhaps accepts penalty).
! !88
From the above it is obvious that the business faces these specific
situations. Each of these situations known as Business Events requires that
the business should respond in a particular manner. The response is
therefore based on certain business rules. While the actual response is a
process which needs to be followed to handle the situation.
When we develop a software to meet the above requirements, we need to

have programs which can handle each of the above situation and offer the
variety of responses required by the organization as per the business rules.
Thus for instance if a customer cancels an order there could be 2 types of
responses for a regular and high value customer we may allow
cancellation without penalty while for a one-off customer we may levy a
penalty for cancellation. Thus we need 2 programs to address the business
event of cancellation.
Thus for estimation of the software requirements it is essential to make a

list of all possible situations such as those described above which the
business may have to respond to. Software specification is thus a
documentation of all such situations which a software is expected to handle
and the specific manner in which it should respond based on the business
rule and the procedure for handling the situation which the user should
describe.
The list of such events and the corresponding responses gives us a list of
programs required.
To get into more detailed list of programs we next have to view the entire
business as composed of several objects for instance, the Enquiry, Order,
Delivery, The product, Customer all are examples of objects. If we focus on
each object at a time and list out the various possibilities in real life which
may in any manner affect the object we get a fairly accurate list of
programs which we need to have to meet these situations.
For instance if we focus on customer as an object what can imagine the

following:
The customer is a first time customer.

A customer is a repeat customer.
A customer is also our supplier.
A customer is no longer our customer.
! !89
A customers information has changed such as his name, address etc.

A customer has added more locations for delivery.
Etc.
Thus we can now imagine the list of possibilities each requiring a suitable
program to handle it.
If we do this for all the objects we will have a fairly long list of programs
which need to be developed.
The method of handling each such business situation would have to be

discussed with the user to understand its complexity.
4.6 Estimation Techniques
Once we are equipped with a list of possible functionality and therefore the
broad list of programs required to address this functionality we can use
some of the popular methods for estimating the size of the software to be
developed:
Some of the common ways of estimation of software size and effort are:
Program Complexity Method also known as a Task based Estimate

Lines-of-Code Method
COCOMO Model
Function Point Analysis
Activity A:
1. Use an Internet Search engine to collect information on Project

Estimation Techniques .
! !90
4.7 Task Based Estimation
The task based method seeks to at first classify the various programs
required to be delivered as above. Each program based on its complexity is
classified as either simple, medium or complex. Once we get a count of the
number of simple, medium and complex programs we multiply them by a
weighting factor which converts all programs into simple. Thus for instance
we could have a weight of 2 for medium programs. This is to say that a
medium program is two times more complex than a simple program. Like
wise if we assume that the complex programs are 5 times more complex
than the simple programs.
Thus if we had 5 simple, 10 medium and 10 complex programs we would

have:
5 + 10 X 2 + 10 X 5 = 75 program units of simple nature.
We next have to associate time to each of the simple programs. From

experience or past data we may have seen that each simple program takes
1 day of work from coding to unit testing. Thus 75 simple programs would
take about 75 man days of work which @ 25 days per month would
translate into 3 man months of effort.
The time required to delivery this would vary depending on the number of
resources and the productivity.
Assuming that productivity is 75% and there are 6 people put on the
project the elapsed time from the start date would be:
= 3 man months/6 people = 0.5 months at 100% productivity
= 0.5/0.75 = 2/3 = 0.667 months at 75% productivity
The cost estimate can be worked out as effort in man months rate of
resource. If the cost of the resource per man month is ` 50,000/- the cost
of the project at 100% productivity = 3 50,000/- = ` 1. 5 Lakhs.
! !91
4.8 Lines of Code Method
The lines of code method assumes that the effort in programming is

proportionate to the number of lines of code. This is particularly suitable
for maintenance of projects where the software already exists and it is
possible to estimate or even measure the number of lines of code to be
maintained.
Thus we can associate an effort and cost to a certain number of lines of

code. For instance the effort per 1000 lines of code could be x man days or
man months.
One of the best example of use of this method was during the Y2K
maintenance work. All quotations were also expressed in terms of 1000
lines of Y2K bug fixing.
This method is however not suitable for new development projects since
we may not be able to estimate the number of lines of code required.
Lines of code is also fraught with problems such as:
Should blank lines in a code be counted or not.

Should comments written in a program be counted or not.
Should certain definitions and declarative statements be counted.
How do we count the lines in case of re useable code which is shared by
a number of programs?
4.9 COCOMO Method
The COCOMO method is a cost based estimation technique. It is based on

empirical research which has resulted in a set of formulas which can be
used to estimate the size and effort depending on certain empirical
parameters. The formula are as follows:
Basic COCOMO
E = Ab(KLOC)exp(Bb)
D = Cb(E)exp(Db)
! !92
Software Project Ab Bb Cb Db
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
Value of coefficients and exponents for Basic COCOMO Model Cost Driver
Attributes for COCOMO:
Product Attributes
Required Software Reliability.

Size of Application Database.
Complexity of the product.
Hardware Attributes
Run time performance constraints.

Memory constraints.
Volatility.
Required Turn around time.
Project Attributes
Use of Tools.
Software Engineering Methodologies.
Required Development Schedule.
Personnel Attributes
Analyst Capability.
Software Engineer Capability.
Application Experience.
Machine Experience.
Programming Language Experience.
Each attribute is rated on a 6 point scale.
Effort Multiplier for each rating from Boehm Tables.
Multiply all effort multipliers to arrive at Effort Adjustment Factor (EAF).
! !93
Thus depending on the choice of parameters and the various cost driver
attributes and effort estimate can be worked out.
A detailed discussion on the COCOMO model is beyond the scope of this

book.
4.10 Function Point Estimate
Function point is perhaps one of the most discussed methods for

estimation. The IFPUG which is the International Forum for Function Point
has documented the method in great detail and Function Point counting is
fast becoming a science.
A step by step calculation of function point is shown below:
Step 1: Compute the Function Counts
External Inputs
External Outputs
Enquiries
Files
Interfaces
Step 2: Arrive at Processing Complexity
Complexity Factors are fixed

Complexity Measures
0 No Influence
1 Insignificant
2 Moderate
3 Average
4 Significant
5 Uniformly strong Influence
! !94
Categorized as Simple, Average and Complex
Complexity
Description Simple Average Complex Total
External Inputs 13 74 06 31
External Outputs 34 55 37 58
Inquiries 43 14 06 16
Master Files & DBs 10 7 1 10 0 15 80
External Interfaces 15 17 0 10 12
Total Unadjusted Function Points (FC) = 197
Step 3: Compute the Adjusted Processing Complexity
PCA = 0.65 + (0.01*PC)

PCA can vary between .65 and 1.35
PCA = 0.65 + (.01*45) = 1.1
Step 4: Compute Function Points
FP = FC * PCA
FP = 197 x 1.1 = 216.7
Complexity Factor Complexity Measure

Data communications 3
Heavily used configuration 4
Transaction rate 4
End user efficiency 2
Complex processing 2
Installation ease 4
Multiple sites 3
! !95
Performance 3
Distributed processing 3
On-line data entry 5
On-line update 4
Reusability 2
Operational ease 5
Extensibility 1
(Total) Processing Complexity 45
Step 5: Translate Function Points to Effort based on history data:
Work-Hours = 216.7/0.2 = 1083.5 hours
To summaries Function point:
Calculate the basic or unadjusted function points based on the number of

inputs etc.
Classify the function points based on simple, medium and complex.
Compute a weighted un adjusted function points.
Compute the adjustment factor by giving scores to each of the risk

factors mentioned.
Compute modified function point.
Use productivity expressed as no. of function points per month to

calculate the effort in man months.
4.11 Overhead Activities
Apart from the basic work in many projects there would be effort and time
required for certain overhead activities which form a part of the task
completion. For instance a task level inspection or quality check, loading
! !96
and unloading activities in case of processing machines etc could be

examples of such overhead activities. Even information related activities
either prior, during or after the task is over, are also overhead activities.
For instance in call centers after a call is answered the agent has to write
the outcome and other details of the call. While the person is writing this
the person is not available for handling other calls. Hence Call handling
time include the actual call duration + the time required for such overhead
activities.
Projects also involve several such overhead activities. This could include
task planning, work allocation, task inspection and task reporting, Time
sheet etc. To the extent these activities relate to the task at hand the
effort, time and cost of these activities should be allocated to the task.
4.12 Task Durations are not Deterministic
All natural phenomena such as height of people, weight of people etc. tend
to vary and follow a statistical distribution called the Normal distribution.
Like-wise task durations are also not absolute numbers and they tend to
vary depending on numerous factors affecting them and the project as a
whole.
For instance some of the factors which may affect the actual duration
versus the planned duration are the skill level of the people actually
deployed, breakdown of equipment, power outages and other such
environmental factors etc.
Thus Task Durations have to be probabilistic and must therefore follow

some statistical distribution. Task Durations tend to follow the Beta
Distribution. The Beta Distribution is a skewed Distribution.
4.13 Beta Distribution and Optimistic, Pessimistic and Most

Likely Duration Estimates
If you were asked to estimate the time it takes to come from the Dadar
Station in Mumbai to the Welingkar Institute at Matunga, (Mumbai). Under
ideal conditions, when there is no traffic and you manage to get a cab
easily at the station, most people would tend say anywhere between 10 to
12 minutes. Thus the probability or the estimate of various people under
! !97
ideal circumstances tends to be very close (i.e. hardly a 2 minute

difference). This is in Project Management Terminology is known as the
Optimistic Estimate of the Duration. Hence one side of the curve tends to
be very small at the base since every one seems to have a very similar
estimate.
On the other hand if the same set of people are asked to estimate the
pessimistic estimate the answers tend to vary greatly depending upon each
person experience. For instance during the July 26, 2005 Floods recently,
the road from Dadar Station to Welingkar Inst. was completely flooded.
Hence a person who may have experienced this would aver that in the
worst situation a person may never reach the institute! Thus the duration
would be virtually infinite. Most others however would remember their
experience of traffic jams or not getting a cab on time or not getting cab at
all in which case they may have had to walk it down. Hence their estimates
could vary from 15 minutes to half an hour or even perhaps 45 minutes.
From the foregoing it would be clear that when we estimate durations as

well as when the work is actually be carried out the duration tends to vary
greatly on the worst case side but is the spread is much less on the
optimistic side. This explains the skewed nature of the curve used for
Duration estimates.
In practice, 3 types of duration estimates are taken:
Optimistic Estimate
Pessimistic Estimate
Most Likely Estimate
To arrive at these estimates, the best practice is to use the Delphi

Technique. The Delphi Method involves seeking independent guesstimates
from experts from that domain. These estimates can then be discussed and
crystallized to work out the estimates.
If the experts provide the above three types of estimates for a task
duration we can find a weighted average of the duration using the
following formula as given in PERT technique (to be discussed in
subsequent topics):
! !98
Since duration estimates vary statistically, we also need to calculate the

standard deviation i.e. the variation of an estimate around the mean or
average.
!
Thus every task in a Project plan would have a Average Duration (d) with a
standard deviation (Sd).
Thus for instance if the 3 duration estimates for the travel from Dadar
Station to Welingkar institute are provided by students and staff who travel
the route regularly (who are therefore experts from that domain):
Optimistic time = 10 minutes

Pessimistic time = 30 minutes
Most likely time = 20 minutes
The average time for this task is d = (10 + 4 20 + 30)/6 = 120/6

= 20 Minutes
This is subject to a standard deviation, Sd = (30-10)/6 = 3.33
4.14 Final Word on Duration Estimates
There is a tendency to pad up task durations at every level of an

organization. This is human nature. Thus if you are asked when you would
be able to deliver a particular project/assignment you would like to be
viewed as successful and would there would like to succeed in delivering
the assignment. The natural tendency would therefore quote 1 week for a
task which perhaps could be done in 1 day.
In an organization, with several levels, each person tends to pad up

estimates before committing to the next level. Thus imagine the situation
that a task which is worth just 1 day may end up being quoted at 1 week
depending on the number of levels in the hierarchy.
The top management then realizes this behavior and develops the
tendency to cut down the target time of any task by 30-40% assuming
that people below would have padded it anyways.
! !99
This creates a vicious cycle of padding and arbitrarily slashing the task and
project durations which can sometimes lead to un realistically tight
timeframes leading to delayed delivery or even project failure due to
mistakes made due to the excessive pressure.
It is therefore important to create a culture of transparency where both

management and the project team understand and appreciate that the
duration estimates given are Pure estimates and are subject to normal
stochastically/statistical variation. Such a culture leads to better control
over projects and generates greater motivation among the project team
since they feel committed to realistic estimates.
4.15 Task Dependency
The next step leading to preparing a project schedule is to understand the

interdependencies among tasks. The sheer nature of the work necessitates
that the tasks be performed in a certain sequence. This is task
dependency, i.e., the subsequent task cannot begin unless the previous
task is not over.
In practice several types of dependencies may exist between two tasks A

and B (assuming B is the subsequent one)
B cannot begin before A is complete

B can begin only if A has commenced
B can begin only if A is completed upto %
Etc.
However for most tasks the first case seems to apply.
It is advisable to prepare a task list showing dependency and durations as

follows:
Task Preceding Optimistic Pessimistic Most Avg Std

Task Duration Duration Likely Deviation
! !100
4.16 Graphical Techniques for Plotting the Project Schedule

Considering the complexity and number of tasks involved in real life
projects it is difficult to work out a schedule in the form of a tabulation as
above. Graphical techniques have therefore been evolved.
As they say a Picture is worth a thousand words a graphical

representation of a Project schedule facilitates understanding. Further with
the use of computers it is far more easier to construct, modify, scroll and
plan a large project schedule which is graphical.
The following graphical techniques are used very frequently in Project

Management:
Gantt Chart
Resource Chart
PERT/CPM Diagrams
Visual Work Allocation Charts
4.17 The Gantt Chart
This diagramming method is used not just for a Project but for any
scheduling, be it machine scheduling or order scheduling in manufacturing.
It is very simple and intuitive for people to draw and follow. Given below is
an example of a Gantt Chart.
! !101
The Gantt Chart above, shows various tasks against the time schedule in
Months. The interpretation of the chart is obvious, however it is explained
below for the sake completeness:
The project starts with the Task called Analysis.
There after (indicating dependence on Analysis being completed),

development of 4 modules of the software are started in parallel. The line
representing the first and the last modules are smaller than the other
two modules.
The - - - - lines indicate there is some float or slack available for the
smaller two tasks.
Since the project schedule depends on the tasks with the longest
Duration this is known as the Critical Path. The Critical Path in the
above chart consists of the Analysis of the 2 Parallel Longer duration
Modules and the final task of integration and testing. The Critical Path
must be managed well to ensure that the project completes as per the
schedule.
Resources employed for each task can be marked on top of the Task line
itself.
Activity B:
1. Use an Internet Search engine to collect information on The Gantt

chart .
4.18 Resource Chart
Assuming that in the previous Gant Chart
Analysis requires 4 People,

Developing of the programmes for each of the larger modules
takes 4 people.
Also Developing the smaller modules takes 2 people each.
! !102
The resource chart for the above Gantt Chart would appear to be as
follows:
!
The above chart is a resource allocation chart. The following are the salient
points to note:
For most projects, the resources tend to begin with a small team.
The core activity such as programming in Software, or cement and brick

work in construction requires a large team. Thus the resource level peaks
up and stays that way for several weeks or months.
Finally as each module or sub-project begins to get over the resources

are freed up and either transferred to subsequent tasks or released. As a
result the resource levels start dropping.
Finally for the integration and implementation phases fewer people are
required just as in case of construction fewer people are required for
finishing work.
The resources could then either become zero or may be at a minimum

level to take care of maintenance work.
! !103
The resource chart is vital for Project Planning and correlates with the basic
project schedule. If the resources are not likely to be available as per the
required schedule or the peak requirement of resources cannot be met due
to some reason the Project Manager does what is known as Resource
Levelling.
Which means the Project Manager alters the Project Schedule by placing
some of the parallel tasks as sequential tasks so that the resources from
one module can be moved to the next one on completion of the previous
module. This reduces the Peak resource requirement.
Resource Levelling may also be required so that the resources primarily

people who are employed can be provided employed on a continuous basis
rather than as contract labourers for a project on a need basis.
4.19 PERT/CPM Charts

These charts use two concepts viz. Nodes and Arrows. The diagrams can
be drawn either as:
Activity on Node Diagram.

Activity on Arrow where the node only serves as a point of connection for
two successive Activities (arrows).
In case of Activity on Node Diagram Each Node Indicates an Activity or
Task
! !104
In case of Activity on Arrow Each Arrow Indicates an Activity
Each Activity has a Duration
In addition the following parameters are calculated for each task/activity
Earliest Start Date (ESD) Is the earliest possible date/time when

the activity can begin. For instance if the previous activity ends today
the subsequent activity will have an EST whose date is that of
tomorrows date.
Earliest Finish Date (EFD) Assuming an activity begins at the

Earliest Start time, the earliest that it can get over is after its duration.
For instance if the EST of an activity is tomorrows date and the
activity has a duration of to 7 days or 1 week, the EFD = ESD + 7
Days
Latest Start Date (LSD) This is the latest date by when the Activity
MUST begin else the project will get delayed
Latest Finish Date (LFD) This is the date by which the activity
MUST end else the project will get delayed.
Calculating ESD/EFD/LSD/LFD:
Consider the following project:
Assume that we have a Network diagram with Activities/Tasks shown as

arrows and the nodes are A, B, C, D, E & F. Also assume that the start date
is taken as Day Zero. Also all the parameters are expressed in terms of day
number rather than actual dates.
! !105
The Forward Pass
Let us start from the first task and move towards the last task using each
path and find out the ESD and EFD.
Task Preceding Duration Earliest Start Earliest Finish

Task (days) (Day no.) (Day No)
A-B (A and B __ 5 0 0+5 = 5

are Nodes)
B-C A-B 10 5 5+10=15
B-E (parallel to A-B 10 5 15+5=20

B-C-D-E)
C-D B-C 5 10+5 =15 20+5=25
D-E C-D 5 15+5=20 25+5=30
E-F D-E & B-E 5 Max (20,15) = Max (20,30) +5 =

20 35
Note the following points:
The Path B-C-D-E is parallel to path B-E
The Earliest start date is taken as the day after the Earliest Finish Date
by adding 1 to the day number of EFD.
Since path A-B-C-D-E (20 Days) has a greater task duration than A-B-E
(15) the earliest date that task E-F can begin depends on the completion
of A-B-C-D-E. Hence the larger of the two day numbers i.e. 20 and 15 =
Max is 20 is taken.
The Earliest Finish Day for the whole project is represented by the path
A-B-C-D-E-F = day number 35.
Path A-B-C-D-E-F is called the Critical Path since the Project duration
directly depends upon the duration of this path.
The Project Manager Must control tasks on the Critical Path. Very closely.
! !106
Path A-B-E-F is non-Critical. The duration of the path is only 5+10+5 =

20 Days. The Tasks A-B and E-F are common to both the paths. Thus
there is a slack of 10 days in the path B-E i.e., even if the activity B-E is
started late by upto 10 days it will not affect the overall project
completion date.
Backward Pass:
In order to find the Latest Start Day and Latest Finish Day we will use the
Backward Pass i.e., we will begin with the Earliest Finish Day as calculated
in the forward pass viz day 35 and treat it as the Latest Finish Day or a
target day if it has been given for the last activity viz E-F. We next subtract
the duration of the activity from the Latest Finish Day and to arrive at the
latest Finish of the previous activity.
Task Preceding Duration Latest Start Latest Finish

Task (Days) date
E-F 5 30 35
D-E 5 25 30
B-E 10 20 30
C-D 5 20 25
B-C 10 10 20
A-B 5 5 Min (20,10) = 10
Note the following Points:
The Sequence of activities has been reversed starting with E-F and
ending in A-B. This is to make it easy to calculate for the backward pass.
The Latest Finish is the same as Earliest Finish in this case. However in
practice these could be different. Suppose the Latest Finish is provided
by the client and assuming the date of latest finish is higher than the
Earliest Finish Date you would have some flexibility in finishing the
project. i.e., the project could get over anywhere between the earliest
finish and latest finish or target date in this case. Hence we can say there
is some end project time - buffer available in the project.
! !107
While working out a schedule is always a good idea, to provide some end
project time buffer i.e., take the target date, leave a few days/weeks as
the case may be from the end and plan activities prior to this date. This
is known as Backward planning.
You will note that the path A-B-C-D-E-F is much longer in duration
compared to the path A-B-E-F. Since A-B and E-F are common to both
the paths we can say that the activity B-E has a certain amount of float
i.e. the activity B-E can either start as per the earliest start date of 5 or
start as late as day no. 20 (from above table). Thus it has a natural
freedom of around 15 days to start.
Like wise the activity B-E can either end earlier as per the earliest Start
day 15, or end as late as Latest Finish Day i.e., Day no 30. Thus it has a
natural freedom of around 15 days.
Slack time or float gives the project Manager the opportunity to

distribute the tasks so as to balance the resource requirement.
4.20 Critical Path
The Path with the longest duration is called the Critical Path. In this case
there are two paths:
A-B-C-D-E-F duration = 30 days

A-B-E-F duration = 20 days
Hence path A-B-C-D-E-F is called the critical path. This is because even if
the path A-B-E-F is delayed by a few days the overall project duration will
not be affected however if the path A-B-C-D-E-F is delayed even by a
single day it would delay the project.
Project managers are most concerned with guarding the critical path, i.e.,
they must devote maximum energy and care in controlling each of the
activities which constitutes the Critical Path.
Non-Critical Paths such as A-B-E-F have slack in them. That is they can
start or finish a little later without affecting the path. However the available
slack has to be monitored so that the non-critical does not become critical
due to neglect.
! !108
4.21 Project Evaluation Review Technique (PERT)
So far we have considered activity durations as being deterministic, i.e. it

is expressed as a fixed and predictable number such as 10 days etc.
While the diagramming technique for PERT remains the same as explained
earlier, PERT recognizes the fact that the activity/Task durations are NOT
deterministic but vary in real life.
PERT therefore uses statistical variation in durations for calculating the

above parameters. Thus every task in the Network diagram will have
parameters based upon:
Optimistic Estimate of Duration

Pessimistic Estimate of Duration
Most Likely Estimate of Duration
The benefit of doing this is that it gives various scenarios i.e., what is the
best possible completion date and what could be the worst case scenario
for completion for the project as a whole.
We have in another section discussed how the duration estimates are used
for calculating the mean and standard deviation for each task.
To repeat the formula:
!
Standard Deviation Sd = (pessimistic optimistic)/6
Duration and Standard Deviation for Project as a Whole
Imagine a Project with Tasks t1, t2, t3, t4. The duration of each task will be
calculated by the above formulae giving d1, d2, d3, d4 as means with
respective standard Deviations d1, d2, d3, d4.
! !109
The duration of the project as a whole can be computed as follows:
Project Duration D = d1 + d2 + d3 + d4
Standard Deviation for the Project Duration SD
= Square Root (Square(t1) + Square(t2) + Square(t3) + Square(t4))
The Standard Deviation implies that the duration D is subject to variation

expressed by the SD.
To be 100% sure about the duration estimate we should use 3 times

Standard Deviation (SD).
Hence a 100% sure estimate = D + 3 SD
For example, if a project is expected to have a mean D = 30 days with a

Standard Deviation = 5 days a 100% accurate estimate would be
= 30 + 3 X 5 = 30 + 15 = 45 Days
Confirming if Project will Achieve a Target Date
The PERT formulae can be used to determine whether or not a Project will
achieve a given target date. This target date can be the target date for the
project as a whole or any specific task or milestone or project event. PERT
helps us to determine whether or not the project will meet this dead line.
The method involves:
Calculating the Standard Deviation for the task or project as the case
may be.
Calculating the Z Value for this event

Z = (Target Date Expected Completion date) /Standard Deviation.
Using the Probability Tables find the probability corresponding to the Z

Value.
This probability indicates the probability of meeting the deadline.
! !110
A more elaborate explanation on this is beyond the scope of this book

however suffice to say that PERT method can be used to conduct a
sensitivity analysis i.e. analyse the impact of any delays and it likelihood of
affecting or achieving the planned completion date.
4.22 Visual Task/Resource Allocation Schedule
Knowledge workers such as those in IT, engineering companies etc do not

like nor do they need to be supervised in the sense of a manual labourer in
a construction situation. What is therefore needed is a tool which can bring
in a sense of commitment in each of the engineers so that the resultant
work leads to project completion. To create commitment it is necessary to
involve the knowledge worker in the planning process so that he/she does
not feel that some plan was thrust upon him/her. Beyond this the plan has
to split into broad deliverables. For each such deliverable duly prioritized by
the project manager, it is preferable to allow the person to decide hows he
wishes to divide the tasks across weeks or days. This gives him/her the
freedom to schedule the tasks based on considerations best known to him/
her such local site conditions, desire to satisfy local clients, personal
constraints etc. However this schedule must be bounded by the overall
expectations set out by the project manager.
The sheer freedom to schedule work, generates a sense of commitment

since she feels thats she is in-charge.
Thus, for instance if a programmer was to deliver 20 programs in the given

months he could be allowed to schedule the programs across the 4 weeks
of the month. Thus supposes he commits to doing 4 programs in the first 2
weeks due to certain constraints and 6 programs in the remaining two
weeks, give him/her the freedom to do that provided the schedule sounds
feasible. If it does not guide him/her in making this schedule leave it to
him/her to work out the final schedule.
This approach generates tremendous self-commitment and the person

would not like let himself/herself down by failing to achieve the stated
tasks every week. At the end of the week he should be asked to review
his/her work with reference to his/her own schedule. This auto-feedback
helps him/her to correct himself.
! !111
The project managers role in all this is to help the person succeed in
scheduling and achieving that schedules. She has to bear in mind that the
success of his/her team mates will only ensure overall project success
the PM should therefore focus on day to day and week by week success of
his/her team mates.
Visual planning tools are very useful in this context. Given below is a
weekly planner for a project team as discussed above:
Visual Planner
Team Member Week 1 Week 2 Week 3 Week 4
Sriram Task 1 Task 5

Task 2 Task 6 -
Mahesh Task 3 Task 7

Task 4 Task 8
. .
. .
This is a very simple and intuitive chart which indicates the tasks scheduled
by each individual. The total list of the tasks for e.g., T1, T2, T5, T6 were
allotted to team member Sriram by the project Manager. However the
scheduling across weeks is done by Sriram himself with consultation with
the Project Manager.
At the end of each week each team member tick marks the completed
tasks. Note here that the definition of the work complete should be well
understood and consistently practiced.
If such a chart is placed prominently in the team office, any visitor to the
office including the Project Manager/any other senior executive or client
would not fail to notice the professionalism and the extent of work being
done.
! !112
Such visual schedules provide a sense of direction for each person day by
day. It also instills in them a sense of pride in the work since they feel that
they have control over a larger chunk of work and not merely a task.
There are few points to note however:
Since the tasks assigned to each person may be of different complexity it

must be clearly stated to every one that a difference in the number of
tasks scheduled or completed by each team member is not an indicator
of the amount of work done by each person. The load balancing between
team members is done by the Project manager.
Some people and organizations do not like the idea of a public display of
this kind. If they are very sensitive to it the Project Manager should ask
them to put a similar schedule at each persons work desk perhaps
limited to his task list. Ultimately the idea is to provide a means for the
individual to get a sense of self control over his own tasks.
Those who seem to fail in scheduling and perhaps in achieving what they
plan are perhaps the ones where the Project Planner needs to devote
extra time This time could be to help them work out a schedule if they
are novices or to guide them achieving. The chart helps the project
manager identify the people who need such help since they seem to be
failing against their own plans. The project manager should at a first
level try to guide them to success. In cases he however finds that some
person is consistently failing even with the PMs guidance, she can either
try to redeploy him/her for some other easier tasks or to progressively
weed him/her out as a non-performer.
For those people who seem to be in good control over their work, the PM
can use the principle of managing by exception and allow them full
freedom to control their work and devote more time to others who need
help.
The charts thus help in performance management. Also in implementing

situational leadership.
The Visual planning chart shown above is for planning tasks, similar
charts can be drawn for any process metric such as Productivity,
Production/team output itself etc.
! !113
Activity C:
1. Use an Internet Search engine to collect information on Pert/CPM

Chart.
4.23 Summary
This Chapter deals with project plan & various evaluation techniques.
Project management processes and techniques are used to coordinate

resources to achieve predictable results. However, it should be
understood up front that project management is not an exact science
and there is never a guarantee of success.
Since projects involve people, there is always complexity and uncertainty

that cannot be absolutely controlled.
Project management is a science in that it relies on proven and

repeatable processes and techniques to achieve project success.
It is an art because it also involves managing and relating to people and

requires the project manager to apply intuitive skills in situations that are
totally unique for each project.
A good project management methodology provides the framework,

processes, guidelines and techniques to manage the people and the
workload.
A good methodology increases the odds of being successful and therefore

provides value to the organization, the project and the project manager.
The Project Calendar ensures that there is a consistent understanding

about each work day for the project.
! !114
The Work break down Structure is a break down of the project product
into a hierarchy of components & sub components which together lead to
the completed product
The WBS lead to identification of individual tasks.
Working out a project schedule is to estimate the time & effort required
for each task.
In order to break down a customer requirement into software programs

one of the best ways is to apply object analysis.
Some of the common ways of estimation of software size & effort are.
Task based method, Lines of code method, COCOMO Model & Functional
point Analysis.
Gantt Charts (sometimes misspelled "Gant Charts") are useful tools for
analyzing and planning complex projects. They:
Help you to plan out the tasks that need to be completed.
Give you a basis for scheduling when these tasks will be carried out.
Allow you to plan the allocation of resources needed to complete the

project, and when a project is under way, Gantt Charts help you to
monitor whether the project is on schedule. If it is not, it allows you to
pinpoint the remedial action necessary to put it back on schedule.
The path with longest duration is called critical path
Program Evaluation & review Techniques (PERT) formulae can be used to

determine whether or not a project will achieve a given target date.
Visual planning tools like weekly planner are very useful
! !115
1. What do you understand by Work break structure? Illustrate with

examples
2. What do you understand by Task based Estimation? Illustrate with

examples
3. Explain Visual Task/Resource Allocation with examples
! !116
REFERENCE MATERIAL
chapter
Summary
PPT
MCQ
! !117
PROJECT RISK MANAGEMENT
Chapter 5
Objectives:
What is a risk?
Examples of a Project risk
Risk classification
Categorizing risk
Four broad categories for handling risk
Risk controls
Buffers
Project meetings
Structure:
5.1 What is a Risk?

5.2 Examples of a Project Risk
5.3 Risk Identification
5.4 Risk Checklist
5.5 Risk Classification
5.6 Categorizing Risk
5.7 Four Broad Categories for Handling Risk
5.8 Risk Controls
5.9 Role of Buffers & Contingency Plans
5.10 Buffers
5.10.1 How Much to Buffers?

5.10.2 Types of Buffers
5.10.3 Where to Place Buffers?
5.11 Project Tracking Meetings

5.12 Summary
! !118
5.1 What is a Risk?
We have already seen that every project has some risk associated with it.
A risk is a likelihood of an event which can have either a negative or a
positive (also!) impact on a project (delivery or outcome).
The Importance of Project Risk Management
Project risk management is the art and science of identifying, analyzing,

and responding to risk throughout the life of a project and in the best
interests of meeting project objectives.
Risk management is often overlooked in projects, but it can help improve

project success by helping select good projects, determining project
scope, and developing realistic estimates.
5.2 Examples of Project Risks
New Domain or Technology hence lack of expertise in that area

Absenteeism
Breakdown of equipment leading to loss of productivity
Changes in Scope.
Relationship related risks between client and service provider.
Etc.
5.3 Risk Identification
Risk identification is the process of understanding what potential events

might hurt or enhance a particular project.
Risk identification tools and techniques include:
Brainstorming
The Delphi Technique
Interviewing
SWOT analysis
! !119
The Project Charter also identifies the foreseeable risks or risks known to
all the stakeholders at the start of the project. The purpose of documenting
these risks is to inform all stakeholders about these risks and seek their
commitment to the project in the face of these risks some of which may
even threaten the very success of the project.
Given the overall attractiveness of the Project from the Business

Perspective however, all stakeholders would agree to take such risks in the
interest of the Business.
Knowledge of these risks at the very start of the project makes it easy to
work out suitable strategies to either reduce the probability of the risk itself
or the impact of the risk on the project.
From a contract perspective if a risk actually becomes a reality the affected

party can seek proper recourse as per the terms of the contract. Thus
documenting risks protects the interest of both the customer as well as the
service provider from potentially damaging effects of a risk.
Negative Risk
A dictionary definition of risk is the possibility of loss or injury.
Negative risk involves understanding potential problems that might occur

in the project and how they might impede project success.
Negative risk management is like a form of insurance; it is an

investment.
Risk Can Be Positive
Positive risks are risks that result in good things happening; sometimes
called opportunities.
A general definition of project risk is an uncertainty that can have a

negative or positive effect on meeting project objectives.
The goal of project risk management is to minimize potential negative

risks while maximizing potential positive risks.
! !120
Risk Management Planning
The main output of risk management planning is a risk management

plana plan that documents the proced-ures for managing risk
throughout a project.
The project team should review project documents and understand the
organizations and the sponsors appro-aches to risk.
The level of detail will vary with the needs of the project.
Contingency plans are predefined actions that the project team will
take if an identified risk event occurs.
Fallback plans are developed for risks that have a high impact on
meeting project objectives, and are put into effect if attempts to reduce
the risk are not effective.
Contingency reserves or allowances are provisions held by the project

sponsor or organization to reduce the risk of cost or schedule over runs
to an acceptable level.
Topics Addressed in a Risk Management Plan:
Methodology
Roles and responsibilities
Budget and schedule
Risk categories
Risk probability and impact
Risk documentation
5.4 Risk Checklists
The list of foreseeable risk can be very large. Experienced project

Managers maintains a checklist of possible risks. This helps them to
document such risks as a part of the project charter.
The risk checklist helps them to select the risks most likely to occur in the
given situation.
! !121
The risk checklist will vary from domain to domain and for different types
of projects.
For instance the risks associated with implementing an ERP could be quite
different from those associated with implementing a Supply Chain Product
which connects a company with its suppliers.
5.5 Risk Classification
We must next analyze which are the tasks which are prone to the risk
identified as mentioned above.
This is done by drawing up task-Risk Matrix and marking them with the
Probability that the risk does impact that risk and the Possible Impact of
that risk on the task should it actually occur i.e., Probability/Impact.
The Probability as well as Impact are categorized as Low (L)/Medium (M)/

High (H) or suitable numeric measures are used.
In practice the L/M/H categorization is preferred since many a time it is not

possible to compute the numeric probability and much the impact or loss in
terms of Rupees on that task.
The matrix looks as shown below:
Risk Risk 1 Risk 2 Changes in Risk 3 Risk 4

Task Absenteeis Requirement Etc
m
Programming M/M M/High Impact Etc
Task 2
Task 3
Etc
! !122
5.6 Categorizing the Risk
From the above matrix one can categorize the risk impact combinations
into:
Low/Low
Low/Medium
Medium/Low
Medium/Medium
Low/High
Medium/High
High/High
The Project Management team in consultation with the stakeholders and

project sponsors should decide on a base strategy for managing each of
these categories at a planning stage as well as subsequently.
The strategy and policy would provide a guideline so that when the risk
actually occurs the project team does not have to waste time for decisions
but can act based on the situation based on the guidelines.
For Instance a possible policy could be:
For Low/Low, Low/Medium, Medium/Low and High/Low type of risk-

impact categories the management can decide not to make any provision
for them but rather take them as they come.
For Medium/Medium, High/Medium, Low/High the management may

decide to provide suitable buffers as well as contingency plans where
appropriate.
For Medium/High and High/High type of risk category the management

may provide a buffer in terms of resource, time and even monetary
buffer. They may even decide to take a insurance policy. If it is possible
they may even try to transfer some part of the risk to subcontractors etc
to reduce the impact of the risk on the organization.
Such policies serve as a broad guideline.
! !123
Broad Categories of Risk
Market risk
Financial risk
Technology risk
People risk
Structure/process risk
Activity A:
1. Use an Internet Search engine to collect information on Risk

Identification .
5.7 Four Broad Strategies for Handling Risks
Based on the foregoing the four basic strategies for handling risk of any
kind are:
Risk Avoidance: do not tread that path at all for instance if people are
infecting machines with viruses by bringing in external CDs/Floppies etc
a simple way to avoid the risk is not to provide CD/Floppy drives or
deactivate them. This is risk Avoidance. It is however not always possible
to do business without facing a risk
Risk Mitigation: i.e., Either reduce the possibility of the risk or reduce
its impact. Consider the same virus example we may allow access to
the CD/Floppy but install the Anti virus software which automatically
checks any CD/Floppy as soon as it is inserted.
Risk Transfer: the organization can either bind subcontractors and

manage to share the part of the risk with them for instance some part
of the subcontractor payment can be linked to successful completion of
the project. The other way to transfer the risk is to take a Insurance. For
instance, today several types of insurance policies are possible such as:
Key man Insurance for risks arising out of loss of a key person
! !124
Fire, Floods, Earthquakes and acts of Goods, war, terrorism etc.
either covered by a Force Majeaure clause which exempts the
organization for failure to deliver the project due to such extraneous
factors or by way of an appropriate General Insurance policy
Risk Acceptance: Here considering the low impact of the risk the
organization may decide not do anything but take the risk in its stride
and absorb financially as well as otherwise the impact of such risk
Technical Risks Cost Risks Schedule Risks

Emphasize team Increase the frequency Increase the frequency
support and avoid of project monitoring of project monitoring
stand-alone project
structure
Increase project Use WBS and CPM Use WBS and CPM
manager authority
Improve problem Improve communi- Select the most
handling and cation, project goals experienced project
communication understanding and manager
team support
Increase the frequency Increase project
of project monitoring manager authority
Use WBS and CPM
5.8 Risk Controls
Having decided the strategy to manage each category of Risk-Impact

combination the next step is to select appropriate controls particularly for
those category where it is decided to either Mitigate the risk. Risk
avoidance may also require a means of detecting the risk and then
procedures and controls to avoid it.
The choice of the control depends on the severity of the risk as well as the
nature of risk. For instance power failure in a city like Mumbai is quite less
compared to some other parts of the country. Hence one may chose a
small Uninterruptible Power supply (UPS) which can atleast allow you to
! !125
continue work for another 15-20 minutes by which time the power gets
restored. However in places where power failure is frequent and for long
duration, a UPS will only provide time for ensuring a safe shutdown of
machines. However, if the nature of the project does not allow stoppage of
work it may be necessary to have UPS + a genset which will automatically
start up as soon as power fails. The UPS only provides a means of
transition from main power to genset and back.
It may be noted that for the same risk the control used will vary depending
on the severity, the tolerance level of business to such risk as well as the
ability to afford the control. For instance a Genset will involve heavy capital
expenditure + higher operating costs which not every company can afford.
Controls are as varied as the variety of risks. A judicious choice needs to

be made as explained above.
Top Ten Risk Item Tracking
Top Ten Risk Item Tracking is a qualitative risk analysis tool that
helps to identify risks and maintain an awareness of risks throughout the
life of a project.
Establish a periodic review of the top ten project risk items.
List the current ranking, previous ranking, number of times the risk
appears on the list over a period of time, and a summary of progress
made in resolving the risk item.
Example of Top Ten Risk Item Tracking
Monthly Rankin
Risk Item This Last Number Risk Resolution Progress

Months Month of Months
Inadequate 1 2 4 Working on revising the

planning. entire project plan.
Poor definition 2 3 3 Holding meetings with

of scope. project customer and
sponsor to clarify scope.
! !126
Absence of 3 1 2 Just assigned a new project

leadership. manager to lead the project
after old one quit.
Poor cost 4 4 3 Revising cost estimates.

estimates.
Poor time 5 5 3 Revising schedule

estimates. estimates.
Activity B:
2. Use an Internet Search engine to collect information on Risk controls.
5.9 Role of Buffers and Contingency Plans in Risk

Management
Two common ways of dealing with Project related risks are:
Working out suitable Contingency Plans

Putting Buffers either time buffers, Resource Buffers or use of Natural
buffers or combination of all three
Contingency Plans:
Based on the risks identified at the start of the project using a checklist
and other inputs from people from that domain, suitable contingency plans
can be defined as a part of the planning activity. Separate contingency
plans may be required for each risk.
A contingency plan is a stand by plan which can be activated once the

normal course is affected by the emergence of a risk.
For instance if power failure is a known risk for project in a particular

geographic region, the project manager can provide for a standby
generator set which can be put into action as and when required.
! !127
A contingency plan needs to be in the form of certain standby resources

such as the standby genset in the above example + a set of well
documented and well understood procedures, which can be put into action
should the risk emerge.
More specific responsibilities should also be documented and

communicated to all concerned so that if and when the risk occurs, there is
no panic but the team gets galvanized into action and they know exactly
what they are supposed to do. To ensure that this happens, it is a good
practice to conduct mock drills at least for critical risks.
For instance in the event of a fire the person designated to take charge of
the situation would direct others towards evacuating people to safety,
calling up the fire brigade, using the fire control equipment etc.
While some of the above examples seem to sound very drastic, in real life
many environmental risks affect projects particularly in engineering, EPC
and construction.
In the Software Industry disasters such as hardware crashes, attack by

viruses, break down of the Network or even several people leaving the
company at the same time are all probable.
Hence contingency plans for some of these areas need to be defined.
5.10 Buffers
For certain other risks the Project Manager can build suitable buffers to
reduce the impact of the risk on the project.
For instance if a project manager expects 20% loss of productivity due to

absenteeism and attrition, a buffer of 20% in terms of excess manpower
may be provided to buffer this possibility.
5.10.1 How Much to Buffer?
We have in the earlier sections discussed the need to create a culture of

working on Pure Duration Estimates.
We have also discussed how a risk can be mapped on to specific tasks.
! !128
The combination of the two concepts can be used for working out
appropriate buffers proportionate to the impact of the risk.
As mentioned in the previous example if absenteeism is to the extent of

20% one way to buffer is by providing 20% more people throughout the
project. However this could be un-necessary. For instance you may be
aware that while the natural absenteeism of only 5% is expected
throughout the project, only on certain periods such as during the Festive
Seasons in Oct./Nov. for Diwali/Ramzan and in December for Christmas the
absenteeism goes up to 20% - we may decide to buffer only those tasks
which are likely to occur during these periods. This would imply that not
only the amount of buffer resources but also the specific skills which are to
be deployed during these periods needs to be buffered. This could
considerably reduce the cost of the buffer.
Thus we can decide on the buffer by:
Identifying which tasks are affected by a risk
Assess the extent of the impact due to that risk by quantifying it in terms
of effort, time or cost impact
Providing appropriate amount of buffer to tide over the risk.
5.10.2 Types of Buffers
Buffers can be of 3 types:
Resource Buffers i.e., providing more resource such as people,

equipment etc
Time Buffers i.e., if the task is expected to be over in 4 days provide

1 extra day as a buffer
Natural Buffers Usually, a plan is prepared based on a normal work

day i.e., 8 hours of work and perhaps 5 or 6 days per week. However if
there is a problem the project team can stretch extra hours every day or
even work on a few week ends. Since these Buffers are always available
to manager, they are termed as Natural Buffers
! !129
5.10.3 Where to Place Buffers
It is usually a good practice to place buffers at the following places:
Project-end buffer: this is a buffer which prevents the project so it

does not cross the final date. This is usually a time buffer. Thus if you are
to deliver something by end of December, you would prefer to leave a 15
day period at the end and work on an internal deadline of 15th
December. The project plan thus tries to achieve project completion by
15th December. Should there be some delay, the 15 day time buffer
helps you still end the project on time i.e. end of December.
Mile Stone and Phase end Buffers: To prevent a delay in one phase or
a milestone eating into the time of the next phase or milestones it is
important to place a buffer in terms of time/resource. These buffers
isolate distinct phases and milestones and prevents overall delays.
Task Level Buffers: This is as was explained earlier where we use pure
estimates and add buffers to those tasks which are likely to be impacted
by a risk. These buffers are usually resource buffers but could also be
time buffers.
Buffering the Tasks on The Critical Path: More importantly tasks

which are on the Critical Path Must be buffered by resources buffers to
ensure there is no delay on the Critical Path. Because if the critical path
is delayed it delays the entire project completion.
Buffering Non-Critical Paths: Many a times it is also a good idea to

buffer non-critical paths. This is though they are non-critical i.e., there is
a slack in terms of time in these paths the actual duration of each task
and hence that of the non-critical path is subject to variation. Sometimes
the variation is so much that it leads the non-critical to impact the critical
path, i.e., what was non-critical actually now becomes critical. This
usually happens because the project manager tends to delegate non-
critical tasks and does not monitor them closely sinces he has to manage
the critical path. Hence it may be better to provide extra resources to
some of the non-critical paths to be doubly sure that the tasks on the
non-critical path definitely complete on time even if these tasks are left
to other executives by the Project Manager. Such buffers are known as
link buffers.
! !130
Risk Management is Not Merely to be Done at the Planning Stage
While it is important to plan for foreseeable risks at the Planning stage of a

project it must be mentioned that the Project is exposed to all risks every
day of its course. It is therefore necessary that every member and not just
the Project Manager be alert at all times to any symptoms of a risk
emerging in the near future.
Further these risks are not just the risks which had been imagined at the
Planning Stage. New risks may emerge which had not been imagined
earlier. The Success of the Risk Management can be judged by:
Proportion of risks which were imagined at the planning stage have

actually occurred and were successfully managed because the
organization had planned for them
Proportion of risks which were not planned but did occur indicating the
inadequacy in Risk Planning
All such risks which could not be imagined should be added to the Risk
Check List so that future projects do not suffer from these risks.
5.11 Project Tracking Meetings as a source of Identifying

Risk on a On-Going Basis
Project Tracking Meeting is perhaps the best place to identify risk which
is likely to hit the project in the near future. Each project team member is
aware of the risks likely emerge in his/her work area or tasks. If the
project team has a open culture where people tend to share problems in
the tracking meeting, it will help in identifying such risks and focus on
resolving it before it impacts the project. However if the Project Manager
is very dominating or tends to use such sharing of information as a means
of putting the blame on the project team members, a culture of hiding
possible risks creeps in. This becomes counter productive.
Hence good project managers should use Project Tracking meetings not
just to review project status but also as a great source of identifying risk.
! !131
Risk Management Process for On Going Risk Management
Having identified the risk there has to be a formal process for managing
the risk.
Usually, Risk Management involves the following steps:
Risk Identification
Risk Quantification
Risk Classification
Risk Response Development
Risk Response Execution
Risk Response Monitoring
Risk Closure
We have seen many of these steps at the planning stage. We must

understand that this end to end process however needs to be working
continuously on an on-going basis.
A properly defined process which takes the project from risk detection to
closure will help in gliding over any eventuality during the course of the
Project.
Activity C:
3. Use an Internet Search engine to collect information on Project

Tracking Meetings.
5.12 Summary
This chapter deals with project risks
A risk is a likelihood of an event which can have either a negative or

positive impact on project
The project charter identifies the following risks to all stakeholders
! !132
The risk that the project will exceed the budgets he is thinking of
committing to.
The risk that the project will miss any dates he has in mind.
The risk that the project will fail to meet any other commitments she is
about to make
Many organizations have checklists - things that have gone wrong in

previous similar projects - which are therefore things that might cause
problems in future projects
Some organizations have several checklists reflecting the various types of

project they undertake. However, checklists (and I've met PMs who have
done this) can lead to the PM "filling in the checklist", filing it away and
believing they have "done risk management"
A better approach might be to invite the team and other stakeholders to

a Risk Identification Workshop. Brainstorm: "team, what do we think
could cause us problems, or even cause us to fail?" When that has been
exhausted, zip through any checklists you've managed to lay your hands
on to see if they prompt anything you hadn't thought of
Four major strategies to handle risks are Risk avoidance, Risk Mitigation,
Risk Transfer, Risk Acceptance
The Project Manger can build suitable buffers to reduce the impact of the
risk on the project
There are 3 types of buffers Resource, time & natural
At weekly team meetings risk owners report, briefly, the team on the
status of their risks. What planned (or unplanned) actions are being
taken to reduce the risk. Is the risk receding or growing? This should
ensure that the team is involved in risk reduction activities and in
refining the risk management plan. Keep the register updated - relegate
receding risks, promote growing ones.
A properly defined process which takes the project from risk detection to
closure is quintessential for success of the project.
! !133
1. Explain Examples of a Project risk in software development
2. What are buffers? Where to place them.
3. Why Project Tracking Meetings are important?
! !134
REFERENCE MATERIAL
chapter
Summary
PPT
MCQ
! !135
PROJECT TRACKING
Chapter 6
PROJECT TRACKING
Objectives:
Purpose of tracking
Tracking needs
Role of metrics
Improving productivity using tracking.
Advanced methods of tracking
The outcome of tracking
Structure:
6.1 Purpose of Tracking

6.2 What to Track?
6.3 Tracking Needs
6.4 Role of Metrics
6.5 Relating to Big Picture
6.6 Role of Milestones
6.7 Rescheduling a Project Delivery
6.8 Improving Productivity
6.9 Managing Risk
6.10 Escalations
6.11 Advanced Methods of Tracking
6.12 Motivating Team
6.13 The Outcome of Tracking
6.14 Summary
! !136
PROJECT TRACKING
Tracking
Tracking is a process of checking the status and progress made in the

project with respect to the plan. The purpose of Tracking is to primarily
judge whether the project is on-track i.e., it is going as per schedule and
other plans related to the project.
Tracking covers virtually all the aspects mentioned under planning.

However the reference is to the week/period gone by. Tracking however
also should help the Project Manager to judge how the past week has
taken him/her closer to his/her goal. If there has been any deviations he
would want to know the cause for this deviation and more importantly find
a way to put the project back on course.
6.1 Purpose of Tracking
The purpose of Tracking can be summed up as follows:
To evaluate the status of each task with reference to the Schedule/Plan.
To evaluate the status of each milestone and the project as a whole with
reference to Schedule/Plan.
To judge the extent of progress made since the last tracking meeting.
To evaluate the extent of carry over of work from this period to the next.
To evaluate how the period gone by has take the project closer to its
goal.
To calculate the new Asking Rate so as to stay on course with reference

to the overall schedule and goal.
To check the status of Critical Items identified during the previous

periods.
To detect new risks and new critical areas.
To assign responsibility to tasks newly planned and for Critical areas.
To modify the schedule/plan if justified and communicate the same to all

concerned and to update the plans.
! !137
PROJECT TRACKING
To acknowledge achievements during the previous period and perhaps

call for a small impromptu celebration.
To Identify issues which need to be escalated to higher management.
To capture lessons learnt during the period and document the same for
future use.
Why Are Projects Late?
An unrealistic deadline established by someone outside the software

development group;
Changing customer requirements that are not reflected in schedule

changes;
An honest underestimate of the amount of effort and/or the number of

resources that will be required to do the job;
Predictable and/or unpredictable risks that were not considered when;
The project commenced;
Technical difficulties that could not have been foreseen in advance;
Human difficulties that could not have been foreseen in advance;
Miscommunication among project staff that results in delays;
A failure by project management to recognize that the project is falling

behind schedule and a lack of action to correct the problem;
6.2 What to Track?
Tracking of a project involves the careful inspection and follow. up of the

following (the list is only indicative and not exhaustive):
The tasks scheduled during the period being reviewed, their status with
reference to schedule
Cumulation of tasks completed till date or from the last milestone.
The tasks which are pending from the previous period.
! !138
PROJECT TRACKING
The tasks to be undertaken in the coming period after the tracking

meeting.
The dependency of these tasks with earlier tasks.
The preparedness/readiness to undertake the next set of tasks.
The effort and cost expended on tasks which were undertaken during the
past period.
Comparison of effort and cost with respect to the planned effort and
costs and reasons for the deviations.
Critical items identified during the past tracking meetings and the status
of corrective action initiated for them.
Resource availability, productivity and Morale etc.
6.3 Tracking Needs Accurate Information
From the foregoing, it would be obvious that Tracking requires a lot of

information and this is where the MIS is necessary. It also implies that the
nature of information, the format, frequency, the form (e-mail or paper
based) etc has to be preplanned.
Objective reporting is equally important. Let us understand what objective

information means in the context of a project. Imagine a Software project
requiring 100 programmes to be developed. These are distributed to
various programmers for development. During the tracking meeting the
programmers should report
The number of programmes completed during the week and.

The cumulative number of programmes completed till date.
Balance to complete.
A status of the incomplete tasks.
The available time and therefore the new asking rate for development.
While this sounds quite simple, in reality each programmer interprets this
differently. Thus a programmer may say that he/she has completed 5
programmes and a cumulative of 15 programmes till date. After
questioning him/her, he/she confesses that of the 15 delivered so far
! !139
PROJECT TRACKING
atleast 5 have known bugs which need to be corrected while 10 of them

are yet to be documented.
With a large team it is not possible to get into so many details to verify the
actual meaning of a reported information. It is therefore a good practice to
evolve a uniform definition of each piece of information reported and
ensure that all the concerned person have understood this common
definition and actually practice it.
Thus in the previous example if we define a programme to be complete as

a being one which has been coded, the programmer has tested it, the QC
has tested it, the code has been reviewed and documentation has been
done.
Thus on an objective basis the progrmmer mentioned above should report

perhaps only 5 completed while other 10 are incomplete tasks either
because of bugs or because documentation is still pending. Thus if coding,
testing, code review and documentation are identifiable stages the number
of programmes which have reached each stage can be mentioned.
This gives a correct picture to the project manager.
Getting the correct status at a Task level and overall is one of the first
purpose of Tracking.
Activity A:
1. Use an Internet Search engine to collect information on Advanced

methods of Project Tracking .
6.4 Role of Metrics
Since the objective reporting is necessary, the project leader must develop
measures to judge the success of various aspects of a project. Such
measures which help in judging various dimensions of a project are known
as Metrics.
! !140
PROJECT TRACKING
While Metrics is a subject in itself, it suffices here to say that the project
leader should at least aim to define appropriate metrics in the following
areas:
Size (to judge if scope of the project has been changed)
Effort (to judge the amount of effort put in vis--vis the planned)
Time (to judge the slippage in time and perhaps relate it to various other
factors)
Cost (to judge the deviation in the cost with reference to the projects
original budget and perhaps relate it to various factors such as changes,
risk etc)
Quality (to judge whether the work products delivered are of the desired
quality, the extent of rework required and to judge if the process of
delivery is performing all right with reference to quality etc)
People Metrics to judge people performance and related factors such as

absenteeism etc.
It would be obvious that Metrics are measures or indicators of some aspect

of a project.
The purpose of generating this information is to be able to benchmark the

project with other similar projects in the past and also to use this data for
future projects.
Such benchmarking helps in ensuring that the processes involved in the

project are working as per the organizations expected levels.
6.5 Relating to the Big Picture the Project Goal
The status should also be viewed from the point of view of achieving the
goal. Does the present status indicate that the project has moved in the
direction of the goal during the period under review? This is important
since many a times we tend to get carried away by the sheer amount of
activity or work done. It is equally important to know that the activities
being done are indeed as per the plan and not too many tasks are being
done out of sequence since they may affect the completion of intermediate
phases of the project.
! !141
PROJECT TRACKING
Project Goal or vision is a document which gives the basic purpose of

undertaking the project. The Project Leader must check during each
tracking meeting or at least during a monthly review of the project,
whether the project goals and vision are likely to be met. He/she can then
take corrective actions in the form of ensuring completion of those
functionalities of the work products being delivered which will fulfill the
project goals and vision.
6.6 Role of Milestones
Milestones are significant points in a project. They are identified at the

planning stage of the project. Reaching a Milestone indicates that the
project has moved one step ahead towards its completion. Milestones are
usually also linked to customer deliverables such as for instance signoff of
specifications or laying the foundation or a slab in construction etc. Even
commercials may be linked to milestones i.e., confirming a milestone may
lead to a stage payment from a customer etc.
A milestone is therefore an appropriate point in a project for conducting a

major review of the project. Apart from the usual aspects which a project
manager looks into in any tracking meeting, one should plan for a more
elaborate review of the project as whole. This could involve the revisiting
the vision/goal and benefits of the project, the quality processes in delivery
of the project, human aspects etc.
A milestone is also an occasion to reflect on the learnings of the journey so

far in the project. These learnings need to be captured and made available
to all team members so that mistakes or opportunities missed are not
repeated in subsequent stages in the project.
A milestone is also may also call for a celebration. For instance the
foundation stone ceremony for a building or a bridge is milestone and is
also occasion to celebrate. This celebration is a recognition of reaching an
important point in the project, and a recognition of the hard work put in by
the team to reach that stage.
The Asking Rate
The project manager must think about how to keep the project on course.
Where the project is at present lagging, the backlog of work plus the
! !142
PROJECT TRACKING
balance planned work must be completed in the remaining time. This is

much like the game of 1 day cricket. If a team needs to achieve 200 runs
in 50 overs at the start of the innings but the batsmen are unable to score
fast enough and as a result reach a stage where they have 30 overs left
but 180 runs to score, the New Asking rate is 6 runs per over making it
more challenging.
This is the same situation for a project team. The project manager thus
has to calculate the New Asking rate for doing the work, which in the
context of a project would mean deliver more number of tasks or more
meters of road construction or more function points of software during the
balance time. This is like the new asking rate. In cricket we cannot add
more people to help us deliver since the game demands that only 2
batsmen can be at the crease. In projects however, we have the possibility
of adding resources to the existing team and thereby try to complete more
tasks in the remaining time.
The underlying philosophy is that the project manager must ask himself/
her and his/her team the question What needs to be done to still
complete the task, milestone or project as per the committed schedule.
This is a question of re-planning resources and productivity.
6.7 Rescheduling a Project Delivery
There is always a temptation to reschedule a task, milestone or project due

to sheer team pressure who state that it may be difficult to deliver as per
the previous plan. The project leader must therefore focus first on how he/
she can achieve the plan. Only if his/her analysis convinces him that the
existing plan is no longer viable should he consider rescheduling as an
option.
6.8 Improving Productivity
Productivity is yet another lever in the hands of a project manager. Even

while adding more people he/she can try to increase the productivity of the
existing team.
Productivity = Output/Input
! !143
PROJECT TRACKING
Incase of the service industries output can be measured in terms of

number of completed customer services such as customer claims etc or the
number of completed programmes in software or function points etc. In a
construction project the number of floors completed or the number running
feet of wiring done etc. could be used as measures of output.
Input in the service industry is usually Labour. Hence, man hours, man
month etc. could be typical measure of input.
Productivity can be improved by either:
Increasing output for the same level of input or

Reducing the input for the same level of output
Increasing output for the same input requires improving level of

motivation, level of engagement of people, level of skills or use of new
tools and techniques. This usually requires investment in new tools etc.
and therefore requires more thought and approvals.
The project manager may find getting such approvals, a time consuming
process and would be useful only if planned at the start of the project.
He/She would therefore have to work on motivating the team or more

likely try to reduce the effort required for delivering the same level of
output.
Reducing the effort usually means trying to reduce the waste in the
process. The project manager has to identify such wastes and bottlenecks
and try to minimize them. For instances if various documentation activities
are delaying the actual production work, he/she should look at ways to
reduce such delays since delays are a form of a waste.
Other wastes in any service industry are:
Unplanned absenteeism
Unplanned breaks
Rework
Unplanned meetings thereby wasting a lot of time of the entire team
Systematically eliminating such waste will definitely give substantial

improvement in productivity.
! !144
PROJECT TRACKING
6.9 Managing Risk
Risk Management as a topic has been covered in the section on Planning.

However it is important to understand that while we anticipate various
risks involved in a project at the start and accordingly buffer or build
contingency for the project, it is only during tracking that one senses if
some risk whether foreseen or un-foreseen is likely to emerge.
The success of a project manager largely depends on his/her ability to

sense/discover risk before it hits the project.
The tracking meeting is a rich source of information on potential risk. The

project team members who are closely connected with the various tasks
being performed are keenly aware of any emerging risk both in their own
tasks as well as those of others. There is however a tendency to keep quiet
about it in the wrongful hope that Things will take care of themselves. It is
the ability of the project leader to therefore create a culture of openness
and sharing, so that during the tracking meeting people speak out about
possible problems, so that they may be resolved in time.
Once a risk has been identified, if a solution is readily available the project
leader may decide of the course on action and assign the task to one of the
team members.
All such tasks related to the projects Risk Areas must also be included in
subsequent tracking meetings so that the Project leader can ensure that
the corrective and preventive actions required to take care of the risk are
followed through.
6.10 Escalations
Usually tracking is done keeping the focus on within the four walls of the
tracking meeting. That is to say that the Project leader focuses first on
issues which can be resolved by the team present. Another way of putting
it is Let us put our house in order first. Only when such issues are tackled
should he/she look at issues which need external support. This external
support could be another department or a supplier or a customer. This
discipline of internal issues first not only helps the project leader resolve a
lot of issues within the control of the team but also reduces the tendency
on part of team members to blame everything on external entities and
divert the attention.
! !145
PROJECT TRACKING
Things beyond the control of the team thus require what is popularly called
as Escalation. For instance if the operating person on the client is not
cooperating which has lead to delays one possible course of action would
be escalate the matter to his superior. At other times the Project team may
need support from other service departments within its organization. The
Project leader can then put a request enlisting the support through proper
channels within his organization.
Most project plans would mention the escalation paths so that such issues
reach the right people who have been empowered to take decision on
them. Escalation helps in removing any dead-lock situations in projects and
puts it back on course.
One fear associated with escalation in the minds of the project team as
well as the project leader is how will the client perceive it will he/she
take it as a complaint? will he/she retaliate in some other ways?
It is therefore important to have a formally defined escalation path. More

importantly while escalating always keep the focus on what needs to be
done rather than focusing on complaining either about some person or his
intentions.
Escalation managed well can be a healthy route to resolve conflicting

issues arising in a project. Escalation meetings could be held within a day
or on the same day of the tracking meeting so that issues detected during
tracking meetings can be quickly escalated and resolved.
6.11 Advanced Methods of Tracking Earned Value

Analysis (EVA) Method
The Earned Value method is a method of judging the progress of project

based on the actual cost incurred up to the day of tracking versus planned
cost up to that date. Cost is used as a surrogate measure for the value
earned by the project. The Budgeted cost for a project indicates the value
earned at the end of the project expressed in cost units. Thus a project
which is going slow in terms of time schedule would not have spent the
planned amount at a given stage in the project. It could also happen that
the project meets the schedule but ends up spending more than the
planned amount. Both these variances are a way of judging the
performance of a project. EVA is beyond the scope of this book.
! !146
PROJECT TRACKING
6.12 Motivating the Team
Tracking is also an opportunity to motivate the team. This could take the
form of acknowledging progress or work and specific contributions of team
members. It could also be in the form of a spontaneous celebration of say
achieving a milestone or a significant task in the project. Sharing and
openness during the tracking meeting and the focus on what has gone
wrong, how to resolve it rather than on who made the mistake? can go a
long way not merely in getting the problems resolved but also gets the
teams commitment to the project and earns loyalty towards the project
leader.
6.13 The Outcome of Tracking
By the end of each tracking meeting the project team and leader develop a
good understanding of:
Present status of the project.
Performance during the period being reviewed.
The balance work.
Risks which have emerged and which are likely to emerge in the near
future.
The actions to be taken and whos responsibility it is for these actions.
Changes to any aspect of the project plan.
Learnings from the project so far.
The success of the tracking meeting can be judged by:
The time it takes to track
The extent of time required for understanding status and issues versus
the time devoted to resolving these issues and motivating the team
How many issues were actually resolved during the meeting?
! !147
PROJECT TRACKING
How may risks were uncovered during the meeting?
How charged up is the team to go ahead and do the right things?
Activity B:
2. Use an Internet Search engine to collect information on Importance of

Project Tracking .
6.14 Summary
This chapter deals with project tracking:
Tracking is a process of checking the status & progress made in the

project with respect to the plan
Tracking of project needs careful inspection & follow up various checklists

& milestones
Tracking of project needs accurate information
Create a Risk Register, which lists risks in priority order? For each risk,
the register might include:
Risk number
Description
Consequence if risk happens
Probability (high, medium or low)
Planned actions to mitigate the risk
Contingency plan (what you'll do if the risk happens)
Risk owner (a member of the project team)
Status (e.g. closed: no longer a risk)
The earned value method of tracking is a method of judging the
progress of project based on actual cost incurred
The success of tracking meeting is how the project team is charged
to go ahead & do the right things
! !148
PROJECT TRACKING
1. Why is tracking important for improving productivity?
2. What are the advanced methods of tracking?
! !149
PROJECT TRACKING
REFERENCE MATERIAL
chapter
Summary
PPT
MCQ
! !150
CONFIGURATION MANAGEMENT
Chapter 7
Objectives:
How do we do Configuration management?
Structure:
7.1 Configuration Management

7.2 How do we do Configuration Management?
7.3 What makes configuration management difficult?
7.4 Summary
! !151
7.1 Configuration Management
Although this is not a project management related concept, Configuration

management is an extremely important part of a software lifecycle. So
much so that many a time problems in project delivery happen due to poor
and or lack of configuration management practices.
So what is Configuration Management?
Configuration, to form from or after, derives from the Latin com-,

meaning with or together, and figurare, to form. It also means a
relative arrangement of parts or elements. Configuration management
therefore refers to managing a relative arrangement of parts or elements.
Its as simple as that.
Configuration management, as we know it today, started in the late 1960s.
In the 1970s, the American government developed a number of military

standards, which included configuration management. Later, especially in
the 1990s, many other standards and publications discussing configuration
management have emerged.
In the last few years, the growing understanding of software development

as a collection of interrelated processes has influenced work on
configuration management.
This means that configuration management is now also considered from a

process point of view.
A Software project produces several work products. These could be:
Individual programs developed by tens of programmers,
A set of programs constituting a module,
A set of modules,
Several specification notes program, module, software specifications,
Various plans project schedules, project charter, quality plans etc.,
! !152
User documentation user manual, operations manual, systems

documentation etc.,
Commercial documents delivery notes for software delivered, invoice

copies, contract documents,
Correspondence which may have bearing on the project status reports,

change requests, feedbacks and customer inputs received via e-mail and
other forms of communication
These work products and documents need to be kept in a form such that
the project team always works on the correct version of each thereby
ensuring that the delivered product meets the agreed requirements.
For instance, if a program was developed according to a certain program

specification which corresponded to a certain Use Case in software
specification. Based on the customers feedback, if some change was made
to the Use Case, which lead to a change in the software specification and
then the program specification finally leading to modifying a program.
A second situation could be that the same software consisting of say over
100 programs is implemented at 20 different branches. However since local
branch requirements vary it may be necessary to make changes to the
certain programs as required by each branch. At the IT department of this
company or the Project Office of this company, it is necessary to keep a
copy of the version of the software which works in each branch separately.
This is because though in principle there is only one product there are 20
different versions. While making further changes in future it would be
necessary to access the correct version which is working in the branch
where such a change is requested.
Another scenario could be there were different bugs detected at different

points in time in a software. Accordingly only the program causing the bug
at a given time was modified. However the act of modifying even one
program from a suite of programs results in a different configuration 99
older programs + 1 modified program. When this happens frequently, it is
important to ensure that we always have the latest configuration to work
on. If by mistake we take an earlier version of the configuration, the bugs
which had been removed would resurface and the client would complain.
! !153
In case of system software such as an operating system etc, the correct

configuration management is important to ensure that the application
software which are to work on it do not get affected by an unplanned
change in configuration. For instance many a time it happens that the
software developer has developed a solution which works well at his/her
office on a certain version of Windows. However when he/she tries to
implement the same at the clients place which has a different variant of
the Windows OS the person has problems. He/she than creates a separate
version of his/her solution which works on his clients machine. He/she has
to now keep track of this version so that every time the client asks for a
change he/she carries out the change in the version which is suitable for
the clients Windows OS.
Some of the reasons why Configuration management is required are:
Sheer inventory of various versions of each object placed under

configuration management.
To provide complete trace-ability (backwards and forwards) between the

origin of a change to its final effect in a delivered program.
Help in maintaining information on the combination of different versions

of various configurable objects, which collectively form each version of a
customer delivered product.
Help in maintenance of multiple versions of software.
! !154
Overview of Configuration Management Activities
7.2 How do we do configuration Management?
The steps to take are as follows:
Each document, program etc. which should be, management by the

configuration management process must first be identified and a suitable
numbering and storing system must be evolved.
! !155
Whenever any object is created or a new version of any existing object is

created e.g., a new program written or a change made to the
documentation etc the new object must be checked-into the
configuration management records and stored appropriately.
Each time an object is dropped from the configuration the same must be
recorded.
A link between all objects which belong to a given version must be

created. Thus for example Version 1.2 of the Software Specification,
along with User Manual version 2.3 along with appropriate versions of
each program could make Version 2.0 of a delivered software product.
This linkage must be maintained
When such a linkage is established during the initial release of the final
product it is known as a configuration baseline. Subsequent changes in
the individual objects which constitute this product are then tracked
accurately
For software and other softcopy of documents and emails there are
software based tools available for implementing configuration
management. These tools make it easy to store and record different
versions of any soft-document be it a program or a specification or an
email and help the project manager to keep track of changes and ensure
correct releases of final product.
You would have released by now that configuration management is

extremely important particularly for software projects since there are a
large number of people involved and a large number of objects which
under go independent as well inter-related changes during and even after
the project is over. From a project perspective if a wrong specification copy
is issued to the team to work on. Worst still if differing copies of the
specification are issued to different team members, despite all other
project planning and tracking being done right the project may end in a
nightmare solely because of poor configuration management.
The Project Managers must therefore understand and practice configuration

management.
The document identifier in Figure contains
! !156
Project and year: SC.91

Document number: 009
Author and affiliation: OA.ect
Activity identifier: T2.3.1
Document type: RP (Report)
Version: 02
Project Nmae : SCOPE

Document Title : SCI Description Formate
Document Identifier : SC . 91/009/OA.etc/T2.3.1/RP/02

Distribution : Project
Manager R & D Department
Manager Technical Support
Date : May 2nd 1991
Author : Ole Andersen , Elektronikcentraien
Approved By :
Project Manager : __________________ Date: _____________
QA : __________________ Date: _____________
Activity A:
1. Use an Internet Search engine to collect information on Importance of

Configuration management.
Activity B:
2. Use an Internet Search engine to collect information on Tools for

Configuration management.
! !157
7.3 What makes configuration management difficult?
Were not sure anyone really believes that implementing configuration

management is easy. In fact, many people believe the task is downright
daunting. Beyond the initial difficulties with program scope and
organizational support, there are some other inherent attributes of todays
IT systems that really complicate matters.
Integrated systems As systems become more integrated, a whole

new set of CIs develop. Middleware software becomes a critical element
to facilitate proper transaction execution. Poor configuration
management at this level can cause significant issues.
Service-oriented architectures (SOAs) The reason an SOA works

well is that it consolidates a set of functions common to many
applications into a single service. If an SOA service configuration and its
relationships are not managed well, many portions of the IT
infrastructure can be impacted.
Bad configurations Many times IT shops deploy bad or unstable

configurations. Bad configurations can have ripple effects that extend to
many other systems in the connected IT world. Many vendors, including
Sun, can help you define and test known good configurations.
Separate domains of IT There are many different disciplines within

IT these days. Each domain (server, network, application, telephony) will
have separate requirements for configuration management and unique
CIs to manage, creating challenges for a central program.
7.4 Summary
This chapter deals with CONFIGURATION MANAGEMENT

CONFIGURATION MANAGEMENT is the key to managing and
controlling the highly complex software projects being developed today.
CM tools have developed from simple version-control systems targeted at

individual developers into systems capable of managing developments by
large teams operating at multiple sites around the world.
! !158
The variety of tools offered means that you can be sure to find one that
is a close match to your individual needs.
The key capabilities of CM tools are the identification and control of

software and software-related components as they change over time.
For most users, the main issue is the tool's ability to support a project
team that develops software in a single repository, even though the
individual members of the team may be at different locations connected
by a network.
Individual members of the team need to be able to undertake the tasks

assigned to them without interference from other team members.
However, as each task is completed, the results need to be made

available to other team members to assimilate into their own work at a
time of their choosing.
Version control, the original CM requirement, maintains a history of the

changes to a component as it evolves over time and allows users access
to a particular versionnot just the last version created.
CONFIGURATION management features address the issues of problem

tracking and change control and the presentation and analysis of
management information derived from these sources.
Gathering management information is greatly simplified if change

features are part of the CM systemwithout them, complex cross-
references between different databases are required, and full navigation
and searching may not be possible.
Many users, particularly those seeking an external quality approval such

as ISO 9000 or a particular Software Engineering Institute Capability
Maturity Model level, have standard development processes they expect
their development teams to follow. In the past, this has often involved
considerable bureaucratic paperwork procedures, which are generally
resented and ignored by developers.
For software & other softcopy of documents & emails there are software
b a s e d t o o l s a va i l a b l e f o r i m p l e m e n t i n g . C O N F I G U R A T I O N
MANAGEMENT
! !159
1. What do you understand by Configuration management?
2. What is the need of Configuration management?
! !160
REFERENCE MATERIAL
chapter
Summary
PPT
MCQ
! !161
PROJECT CLOSEOUT
Chapter 8
PROJECT CLOSEOUT
Objectives:
Project Closeouts
Post project review
Structure:
8.1 Project Closeouts

8.2 Post Project Review
8.3 Project Lessons Learned Process
8.4 Summary
! !162
PROJECT CLOSEOUT
8.1 Project Closeout
A project is not complete until is formerly and mutually agreed to be closed

by both the developer as well as the client.
Project Closeout is therefore the final but not the least important step in
any project be it in IT or otherwise.
Most projects suffer from the 90% complete syndrome. That tail end of
the project drags so much that it is often a cause of dissatisfaction and
even legal battles between a client and the project vendor.
A formal Closeout process ensures:
A common understanding about the status of the project.

Specific issues to be resolved and the responsibility for the same.
Balancing out of expectations between client and vendor.
Clarity of hand-offs so that the client gets prepared to take on the
operational responsibility for the delivered work products.
Clarity on Commercial issues Billing, payments and other contractual
obligations.
The Closeout process need not be completed in a single meeting. It

however creates enough base for the project to be closed over a defined
period once all the issues identified during the initial close out meetings are
resolved by either side.
Close out may involve a very in depth review of the project with reference
to the contract and with reference to the various specification documents
which may have evolved over time.
The success of the project manager depends upon his ability to close out
the project. This depends upon several factors:
The success of the work product when delivered to the client this success
refers to flawless working of the given functionality as well as the ability
of the solution to meet the stated purpose. Many a time if the solution
! !163
PROJECT CLOSEOUT
meets the main purpose the client does not nit-pick on smaller
requirements which may have been missed out.
The Documents related to handing over of products, sign-off after

acceptance tests etc. are very key documents and need to be organized
before the close out process begins.
The managing of expectations at all levels within the client organization.

People who are likely to be negatively affected by the implementation of
a new system are in particular need to be handled carefully. Even a trivial
looking operator of the new system should feel satisfied about the
functional and usability aspects of the software.
Expectations are created through out the project. Each person from the
vendor side who visits the client for any purpose knowingly and
unknowingly creates expectations in the mind of individual users in the
client organization. These tend to burst out during the initial Close Out
meetings. It is therefore important to ensure that there is a proper
debriefing after each such visit by a person so as to grasp any source of
expectation which he/she may have created. Such expectations if
unrealistic must be terminated by discussing about the
miscommunication on part of the engineer who made such commitment.
If the commitments are valid they need to planned and tracked through
the project. If such commitments need any commercial approval the
same should be taken so as to avoid conflicts at the closeout stage

The trust level created, which the Project Manager has reached with
Senior Management at the Clients End. This trust level gets created,
throughout the project lifecycle. Consistency in meeting commitments,
transparency in dealing, timely support to client etc are a few among
several factors which help in building this trust level. Once this trust
exists, clients tend to overlook minor shortcomings or minor
functionalities which may been missed out
Contractual Obligations Delivery by definition must be complete in all

respects. This would include not just the delivery of the required software
solution but also other aspects such as Back up copies of the software,
Documentation (system & user level), Training, copies of tools and other
libraries and Intelle-ctual Property which may been taken from the client
for the purpose of the project.
! !164
PROJECT CLOSEOUT
Contractual Obligations may also involve post delivery support whether

paid separately or included in the contract value.
Tracking and billing of change requests is another aspect. It is important

that all relevant documentation about the baseline specification as well
as the changes, the approval notes for the same and the commercial
implications be kept together in readiness before launching the closeout
process.
Above all the Project Managers ability to negotiate a win-win type closure
largely depends upon his preparedness, inherent delivery and personal
competencies to do so.
Project Closure is usually of 2 types:
Technical Closure
Administrative Closure
Technical Closure deals with the delivery of the product vis--vis

specifications.
Administrative closure deals with issues which go beyond the technical

closure such as the commercial issues, Intellectual property issues,
mutually acceptable plan for pull out people and equipment from the
project etc.
Once the technical signoffs are done, the administrative closure can be
done. Unfortunately many a time getting users to accept that the software
meets the stated purpose is difficult. When this happens people tend to
focus on specifications which are fraught with inherent problems of
misinterpretation leading to disputes.
The Project Manager has a difficult task at this stage while he/she has
put in 100% of the planned effort he may have just collected 50% of the
money. The balance would be available to him/her only if the user accepts
the delivery. He/she therefore has to be persuasive at the same time
realistic and accept last minute changes and suggestions. While doing so
he/she must ensure that he/she does not let the project into a vicious
cycle.
! !165
PROJECT CLOSEOUT
Project Close-Out
Project Close Out Process
! !166
PROJECT CLOSEOUT
8.2 Post Project Review
While the project may have been closed from the client side, it is a good
practice not to close the project from a vendor side till such time a post
project review is not conducted. The post project review is a final review of
the project aimed at understanding what went right and what went wrong
in the project. The purpose is to capture learnings so that they can be
passed on to other project groups and to other similar projects.
There is no fixed agenda; however the Post project review must look at as
many aspects as possible from which learning can be derived.
The post project review should also include a formal handing over of all the
documentation and software and other equipment to the appropriate
operations/service teams in the company.
Only when this happens the project can be formally closed within the
company and the project team may be disbanded.
Activity A:
1. Use the Internet & browse Microsoft Office online site to collect
information on Project Closeouts.
Activity B:
2. Use an Internet Search engine to collect information on Post project

review.
! !167
PROJECT CLOSEOUT
8.3 Project Lessons Learned Process
Project Lessons Learned Process
! !168
PROJECT CLOSEOUT
8.4 Summary
This Chapter deals with Project closeouts
The project is not complete until formerly & mutually agreed to be closed
by both developer as well as client.
The close out process may involve high depth of review with reference to
contract conditions.
Information required in a Project Closure Report include:

Final updated Project Status Report showing the original project
plan and the actual project performance at completion- tasks,
schedules, resources, etc.
Description of the final products/services delivered by the project.
Lessons learned from the project - technical, business process,
management, etc. What worked well and what didn't. Things that
will be of value on future projects and things to avoid
Specific feedback to/from any of the constituencies involved with
the project.
Pointers to further documentation - project history, user
documentation, system documentation, etc.
Post Implementation Review: Following the closure of any project, you

should always review its overall success by undertaking a Post
Implementation Review. This review helps you to determine whether the
project delivered the business benefits, met the customers requirements
and remained within scope and budget
It will also help you determine whether the project conformed to the
management processes identified, such as Change Management and
Quality Management. This comprehensive template will help you
undertake a Post Implementation Review quickly and efficiently
Formal project closure ensures that your team has met its objectives,
satisfied the customer, captured important knowledge, and been
rewarded for their efforts. With the door closed securely behind you, you
can move on to your next project with confidence
! !169
PROJECT CLOSEOUT
1. What type of Information is required in a Project Closure Report?
2. What do you understand by Post Implementation Review?
! !170
PROJECT CLOSEOUT
REFERENCE MATERIAL
chapter
Summary
PPT
MCQ
Video Lecture
! !171
BIBLIOGRAPHY AND OTHER RESOURCES
BIBLIOGRAPHY AND OTHER RESOURCES
1. Project Management Book of Knowledge PMBok Published by the

Project Management Institute. Check the PMI or PMI-India websites.
2. Software Project Management by Bob Hughes and Mike Cottterel.
3. International Function Point Users Group IFPUG check the website

for the function point computation manual and other papers on function
point.
4. Earned Value Method Covered in PMBok (Project Management Book of

Knowledge) check for EVA as a keyword.
5. Prince 2 This is structured method of managing projects developed by

the UK Government. Similar to PMI but has several key differences. This
for additional reading for those interested in doing business in the UK
and EU markets.
! !172

MANAGING PROJECTS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MANAGING PROJECTS

Uploaded by

Copyright:

Available Formats

MANAGING IT PROJECTS

Chapter No. Chapter Name Page No.

1 Projects Overview and Basic Concepts and 3-35

2 The PMI Framework 36-56

3 Software Project Lifecycle 57-76

4 Project Planning and Scheduling 77-117

5 Project Risk Management 118-135

6 Project Tracking 136-150

7 Configuration Management 151-161

8 Project Closeout 162-171

The Objectives of this lesson are to give you an insight into:

What is a project & Why learn project management?

1.1 What is a Project and Why Learn Project Management.

1.1 What is a Project and Why Learn Project Management?

In personal life as well as Corporate life we are frequently engaged in

In the organizational context every person is increasingly being involved in

A project is a temporary endeavour undertaken to achieve something

A project is, therefore, always characterized by one or more of the

It is a One time and non-repetitive activity

Even where it is repetitiveeach product/service delivered is very large in

There is something which is unique about it which means that each

A project has a single objective that must be accomplished through the

Projects are completed through the deployment of resources.

While we learn management in general and also understand the nuances of

Construction of Ships, Aircraft or Space Craft.

From the foregoing, it would be obvious that we would come across

What is project management?

Managing a project includes:

Identifying the requirements.

Establishing clear and achievable objectives.

1.2 Why do Projects Fail?

It is common knowledge that many projects seem to fail in some ways. A

Fail to achieve some or all aspects of its basic purpose.

In the field of Information Technology, project failures are very common.

In several surveys of projects in various domains, it has been found that

Unclear Project Goals.

As project Managers we must, therefore, attempt to overcome the above

Some of the important concepts related to Project Management are:

Project Charter Project Purpose and Goals.

Work Break Down Structure and Task List.

In the subsequent sections we shall study about each of these separately.

1.3 Project Life Cycle

As we have seen in the examples given above, projects could be of

For instance, a software development company should understand the

These series of steps provide the sequence of tasks necessary to complete

software could be different from developing software for an embedded

It is therefore necessary that:

We understand the Project Lifecycle for the Business Domain

Select an Appropriate Project Lifecycle within that Domain which best

Before we proceed, let us understand the nature of software projects.

1.4 The Peculiar Nature of Software Projects

Software unlike many other domains is an area which is very nebulous. It

It is difficult to define very definitively.

It is difficult to test it completely.

Estimation of complexity, effort and time is another grey area in the IT

Add to this, the company specific requirement such as maintaining stock of

Other factors such as:

User experience with technology.

Geographical spread of the organization.

All these factors add to the complexity of the IT project.

Software Design is also subject to ambiguity. For any given requirement, a

Technology itself creates a myriad of options. Client server applications

Features, complexity, effort vary greatly with technology, making it difficult